大话设计模式读书笔记

设计模式

什么是设计模式

**在变化和稳定之间寻找隔离点，从而来管理变化，**正常的软件体系结构，一定既有变化又有稳定点(稳定更具有复用性,如lib库定义主流程)，把变化像小兔子一样关在笼子里不干扰全局，谨记，我们最大的敌人是变化。

“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”。
——Christopher Alexander

如何解决复杂性？

• 分解
  • 人们面对复杂性有一个常见的做法：即分而治之，将大问题分解为多个小问题，将复杂问题分解为多个简单问题。
• 抽象
  • 更高层次来讲，人们处理复杂性有一个通用的技术，即抽象。由于不能掌握全部的复杂对象，我们选择忽视它的非本质细节，而去处理泛化和理想化了的对象模型。

面向对象设计原则

1. 依赖倒置原则（DIP去依赖抽象接口）

   • 高层模块(稳定)不应该依赖于低层模块(变化)，二者都应该依赖于抽象(稳定) ，MainForm都依赖于Shape，存基类指针达到了多态，封装变化的对象。
   • 抽象(稳定)不应该依赖于实现细节(变化) ，实现细节应该依赖于抽象(稳定)。
   • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YqAdzGvd-1677046937643)(null)]

2. 开放封闭原则（OCP）

   • 对扩展开放，对更改封闭。
   • 类模块应该是可扩展的，但是不可修改，家具增加了防火需求。

3. 单一职责原则（SRP）

   • 一个类应该仅有一个引起它变化的原因，一个类如果有80个过多方法不太正常。
   • 变化的方向隐含着类的责任。

4. Liskov 替换原则（LSP）

   • 子类必须能够替换它们的基类(IS-A)。
   • 继承表达类型抽象。

5. 接口隔离原则（ISP）

   • 不应该强迫客户程序依赖它们不用的方法。
   • 接口应该小而完备。

6. 组合优于继承

   • 类继承通常为“白箱复用”，对象组合通常为“黑箱复用”，继承基类和类内组合一个基类的指针对象，效果是一样的。

     class CopytoNetworkStream :: public NetworkStream{
       
     public:	
       virtual void Read(){
         //额外的加密操作...
       	public NetworkStream::Read();
         //额外的加密操作...
       }
       
     }
     
     class CopytoNetworkStream {
       
       	//优化1、 继承:: public NetworkStream换为类内组合
         NetWorkStream* stream;
       
       //优化2、共同基类多态new NetWorkStream()
       	Stream* stream;//new NetWorkStream()
       //核心：编译时一样运行时不一样
       
     public:	
       virtual void Read(){
         //额外的加密操作...
       	stream->Read();//public NetworkStream:: -> 调用改为指针调用;
         //额外的加密操作...
       }
       
     }
     

     //扩展操作
     
     // 由于两个子类有相同的成员Stream*，所以这个成员要往上提到他们公有的父类，如果父类又其他继承则声明中间类来当他们共同的父类
     DecoratorStream: public Stream{
     protected:
         Stream* stream;//...
         
         DecoratorStream(Stream * stm):stream(stm){
         
         }
         
     };
     

   • 继承在某种程度上破坏了封装性，子类父类耦合度高。

   • 而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。

7. 封装变化点

   • 使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。

8. 针对接口编程，而不是针对实现编程

   • 不将变量类型声明为某个特定的具体类，而是声明为某个接口。
   • 客户程序无需获知对象的具体类型，只需要知道对象所具有的接口。
   • 减少系统中各部分的依赖关系，从而实现“高内聚、松耦合”的类型设计方案。

从封装变化角度对模式分类

组件协作：

• Template Method

  动机（Motivation）

  • 在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因，而无法和任务的整体结构同时实现。
  • 如何在确定稳定操作结构的前提下，来灵活应对各个子步骤的变化或者晚期实现需求？
  • 例子：比如框架与应用之间的关系,step1()step2()Lib定义剩下的你去填补即可

  模式定义

  定义一个操作中的算法的骨架 (稳定) ，而将一些步骤延迟 (变化) 到子类中。 Template Method使得子类可以不改变(复用)一个算法的结构即可重定义(override 重写)该算法的 某些特定步骤。 ——《 设计模式》 GoF

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-z0u0SchU-1677046937720)(null)]

  要点总结

  • UML把稳定的变化的画出来，感受之间的力量

  • Template Method模式是一种非常基础性的设计模式，在面向对象系统中有着大量的应用。它用最简洁的机制（虚函数的多态性） 为很多应用程序框架提供了灵活的扩展**(扩展=继承+虚函数)**点，是代码复用方面的基本实现结构。

  • 除了可以灵活应对子步骤的变化外， 站在类库的角度，“不要调用我，让我来调用你” 的反向控制结构是Template Method的典型应用。

  • 在具体实现方面，被Template Method调用的虚方法可以具有实现，也可以没有任何实现（抽象方法、纯虚方法），但一般推荐将它们设置为protected方法。

