2020-05-01

C++设计模式
面向对象设计原则：
1.依赖倒置原则（DIP）：高层模块(稳定)不应该依赖于低层模块(变化)，二者都应该依赖于抽象(稳定)。抽象(稳定)不应该依赖于实现细节(变化)，实现细节应该依赖于抽象(稳定)。
2.开放封闭原则（COP）：对扩展开放，对更改封闭。类模块应该是可扩展的，但是不可修改。
3.单一职责原则（SRP）:一个类应该仅有一个引起它变化的原因。变化的方向隐含着类的职责。
4.里式替换原则（LSP）:子类必须能够替换它们的基类（IS-A）。继承表达类型抽象。
5.接口隔离原则（ISP）:不应该强迫客户程序依赖它们不用的方法。接口应该小而完备。
6.优先使用对象组合，而不是类继承：类继承通常为"白箱复用"，对象组合通常为"黑箱复用"。继承在某种程度上破坏了封装性，子类父类耦合度高。而对象组则合只要求被组合的对象具有良好定义的接口，耦合度低。
7.封装变化点：使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良影响，从而实现层次间的松耦合。
8.针对接口编程，而不是针对实现编程。不将变量类型声明为某个特定的具体类，而是声明为某个接口客户程序无需获知对象的具体类型，只需要知道对象所具有的接口。减少系统中各部分的依赖关系，从而实现"高内聚，松耦合"的类型设计方案。

高内聚低耦合，是软件工程中的概念，是判断设计好坏的标准，主要是面向对象的设计，主要看类的内聚性是否高，耦合度是否低。目的是使得模块的可重用性、移植性大大增强。
通常程序结构中各模块的内聚程度越高，模块间的耦合程度就越低。内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事。
它描述的是模块内的功能联系；耦合是软件结构中各模块之间相互连接的一种度量，耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。
例如：
比如订单模块，订单是跟库存息息相关的，没有库存就没有订单，订单强依赖库存。把扣减库存的逻辑直接写在在订单模块中，那么订单模块和库存模块就耦合了另一方面，订单模块中有扣减库存的逻辑会造成订单模块的功能比较分散，功能就不够集中，便构成了低内聚。
把订单中的库存逻辑给拆分出来一个独立的库存模块，库存模块对外暴露扣减库存的接口，订单模块调用接口实现减少库存的操作，将订单逻辑与库存逻辑的依赖降低到最小，减小了订单与库存的耦合。
同时订单模块只包含订单处理的逻辑，库存系统只包含库存的处理逻辑，两个系统的业务上更加内聚。

设计模式的六大原则
1、开闭原则（Open Close Principle）开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
2、里氏代换原则（Liskov Substitution Principle）里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
3、依赖倒转原则（Dependence Inversion Principle）这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（Interface Segregation Principle）这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。5、迪米特法则，又称最少知道原则（Demeter Principle）最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
6、合成复用原则（Composite Reuse Principle）合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。

将设计原则提升为设计经验：
1.设计习语 Design IdiomsDesign Idioms 描述与特定编程语言相关的低层模式、技巧、惯用法。
2.设计模式 Design PatternsDesign Patterns 主要描述的是 ：类与相互通信的对象之间的组织关系，包括它们的角色、职责、协作方式等方面。
3.架构模式 Architectural PatternsArchitectural Patterns 描述系统中与基本结构组织关系密切的高层模式，包括子系统划分，指责，以及如何组织它们之间关系的规则。

