设计模式原则

设计模式的基本原则

设计模式的基本原则非常重要，只要真正深入地理解了设计原则，很多设计模式其实就是原则的应用而已，或许在不知不觉中就在使用设计模式了：

单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化的原因。

单一职责原则（SRP：Single responsibility principle）

定义

一个类应该只有一个发生变化的原因，即一个类只负责一项职责。

如果一个类有多个职责，这些职责就耦合在了一起。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起会影响复用性。

此原则的核心是解耦和增强内聚性。

由来

类A负责两个职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类A时，有可能会导致原本运行正常的职责P2功能发生故障。

解决方案

遵循SRP。分别建立两个类A1、A2，使A1完成职责P1，A2完成职责P2。这样，当修改类A1时，不会影响到职责A2；同理，当修改A2时，也不会影响到职责P1。

优点

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

提高类的可读性，提高系统的可维护性。

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

开放-封闭原则（OCP），是说软件实体（类、模块、函数等等）应该可以拓展，但是不可修改。

⚠️注意这个是理想化的

定义

一个软件实体(如类、模块、函数)应当对扩展开放，对修改关闭。

定义解读

在项目开发的时候，都不能指望需求是确定不变化的，大部分情况下，需求是变化的。那么如何应对需求变化的情况？这就是开放-关闭原则要谈的。

开放-封闭原则的思想就是设计的时候，尽量让设计的类做好后就不再修改，如果有新的需求，通过新加类的方式来满足，而不去修改现有的类(代码)。那么在实际的项目开发中，是否能做到绝对的对修改关闭呢？答案一般也是否定的。既然这样，那么就要求我们在开发前，去找出变化点，然后针对变化点构造抽象，隔离出这些变化。由此可见，实现开闭原则关键是抽象。

优点

具有灵活性，通过拓展一个功能模块即可实现功能的扩充，不需修改内部代码。

具有稳定性，表现在基本功能类不允许被修改，使得被破坏的程度大大下降。

总结

对于设计模式的六大设计原则，单一职责原则主要说明类的职责要单一；里氏替换原则强调不要破坏继承体系；依赖倒置原则描述要面向接口编程；接口隔离原则讲解设计接口的时候要精简；迪米特法则告诉我们要降低耦合；开闭原则讲述的是对扩展开放，对修改关闭。

六大设计原则并没有很明显的界限，当我们在遵守某一个设计原则的时候，可能也遵守了其他的设计原则。设计原则是后面要讲述的设计模式的基础，因此在本系列讲述设计模式之前，对设计原则进行了解说。

依赖倒转原则（DIP），A. 高层模块不应该依赖低层模块，两个都应该依赖抽象。B. 抽象不应该依赖细节，细节应该依赖抽象。

定义

高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖细节；细节应该依赖抽象。

定义解读

依赖倒置原则在程序编码中经常运用，其核心思想就是面向接口编程，高层模块不应该依赖低层模块(原子操作的模块)，两者都应该依赖于抽象。我们平时常说的“针对接口编程，不要针对实现编程”就是依赖倒转原则的最好体现：接口（也可以是抽象类）就是一种抽象，只要不修改接口声明，大家可以放心大胆调用，至于接口的内部实现则无需关心，可以随便重构。这里，接口就是抽象，而接口的实现就是细节。如果不管高层模块还是底层模块，它们都依赖于抽象，具体一点就是接口或者抽象类，只要接口是稳定的，那么任何一个的更改都不用担心其他受到影响，这就使得无论高层模块还是低层模块都可以很容易地被复用。

依赖倒转原则其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之那就是过程化的设计(说这句话可能不怎么好理解，再加上一句话就好理解了：面向对象的设计，出发点就是应对变化的问题)。

再举一个生活中的例子，电脑中内存或者显卡插槽，其实是一种接口，而这就是抽象；只要符合这个接口的要求，无论是用金士顿的内存，还是其它的内存，无论是4G的，还是8G的，都可以很方便、轻松的插到电脑上使用。而这些内存条就是具体实现，就是细节。

错误做法：抽象A依赖于实现细节b

正确做法：抽象A依赖于抽象B，实现细节b实现抽象B

优点

代码结构清晰，维护容易。

问题提出

类A直接依赖类B，假如需要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

解决方案

将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在C#/Java中，抽象指的是接口或者抽象类；在Objective-C中，抽象指的是委托，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成

里氏代换原则（LSP），子类型必须能够替换掉它们的父类型。

定义：

所有引用基类（父类）的地方必须能透明地使用其子类的对象。

只要父类能出现的地方子类就可以出现，而且替换为子类还不产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。

下面通过具体程序实例进行进一步的解释。

父类作函数声明，但并不实现具体函数，以虚函数的形式呈现，即什么也不做，空实现。