• Strategy

  动机（Motivation）

  • 在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。
  • 如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上述问题？
  • 例子：通过多态实现CN_Money,US_Money等，看到多条ifelse判断语句组合通常需要Strategy模式

  模式定义

  定义一系列算法，把它们一个个封装起来，并且使它们可互相替换。该模式使得算法可独立于使用它的客户程序(稳定)而变化（扩展，子类化）。 ——《设计模式》 GoF

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-m5j6o28A-1677046937744)(null)]

  要点总结

  • Strategy及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换。
  • Strategy模式提供了用条件判断语句以外的另一种选择，看到多条ifelse判断语句组合通常需要Strategy模式，消除条件判断语句，就是在解耦合。
  • 如果Strategy对象没有实例变量，那么各个上下文可以共享同一个Strategy对象，从而节省对象开销。

• Observer/Event（常用）

  动机（Motivation）

  • 在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系，如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。
  • 使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。
  • 例子：分割文件软件的图形界面 ——不应定义在Splitter类内部，仅定义一个通知函数接口，放在MainForm类来继承，这样当图形界面需求发生改变，所有的依赖对 象（观察者对象）都将得到通知。

  模式定义

  定义对象间的一种一对多（变化）的依赖关系，以便当一个对象(Subject)的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。 ——《 设计模式》 GoF

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gbVBfuQq-1677046937704)(null)]

  要点总结

  • 使用面向对象的抽象，Observer模式使得我们可以独立地改变目标与观察者，从而使二者之间的依赖关系达致松耦合。
  • 目标发送通知(addProgress)时，无需指定观察者(ProgressBar)，观察者决定自己是否调用通知(DoProgress)。
  • Observer模式是基于事件的UI框架中非常常用的设计模式，也是MVC模式的一个重要组成部分。

单一职责(过度的继承会出现问题)：

• Decorator（常用）

  动机（Motivation）

  • 在某些情况下我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性； 并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。

  • 如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响将为最低？

  • 例子：为各种流添加加密算法，不用CopytoNetworkStream子类继承用指针组合，定义Decorator类存放这个公有指针

    //扩展操作
    
    // 由于两个子类有相同的成员Stream*，所以这个成员要往上提
    //既继承Stream又组合Stream一般都是装饰器
    //继承为了完善接口的规范，定义在子类Stream里有些继承不需要
    //组合为了实现扩展的功能
    DecoratorStream: public Stream{
    protected:
        Stream* stream;//...
        
        DecoratorStream(Stream * stm):stream(stm){
        
        }
        
    }
    

  模式定义

  动态**（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类（继承）更为灵活（**消除重复代码 & 减少子类个数）。 ——《设计模式》GoF

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uXdpE2at-1677046937854)(null)]

  要点总结

  • 通过采用组合而非继承的手法， Decorator模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能。 避免了使用继承带来的“灵活性差”和“多子类衍生问题”。
  • Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。 但在实现上又表现为has-a Component的组合关系，即Decorator类又使用了另外一个Component类，既继承又组合某一个类。
  • Decorator模式的目的并非解决“多子类衍生的多继承”问题，Decorator模式应用的要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义。

• Bridge

  动机（Motivation）

  • 由于某些类型的固有的实现逻辑，使得它们具有两个变化的维度，乃至多个纬度的变化。
  • 如何应对这种“多维度的变化”？如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化，而不引入额外的复杂度？
  • 例子：基本版，改进版，最终版加入不同的功能，在最基类中定义了这些方法，平台实现和业务扩展变化的方向不一致，应该拆为两类

  模式定义

  将抽象部分(业务功能)与实现部分(平台实现)分离，使它们都可以独立地变化。 ——《设计模式》GoF

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uYKd4Xd8-1677046937921)(null)]

  要点总结

  • Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自纬度的变化，即“子类化”它们。
  • Bridge模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
  • Bridge模式的应用一般在“两个非常强的变化维度”，有时一个类也有多于两个的变化维度，这时可以使用Bridge的扩展模式。

对象创建:都是绕开new的

• Factory Method(常用)

  动机（Motivation）

  • 在软件系统中，经常面临着创建对象的工作；由于需求的变化，需要创建的对象的具体类型经常变化。
  • 如何应对这种变化？如何绕过常规的对象创建方法(new)，提供一种“封装机制”来避免客户程序和这种“具体对象创建工作”的紧耦合？
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1kv0yVBy-1677046937951)(null)]

  模式定义

  定义一个用于创建对象的接口(工厂基类中的CreateSplitter()就是负责创建对象的接口)，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟（目的：解耦，手段：虚函数）到子类。 ——《设计模式》GoF

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6c0zm0VA-1677046937813)(null)]

  要点总结

  • Factory Method模式用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系(new)会导致软件的脆弱。
  • Factory Method模式通过面向对象的手法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好地解决了这种紧耦合关系。
  • Factory Method模式解决“单个对象”的需求变化。缺点在于要求创建方法/参数相同。

• Abstract Factory

  动机(motivation)

  • 在软件系统中，经常面临着“一系列相互依赖的对象创建工作(本来定义三个工厂类,有关联放一个类里,工厂模式是抽象工厂的特例)”，；同时，由于需求的变化，往往存在更多系列对象的创建工作。
  • 如何应对这种变化？如何绕过常规的对象创建方法(new)，提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合。
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PKuc7uEA-1677046937800)(null)]

  模式定义

  提供一个接口，让该接口负责创建一系列”相关或者相互依赖的对象“，无需指定它们具体的类。 ——《设计模式》GoF

  要点总结

  • 如果没有应对”多系列对象创建“的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的工厂即可。
  • ”系列对象“指的是在某一个特定系列的对象之间有相互依赖、或作用的关系。不同系列的对象之间不能相互依赖。
  • Abstract Factory模式主要在于应用”新系列“的需求变动。其缺点在与难以应对”新对象“的需求变动。

• Prototype

  动机(motivation)

  • 在软件系统中，经常面临这**“某些结构复杂的对象”的创建工作**；由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口。
  • 如何应对这种变化？如何向“客户程序(使用这些对象的程序)”隔离出“这些易变对象”，从而使得依赖这些”易变对象“的客户程序不随着需求改变而改变。
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Wj4Eilrm-1677046937965)(null)]

  模式定义

  使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象。 ——《设计模式》GoF

  要点总结

  • Prototype模式同样用于隔离对象的使用者和具体类型(易变类)之间的耦合关系，它同样要求这些“易变类”拥有稳定的接口。
  • Prototype模式对于“如何创建易变类的实体对象“采用”原型克隆“的方法来做， 它使得我们可以非常灵活地动态创建”拥有某些稳定接口“的新对象——所需工作仅仅是注册一个新类的对象(即原型)， 然后在任何需要的地方Clone。
  • Prototype模式中的Clone方法可以利用某些框架中的序列化(c++直接用拷贝构造函数)来实现深拷贝。

• Builder

  动机（Motivation）

  • 在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这 个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。
  • 如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？

  模式定义

  将一个复杂对象的构建与其表示相分离，使得同样的构建过程(稳定)可以创建不同的表示(变化)。 ——《设计模式》GoF

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ej09VCB7-1677046937758)(null)]

  要点总结

  • Builder 模式主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。
  • 变化点在哪里，封装哪里—— Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。
  • 在Builder模式中，要注意不同语言中构造器内调用虚函数的差别（C++(构造函数中不可以调用虚函数) vs. C#)。

对象性能：

• Singleton(常用)

  动机(Motivation)

  • 在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确性、以及良好的效率。
  • 如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例？
  • 这应该是类设计者的责任，而不是使用者的责任。
  • 设置检查锁，变原子访问，单线程OK，但并发进程多时如Web服务读访问浪费效率。
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CIcDKPUB-1677046938012)(null)]
  • 双检查锁在编译运行层面的内存优化会reorder创建对象的步骤，被证实不安全。
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MQoDlpmC-1677046938000)(null)]
  • 声明一个原子对象atomic，用load得到指针，帮助实现屏蔽编译器的reorder，fence理解为内存的屏障，tmp可保证new的时候不会reorder。
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DimPFwif-1677046937780)(null)]

  模式定义

  保证一个类仅有一个实例，并提供一个该实例的全局访问点。 ——《设计模式》GoF

  要点总结

  • Singleton模式中的实例构造器可以设置为protected以允许子类派生。
  • Singleton模式一般不要支持拷贝构造函数和Clone接口，因为这有可能导致多个对象实例，与Singleton模式的初中违背。
  • 如何实现多线程环境下安全的Singleton？注意对双检查锁的正确实现。

• Flyweight

  动机(Motivation)

  • 在软件系统采用纯粹对象方案(一切皆对象)的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价——主要指内存需求方面的代价。
  • 如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式来进行操作？—用如下的类对象池、线程池、String常量池来解决
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5SEhM5Pe-1677046937828)(null)]

  模式定义

  运行共享技术(如字符串的共享)有效地支持大量细粒度的对象。 ——《设计模式》GoF

  要点总结

  • 面向对象很好地解决了抽象性的问题，但是作为yield运行机器中的程序实体，我们需要考虑对象的代价问题， Flyweight主要解决面向对象的大家问题，一般不触及面向对象的抽象性问题。
  • Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的压力。在具体实现方面，要注意对象状态(设为只读)的处理。
  • 对象的数量太大从而导致对象内存开销加大——什么样的数量才算大？这需要我们仔细的根据具体应用情况进行评估，而不能凭空臆断。
  • 一个对象40Byte，1000个对象40KB，100*1000大概4MB

接口隔离：间接思想

• Façade(门面模式)

  动机(Motivation)

  • 客户和组件中各种复杂的子系统有过多的耦合
  • 如何简化外部客户程序和系统间的交互接口？如何解耦？
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xjrPdwpu-1677046937892)(null)]

  模式定义

  为子系统中的一组接口提供一个一致(稳定)的界面，Façade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用(复用)。 ——《设计模式》GoF

  要点总结

  • 从客户程序角度来看，Façade模式简化了整个组件系统的接口，对于组件内部与外部的客户程序来说， 达到了一种”解耦“的效果——内部子系统的任何变化不会影响到Façade接口的变化。
  • Façade设计模式**更注重架构的层次去看整个系统，而不是单个类的层次。**Façade很多时候是一种架构设计模式。
  • Façade设计模式并非一个集装箱，可以任意地放进任何多个对象。Façade模式组件中的内部应该是”相互耦合关系比较大的一系列组件“，而不是一个简单的功能集合。

• Proxy(常用)

  动机(Motivation)

  • 在面向对象系统中，有些对象由于某种原因(**比如对象创建的开销很大，或者某些操作需要安全控制，**或者需要进程外的访问等)， 直接访问(即new某个对象)会给使用者、或者系统结构带来很多麻烦。
  • 如何在不失去透明操作对象的同事来管理/控制这些对象特有的复杂性？增加一层间接层，来实现不为外界所知的功能，如copy-on-write对性能的提升是软件开发中常见的解决方式。
  • 一些原因你拿不到new RealSubject()，需要代理，或访问外网需要代理
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jjVhmPpj-1677046937841)(null)]
  • 用一些工具SubjectProxy类替代RealSubject来间接获得realSubject，这个工具就是对其的代理，内部可以处理一些安全控制等。
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xys9aV0e-1677046937937)(null)]

  模式定义

  为其他对象提供一种代理以控制(隔离，使用接口)对这对象的访问。 ——《设计模式》GoF

  要点总结

  • Copy-on-wirte字符串常用，若复制的对象不经常更改，复制时潜拷贝，但需要改这个对象时需要在内部再拷贝一份，实际上就是代理。

  • WebService分布式系统中，拿到rest接口，往往有一些工具帮你生成实际客户端的代理类。

  • Proxy并不一定要求保持接口完整的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。

• Mediator

  动机(Motivation)

  • 多个对象相互关联的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。
  • 在这种情况下，可以使用一种”中介对象“来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ffJWzSEe-1677046937674)(null)]
  • 解耦依赖关系
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EoIBb75R-1677046937866)(null)]

  模式定义

  用一个中介对象来封装(封装变化)一系列的对象交互。中介者使各对象不需要显式的相互引用(编译时依赖->运行时依赖)， 从而使其耦合松散(管理变化)，并且可以独立地改变它们之间的交互。 ——《设计模式》GoF

  要点总结

  • 将多个对象间发杂的关联关系解耦
  • Facade模式是解耦系统间(单向)的对象关联关系；Mediator模式是解耦系统内各个对象之间(双向)的关联关系

• Adapter

  动机(Motivation)

  • 由于应用环境的变化，常常需要将”一些现存的对象“放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足。
  • 如何应对这些”迁移的变化“？
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AtpWmLSd-1677046937878)(null)]
  • 组合(has a deque)遗留类型接口，继承(is a queue)新类型接口，栈和队列都是适配器

  模式定义

  将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 ——《设计模式》GoF

  要点总结

  • 在遗留代码复用、类库迁移等方面有用
  • 类适配器采用多继承"组合那个类变为继承那个类"

