C++ 设计模式面向对象设计原则相关概念介绍

（结合UnrealEngine4）2020.5.4修订

面向对象设计原则（1）

依赖倒置原则（DIP）

开放封闭原则（OCP）

单一职责原则（SRP）

该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：

单一职责原则的优点

Liskov 替换原则（LSP）

接口隔离原则（ISP）

优先使用对象组合，而不是类继承

封装变化点

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

面向对象设计原则（1）

依赖倒置原则（DIP）

• 高层模块(稳定)不应该依赖于低层模块(变化)，二者都应该依赖于抽象(稳定) 。

• 抽象(稳定)不应该依赖于实现细节(变化) ，实现细节应该依赖于抽象(稳定)。

开放封闭原则（OCP）

• 对扩展开放，对更改封闭。

• 类模块应该是可扩展的，但是不可修改。

单一职责原则（SRP）

• 一个类应该仅有一个引起它变化的原因。

• 变化的方向隐含着类的责任。

该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：

1、一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；

2、当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。

单一职责原则的优点

单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点。

1、降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。

2、提高类的可读性。复杂性降低，自然其可读性会提高。

3、提高系统的可维护性。可读性提高，那自然更容易维护了。

4、变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

Liskov 替换原则（LSP）

• 子类必须能够替换它们的基类(IS-A)。

• 继承表达类型抽象。

接口隔离原则（ISP）

• 不应该强迫客户程序依赖它们不用的方法。

• 接口应该小而完备。

优先使用对象组合，而不是类继承

• 类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。

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

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

封装变化点

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

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

• 不将变量类型声明为某个特定的具体类，而是声明为某个接口。

• 客户程序无需获知对象的具体类型，只需要知道对象所具有的接口。

• 减少系统中各部分的依赖关系，从而实现“高内聚、松耦合” 的类型设计方案。

相关概念

继承（英语：inheritance）

是面向对象软件技术当中的一个概念。如果一个类别A“继承自”另一个类别B，就把这个A称为“B的子类别”，而把B称为“A的父类别”也可以称“B是A的派生类”。继承可以使得子类别具有父类别的各种属性和方法，而不需要再次编写相同的代码。在令子类别继承父类别的同时，可以重新定义某些属性，并重写某些方法，即覆盖父类别的原有属性和方法，使其获得与父类别不同的功能。另外，为子类别追加新的属性和方法也是常见的做法。一般静态的面向对象编程语言，继承属于静态的，意即在子类别的行为在编译期就已经决定，无法在执行期扩充。

面向对象的接口编辑

在C++中，一个类被允许继承多个类。但是在Java以后的语言不被允许。

这样，如果想继承多个类时便非常困难。所以开发方想出了新办法：接口。

一个接口内，允许包含变量、常量等一个类所包含的基本内容。但是，接口中的函数不允许设定代码，也就意味着不能把程序入口放到接口里。由上可以理解到，接口是专门被继承的。接口存在的意义也是被继承。和C++里的抽象类里的纯虚函数是相同的。不能被实例化。

耦合

定义

耦合性也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。

耦合度就是某模块（类）与其它模块（类）之间的关联、感知和依赖的程度，是衡量代码独立性的一个指标，也是软件工程设计

及编码质量评价的一个标准。耦合的强度依赖于以下几个因素：

（1）一个模块对另一个模块的调用；

（2）一个模块向另一个模块传递的数据量；

（3）一个模块施加到另一个模块的控制的多少；

（4）模块之间接口的复杂程度。

分类

耦合按从强到弱的顺序可分为以下几种类型：

1、非直接耦合：两模块间没有直接关系，之间的联系完全是通过主模块的控制和调用来实现的　　

2、数据耦合：指两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言的值传递;　

3、标记耦合：指两个模块之间传递的是数据结构，如高级语言中的数组名、记录名、文件名等这些名字即标记，其实传递的是这个数据结构的地址;　　

4、控制耦合：一指一个模块调用另一个模块时，传递的是控制变量（如开关、标志等），被调模块通过该控制变量的值有选择地执行块内某一功能;　

5、外部耦合：一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数传递该全局变量的信息　　

6、公共耦合：一组模块都访问同一个公共数据环境。该公共数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。　　

7、内容耦合：这是最高程度的耦合，也是最差的耦合。当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部。

为什么要低耦合（解耦合）

在面向对象编程中，对象自身是内聚的，是保管好自己的数据，完成好自己的操作的，而对外界呈现出自己的状态和行为。但是，没有绝对的自力更生，对外开放也是必要的！一个对象，往往需要跟其他对象打交道，既包括获知其他对象的状态，也包括仰赖其他对象的行为，而一旦这样的事情发生时，我们便称该对象依赖于另一对象。只要两个对象之间存在一方依赖一方的关系，那么我们就称这两个对象之间存在耦合。比如妈妈和baby，妈妈要随时关注baby的睡、醒、困、哭、尿等等状态，baby则要仰赖妈妈的喂奶、哄睡、换纸尿裤等行为，从程序的意义上说，二者互相依赖，因此也存在耦合。首先要说，耦合是必要的。

耦合的程度就是耦合度，也就是双方依赖的程度。上文所说的妈妈和baby就是强耦合。而你跟快递小哥之间则是弱耦合。一般来说耦合度过高并不是一件好事。就拿作为IT精英的你来说吧，上级随时敦促你的工作进度，新手频繁地需要你指导问题，隔三差五还需要参加酒局饭局，然后还要天天看领导的脸色、关注老婆的心情，然后你还要关注代码中的bug 、bug、bug，和需求的变化、变化、变化，都够焦头烂额了，还猝不及防的要关注眼睛、颈椎、前列腺和头发的状态，然后你再炒个股，这些加起来大概就是个强耦合了。从某种意义上来说，耦合天生就与自由为敌，无论是其他对象依赖于你，还是你依赖其他对象。比如有人嗜烟、酗酒，你有多依赖它们就有多不自由；比如有人家里生了七八个娃，还有年迈的父母、岳父母，他们有多依赖你，你就有多不自由。所以老子这样讲：“五音令人耳聋，五色令人目盲，驰骋狩猎令人心发狂，难得之货令人行妨。”卢梭也是不无悲凉的说“人生而自由，却又无往而不在枷锁中”。因此，要想自由，就必须要降低耦合，而这个过程就叫做解耦和。

耦合度很高的情况下，维护代码时修改一个地方会牵连到很多地方，如果修改时没有理清这些耦合关系，那么带来的后果

可能会是灾难性的，特别是对于需求变化较多以及多人协作开发维护的项目，修改一个地方会引起本来已经运行稳定的模块错误，严重时会导致恶性循环，问题永远改不完，开发和测试都在各种问题之间奔波劳累，最后导致项目延期，用户满意度降低，成本也增加了，这对用户和开发商影响都是很恶劣的，各种风险也就不言而喻了。

如何降低耦合（解耦合）

少使用类的继承，多用接口隐藏实现的细节。
模块的功能化分尽可能的单一，道理也很简单，功能单一的模块供其它模块调用的机会就少。（其实这是高内聚的一种说法，高内聚低耦合一般同时出现）。
遵循一个定义只在一个地方出现。
少使用全局变量。
类属性和方法的声明少用public，多用private关键字，
多用设计模式，比如采用MVC的设计模式就可以降低界面与业务逻辑的耦合度。
尽量不用“硬编码”的方式写程序，同时也尽量避免直接用SQL语句操作数据库。
最后当然就是避免直接操作或调用其它模块或类（内容耦合）；如果模块间必须存在耦合，原则上尽量使用数据耦合，少用控制耦合，
限制公共耦合的范围，避免使用内容耦合。

内聚

内聚，通俗的来讲，就是自己的东西自己保管，自己的事情自己做。每个模块尽可能独立完成自己的功能，不依赖于模块外部的代码。

对象是什么？对象就是保管好自己的东西，做好自己的事情的程序模块——这就是内聚！当然，对象的内聚只是内聚的一个层次，在不同的尺度下其实都有内聚的要求，比如方法也要讲内聚，架构也要讲内聚。

内聚：内聚性又称块内联系。指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素（语名之间、程序段之间）联系的越紧密，则它的内聚性就越高。

高内聚:类与类之间的关系而定，高，意思是他们之间的关系要简单，明了，不要有很强的关系，不然，运行起来就会出问题。一个类的运行影响到其他的类。由于高内聚具备鲁棒性，可靠性，可重用性，可读性等优点，模块设计推荐采用高内聚。

内聚度是指内部各元素之间联系的紧密程度，模块的内聚种类通常可分为7种，按其内聚度从低

到高的次序依此为：偶然内聚、逻辑内聚、瞬时内聚、过程内聚、通信内聚、顺序内聚、功能内聚。

偶然内聚: 指一个模块内的各处理元素之间没有任何联系。
逻辑内聚: 指模块内执行几个逻辑上相似的功能，通过参数确定该模块完成哪一个功能。
时间内聚: 把需要同时执行的动作组合在一起形成的模块为时间内聚模块。
通信内聚: 指模块内所有处理元素都在同一个数据结构上操作（有时称之为信息内聚），或者指各处理使用相同的输入数据或者产生相同的输出数据。
顺序内聚: 指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素输出就是下一功能元素的输入。
功能内聚: 这是最强的内聚，指模块内所有元素共同完成一个功能，缺一不可。与其他模块的耦合是最弱的。

GOF设计模式分类

从目的来看：

• 创建型（Creational）模式：将对象的部分创建工作延迟到子类或者其他对象，从而应对需求变化为对象创建时具体类型实现引来的冲击。

• 结构型（Structural）模式：通过类继承或者对象组合获得更灵活的结构，从而应对需求变化为对象的结构带来的冲击。

• 行为型（Behavioral）模式：通过类继承或者对象组合来划分类与对象间的职责，从而应对需求变化为多个交互的对象带来的冲击。

从范围来看：

• 类模式处理类与子类的静态关系。

• 对象模式处理对象间的动态关系。

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

组件协作：

• Template Method

• Observer / Event

• Strategy

单一职责：

• Decorator

• Bridge

对象创建:

• Factory Method

• Abstract Factory

• Prototype

• Builder

对象性能：

• Singleton

• Flyweight

接口隔离:

• Façade

• Proxy

• Mediator

• Adapter

状态变化：

• Memento

• State

数据结构：

• Composite

• Iterator

• Chain of Resposibility

行为变化：

• Command

• Visitor

领域问题：

• Interpreter

重构获得模式 Refactoring to Patterns

面向对象设计模式是“好的面向对象设计”，所谓“好的面向对象设计”指是那些可以满足 “应对变化，提高复用”的设计。
现代软件设计的特征是“需求的频繁变化”。设计模式的要点是 “寻找变化点，然后在变化点处应用设计模式，从而来更好地应对需求的变化”.“什么时候、什么地点应用设计模式”比“理解设计模式结构本身”更为重要。
设计模式的应用不宜先入为主，一上来就使用设计模式是对设计模式的最大误用。没有一步到位的设计模式。敏捷软件开发实践提倡的“Refactoring to Patterns”是目前普遍公认的最好的使用设计模式的方法。

重构关键技法

静态 → 动态
早绑定 → 晚绑定
继承 → 组合
编译时依赖 → 运行时依赖
紧耦合 → 松耦合

参考资料：AboutCG,B站设计模式相关教程