GOF23种设计模式
设计模式主要分三个类型:创建型、结构型和行为型。
创建型
- Singleton,单例模式:保证一个类只有一个实例,并提供一个访问它的全局访问点
- Abstract Factory,抽象工厂:提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们的具体类。
- Factory Method,工厂方法:定义一个用于创建对象的接口,让子类决定实例化哪一个类,Factory Method使一个类的实例化延迟到了子类。
- Builder,建造模式:将一个复杂对象的构建与他的表示相分离,使得同样的构建过程可以创建不同的表示。
- Prototype,原型模式:用原型实例指定创建对象的种类,并且通过拷贝这些原型来创建新的对象。
行为型
- Iterator,迭代器模式:提供一个方法顺序访问一个聚合对象的各个元素,而又不需要暴露该对象的内部表示。
- Observer,观察者模式:定义对象间一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知自动更新。
- Template Method,模板方法:定义一个操作中的算法的骨架,而将一些步骤延迟到子类中,TemplateMethod使得子类可以不改变一个算法的结构即可以重定义该算法得某些特定步骤。
- Command,命令模式:将一个请求封装为一个对象,从而使你可以用不同的请求对客户进行参数化,对请求排队和记录请求日志,以及支持可撤销的操作。
- State,状态模式:允许对象在其内部状态改变时改变他的行为。对象看起来似乎改变了他的类。
- Strategy,策略模式:定义一系列的算法,把他们一个个封装起来,并使他们可以互相替换,本模式使得算法可以独立于使用它们的客户。
- China of Responsibility,职责链模式:使多个对象都有机会处理请求,从而避免请求的送发者和接收者之间的耦合关系
- Mediator,中介者模式:用一个中介对象封装一些列的对象交互。
- Visitor,访问者模式:表示一个作用于某对象结构中的各元素的操作,它使你可以在不改变各元素类的前提下定义作用于这个元素的新操作。
- Interpreter,解释器模式:给定一个语言,定义他的文法的一个表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子
- Memento,备忘录模式:在不破坏对象的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。
结构型
- Composite,组合模式:将对象组合成树形结构以表示部分整体的关系,Composite使得用户对单个对象和组合对象的使用具有一致性。
- Facade,外观模式:为子系统中的一组接口提供一致的界面,fa?ade提供了一高层接口,这个接口使得子系统更容易使用。
- Proxy,代理模式:为其他对象提供一种代理以控制对这个对象的访问
- Adapter,适配器模式:将一类的接口转换成客户希望的另外一个接口,Adapter模式使得原本由于接口不兼容而不能一起工作那些类可以一起工作。
- Decrator,装饰模式:动态地给一个对象增加一些额外的职责,就增加的功能来说,Decorator模式相比生成子类更加灵活。
- Bridge,桥模式:将抽象部分与它的实现部分相分离,使他们可以独立的变化。
- Flyweight,享元模式
一、工厂模式
1.1、简单工厂模式(静态工厂模式)
“当你需要某个对象的时候,通常你是new出来的,但是这样代码耦合度太高,因此我们通过一个工厂来生产出来这个对象”
- 工厂:负责实现创建所有实例的内部逻辑,并且提供一个外界调用的方法,创建所需产品对象
- 抽象产品:用来描述产品的公共接口
- 具体产品:描述生产的具体产品
1 | /** |
优点:将创建使用工作分开,不必关心类对象如何创建,实现了解耦;
缺点:违背“开放 - 关闭原则”,一旦添加新产品就不得不修改工厂类的逻辑,这样就会造成工厂逻辑过于复杂。
1.2、工厂方法模式(工厂模式)
可以理解成将上述的静态工厂模式中的工厂进行拆分,让对应的实例产品都有一个单独的工厂对其进行生产。
1 | /** |
工厂:Factory.java、FactoryA.java 、FactoryB.java
1 | /** |
测试:Test.java
1 | public class Test { |
一个抽象产品类,可以派生出多个具体产品类。一个抽象工厂类,可以派生出多个具体工厂类。每个具体工厂类只能创建一个具体产品类的实例。
优点:
- 符合开-闭原则:新增一种产品时,只需要增加相应的具体产品类和相应的工厂子类即可
- 符合单一职责原则:每个具体工厂类只负责创建对应的产品
缺点:
- 增加了系统的复杂度:类的个数将成对增加
- 增加了系统的抽象性和理解难度
- 一个具体工厂只能创建一种具体产品
1.3、抽象工厂模式
为了解决工厂模式中一个工厂只能生产一个具体产品的问题。抽象工厂模式使用抽象类添加了抽象工厂,然后让具体工厂继承该抽象工厂达到一个具体工厂可以生产多种具体产品的效果。
抽象工厂:描述具体工厂的公共接口
具体工厂:描述具体工厂,创建产品的实例,供外界调用
抽象产品族:描述抽象产品的公共接口
抽象产品:描述具体产品的公共接口
具体产品:具体产品
1 | /** |
工厂:Factory.java、FactoryA.java
1 | /** |
测试:Test.java
1 | public class Test { |
多个抽象产品类,每个抽象产品类可以派生出多个具体产品类。一个抽象工厂类,可以派生出多个具体工厂类。 每个具体工厂类可以创建多个具体产品类的实例。.
优点:
- 降低耦合
- 符合开-闭原则
- 符合单一职责原则
- 不使用静态工厂方法,可以形成基于继承的等级结构。
缺点:难以扩展新种类产品
二、单例模式(singleton)
确保一个类只有一个实例,并提供该实例的全局访问点。
单例的实现主要是通过以下两个步骤:
- 将该类的构造方法定义为私有方法,这样其他处的代码就无法通过调用该类的构造方法来实例化该类的对象,只有通过该类提供的静态方法来得到该类的唯一实例;
- 在该类内提供一个静态方法,当我们调用这个方法时,如果类持有的引用不为空就返回这个引用,如果类保持的引用为空就创建该类的实例并将实例的引用赋予该类保持的引用。
1、单例模式的应用场景和优缺点
举一个小例子,在我们的windows桌面上,我们打开了一个回收站,当我们试图再次打开一个新的回收站时,Windows系统并不会为你弹出一个新的回收站窗口。,也就是说在整个系统运行的过程中,系统只维护一个回收站的实例。这就是一个典型的单例模式运用。
继续说回收站,我们在实际使用中并不存在需要同时打开两个回收站窗口的必要性。假如我每次创建回收站时都需要消耗大量的资源,而每个回收站之间资源是共享的,那么在没有必要多次重复创建该实例的情况下,创建了多个实例,这样做就会给系统造成不必要的负担,造成资源浪费。
适用场景:
- 1.需要生成唯一序列的环境
- 2.需要频繁实例化然后销毁的对象。
- 3.创建对象时耗时过多或者耗资源过多,但又经常用到的对象。
- 4.方便资源相互通信的环境
常见应用场景:
- Windows的Task Manager(任务管理器)
- windows的Recycle Bin(回收站)也是典型的单例应用
- 应用程序的日志应用,一般都何用单例模式实现,这一般是由于共享的日志文件一直处于打开状态,因为只能有一个实例去操作 ,否则内容不好追加。
- 数据库连接池的设计一般也是采用单例模式,因为数据库连接是一种数据库资源
- 操作系统的文件系统,也是大的单例模式实现的具体例子,一个操作系统只能有一个文件系统
- Application 也是单例的典型应用(Servlet编程中会涉及到)
- 在Spring中,每个Bean默认就是单例的,这样做的优点是Spring容器可以管理
- 在servlet编程中,每个Servlet也是单例
- 在spring MVC框架/struts1框架中,控制器对象也是单例
优点:
- 在内存中只有一个对象,节省内存空间;
- 避免频繁的创建销毁对象,可以提高性能;
- 避免对共享资源的多重占用,简化访问;
- 为整个系统提供一个全局访问点。
缺点:
- 不适用于变化频繁的对象;
- 滥用单例将带来一些负面问题,如为了节省资源将数据库连接池对象设计为的单例类,可能会导致共享连接池对象的程序过多而出现连接池溢出;
- 如果实例化的对象长时间不被利用,系统会认为该对象是垃圾而被回收,这可能会导致对象状态的丢失;
单例模式的要点有三个:一是某个类只能有一个实例;二是它必须自行创建这个实例;三是它必须自行向整个系统提供这个实例。单例模式是一种对象创建型模式。单例模式又名单件模式或单态模式。
单例模式的实现代码如下所示:
1 | public class Singleton |
在单例模式的实现过程中,需要注意如下三点:
• 单例类的构造函数为私有;
• 提供一个自身的静态私有成员变量;
• 提供一个公有的静态工厂方法。
2、饿汉式——线程安全、调用效率高、无法延时加载
类加载的方式是按需加载,且加载一次。。因此,在上述单例类被加载时,就会实例化一个对象并交给自己的引用,供系统使用;而且,由于这个类在整个生命周期中只会被加载一次,因此只会创建一个实例,即能够充分保证单例。
1 | // 饿汉式单例 |
优点:这种写法比较简单,就是在类装载的时候就完成实例化。避免了线程同步问题。
缺点:在类装载的时候就完成实例化,没有达到Lazy Loading的效果。如果从始至终从未使用过这个实例,则会造成内存的浪费。
3、懒汉式——线程安全、调用效率低、延时加载
单例实例被延迟加载,即只有在真正使用的时候才会实例化一个对象并交给自己的引用。
1 | // 懒汉式单例 |
优点:单例只有在使用时才会被实例化,在一定程度上节约了资源
缺点:第一次加载时需要及时进行实例化,反应稍慢,最大的问题是每次调用getInstance都进行同步,造成不必要的同步开销。这种模式一般不建议使用。
4、双重加锁机制(Double Check Lock)——线程安全
Double-Check概念对于多线程开发者来说不会陌生,如代码中所示,我们进行了两次if (singleton == null)检查,这样就可以保证线程安全了。这样,实例化代码只用执行一次,后面再次访问时,判断if (singleton == null),直接return实例化对象。
使用双重检测同步延迟加载去创建单例的做法是一个非常优秀的做法,其不但保证了单例,而且切实提高了程序运行效率
1 | public class Singleton |
1 | public class Singleton |
第一次 if (instance == null)主要是为了避免不必要的同步,第二次的判断是为了在null的情况下创建实例。
优点:既能够在需要时才初始化单例,又能够保证线程安全,且单例对象初始化后调用getInstance不进行同步锁。
资源利用率高,第一次执行getInstance时单例对象才会被实例化,效率高。
缺点:第一次加载慢
5、静态初始化
1 | //阻止发生派生,而派生可能会增加实例 |
6、静态内部类
解决DCL在某些情况下出现失效的问题
1 | public class Singleton{ |
当第一次加载singleton类时并不会初始化sInstance,只有在第一次调用Singleton的getInstance方法时才会导致sInstance被初始化。
第一次调用getInstance方法会导致虚拟机加载SingletonHolder类,这种方式不仅能够确保线程安全,也可以确保单例对象的唯一性,同时也延迟了单例的实例化。推荐。
7、枚举单例
1 | public enum SingletonEnum{ |
8、使用容器实现
1 | public class SingletonManager{ |
在程序的初始时,可以将多种单例类型注入到一个统一的管理类中,在使用时根据key获取对象对应类型的对象。
优点:可以管理多种类型的单例,并且在使用时可以通过统一的接口进行获取操作,降低用户的使用成本,降低耦合度。
要想实现效率高的线程安全的单例,我们必须注意以下两点:
- 尽量减少同步块的作用域;
- 尽量使用细粒度的锁。