状态变化：

• Memento(备忘录)

  动机(Motivation)

  • 某些对象的状态转换过程中，可能由于某中需要，要求程序能够回溯到对象之前处于某个点的状态。 如果使用一些公开接口来让其他对象得到对象的状态，便会暴露对象的细节实现。
  • 如何实现对象状态的良好保存与恢复？但同时又不会因此而破坏对象本身的封装性、
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9PV4LqPM-1677046937770)(null)]

  模式定义

  在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。 ——《设计模式》GoF

  要点总结

  • 备忘录存储原发器(Originator)对象的内部状态，在需要时恢复原发器状态。
  • 有些过时。

• State

  动机(Motivation)

  • 对象状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。
  • 如何在运行时根据对象的状态来透明地改变对象的行为？
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HSldX6cn-1677046937732)(null)]

  模式定义

  允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。 ——《设计模式》GoF

  要点总结

  • State模式将所有与一个特定状态相关的行为都放入一个State的子对象中，在对象状态切换时，切换相应的对象； 但同时维持State的接口，这样实现了具体操作与状态转换之间的解耦。
  • 转换是原子性的
  • 与Strategy模式类似，碰见if else转为多态对象

数据结构：

• Composite

  动机(Motivation)

  • 客户代码过多地依赖于对象容器复杂的内部实现结构，对象容器内部实现结构(而非抽象结构)的变化 引起客户代码的频繁变化，带来了代码的维护性、扩展性等弊端。
  • 如何将”客户代码与复杂的对象容器结构“解耦？让对象容器自己来实现自身的复杂结构，从而使得客户代码就像处理简单对象一样来处理复杂的对象容器？
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-78EskGDI-1677046937907)(null)]

  模式定义

  将对象组合成树形结构(用List里放多态对象)以表示”部分-整体“的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性(稳定)。 ——《设计模式》GoF

  要点总结

  • Composite模式采用树性结构来实现普遍存在的对象容器，从而将”一对多“的关系转化为”一对一“的关系，使得客户代码可以一致地(复用)处理对象和对象容器， 无需关心处理的是单个的对象，还是组合的对象容器。
  • 客户代码与纯粹的抽象接口——而非对象容器的内部实现结构——发生依赖，从而更能”应对变化“。
  • Composite模式在具体实现中，可以让父对象中的子对象反向追溯；如果父对象有频繁的遍历需求，可使用缓存技术来改善效率。

• Iterator

  动机(Motivation)

  • 集合对象内部结构常常变化异常。但对于这些集合对象，我们希望不暴露其内部结构的同时，可以让外部客户代码透明地访问其中包含的元素； 同时这种”透明遍历“也为”同一种算法在多种集合对象上进行操作“提供了可能。
  • 使用面向对象技术将这种遍历机制抽象为”迭代器对象“为”应对变化中的集合对象“提供了一种优雅的方式。

  模式定义

  提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露(稳定)该对象的内部表示。 ——《设计模式》GoF

  要点总结

  • 迭代抽象：访问一个聚合对象的内容而无需暴露它的内部表示。
  • 迭代多态：为遍历不同的集合对象提供一个统一的接口，从而支持同样的算法在不同的集合结构上进行操作。
  • 对C++来说是过时的，现在迭代器用函数模板，静态编译时多态；面向对象的方式采用动态多态，每次虚表访问性能低
  • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-w9TTiDny-1677046937689)(null)]

• Chain of Resposibility(职责链)

  动机(Motivation)

  • 一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接收者，如果显式指定，将必不可少地带来请求发送者与接收者的紧耦合。
  • 如何使请求的发送者不需要指定具体的接收者？让请求的接收者自己在运行时决定来处理请求，从而使两者解耦。

  模式定义

  使多个对象都有机会处理请求（鼠标点击），从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。 ——《设计模式》GoF

  要点总结

  • 应用于”一个请求可能有多个接受者，但是最后真正的接受者只有一个“，这时候请求发送者与接受者有可能出现”变化脆弱“的症状，职责链解耦。
  • 有些过时。

行为变化：

• Command
• Visitor

领域问题：

• Interpreter

总结

现代较少用的模式

• Builder
• Mediator
• Memento
• Iterator
• Chain of Resposibility
• Command
• Visitor
• Interpreter