子类一继承自父类SourceView，并具体实现 show 方法

子类二同样继承自父类SourceView，并具体实现 show 方法

最后在ViewController中引入，并实例化，最终运行结果如下：

由此，便用一个非常简单的实例演示了里氏代换原则。

里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

在使用里氏代换原则时需要注意如下几个问题：

子类必须实现父类所有非私有的属性和方法 或 子类的所有非私有属性和方法必须在父类中声明。即，子类可以有自己的“个性”，这也就是说，里氏代换原则可以正着用，不能反着用（在项目中，采用里氏替换原则时，尽量避免子类的“个性”，一旦子类有“个性”，这个子类和父类之间的关系就很难调和了）。根据里氏代换原则，为了保证系统的扩展性，在程序中通常使用父类来进行定义，如果一个方法只存在子类中，在父类中不提供相应的声明，则无法在以父类定义的对象中使用该方法。

尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法，运行时，子类实例替换父类实例，我们可以很方便地扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。

迪米特法则（LoD），如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

迪米特法则又叫最少知道原则，最早是在1987年由美国Northeastern University的Ian Holland提出。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。于是就提出了迪米特法则。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。

迪米特法则的简单定义：

只与直接的朋友通信。

首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，当前对象本身（this）、成员变量、以参数形式传入当前对象方法中的对象、方法返回值中的类，当前对象创建的对象为直接的朋友。

迪米特法则的作用：

迪米特法则可降低系统的耦合度，使类与类之间保持较低的耦合关系。我们知道，软件编程有一个总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。低耦合的优点不言而喻，但是怎么样编程才能做到低耦合呢？那正是迪米特法则要去完成的。

迪米特法则的示例：

如图1所示，类之间存在复杂的交互关系，一个ClassBase类的动作执行将导致多个其它关联类产生响应，例如，当ClassBase有动作时时，和它有关联的类ClassB、ClassC、ClassD等都将发生改变，在初始设计方案中，对象之间的交互关系可简化为如图1所示结构：

在图1中，由于类之间的交互关系复杂，导致在该系统中增加新的对象时需要修改与之交互的其它类的源代码，系统扩展性较差，也不便于增加和删除新对象。

在本示例中，可以通过引入一个专门用于控制对象间交互的中介类(Mediator)来降低各对象之间的耦合度。引入中间类之后，相关对象之间不再发生直接引用，而是将请求先转发给中间类，再由中间类来完成对其它对象的调用。当需要增加或删除新的对象时，只需修改中间类即可，无须修改新增对象或已有对象的源代码，重构后结构如图2所示：

迪米特法则的使用总结：

(1).在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波及；

(2).在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限；

(3).在类的设计上，只要有可能，一个类型应当设计成不变类；

(4).在对其他类的引用上，一个对象对其他对象的引用应当降到最低。

合成/聚合复用原则（CARP），尽量使用合成/聚合，尽量不要使用类继承。

组合/聚合复用原则（Composite/Aggregate Reuse Principle CARP）.组合和聚合都是对象建模中关联（Association）关系的一种.聚合表示整体与部分的关系，表示“含有”，整体由部分组合而成，部分可以脱离整体作为一个独立的个体存在。组合则是一种更强的聚合，部分组成整体，而且不可分割，部分不能脱离整体而单独存在。在合成关系中，部分和整体的生命周期一样，组合的新的对象完全支配其组成部分，包括他们的创建和销毁。一个合成关系中成分对象是不能与另外一个合成关系共享。

组合/聚合和继承是实现复用的两个基本途径。合成复用原则是指尽量使用合成/聚合，而不是使用继承。

只有当以下的条件全部被满足时，才应当使用继承关系。

1. 子类是超类的一个特殊种类，而不是超类的一个角色，也就是区分“Has-A”和“Is-A”.只有“Is-A”关系才符合继承关系，“Has-A”关系应当使用聚合来描述。

2 .永远不会出现需要将子类换成另外一个类的子类的情况。如果不能肯定将来是否会变成另外一个子类的话，就不要使用继承。

3 .子类具有扩展超类的责任，而不是具有置换掉或注销掉超类的责任。如果一个子类需要大量的置换掉超类的行为，那么这个类就不应该是这个超类的子类。

错误的使用继承而不是合成/聚合的一个常见原因是错误地把“Has-A”当成了“Is-A”.”Is-A”代表一个类是另外一个类的一种；而“Has-A”代表一个类是另外一个类的一个角色，而不是另外一个类的特殊种类。

我们需要办理一张银行卡，如果银行卡默认都拥有了存款、取款和透支的功能，那么我们办理的卡都将具有这个功能，此时使用了继承关系：

为了灵活地拥有各种功能，此时可以分别设立储蓄卡和信用卡两种，并有银行卡来对它们进行聚合使用。此时采用了合成复用原则: