c++设计模式精解－GoF 23种设计模式解析附C++实现源码

### c++设计模式精解—GoF 23种设计模式解析附C++实现源码 #### 0. 引言 设计模式是面向对象编程领域的重要组成部分，它提供了一系列解决常见问题的方法论。本文旨在深入解析GoF（Gang of Four）所提出的23种设计模式，并附带C++实现的源码示例。 #### 1. 创建型模式 ##### 1.1 Factory模式 - **定义**：工厂方法模式是一种创建型设计模式，它能让我们定义创建对象的接口，但让子类决定实例化哪个类。工厂方法使一个类的实例化延迟到其子类。 - **应用场景**：当不知道确切的产品类的时候；当一个类希望通过其子类来指定它所创建的对象的时候；或者当类将创建对象的职责委托给多个帮助子类中的某一个，并且用户希望增加新的具体产品时而不修改代码的情况下。 - **优点**：客户端不必知道所创建的具体产品类；隐藏产品的创建细节；易于扩展；易于维护。 - **缺点**：每添加一个新的产品就要增加一个新的具体工厂类。 ##### 1.2 Abstract Factory模式 - **定义**：抽象工厂模式是一种创建型设计模式，它能让我们能够创建一系列相关的或相互依赖的对象，而无需指定它们具体的类。 - **应用场景**：当系统中存在多个系列和等级结构的产品时；当系统中创建的对象必须依赖于多个互相依赖或互斥的产品族中的产品时；或者当需要独立地改变产品等级结构中的各个家族时。 - **优点**：可以创建一系列相关的对象；提供了一个明确的合同用于创建产品；可以很容易地增加新产品家族。 - **缺点**：产品族扩展困难。 ##### 1.3 Singleton模式 - **定义**：单例模式是一种创建型设计模式，它确保一个类只有一个实例，并提供一个全局访问点来访问该实例。 - **应用场景**：当希望在整个系统中，某个类只能出现一个实例时；或者希望在系统中有多个实例，但希望按某种顺序创建这些实例。 - **优点**：确保类只有一个实例；提供了对唯一实例的全局访问点。 - **缺点**：过度使用单例会降低系统的可扩展性；破坏了单一职责原则。 ##### 1.4 Builder模式 - **定义**：建造者模式是一种创建型设计模式，它允许你分步骤地构建复杂对象。它把构造代码和表示代码分离。 - **应用场景**：当对象的创建算法应该独立于部件的构成部分及其装配方式时；或者当构建过程必须允许被构造的对象有不同的表示时。 - **优点**：封装了构建过程；允许分步骤构建对象；易于控制构建过程。 - **缺点**：产品内部结构复杂时，建造者模式会使代码难以理解。 ##### 1.5 Prototype模式 - **定义**：原型模式是一种创建型设计模式，它让你能够复制已有的对象，同时不需要让对象所属的类知道这一情况。 - **应用场景**：当需要创建的对象拥有复杂的内部结构时；或者当创建对象的成本较高时。 - **优点**：可以复制任何复杂的对象；可以减少创建新对象的时间成本。 - **缺点**：需要为每一个类配备一个克隆方法。 #### 2. 结构型模式 ##### 2.1 Bridge模式 - **定义**：桥接模式是一种结构型设计模式，它将抽象部分与它的实现部分分离，使它们都可以独立地变化。 - **应用场景**：当一个类的某个或某些属性经常发生变化时；或者当一个类有多个维度的变化时。 - **优点**：实现细节对客户透明；可以在不修改代码的情况下更换实现；可以添加新的抽象和实现。 - **缺点**：桥接模式可能会增加系统的复杂度。 ##### 2.2 Adapter模式 - **定义**：适配器模式是一种结构型设计模式，它能让不兼容的接口合作无间。它通常通过继承或者关联关系来实现。 - **应用场景**：当现有类的接口不符合需求时；或者当想要创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）合作时。 - **优点**：可以让任何接口一起工作；可以复用现有的类；可以提高系统的灵活性。 - **缺点**：过多地使用适配器会让系统变得非常凌乱。 ##### 2.3 Decorator模式 - **定义**：装饰器模式是一种结构型设计模式，它允许向一些对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于对象结构型模式。 - **应用场景**：当动态地给一个对象添加一些额外的功能；或者为了增强功能，需要增加新的类。 - **优点**：可以在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责；可以以一种灵活的方式扩展功能。 - **缺点**：会产生很多的小对象。 ##### 2.4 Composite模式 - **定义**：组合模式是一种结构型设计模式，它能让您将对象组合成树形结构以表示“部分-整体”的层次结构。 - **应用场景**：当需要表示对象的整体-部分层次结构；或者需要用户忽略组合对象与单个对象之间的差异时。 - **优点**：可以使用户以一致的方式处理单个对象和组合对象；易于实现递归操作。 - **缺点**：设计较为复杂；需要识别出适用于这种模式的情况。 ##### 2.5 Flyweight模式 - **定义**：享元模式是一种结构型设计模式，它用于减少创建大量相同或相似对象时所需的内存。 - **应用场景**：当系统中存在大量的相似对象；或者对象的大部分状态都可以外部化时。 - **优点**：可以显著地减少内存中对象的数量；可以减少对象的创建数量。 - **缺点**：增加了系统的复杂性；获取外部状态时可能会影响性能。 ##### 2.6 Facade模式 - **定义**：外观模式是一种结构型设计模式，它为你子系统中的一组接口提供了一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。 - **应用场景**：当一个系统有多个子系统，而且这些子系统之间相互独立；或者当一个系统很复杂，而且需要为用户提供一个简单的接口时。 - **优点**：降低了客户端与子系统之间的耦合度；提高了子系统的独立性；简化了客户端代码。 - **缺点**：不能很好地限制客户端直接使用子系统类；增加了很多额外的工作。 ##### 2.7 Proxy模式 - **定义**：代理模式是一种结构型设计模式，它让你可以提供一个替代或占位符对象来控制对一个对象的访问。 - **应用场景**：当客户端不能直接访问某些对象，或者需要对访问进行一些额外处理；或者为了控制对某个资源的访问。 - **优点**：客户端可以统一地访问真实对象或代理对象；可以通过代理对象对目标对象进行预处理或后续处理。 - **缺点**：增加了解决方案的复杂度；需要为真实对象创建代理对象。 #### 3. 行为模式 ##### 3.1 Template Method模式 - **定义**：模板方法模式是一种行为设计模式，它定义了算法的骨架，而将一些步骤延迟到子类中。 - **应用场景**：当希望子类重用父类的方法，但又希望子类能自由地覆盖某些特定步骤时；或者当算法的结构相同，但某些步骤的实现不同。 - **优点**：封装了不变部分，扩展可变部分；提取公共部分代码，便于维护；行为由父类控制，子类实现。 - **缺点**：每个不同的实现都需要一个子类来实现，导致类的个数增加。 ##### 3.2 Strategy模式 - **定义**：策略模式是一种行为设计模式，它使你能在运行时改变对象的行为。 - **应用场景**：当一个系统需要根据不同条件执行不同的行为；或者当一个操作中实现算法的职责应当独立于使用此算法的客户时。 - **优点**：避免使用多重条件判断语句；易于扩展，增加新的策略比较方便。 - **缺点**：客户端必须了解所有策略类，并自行决定使用哪一种策略类。 ##### 3.3 State模式 - **定义**：状态模式是一种行为设计模式，它允许对象在其内部状态改变时改变它的行为。 - **应用场景**：当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为；或者当一个操作中含有庞大的多分支结构，并且这些分支决定于对象的状态时。 - **优点**：将与特定状态相关的行为局部化，并且将不同状态的行为分割开来；允许状态转换逻辑与状态对象合成一体。 - **缺点**：状态模式的使用必然会增加系统的类和对象的个数；结构与实现都比较复杂，如果使用不当将导致程序结构和代码的混乱。 ##### 3.4 Observer模式 - **定义**：观察者模式是一种行为设计模式，它允许你定义一个订阅机制，可以在对象事件发生时通知多个“观察”该对象的其他对象。 - **应用场景**：当一个对象的状态发生改变时，所有的依赖对象都应该得到通知并自动更新；或者当对象与对象之间存在一对多的关系时。 - **优点**：减少了耦合；支持广播通信；易于扩展。 - **缺点**：如果一个观察目标对象有很多直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间；如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用。 ##### 3.5 Memento模式 - **定义**：备忘录模式是一种行为设计模式，它允许在不破坏封装的前提下捕获一个对象的内部状态，并在该对象之外保存这个状态。 - **应用场景**：当需要保存和恢复数据时，不能简单地存储内部状态，因为可能有复杂的计算或者是临时的信息；或者当需要记录一个对象的多个状态，并且需要在不破坏封装性的前提下在对象之外保存这些状态时。 - **优点**：可以保存和恢复数据而无需暴露对象的内部状态；简化了原发器。 - **缺点**：消耗额外的内存空间。 ##### 3.6 Mediator模式 - **定义**：中介者模式是一种行为设计模式，它通过一个中介对象来封装一系列的对象交互。 - **应用场景**：当一组对象以定义良好但是复杂的方式进行通信；或者当系统中对象之间存在复杂的引用关系，以至于难以复用一个对象。 - **优点**：降低了类的复杂度，将一对多的依赖转化为一对一的依赖；各个类之间的解耦。 - **缺点**：中介者模式的使用需要额外的工作。 ##### 3.7 Command模式 - **定义**：命令模式是一种行为设计模式，它把请求包封为对象，从而让你可以使用不同的请求、队列或者日志来参数化其他对象。 - **应用场景**：当需要将请求调用者和请求接收者解耦；或者需要在不同的时间点指定请求、排队或者执行请求时。 - **优点**：降低了对象之间的耦合度；新的命令可以很容易添加到系统中去。 - **缺点**：可能导致某些系统有过多的具体命令类。 ##### 3.8 Visitor模式 - **定义**：访问者模式是一种行为设计模式，它让你能定义一个新的操作，而不用改变类的结构。 - **应用场景**：当一个对象结构包含很多类型的对象，希望对这些对象实施一些依赖于其具体类的操作；或者当需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作“污染”这些对象的类。 - **优点**：增加新的操作很容易；符合单一职责原则。 - **缺点**：增加新的元素类很困难。 ##### 3.9 Chain of Responsibility模式 - **定义**：职责链模式是一种行为设计模式，它让你可以将请求沿着处理者链进行发送。收到请求后，每个处理者均可对请求进行处理，或将其传递给链上的下一个处理者。 - **应用场景**：当多个对象处理同一个请求，具体哪一个对象处理该请求由运行时刻自动确定；或者希望在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。 - **优点**：降低耦合度；简化了对象；增强了给对象指派职责的灵活性。 - **缺点**：不能保证请求一定被接收；系统性能将受到一定影响。 ##### 3.10 Iterator模式 - **定义**：迭代器模式是一种行为设计模式，它允许遍历一个聚合对象，而无需暴露它的内部表示。 - **应用场景**：当需要遍历容器内的元素；或者希望提供多种方式来遍历容器内的元素。 - **优点**：它支持以不同的方式遍历一个聚合对象；迭代器简化了聚合类；在同一个聚合上可以有多个遍历。 - **缺点**：由于迭代器模式将存储结构和遍历结构分离，增加新的聚合类需要对应增加新的迭代器类。 ##### 3.11 Interpreter模式 - **定义**：解释器模式是一种行为设计模式，它允许为语言定义一个文法表示，并且基于该文法表示解析表达式。 - **应用场景**：当有一个简单的语言需要解释执行；或者希望运行时通过代码定义语法来解析表达式。 - **优点**：易于改变和扩展文法；增加新的语法规则很方便。 - **缺点**：对于复杂文法难以维护；解释器模式会引起类膨胀；采用解释器模式将会增加许多类。 #### 4. 总结 设计模式的学习和应用对于软件开发人员来说至关重要。通过对这些模式的理解和实践，我们可以更好地解决软件开发中的常见问题，提高代码质量和可维护性。本文详细介绍了GoF所提出的23种设计模式，包括创建型、结构型和行为型模式，并针对每一种模式给出了定义、应用场景、优缺点等方面的解析。希望本文能对读者理解和应用这些设计模式有所帮助。