ly52352148的博客

此书从1994年出版至今已有30年，虽然大部分依然十分有效，但是难免部分内容已经不适合现代的开发习惯，或者几乎不在实际生产中使用。中说的一样，我会把更多的精力放在那些使用频率高的场景中。用20%的精力学习80%的常用场景，然后在实际生产中，根据业务和团队特点，针对性学习，可以做到事半功倍。本系列，主要结合个人经验，对《设计模式：可复用面向对象软件的基础》书中经典设计模式，用极简的语言说明核心作用和使用场景，并用c++实现。最后，本系列的文章，是我在工作之余，从个人历史的笔记、总结、分享中提炼出来。

个人说明：原则是为了目标设定的，设计目标是：对过去的系统稳定，对未来的系统扩展成本低。不管什么原则，都是为了这两个核心目的而服务的。其中开闭原则是为了系统稳定，其他原则的核心思想都是，在扩展时，尽量改动少的逻辑，降低开发成本。原则不是盲目使用和万能的，当某些场景，使用该原则违背了目的，我们需要修改甚至放弃它。记住目的，远比记住原则重要。

本章简要说明工厂模式如何实践。并给出我认为的最佳实践代码。

直到设计、开发时发现，对象的构建过程比较复杂，且在较多场景需要构造，且构造过程不同。个人更偏爱工厂模式来做创建，将类的创建过程封装到一个函数，如果有不同的构建需求，通过输入参数走不同的构建逻辑，如果类的构建十分负责，如构建一个“人”，则通过组合的方式，构建多个类（如手脚头等），挂在“人”下面。： “类构建过程”和“类的属性、结构、行为”分离。将对象的构建过程拆分成多个步骤，并定义一个抽象接口以及具体的实现类来完成每个步骤。这里的本质是大部分场景，“未来降低的维护成本”低于“当前增加的维护成本”

本文章属于专栏继续上一篇。本章简要说明单例模式。本文分为模式说明、本质思想、实践建议、代码示例四个部分。模式说明本质思想。

难以维护，且只能在小范围使用，另外指向派生类的基类的深拷贝效率低，所以使用频率极低。如果实在需要，在基类中维护一个基础类型，转换时，通过基础类型判断，转换成派生类再拷贝。：通过基类虚函数，规范指向派生类的基类的拷贝行为。模式说明、本质思想、实践建议、代码示例。本章简要说明原型模式。

适配器模式通过引入一个适配器类来兼容不同接口，使得原本无法一起工作的类能够相互合作。它将一个类的接口转换成客户端所期望的另一个接口，使得原本由于接口不匹配而无法在一起工作的类能够协同工作。：合并多个不同的类，提供同一的调用接口，是在应用维护中使用，以解决设计时未考虑到的共性问题。模式说明、本质思想、实践建议、代码示例。本章简要说明适配器模式。

模式说明、本质思想、实践建议、代码示例。本章简要说明桥接模式。

示例代码// 基类 Birdpublic:// 具体类：鸟类public:} // 飞行鸟public:} // 水中鸟// 具体过滤器：飞行鸟过滤器public:// 过滤器使用示例}else {/*输出：*/return 0;

类A中有一个数组，数组里面都是A*（可以实际指向A的派生类），这样可以建一个全是A的树。：在运行时，需要构建一个全是相同基类的树，并要统一处理时使用。本章简要说明组合模式。模式说明、本质思想、实践建议、代码示例。

派生类和装饰类都继承Base，然后装饰器类中放一个Base指针，存派生类。这样装饰器类和派生类可以放一个数组中，调用相同接口，这样部分类的功能看起来像被装饰了。前面是核心思想，基于这个再扩展，很容器基于装饰器加装饰器，或者把有相似接口的装饰器抽象出一个装饰器基类。方案： 装饰类和派生类同根，然后装饰类中放一个派生类，以在接口不动的情况下增加功能。注意组合关系，确保装饰器和被装饰对象之间的接口一致。缺点： 增加了许多小对象，易于出错，不易调试。装饰器的功能应该是可组合的，可叠加的。

【代码】《外观模式（极简c++）》

在有大量相似对象时，且相似部分状态不变时使用（如果要变。则需要对象提供的接口全部线程安全，则有性能风险，需要慎重）：将对象分为可共享的内部状态和不可变的外部状态，通过共享内部状态来减少对象的数量，以节省内存和提高性能。

确保代理和真实对象具有相同的接口，以便可以无缝替换。代理的核心作用是隔离，这里要实践中，：代理模式的核心思想是在访问对象时引入一定程度的间接性，以在访问时进行一些额外的处理。，也就是两个团队维护同一个的系统时，使用代理模式，将极大提高组织开发效率。收益最高的是组织隔离。

该模式会降低性能，且分离的处理逻辑分支，会降低代码可读性。当遇到逻辑复杂，判断分支繁琐的逻辑，我们要做的是解耦，而不是把代码简单地拆开。：责任链模式的本质思想是将多个处理者组成一条链，依次尝试处理请求，直到找到能够处理该请求的对象为止。

把调用的语义封装在一个具体的命令对象中，再创建一个执行调用命令的方法，这样对于所有传入的命令，都可以复用“调用命令的方法”。比如“一只鸟飞起来，然后吃东西”，会有一个有一个调用命令的方法，做的事情是“先执行A，再执行B”，然后传入命令A为“燕子飞起来”，传入“燕子吃东西”。核心收益是，命令调用者的逻辑就可以复用了。：在命令调用顺序固定，且使用高频时，把这部分逻辑抽象出命令模式。降低命令流程和命令本身的耦合。注意这块不适合放在业务占用cpu极高的代码部分，它对性能有少量影响。

解释器模式通过将语言的文法表示为类的层次结构，然后建立解释器来解释这些类，从而实现对语言的解释和执行。：除了正则表达式，文本相关的解析等特别灵活、规则链复杂的场景。95%以上的业务用不到。

c++以及大部分语言中，都有自己封装好的第三方迭代器。如std::vector，业务代码一般不需要单独封装，而是把基类指针放到容器中，就可以实现去除实现细节的遍历。：将对容器的遍历操作封装到迭代器对象中，使得遍历操作可以独立于容器实现。这样，容器可以改变其内部结构而不影响遍历操作。

对象和对象之间的交互逻辑有共性，且对象之间接口需要解耦时使用。和代理模式类似，也是在隔离组织的时候引入，如一个组织开发sdk，另一个组织开发服务时。代理模式隔离的是，访问者和被访问的资料，中介模式隔离的是沟通者和沟通者。不论哪种模式，只有当两边在不同的组织或者被不同的人维护时，才有必要使用，否则降低了开发、维护效率，也降低了代码运行效率。：通过引入一个中介者对象，将系统中的对象解耦，使它们不再直接相互交互，而是通过中介者进行协调，从而降低系统的复杂性。

建立一个M类，可以由A类生产。A类也可以由M类还原。类似于，word写文章时，会自动保存中间状态，而这些中间状态，也可以完全恢复当时的文章。：在低频且重要的逻辑中使用，因为此模式不仅费内存，也费CPU。

观察者模式的本质是将对象之间的依赖关系从硬编码的方式转变为松耦合的方式，使得对象之间能够动态地交互。：一种软件内部模块之间的异步通知方式之一。十分好用，在软件系统中十分常见。

在实际开发中，状态一般用一个变量表示就够了，很少会抽象成一个类。如果，状态需要多个变量表示，且此类状态有固定的方法，则可以使用状态模式。这里封装的是当前状态，以及状态附属的行为。另外，不管是“状态类”作为参数传给“上下文类”执行，还是“上下文类”传给”状态类“执行，没有本质的区别。： 状态模式的本质是将对象的状态抽象为一个独立的类，使得对象在不同状态下有不同的行为，并且能够动态地切换状态。

空对象模式的本质思想是在缺少有效对象时，提供一个默认的“空”对象，使得客户端代码无需特殊处理空值情况，从而简化代码逻辑。，这里省去的代码检查空值以及简化的代码结构，很可能会在未来隐藏关键问题。极大地增加了运维成本。本章简要说明空对象模式。模式说明、本质思想、实践建议、代码示例。

如果算法模块是一个团队开发的，让算法团队提供统一接口，以减少服务端和策略部分耦合。如果算法模块是多个团队开发，应该是服务端同学根据多个算法模块的语意，使用策略模式，让算法模块易于使用。：策略模式通过将算法封装成独立的策略类，使得这些算法可以相互替换，客户端可以根据需求选择不同的策略。模式说明、本质思想、实践建议、代码示例。

在模版模式中，将逻辑的结构定义在一个父类中，而将具体的步骤实现延迟到子类中。这样可以在不改变算法整体结构的情况下，让子类自由地实现某些步骤，从而实现算法的定制化。在一个部门多个服务，且有相同部分可以抽象时，使用一个基类来约束大家的业务行为，不仅降低新人培养成本，也让不同人切换维护的服务成本更低。模式说明、本质思想、实践建议、代码示例。

对大部分情况下，直接修改类中的操作接口就行，如果有类似操作，一般直接抽象一个操作类，和现有类组合就行。这样代码逻辑也会更易读。数据类型A基本不变。但是对应的具体操作O会变化，把这些操作O抽象成一个类B。在类A要操作O的时候，传入类B，以触发动作。

Controller接受输入之后，更新Model，组织View。将本地缓存数据和展示数据解耦合，让不同组织之间合作效率更高。：MVC模式，最开始是做桌面应用GUI的。后来也被广泛应用在前后端结合的服务中，将前端和后端解耦，对团队效率提升极大。

和策略模式没有本质的区别，都是隔离调用者和多个可能被调用者的方式。只是被调用者是算法模块，还是业务模块。：通过引入一个代表对象，将客户端与具体业务逻辑解耦，实现业务访问的统一管理。

组合实体模式的本质思想是将一组相关对象封装到单个对象中，并提供统一的接口来访问和操作这些对象，以简化复杂性并提高系统的可维护性。，在业务中自然而然就会想到的设计模式。如果没想到，说明在对应的场景没啥用。

在业务中如果品类过多，在调整品类信息或者增加种类时，自然而然想到将品类维护到一个map或者vector中。每次使用全部，或者按需取。： 将数据存取操作从业务逻辑中分离出来，使得数据操作和业务逻辑各自独立，易于维护和扩展。

90年代，互联网还没有普及，用户量有限，机器资源有限，开发人员的培养成本高，所以通过设计模式，增加开发一致性，可扩展性和代码复用，降低开发、维护成本，是企业推崇的。而设计模式的目标是，将开发过程标准化，降低项目需要投入的开发、维护人员。基于这个背景，我们不难理解为什么一部分设计模式，以牺牲性能的代价，换取程序的扩展性。各行各业的历史经验告诉我们，没有一劳永逸，一成不变的模式，而软件系统的设计模式也一样。最后，如何在开发中，特别是项目0->1的时候，发现不用设计模式，想不到有什么明显的问题，就建议先不用，