GOF-23模式分类从目的来看：
1.创建型（Creational）模式：将对象的部分创建工作延迟到子类或者其他对象，从而应对需求变化为对象创建时具体类型实现引来的冲击。
2.结构型（Structural）模式：通过类继承或者对象组合获得更灵活的结构，从而用对需求变化为对象的结构带来的冲击。
3.行为型（Behavioral）模式：通过类继承或者对象组合类划分类与对象间的职责，从而应对需求变化为多个交互的对象带来的冲击。
从范围来看：
1.类模式处理类与子类的静态关系。
2.对象模式处理对象间的动态关系。
“组件协作"模式:现代软件专业分工后的第一个结果是 “框架与应用程序的划分”，“组件协作” 模式通过晚期绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式。
经典模式：模板方法（Template Method）、策略模式（Steategy）、观察者模式（Observer / Event）模板方法模式（Template Method）：动机：在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因（比如框架与应用之间的关系）而无法和任务的整体结构同时实现。如何在确定稳定操作结构的前提下，来灵活应对各个子步骤的变化或者晚期实现需求？定义：定义一个操作中的算法的骨架（稳定），而将一些步骤延迟（变化）到子类中，Template Method 使得子类可以不改变（复用）一个算法的结构即可重定义（override重写）该算法的某些特定步骤。要点：1.Template Method 模式是一种非常基础性的设计模式，在面向对象系统中有着大量的应用，它用最简洁的机制（虚函数的多态性）为很多应用程序框架提供了灵活的扩展点，是代码复用方面的基本实现结构。2.除了可以灵活应对子步骤的变化外，“不要调用我，让我来调用你” 的反向控制结构是Template Method 的典型应用。3.在具体实现方面，被Template Method调用的虚方法可以具有实现，也可以没有任何实现（抽象方法、纯虚方法），但一般推荐将它们设置为protected方法。参考链接：https://www.cnblogs.com/fenglangxiaotian/p/7762958.html策略模式（Strategy）：动机：在软件构件过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上述问题？定义：定义一系列算法，把它们一个个封装起来，并且是它们可互相替换（变化）。该模式使得算法可独立于它的客户程序（稳定）而变化（扩展，子类化）。要点：1.Strategry及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换。2.Strategry模式提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。含有许多判断条件语句的代码通常都需要Strategry模式。3.如果Strategry对象没有实例变量，那么各个上下文可以共享同一个Strategry对象，从而节省对象开销。参考链接：https://www.cnblogs.com/ring1992/p/9593575.html 观察者模式（Observer）：动机：在软件构建过程中，我们需要为某些对象建立一种 “通知依赖关系”——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。定义：定义对象间的一种一对多（变化）的依赖关系，以便当一个对象（Subject）的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。要点：1.使用面向对象的抽象，Observer模式使得我们可以独立地改变目标与观察者，从而使二者之间的依赖关系达致松耦合。2.目标发送通知，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播。3.观察者自己会决定是否需要订阅通知，目标对此一无所知。4.Observer模式是基于事件的UI框架中非常常用的设计模式，也是MVC模式的一个重要组成部分。参考链接：https://blog.csdn.net/weixin_44344462/article/details/93205226 或 https://blog.csdn.net/lwbeyond/article/details/7532107"单一职责” 模式：在软件组件的设计中，如果责任划分的不清晰，使用继承得到的往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。经典模式：装饰模式（Decorator）、桥模式（Bridge）装饰模式：动机：某些情况下我们可能会"过度地使用继承来扩展对象的功能"，由于继承为类型引入的静态特质。是的这种扩展方式缺乏灵活性；并且会随着子类的增多(扩展功能的增多)，各种子类的组合(扩展功能的组合)会导致更多子类的膨胀。定义：动态(组合)地给对象增加一些额外的职责。就增加功能而言，装饰模式比生成子类(继承)更为灵活(消除重复代码&减少子类个数)。要点：1.通过采用组合而非继承的手法，装饰模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了使用继承带来的"灵活性差"和"多子类衍生问题"。2.装饰类在接口上表现为is-a Component 的继承关系，即装饰类继承了Component类所有的接口。但是实现上又表现为has-a Component的组合关系，即装饰类又使用了另外一个Component类。3.装饰模式的目的并非解决"多子类衍生的多继承"问题，装饰模式应用的要点在于解决"主体类在多个方向上的扩展功能"——是为"装饰"的含义。装饰模式的一个主要标志为：既使用继承又使用组合。参考链接：https://blog.51cto.com/2309998/1291015桥模式：动机：由于某些类型的固有的实现逻辑，使得它们具有两个变化的维度乃至多个维度的变化。定义：将抽象部分(业务功能)与实现部分(平台实现)分离，使它们都可以独立地变化。要点：1.桥接模式使用"对象间的组合关系"解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自维度的变化，即"子类化"它们。2。桥接模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则(即一个类只有一个变化的原因)，复用性比较差。桥接模式是比多继承方案更好的解决方法。3。桥接模式的应用一般在"两个非常强的变化维度"，有时一个类也有多余两个类的变化维度，这时可以使用桥接模式。桥接模式的定义是将抽象化与实现化分离（用组合的方式而不是继承的方式），使得两者可以独立变化。可以减少派生类的增长。这样看起来和装饰者差不多，但两者还是有一些比较重要的区别：1.桥接模式中所说的分离，其实是指将结构与实现分离（当结构和实现有可能发生变化时）或属性与基于属性的行为进行分离；而装饰者只是对基于属性的行为进行封闭成独立的类。2.桥接中的行为是横向的行为，行为彼此之间无关联；而装饰者模式中的行为具有可叠加性，其表现出来的结果是一个整体，一个各个行为组合后的一个结果。参考链接：https://blog.csdn.net/u012581604/article/details/72887029"对象创建" 模式：通过 “对象创建” 模式绕开 new，来避免对象创建（new）过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口创建后的第一步工作。典型模式：工厂方法模式（Factory Method）、抽象工厂（Abstract Factory）、原型模式（Prototype）、构建器（Builder）。工厂方法模式：定义：定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟（目的：解耦；手段：虚函数）到子类。要点：1.工厂方法模式用于隔离类对象的使用者和具体类之型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系（new）会导致软件的脆弱。2.工厂方法模式通过面向对象的手法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更换）的策略，较好地解决了这种紧耦合关系。3.工厂方法模式解决"单个对象"的需求变化。缺点在于要求创建方法/参数相同。参考链接：https://blog.csdn.net/u013216156/article/details/94859304抽象工厂模式：动机：在软件系统中，经常面临着 “一系列相互依赖的对象” 的创建工作，同时，由于需求的变化，往往存在更多系列对象的创建工作。定义：提供一个接口，让该接口负责创建一系列 “相关或者相互依赖的对象”，无需指定它们具体的类。要点：1.如果没有应对 “多系列对象创建’ 的需求变化，则没有必要使用抽象工厂模式，这时候使用简单工厂模式完全可以。2.“系列对象” 指的是在某一特定系列下的对象之间有相对依赖、或作用的关系。不同系列的对象之间不能相互依赖。3.抽象工厂模式主在于应对 “新系列” 的需求变动。其缺点在于难以应对 “新对象” 的需求变动。参考链接：https://blog.csdn.net/konglongdanfo1/article/details/83380770原型(Prototype)模式：动机：在软件系统中，经常面临着 “某些结构复杂的对象” 的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的的接口。定义：使用原型实例指定创建对象的种类，然后通过深拷贝这些原型来创建新的对象。要点：1.原型模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些 “易变类” 拥有 “稳定的接口”。2.原型模式对于 “如何创建易变类的实体对象” 采用 “原型克隆” 的方法来做，它使得我们可以灵活地动态创建 “拥有某些稳定接口” 的新对象——所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方Clone。3.原型模式中的Clone方法可以利用某些框架中序列化来实现深拷贝。例如，一个对象需要在一个高代价的数据库操作之后被创建。我们可以缓存该对象，在下一个请求时返回它的克隆，在需要的时候更新数据库，以此来减少数据库调用。参考链接：https://blog.csdn.net/huangyimo/article/details/80389540 或 https://blog.csdn.net/ThomasKUI/article/details/79787341构建器：动机：在软件系统中，有时候面临着 “一个复杂对象” 的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着一剧烈的变化，但是将它们组合在一起的算法却相对稳定。定义：将一个复杂对象的构建与其表示分离，使得同样的构建过程（稳定）可以创建不同的表示（变化）。总结：1.建造者模式主要用于 “分步骤构建一个复杂的对象”。在这其中 “分步骤” 是一个稳定的算法，而复杂对象的各个部分则经常变化。2.变化点在哪里，封装哪里——建造者模式主要在于应对 “复杂对象各个部分” 的频繁需求变动。其缺点在于难以应对 “分步骤构建算法” 的需求变动。3.在建造者模式中，要注意不同语言中构造器内调用虚函数的差别（C++、C#）。参考链接：https://blog.csdn.net/tmh_15195862719/article/details/81624045"对象性能” 模式：面向对象很好地解决了"抽象问题"，但是必不可少的要付出一定的代价。对于通常情况来讲，面向对象的成本大都可以忽略不计，但是某些情况，面向对象所带来的成本必须谨慎处理。经典模式：单例模式（Singleton）、享元模式（Flyweight）。单例模式：动机：在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能保证它们的逻辑正确性以及良好的效率。定义：保证一个类只有一个实例，并提供一个该类的全局访问点。注意：双检查锁会因为读写reorder（对分配内存，执行构造器，赋值（返回地址）这三步进行优化，导致顺序混乱，会出现在内存地址已经分配好了的情况，此时单例对象不为nullptr，因此不安全。要点：1.单例模式中的实力构造器可以设置为protocted以允许子类派生。2.单例模式一般不支持拷贝构造函数和Clone函数，因为这有可能导致多个对象实例，与单例模式的初衷违背。添加：由于单例类中new的对象通常没有delete，所有可以使用类中套类的方法进行delete单例对象。class CTest2{public: static CTest2* GetInstance() { if (ct_instance == nullptr) { ct_instance = new CTest2(); static CTest3 ct3; } return ct_instance; } ~CTest2() { if (ct_instance != nullptr) { delete ct_instance; ct_instance = nullptr; } } class CTest3 { public: ~CTest3() { if (ct_instance != nullptr) { delete ct_instance; ct_instance = nullptr; } } };private: CTest2() {} static CTest2 ct_instance;};CTest2 CTest2::ct_instance = nullptr;int main(){ CTest2 * ct = CTest2::GetInstance(); return 0;}使用以上这种方式，在程序退出时（return时），会调用_{CTest3()函数，避免内存泄漏，而}CTest2()函数在程序退出时是不会执行的。补充：可以使用std::once_flag与std::call_once来起到只调用一次某函数的目的。一旦调用的函数抛出了异常，那么下次执行std::call_once时不会跳过，而是会再次尝试，知道函数执行成功，不抛出异常为止。享元模式：动机：在软件系统中采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价——主要指内存需求方面的代价。定义：运用共享技术有效地支持大量细粒度的对象。要点：1.面向对象很好地解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们要考虑对象的代价问题。享元模式主要解决面向对象的代价问题，一般不考虑面向对象的抽象性问题。2.享元模式采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象状态的处理。参考链接：https://www.cnblogs.com/jiese/p/3171463.html 或 https://www.cnblogs.com/ring1992/p/9593235.html接口隔离模式：在组件构建过程中，某些接口之间直接的依赖常常会带来很多问题、甚至根本无法实现。采用添加一层间接（稳定）接口，来隔离本来互相紧密关联的接口是一种常见的解决方案。典型模式：门面模式(Facade)、代理模式(Proxy)、适配器(Adapter)、中介者(Mediator)门面（外观）模式：动机：当组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临着很多变化的挑战。定义：为子系统中的一组接口提供一个一致（稳定）的界面，门面模式定义了一个高层接口，这个接口使得这一子系统更加容易使用（复用）。要点：1.从客户程序的角度来看，门面模式简化了整个组件系统的接口，对于组件内部与外部客户程序来说，达到了一种 “解耦” 的效果——内部子系统的任何变化不会影响到门面接口的变化。2.外观设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。外观模式很对时候更是一种架构设计模式。3.外观设计模式并非一个集装箱，可以任意的放任何多个对象。外观模式中组件的内部应该是 “相互耦合比较大的一系列的组件”，而不是一个简单的功能集合。参考链接：https://blog.csdn.net/qq_29542611/article/details/79534963Proxy代理模式：动机：在面向对象系统中，有些对象由于某种原因（比如对象创建额开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构带来很多的麻烦。在不失去透明操作对象的同时来管理 / 控制这些对象特有的复杂性，增加一层简介层是软件开发中常见的解决方式。定义：为其他对象提供一种代理以控制（隔离，使用接口）对这个对象的访问。要点：1.“增加一层简介层” 是软件系统中对许多纷杂问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会带来很多的问题，作为间接层的proxy对象便是解决这一问题的常见手。2.具体proxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象做细粒度的控制，如copy-on-write技术，有些可能对组件模块提供代理层，在架构层次对对象做proxy。3.proxy并不一定要求保持接口完整的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。参考链接：https://blog.csdn.net/wb175208/article/details/84984169Adapter适配器：动机：在软件系统中，由于应用环境的变化，常常需要将 “一些现存的对象” 放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。定义：将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。要点：1.Adapter模式主要应用于 “希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁移等方面非常有用。2.GoF 23 定义了两种Adapter模式的实现结构：对象适配器和类适配器。但类适配器采用 “多继承” 的实现方式，一般不推荐使用。对象适配器采用 “对象组合” 的方式，更符合耦合精神。3.Adapter模式可以实现的非常灵活，不必拘泥于Gof 23 中定义的两种结构。例如，完全可以采用将Adapter模式中的 “现存对象” 作为新的接口方法参数，来达到适配的目的。参考链接：https://blog.csdn.net/qq_38646470/article/details/80302768Mediator中介者：动机：在软件构建过程中，经常会出现多个用户互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。这种情况下，使用 “中介对象” 来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。定义：用一个中介对象来封装（封装变化）一系列的对象交互。中介者使各对象不需要显示的相互引用（编译时依赖 -> 运行时依赖），从而使其耦合松散（管理变化），而且可以独立地改变它们之间的交互。要点：1. 将多个对象间复杂的关联关系解耦，中介者模式将多个对象间的控制逻辑进行集中管理，变 “多个对象互相关联” 为 “多个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。2. 随着控制逻辑的复杂化，中介者具体对象的实现可能相当复杂。这时候可以对中介对象进行分解处理。3. 门面（外观）模式是解耦系统间（单向）的对象关联关系；中介者模式是解耦系统内各个对象之间（双向）的关联关系。参考链接：https://blog.csdn.net/liang19890820/article/details/79242388 或 https://www.jianshu.com/p/b4e4be7f5daa"状态变化" 模式在组件构建过程中，某些对象的状态经常面临变化，如何对这些变化进行有效的管理？同时又维持高层模块的稳定？“状态变化” 模式为这一问题提供了一种解决方案。经典模式：状态模式(State)、备忘录模式（Memento）状态模式：动机：在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写装状态支持的行为可能就完全不同。如何在运行时根据对象的状态来透明地更改对象的行为？而不会为对象操作和状态转换之间引入紧耦合？定义：允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。要点：1.状态模式将所有与一个特定状态相关的行为都放入一个State的子类对象中，在对象状态切换时，切换相应的对象；但同时维持State的接口，这样实现了具体操作与状态转换之间的解耦。2.为不同的状态引入不同的对象使得状态转换变得更加明确，而且可以保证不会出现状态不一致的情况，因为转换是原子性的——即要么彻底转换过来，要么不转换。3.如果State对象没有实例变量，那么各个上下文可以共享同一个State对象，从而节省对象开销。参考链接：https://www.jianshu.com/p/340f7f3eaef7 或https://blog.csdn.net/yongh701/article/details/49154439备忘录模式（Memento）：动机：在软件构建过程中，某些对象的状态在装换过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其它对象得到对象的状态，便会暴露对象的细节实现。如何实现对象状态的良好保存与恢复？但同时又不会因此而破坏对象本身的封装性。定义：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态 。这样以后就可以将该对象恢复到原先保存的状态。要点：1.备忘录（Memento）存储原发器（Originator）对象的内部状态，在需要时恢复原发器状态。2.Memento模式的核心是信息隐藏，即Originator需要向外界隐藏信息，保持其封装性。但同时又需要将状态保持到外界（Memento）。3.由于现代语言运行时（如C#、Java等）都具有相当的对象序列化支持，因此往往采用效率较高、又容易正确实现的序列化方案来实现Memento模式。注意：备忘录实现过程中可能会需要序列化或内存编码等技术，与量级有关。参考链接：https://blog.csdn.net/wb175208/article/details/85207970 或https://blog.csdn.net/caoshangpa/article/details/52956044数据结构模式：常常有一些组件在内部具有特定的数据结构，如果让客户程序依赖这些特定的数据结构，将极大地破坏组件的复用。这时候，将这些特定的数据结构封装在内部，在外部提供统一的数据接口，来实现与特定数据无关的访问，是一种行之有效的解决方案。经典模式：组合模式（Composite）、迭代器（Iterator）、责任链（Chain of Resposibility）组合模式（Composite）:动机：在软件的某些情况下，客户代码过多地依赖与对象容器复杂的内部实现结构，对象容器内部实现结构（而非抽象接口）的变化将引起客户代码的频繁变化，带来了代码的维护性、扩展性等弊端。如何将 “客户代码与复杂的对象容器结构” 解耦？让对象容器自己来实现自身的复杂结构，从而使得客户代码就像处理简单对象一样来处理复杂的对象容器？定义：将对象组合成树形结构以表示 “部分 - 整体” 的层次结构。Composite使得用户对单个对象的使用具有一致性（稳定）。要点：1.Composite模式采用树形结构来实现普遍存在的对象容器，从而将 “一对多” 的关系转化为 “一对一” 的关系，使得客户代码可以一致的（复用）处理对象的对象容器，无需关心处理的是单个对象还是组合的对象容器。2.将 “客户代码与复杂的对象容器结构” 解耦是Composite的核心思想，解耦之后，客户代码将与纯粹的抽象接口——而非对象容器的内部实现结构——发生依赖，从而更能 “应对变化”。3.Composite模式在具体实现中，可以让父对象中的子对象反向追溯；如果父对象有频繁的遍历需求，可以使用缓存技巧来改善效率。参考链接：https://www.cnblogs.com/ring1992/p/9593013.html 或 https://blog.csdn.net/konglongdanfo1/article/details/83381267迭代器（Iterator）：动机：在软件构建过程中，集合对象内部结构常常变化各异。但对于这些集合对象，我们希望在不暴露其内部结构的同时，可以让外部客户代码透明地访问其中包含的元素；同时这种 “透明遍历” 也为 “同一种算法在多种集合对象上进行操作” 提供了可能。使用面向技术将这种遍历机制抽象为 “迭代器对象” 为 “应对变化中的集合对象” 提供了一种优雅的方式。定义：提供了一种方法顺序访问一个聚合对象中的各个元素，而又不暴露（稳定）该对象的内部表示。要点：1.迭代抽象：访问一个聚合对象的内容而无需暴露它的内部表示。2.迭代多态：为遍历不同的集合结构提供一个统一的接口，从而支持同样的算法在不同的集合结构上进行操作。3.迭代器的健壮性考虑：遍历的同时更改迭代器所在的集合结构，会导致问题。注意：迭代器模式是以面向对象的方式（即虚函数）实现，而在98年以后，使用模板类来实现迭代器，而模板类要比面向对象中虚函数的方式开销更小，效率更高。参考链接：https://blog.csdn.net/u012611878/article/details/78010435责任链（Chain of Resposibility）：动机：在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者，如果显式指定，将必不可少地带来请求发送者与接受者的紧耦合。如何使请求的发送者不需要指定具体的接受者？让请求的接收者自己在运行时决定来处理请求。从而使两者解耦。定义：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条线链，并沿着这条链传递请求，直到有一个对象处理它为止。要点：1.责任链模式的应用场合在于 “一个请求可能有多个接受者，但是最后真正的接受者只有一个”，这时候请求发送者与接受者的耦合可能出现 “变化脆弱” 的症状，职责链的目的就是将二者解耦，从而更好地因对变化。2.应用了职责链模式后，对象的职责分派将更具灵活性。我们可以在运行时动态添加 / 修改请求的处理职责。3.如果请求传递到职责链的末尾仍得不到处理，应该有一个合理的缺省机制。这也是每一个接受对象的责任，而不是发出请求的对象的责任。参考链接：https://blog.csdn.net/wb175208/article/details/85053121"行为变化" 模式：在组件的构建过程中，组件行为的变化经常导致组件本身剧烈的变化。“行为变化” 模式将组件的1行为和组件本身进行解耦，从而支持组件行为的变化，实现两者之间的松耦合。经典模式：命令模式（Command）、访问器（visitor）命令模式（Command）：动机：在软件构建过程中，“行为请求者” 与 “行为实现者” 通常呈现一种 “紧耦合”。但在某些场合——比如需要对行为进行 “记录、撤销 / 重做（undo/redo）、事务” 等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将 “行为请求者” 与 “行为实现者” 解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。定义：将一个请求（行为）封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。要点：1.Command模式的根本目的在于将 “行为请求者” 与 “行为实现者” 解耦，在面向对象语言中，常见的实现手段是 “将行为抽象为对象”。2.实现Comman接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。通过使用Composite模式，可以将多个 “命令” 封装为一个 “复合命令” MacroCommand。3.Command模式与C++中的函数对象有些类似。但两者定义行为接口的规范有所区别：Command以面向对象中的 “接口-实现” 来定义行为接口规范，更严格，但有性能损失；C++函数对象以函数签名来定义接口规范，更灵活，性能更高。参考链接：https://blog.csdn.net/luoyayun361/article/details/88163530访问器（visitor）：动机：在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为（方法），如果直接在基类中做这样的更改，将会给子类发带来繁重的变更负担，甚至破坏原有设计。如何在不更改类层次结构的前提下，在运行时根据需要透明地为类层次结构上的各个类动态添加新的操作，从而避免上述问题？定义：表示一个作用于某对象结构的各元素的操作。使得可以在不改变（稳定）各元素的前提下定义（扩展）作用于这些元素的新操作（变化）。要点：1.Visitor模式通过所谓的双重分发（double diapatch）来实现不更改（不添加新的操作-编译时）Element类层次结构的前提下，在运行时透明地为类层次结构上的各个类动态添加新的操作（支持变化）。2.所谓双重分发，即Visitor模式中间包括了两个多态分发（注意其中的多态机制）：第一个为accept方法的多态辨析；第二个为visitElementX方法的多态辨析。3.Visitor模式的最大缺点在于扩展类层次结构（增添新的Element子类），会导致Visitor类的改变。因此Visitor模式适用于 “Element类层次结构稳定，而其中的操作却经常面临频繁改动”。参考链接：https://blog.csdn.net/wang15061955806/article/details/51038395"领域规则" 模式:在特定领域中，某些变化虽然频繁，但是可以抽象为某种规则。这时候，结合特定领域，将问题抽象为语法规则，从而给出在该领域下的一般性解决方案。经典模式：解析器（Interpreter）解析器（Interpreter）：动机：在软件构建过程中，如果某一特定领域的问题比较复杂，类似的结构不断重复出现，如果使用普通的编程方式来实现将面临非常频繁的变化。在这种情况下，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释器来解释这样的句子，从而达到解决问题的目的。定义：给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子。要点：1.Intrepreter模式的应用场合是Intrepreter模式应用中的难点，只有满足 “业务规则频繁变化，且类似的结构不断重复出现，并且容易抽象为语法规则的问题” 才适和使用Intrepreter模式。2.使用Intrepreter模式来表示文法规则，从而可以使用面向对象技巧来方便地 “扩展” 文法。3.Intrepreter模式比较适合简单的文法表示，对于复杂的文法表示，Intrepreter模式会产生比较大的类层次结构，需要求助于语法分析生成器这样的标准工具。参考链接：https://blog.csdn.net/zang141588761/article/details/53483645设计模式总结一个目标：管理变化，提高复用两种手段：分解 VS 抽象八大原则：依赖倒置原则（DIP）、开放封闭原则（OCP）、单一职责原则（SRP）、里氏（Liskov）替换原则（LSP）、接口隔离原则（ISP）、对象组合优于继承、封装变化点、面向接口编程。重构技法：静态 -> 动态、早绑定 -> 晚绑定、继承 -> 组合、编译时依赖 -> 运行时依赖、紧耦合 -> 松耦合。什么时候不用设计模式？1.代码可读性很差时。2.需求理解还很浅时。3.变化没有显现时。4.不是系统的关键依赖点。5.项目没有复用价值时。6.项目将要发布时。经验之谈：1.不要为模式而模式2.关注抽象类 & 接口3.理清变化点和稳定点4.审视依赖关系5.要有Framework 和 Application 的区隔思维6.良好的设计是演化的结果设计模式成长之路：“手中无剑，心中无剑”：见模式而不知"手中有剑，心中无剑"：可以识别模式，作为应用开发人员使用模式"手中有剑，心中有剑"：作为框架开发人员，为应用设计某些模式"手中无剑，心中有剑"：忘掉模式，只有原则。
学习参考链接：https://www.runoob.com/design-pattern/design-pattern-tutorial.html