Earth Guardian

You are not LATE!You are not EARLY!

0%

设计模式总结

设计模式总结。

模式分类

初步分类

0071-design-patterns-classify.png

细分

0071-design-patterns-classify-2.png

创建型模式

创建型模式对类的实例化过程进行了抽象,能够将软件模块中对象的创建和对象的使用分离。为了使软件的结构更加清晰,外界对于这些对象只需要知道它们共同的接口,而不清楚其具体的实现细节,使整个系统的设计更加符合单一职责原则。
创建型模式在创建什么,由谁创建,何时创建等方面都为软件设计者提供了尽可能大的灵活性。创建型模式隐藏了类的实例的创建细节,通过隐藏对象如何被创建和组合在一起达到使整个系统独立的目的。

建造者模式

建造者模式 Builder Pattern将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示
通俗点讲:建造者模式类似同一条生产线,生产过程可以一样,但是放入的材料不一样生产出来的产品就不一样,比如放入纸就生产出纸碗,放入铁就生产出铁腕。又如个人电脑组装,组装步骤和顺序差不多,但是使用的显示器,显卡,内存,硬盘,操作系统都可以不一样,虽然最终都是组装出来电脑,但是配置完全不一样。

  • 标准建造者模式类图

0044-Builder-standard-class.png

  • 常用简化版模式类图

0044-SimpleBuilder-class.png

工厂方法模式

工厂方法模式 Factory Method Pattern定义一个用于创建对象的接口,让子类决定实现哪一个类。工厂方法使一个类的实例化延迟到其子类
用来生产同一等级结构中的固定产品。支持增加产品,只需增加对应的工厂实现类。

0049-FactoryMethod-uml-classdiag.png

抽象工厂模式

抽象工厂模式 Abstract Factory Pattern提供一个创建一系列相关或相互依赖对象的接口,而无需指定他们具体的类
用来生产不同配置的产品族,比如组装一台电脑,一辆车,他们通常由固定数量的零部件组成,但是每个零部件都会有多种配置。支持增加产品族,只需增加具体的工厂实现类,配置不同的产品类型。但是不支持增加产品,会修改抽象工厂及所有工厂实现类

0049-AbstractFactory-uml-classdiag.png

原型模式

