程序设计模式有哪些（常用的设计模式汇总）

单例模式：

即一个应用程序中，某个类的实例对象只有一个，你没有办法去new，因为构造器是被private修饰的，一般通过其get方法获取到他们的实例。

懒汉写法（线程不安全）

懒汉式写法（线程安全）

饿汉式写法

静态内部类

枚举

这种方式是Effective Java作者Josh Bloch 提倡的方式，它不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象，可谓是很坚强的壁垒啊，不过，个人认为由于1.5中才加入enum特性，用这种方式写不免让人感觉生疏。

双重校验锁

实际应用场景：

观察者模式：

对象间一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

给你举个栗子：假设有三个人，小美（女，22），小王和小李。小美很漂亮，小王和小李是两个程序猿，时刻关注着小美的一举一动。有一天，小美说了一句：“谁来陪我打游戏啊。”

这句话被小王和小李听到了，结果乐坏了，蹭蹭蹭，没一会儿，小王就冲到小美家门口了，在这里，小美是被观察者，小王和小李是观察者，被观察者发出一条信息，然后观察者们进行相应的处理，看代码：

这个接口相当于小王和小李的电话号码，小美发送通知的时候就会拨打getMessage这个电话，拨打电话就是调用接口，看不懂没关系，先往下看

代码很简单，我们再看看小美的代码：

我们写一个测试类来看一下结果对不对

实际应用场景：

场景描述：

以购票为核心业务(此模式不限于该业务)，但围绕购票会产生不同的其他逻辑，如：

• 购票后记录文本日志

• 购票后记录数据库日志

• 购票后发送短信

• 购票送抵扣卷、兑换卷、积分
  -其他各类活动等

传统解决方案:

在购票逻辑等类内部增加相关代码，完成各种逻辑。

存在问题：

1、一旦某个业务逻辑发生改变，如购票业务中增加其他业务逻辑，需要修改购票核心文件、甚至购票流程。

2、日积月累后，文件冗长，导致后续维护困难。

存在问题原因主要是程序的"紧密耦合"，使用观察模式将目前的业务逻辑优化成"松耦合"，达到易维护、易修改的目的，同时也符合面向接口编程的思想。

观察者模式典型实现方式：

• 定义2个接口：观察者（通知）接口、被观察者（主题）接口

• 定义2个类，观察者对象实现观察者接口、主题类实现被观者接口

• 主题类注册自己需要通知的观察者

• 主题类某个业务逻辑发生时通知观察者对象，每个观察者执行自己的业务逻辑。

装饰者模式

对已有的业务逻辑进一步的封装，使其增加额外的功能，如Java中的IO流就使用了装饰者模式，用户在使用的时候，可以任意组装，达到自己想要的效果。

举个栗子，我想吃三明治，首先我需要一根大大的香肠，我喜欢吃奶油，在香肠上面加一点奶油，再放一点蔬菜，最后再用两片面包夹一下，很丰盛的一顿午饭，营养又健康。那我们应该怎么来写代码呢？首先，我们需要写一个Food类，让其他所有食物都来继承这个类，看代码：

代码很简单，我就不解释了，然后我们写几个子类继承它：

这几个类都是差不多的，构造方法传入一个Food类型的参数，然后在make方法中加入一些自己的逻辑，如果你还是看不懂为什么这么写，不急，你看看我的Test类是怎么写的，一看你就明白了

看到没有，一层一层封装，我们从里往外看：最里面我new了一个香肠，在香肠的外面我包裹了一层奶油，在奶油的外面我又加了一层蔬菜，最外面我放的是面包，是不是很形象，哈哈~ 这个设计模式简直跟现实生活中一摸一样，看懂了吗？

实际应用场景：

如上述一样，不同的人，选择的搭配不同，对应价格也不相同，若是应用传统方式你会发现这里四种配料就要写十几种实现类了，那如果我们的配料是二十几种或者三十几种呢，那么使用继承这种 方式肯定会使我们的子类爆炸。

通过不同的组合以Food food = new Bread(new Vegetable(new Cream(new Food("香肠"