wh9109的博客

将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。要点总结Adapter模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁移等方面非常有用。GoF23定义了两种Adapter模式的实现结构：对象适配器和类适配器。但类适配器采用多继承”的实现方式，一般不推荐使用。对象适配器采用”对象组合”的方式，更符合松耦合精神。

为其他对象提供一种代理以控制对这个对象的访问。以下是一个简单的 C++ 代理模式的例子，其中实现了一个图片加载的代理。

从客户程序的角度来看，Façade模式简化了整个组件系统的接口， 对于组件内部与外部客户程序来说，达到了一种“解耦”的效 果——内部子系统的任何变化不会影响到Façade接口的变化。下图中左边方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。为子系统中的一组接口提供一个一致的界面， Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦？

运用共享技术有效地支持大量细粒度的对象。chatGPT给出的享元模式的例子以下是一个简单的 C++ 代码例子，演示了享元模式的实现。这个例子以文本编辑器中的字符格式化为场景。

保证一个类仅有一个实例，并提供一个访问它的全局访问点。在单例模式中使用双检查锁(DCL，Double-Checked Locking)时，可能会遇到一些问题，特别是在多线程环境下。在C++11之前的版本中，由于缺少内存栅栏(memory barrier)的支持，可能导致DCL失效，从而造成线程安全性问题。

由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。这个例子中的产品是简单的包含两个部分的字符串，实际应用中可以根据需求定义更复杂的产品结构。如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？通过调用建造者的方法，按照一定的构建流程组织建造者完成产品的构建。设计模式的目的是将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。，按照一定的构建流程构建了石头房子，并输出结果。

同时，由于需求的变化，往往存在更多系列对象的创建工作。如何绕过常规的对象创建方法（new），提供一种封装机制来避免客户程序和这种多系列具体对象创建工作的紧耦合？第二版：使用工厂方法，但是会遇到问题，使用的时候工厂之间有关联性，必须是同一系列的，比如都是oracle数据库的连接、命令、datareader等，不能是mysql的连接、orable的命令这种交叉使用。第三版：有关联性的创建行为放在一起，合成一个工厂，这就是抽象工厂Abstract Factory。第一版:不好的设计，绑定到具体的类。

定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。具体到上面的代码，用于创建对象的接口SplitterFactory，让子类（BinarySplitterFactory，TxtSplitterFactory等具体工厂）决定实例化哪一个类。在下列情况下可以使用Factory Method模式：• 当一个类不知道它所必须创建的对象的类的时候。• 当一个类希望由它的子类来指定它所创建的对象的时候。

在某些情况下，我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。第二个版本：把CryptoStream继承自Stream，直接对Stream进行加密，运行时绑定它的子类（FileStream，NetworkStream，MemoryStream）。考虑不同的流stream，有文件流，内存流，网络流等，需要对不同的流进行加密，缓冲。

定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动刷新。这一模式中的关键对象是目标(subject)和观察者(observer)。一个目标可以有任意数目的依赖它的观察者。一旦目标的状态发生改变 , 所有的观察者都得到通知。作为对这个通知的响应，每个观察者都将查询目标以使其状态与目标的状态同步。这种交互也称为发布－订阅（puplish-subscribe）。目标是通知的发布者。它发出通知时并不需知道谁是它的观察者。可以有任意数目的观察者订阅并接收通知。

在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都写在对象中，将会使对象变得异常复杂；而且有时候支持不频繁使用的算法也是一个性能负担。如何在运行时根据需要透明地更改对象的算法，将对象和算法解耦？举例：不同国家税率的计算，新的需求是新增一个国家税率的计算。不好的做法：增加一个if else好的做法：定义一个新类（扩展），实现虚函数，以此来实现不同的税率计算。定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。

模板与方法应该是最常使用的设计模式，在GOF（设计模式）中的定义：定义一个操作中的算法的骨架 ，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

使用封装来创建对象之间的分界层，让设计者可以在分解层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。高层模块（稳定）不应该依赖于低层模块（变化），二者都应该依赖于抽象（稳定）。抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象（稳定）。减少系统中的各部分的依赖关系，从而实现“高内聚”，“松耦合”的类型设计方式。而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。不将变量类型声明为某个特定的具体类，而是声明为某个接口。类模块应该是可扩展的，但是不可修改。

抽象：更高层次来讲，人们处理复杂性有一个通用的技术，即抽象。由于不能掌握全部的复杂对象，我们选择忽视它的非本质细节而去处理泛化和理想化了的对象模型。每一个模式描述了一个在我们周围不断重复的问题以及该问题的解决方案的核心，这样，就能一次有一次地使用该方案，而不必做重复劳动。分解：人们面对复杂性有一个常见的做法:即分而治之，将大问题分解为多个小问题，将复杂问题分解为多个简单问题。但是我们通过C++的特性多态来进行操作的话，我们的操作步骤和代码量会明显的减少；