原型模式 Prototype['protəˌtaɪp] Pattern用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新对象
原型模式就是指 Clone 技术,以某个对象为原型,复制出一个新的对象。既然是 Clone 就会涉及到对象的深浅拷贝:

  • 浅拷贝 shallow copy
    浅拷贝在拷贝对象时,并不会拷贝对象里的引用对象,也就是说不拷贝该对象的属性。
  • 深拷贝 deep copy
    深拷贝在拷贝对象时,需要手动代码实现对引用对象的拷贝,也就是把该对象的所有属性也克隆出一份新的。

0050-Prototype-uml-classdiag.png

Java 中,原型模式的 Prototype 抽象类并不需要我们定义,Cloneable 接口实现了这个功能。在使用原型模式时,必须实现 Cloneable 接口,否则会抛出 CloneNotSupportedException 异常。并且 Object.clone 这个方法是直接从堆内存中以二进制流拷贝的,所以产生新对象时并不会调用类的构造方法

单例模式

单例模式 Singleton Pattern保证一个类只产生唯一的一个实例,并提供一个访问它的全局访问点
单例模式一般用于某个类有且仅有一个对象,避免产生多个对象消耗过多资源,或者访问 IO 或数据库等资源时。单例模式的特点:

  • 构造函数为 private
  • 通过静态方法或者枚举返回单例类对象
  • 确保单例类对象有且仅有一个,特别是多线程场景
  • 单例类在反序列化时不会重构对象

单例模式在多线程中,有多种实现方式,常见有:饿汉模式,懒汉模式,经典双检锁,枚举实现等。从多线程角度来看,单元素枚举是实现单例模式最佳方法。详细分析参考:Java 多线程并发:单例模式多线程

0051-Singleton-uml-classdiag.png

结构型模式

结构型模式总共有七种,简写为:ABCDFFP(Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy),也就是对应的的适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式。
结构型模式主要用于描述如何组合类和对象以获得更大的结构。其中,结构型类模式采用继承机制来组合接口和实现,而结构型对象模式则采用组合/聚合方式来组合对象以实现新功能,因为它可以在运行时刻改变对象组合关系,所以对象组合方式具有更大的灵活性。结构型模式体现了优先使用对象组合,而不是类继承的原则。

适配器模式

适配器模式 Adapter Pattern将类的接口转换成客户希望的接口,使得原本由于接口不兼容的类可以一起工作
适配器模式使得接口不兼容的两个类能在一起工作,通俗易懂的例子就是电源适配器。但是 Java 不支持多重继承,也就是每次只能适配一个类。

0052-Adapter-uml-classdiag.png

桥接模式

桥接模式 Bridge Pattern:**将抽象和其实现分离,具体的子类使用不同的方式去实现,从而可以独立的改变它们,体现了组合重用原则。实现独立出来各自变化,每次变化不会影响其他实现 **。
通俗的解释:实现系统可能有多角度的分类,每一种分类都有可能变化,那么就把这种多角度分离出来让他们独立变化,减少他们之间的耦合。任何多维度变化类或者多个树状类,都可以通过桥接模式解耦。桥接模式的桥梁作用也是连接“抽象部分”和“实现部分”;或者是将不同角度的分类连接起来。比如咖啡从容量上可以分为大杯,小杯;从味道上可以分为甜,不甜等等。
桥接模式最大的特点是将抽象部分与它的实现部分分离,使它们都可以独立地变化,也就是两种维度可以独自扩展。

0053-Bridge-uml-classdiag.png

组合模式

组合模式 Composite Pattern将对象组合成树形结构以表示“部分-整体”的层次结构,组合模式使得用户对单个对象和组合对象的使用具有一致性
通常用于可以使用树状结构描述的场景,比如:公司的组织结构图,操作系统中的文件系统,常见的 UI 框架 View/ViewGroup 等等。根据 Composite 中定义的方法,可以分为:

  • 安全组合模式
    Component 中并没有将管理子对象抽象出来,也就是不包含 add/remove 等,但是这会导致子对象和组合对象接口不一致。Android View/ViewGroup 就属于安全组合模式。

0054-Composite_typesafety-uml-classdiag.png

  • 透明组合模式
    Component 中将管理子对象抽象到基类中,使得子对象和组合对象具有完全一致的行为接口,但是叶子类实际上并不需要这些管理行为。

0054-Composite_uniformity-uml-classdiag.png

从两个类图中可以看出,组合模式符合开闭原则:增加叶子或树干并不需要修改类库,在客户端就可以实现。但是违反了依赖倒置原则:叶子节点和组合类都是实现类,而不是抽象类。

装饰模式

装饰模式 Decorator[ˈdɛkəˌretɚ] Pattern动态地给一个对象添加一些额外的职责,就增加功能来说,装饰模式比直接修改子类更加灵活
装饰模式也称为包装模式 Wrapper Pattern,常见于给某个对象添加功能而不是整个类。装饰模式可以修改对象的功能,而不用修改子类代码。代码中如果看到 Wrapper 结尾的类,通常是用了装饰模式的设计思路。
装饰模式通常用于动态和透明的扩展类的功能,特别是当系统维护中需要添加新功能,而这个功能是需要向旧类中添加新代码,而这个功能并不是旧类的主要职责或者核心功能。在这种场景下,使用装饰模式添加一个装饰类,在不破坏原有代码的基础上,动态的给对象添加或修改功能。

0055-Decorator-uml-classdiag.png

外观模式

外观模式 Facade [fəˈsɑːd] Pattern为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用
外观模式描述如何用单个对象表示整个子系统。为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口。体现了依赖倒转原则,典型场景: MVC 架构、基金对股票的封装等。

0056-Facade-uml-classdiag.png

享元模式

享元模式 Flyweight Pattern运用共享技术有效的支持大量细粒度的对象
享元模式将对象划分为内部状态和外部状态,共享内部状态,通过共享池来减少对象的一种模式。

  • 内部状态
    享元对象内部不会随环境改变而改变的共享部分,称为享元对象的内部状态。也就是说,内部状态是不变的部分。
  • 外部状态
    受环境影响改变,不可共享的部分,称为享元对象的外部状态。也就是说,外部状态是变化的。

比如一堆衣服中有男女两个款式,如果需要请模特过来拍照展示,其中性别是无法改变的部分,即内部状态;而衣服款式是多变不一样的,所以款式是外部状态。在这个例子中,通过创建共享池共享性别对象。

0057-Flyweight-uml-classdiag.png

享元模式主要使用了缓存来减少创建重复对象,能大大降低内存占用率。

代理模式

代理模式 Proxy[ˈprɑ:ksi] Pattern为其他对象提供一种代理以控制对这个对象的访问
代理模式也称为委托模式,控制对象使得只有确实需要这个对象时才创建和初始化。代理分为:静态代理和动态代理。静态代理:编译前所有的代码已经存在。动态代理:通过反射机制动态地生成代理对象,也就是代码编译中并不知道代理关系,动态代理将代理和被代理对象进行了解耦。另外,常见代理功能:

  • 远程代理 Remote Proxy
    常见于 C/S 模式,为某个对象在不同的内存地址空间提供局部代理,使系统可以将 Server 部分实现隐藏,Client 像使用本地对象一样使用 Server
  • 虚拟代理 Virtural Proxy
    使用一个代理对象表示一个十分耗资源的对象,并在真正需要时才创建。比如图片代理:对大图浏览的控制,用户通过浏览器访问网页时先不加载真实的大图,而是通过代理对象的方法来进行处理,在代理对象的方法中,先使用一个线程向客户端浏览器加载一个小图片,然后在后台使用另一个线程来调用大图片的加载方法将大图片加载到客户端。
  • 保护代理 Protection Proxy
    使用代理控制对原始对象的访问,这种模式常见于原始对象有不同的访问权限。

0058-Proxy-uml-classdiag.png

在代理模式中,要求给某一个对象提供一个代理,并由代理对象控制对原对象的引用。

行为型模式

解释器模式

解释器模式 Interpreter[ɪnˈtɜ:rprɪtə] Pattern给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子
解释器模式主要用来按指定规则解析一串语句,如:解析歌谱,XML,算术运算,逆波兰表达式,机器人动作指令等等。

0060-Interpreter-uml-classdiag.png

模板方法模式

模板方法模式 Template Pattern定义一个操作中的算法的框架,而将详细的步骤延迟到子类中。模板方法使得子类可以不改变算法的结构下重新定义算法的步骤
一个算法可以明确分割为几个关键步骤,这几个步骤的顺序是固定的,但是每个步骤的实现会随环境的改变而变化,对于这类问题常用模板方法来解决。

0061-TemplateMethod-uml-classdiag.png

模板方法模式是把不变行为搬移到父类,去除子类的重复代码,帮助子类摆脱重复不变行为的纠缠。常见使用场景:

  • 子类有共有方法,并且逻辑基本相同
  • 用于代码重构,将公共方法抽取到父类中

Android 中,Activity/Fragmengt 等的生命周期是标准的模板方法,以及 AsyncTask 的执行步骤 onPreExecute --> doInBackgroud --> onPostExecute 等这些都是模板方法的体现。

责任链模式

责任链模式 Chain of Responsibility[rɪˌspɑ:nsəˈbɪləti] Pattern使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系。将多个对象的请求连成一条链,并沿着这条链传递请求,直到有一个对象处理为止,避免请求的发送者和接收者之间耦合
责任链模式避免请求发送者与接收者耦合在一起,让多个对象都有可能接收请求,将这些对象连接成一条链,并且沿着这条链传递请求,直到有对象处理它为止。也常用来替代各种分支和条件判断语句。

0062-ChainOfResonsibility-uml-classdiag.png

命令模式

命令模式 Command Pattern将请求封装为一个对象,从而可以将不同的请求作为参数来传递。对请求排队或记录日志,以及支持可撤销的操作
命令模式类似系统菜单,比如开机、关机、重启、注销等等,这些动作都封装成命令对象,作为参数记录并执行。命令模式可以对发送者和接收者完全解耦,发送者与接收者之间没有直接引用关系,发送请求的对象只需要知道如何发送请求,而不必知道如何完成请求,这就是命令模式的模式动机。

0063-Command-uml-classdiag.png

迭代器模式

迭代器模式 Iterator[ɪtə'reɪtə] Pattern提供一种方法顺序访问一个聚合对象中各个元素,而又不暴露对象内部表示
迭代器模式又称为游标 Cursor 模式,是非常古老的设计模式,主要用于对容器的遍历访问,当前高级面向对象语言基本上默认包含这个模式。

0064-Iterator-uml-classdiag.png

Java 语言已经包含了迭代器接口 Interator,在实际使用中仅仅需要实现 Collection 集合就能应用迭代器模式,其中 List, Map 等等都都是常见迭代器容器。

中介者模式

中介者模式 Mediator[ˈmidiˌetɚ] Pattern用一个中介对象来封装一系列的对象交互。使得各对象不用显式的相互引用,从而使其耦合松散,而且可以独立改变它们之间的交互
中介者模式又称为调停者模式,将多对多的相互作用转换为一对多的相互作用,减少对象间的复杂引用关系,使得成为一个松耦合系统。

0065-Mediator-uml-classdiag.png

中介者模式是迪米特原则的典型应用,体现了如果不需要直接通信的两个类可以使用第三方转发。中介者模式类似电脑的主板协调各个器件工作;系统的各个总线协调驱动程序运行;中介者模式能够将错综复杂的网状图优化成结构清晰的星型图,其中心就是中介者;MVC 架构中的 Control 就是典型的中介者。
所有的 UI 交互系统,如 C#/Form, Android Activity 中的 UI 交互界面,都承担了中介者的角色,它会将 Button, TextView, EditText 等连接起来,这些控件的交互都是通过窗体来中转,响应并显示的。

备忘录模式

备忘录模式 Memento[məˈmentoʊ] Pattern在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。后期可以直接将该对象恢复到原先保存的状态
备忘录模式常用于存档,编辑回退等场景,主要是保存某个对象当前的状态。

0066-Memento-uml-classdiag.png

根据备忘录发起方 Originator 的可见性,可以将备忘录模式分为:

  • 白箱模式
    备忘录完全可见,暴露给其他类,这种是最常见的备忘录模式,如上面的类图。
  • 黑箱模式
    备忘录抽象一个空接口出来,而备忘录则以内部类的形式在 Originator 中实现对应功能,这样外部类在访问的时候,只能拿到空接口。

观察者模式

观察者模式 Observer Pattern定义一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。在主题对象在状态变化时会通知所有观察者对象,使它们自动更新
观察者模式又叫发布/订阅模式 Publish/Subscribe,最常用于 GUI 系统,订阅发布系统。

0067-Observer-uml-classdiag.png

Java 语言规范中已经集成了标准的观察者模式 Observable/Observer,其中 Observable 即为主题或抽象通知者,Observer 为观察者。所以 Java 中实现观察者模式非常简单,主题继承 Observable ,观察者实现 Observer

状态模式

状态模式 State Pattern当对象的内部状态改变时允许改变其行为,该对象看起来像是改变了其类
状态模式主要是解决当控制一个对象状态转移的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类中,可以把复杂的判断逻辑简化。

0068-State-uml-classdiag.png

状态模式是将与特定状态相关的行为局部化,并且将不同状态的行为分割开来。当一个对象的行为取决于它的状态,并且它必须在运行时刻根据状态改变它的行为时,可以使用状态模式。

策略模式

策略模式 Strategy[ˈstrætədʒi] Pattern定义一系列的算法,单独封装并使它们可以相互替换。这一模式可以使算法独立于使用它的客户而变化
策略模式定义一系列算法的方法,从概念上看,所有的这些算法完成的多是相同的工作,只是实现不同,他们可以使用相同的方法来调用算法,减少了类之间的耦合。

0069-Strategy-uml-classdiag.png

访问者模式

访问者模式 Visitor Pattern表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素类的前提下定义于作用于这些元素的新操作
访问者模式把数据处理和数据结构分离。在数据结构相对稳定时,访问者模式使得数据处理的算法修改或增加都变得非常容易。访问者模式使用两次动态单分派来间接实现伪动态双分派。

0070-Visitor-uml-classdiag.png

访问模式中的动态双分派体现在 accept 这个方法上:

  • 第一次动态分派
    ObjectStructure.accept 中遍历执行 Element.accept 时,并不确定接受者具体是哪个 ConcreteVisitor1/ConcreteVisitor2,运行时确定。
  • 第二次动态分派
    Element.accept 中,Visitor 并不确定参数具体是哪个 ConcreteElementA/ConcreteElementB,运行时确定。

组合实现了双分派,只有在运行时才能确定是哪个 Visitor 访问哪个 Element

模式比对

状态模式和责任链模式的异同

策略模式,责任链模式,状态模式,这三种模式常用来替代各种分支和条件判断语句。

  • 相同点
    都能解耦和优化大量的逻辑判断。
  • 不同点
    状态模式每个子类能清楚的直到下个状态是谁或者哪个子类,相当于 if-else 分支判断;而责任链模式并不清楚整个链条中是哪个子类处理的,下个责任人也需要客户端来指定,更灵活,相当于 switch-case 分支判断。
    通俗来讲,状态模式的下一个状态是明确的,固定的;而责任链中下一个处理者并不固定,需要客户端动态指定。

状态模式与策略模式的异同

  • 相同点
    策略模式也是为了消除或者简化条件语句,和责任链模式,状态模式很类似。所以类图结构上看起来几乎没有太大区别。
  • 不同点
    状态模式中各个状态子类都必须知道它的下一个状态是什么,并且逻辑判断都转移到子类中,客户端并不了解状态的转换逻辑。而策略模式中各个子类是并级的,可以相互替换,他们并不存在状态转换的关系。策略模式是针对单一并行算法的替换,客户端需要提前了解各算法差异,并在策略模式中指定一种算法。

策略模式和责任链模式的异同

  • 相同点
    在功能职责上都是用来简化或消除条件判断,客户端在使用时需要提前指定使用哪种策略,或者指定责任链模式中的下一个继任者。
  • 不同点
    两者在类图上有区别,责任链模式需要持有下一个责任人的引用,策略模式多一个上下文类,由上下文类来持有具体的策略。责任链模式存在级差,每个子类拥有不同的责任权限;而策略模式子类都是并级的,客户端在选用时只需要选择一种策略。

代理模式和外观模式

主要区别在于,代理对象代表一个单一对象而外观对象代表一个子系统。代理模式的客户端无法直接访问目标对象,由代理提供对单独的目标对象的访问控制,而外观模式中客户端可以直接访问子系统的各个对象,但通常由外观对象提供对子系统各个功能简化的、共同层次的调用接口。

适配器模式和外观模式

外观模式通常是定义一个新的接口,为现存系统提供一个更为方便的访问接口;而适配器模式往往是适配一个原有的接口,使两个已有的接口协同工作。另外,适配器模式主要是匹配对象的,只匹配一个类,而外观模式匹配的是整个子系统。

装饰模式和桥接模式

0055-decorator-bridge-classdiag-diff.png

类图结构有较大区别,从对比图中可以看出:

  • 结构维度
    桥接模式是不同维度的分类,属于平行结构;装饰模式是继承结构,在继承的基础上修改功能。
  • 是否继承
    桥接模式的两种维度没有继承关系,仅仅是组合关系(松耦合);而装饰模式除了组合还必须是继承关系(紧耦合),也就是 Decorator 继承并组合了 Component
  • 方法名是否一致
    桥接模式仅仅需要组合,所以方法名一般不同;装饰模式因为带有继承关系,所以装饰时重写方法,方法名相同。

装饰模式和代理模式

  • 类图结构基本一致
  • override 重写方法后的侧重点不一样
    装饰器模式关注于在一个对象上动态的添加或修改方法;代理模式关注于控制对对象的访问,对是否执行实现类有决定权。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    // 1. 装饰器模式
    @Override
    public void operation() {
    impl.operation();
    addBehavior();
    }

    // 2. 代理模式
    @Override
    public void operation() {
    if (hasOption()){
    impl.operation();
    } else {
    System.out.println("不符合选项。");
    }
    }

装饰模式和代理模式非常非常像,唯一的区别在与侧重点不一样:装饰模式侧重于修改功能,代理模式侧重于控制访问。

模式在 Android 中的应用

  • 建造者模式
    常见于 AlertDialog.Builder 及其他 Builder 类中。

  • 原型模式
    Intent.clone 或者其他支持并重写了 Clone 方法的类。

  • 装饰模式
    Android 中的 Context/ContextWraaper 就是经典的装饰模式。

0055-decorator-Android_Context-uml-classdiag.png

  • 责任链模式
    常见的责任链模式就是 View 按键事件分发机制。

  • 迭代器模式
    Cursor 是典型的迭代器模式。

  • 观察者模式
    所有 regeister 类型都是观察者模式,如 Android.BroadcastReceiver 广播,数据库更新通知等。

  • 备忘录模式
    Activity.onSaveInstanceState, Activity.onRestoreInstanceState 保存或恢复当前状态,但并不是每次都会执行。

  • 模板方法模式
    Activity/Fragmengt 等的生命周期是标准的模板方法,以及 AsyncTask 的执行步骤 onPreExecute --> doInBackgroud --> onPostExecute 等这些都是模板方法的体现。

  • 中介者模式
    文件名包含 Mediator 关键字的类,都可能使用了中介者模式,如:KeyguardViewMediator

  • 代理模式
    整个 Binder 机制中都会使用到代理模式,所有服务注册相关都会对应一个代理。

  • 组合模式
    View/ViewGroup 标准组合模式。

  • 适配器模式
    ListView, RecyclerView 等在数据填充时会使用到 Adapter

还有 Java 语言中默认支持原型模式 Cloneable,迭代器模式 Interator,观察者模式 Observable/Observer

参考文档