设计模式的六大原则

引言

        设计模式的提出都是为了解决一个常见的问题而总结出来的办法。所以当你思考采用何种设计模式的时候，你应该先问问自己当前问题的是什么？根据问题去选取合适的设计模式。等你熟悉了设计模式的以后，你会发现部分设计模式之间存在包含关系，甚至很相像，但是不同的设计模式解决的问题是不一样的。

当我们在设计一个模块的时候可以从以下几个角度去考虑：

1. 这个模块与其他模块的关系是什么样的？

2. 模块中哪些部分是不变的，哪些部分是在不断变化的，是如何变化的？

3. 类与类之间的关系是怎么样的，为什么需要依赖，怎么可以不依赖？

4. 要不要加一个接口？接口的存在是为了解决什么问题？

1.单一职责

        一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则。

        这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：

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

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

优点

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

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

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

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

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

2.开闭原则

        一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

        开闭原则是一个非常虚的原则，其余5个原则是对开闭原则的具体解释。就像“好好学习，天天向上”的口号一样，告诉我们要好好学习，但是学什么，怎么学并没有告诉我们，需要去体会和掌握，开闭原则也是一个口号，那我们怎么把这个口号应用到实际工作中呢？

解决方案：

1. 使用接口和抽象类，为系统定义一个相对稳定的抽象层，而将不同的实现行为移至具体的实现层中完成；
2. 参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；
3. 抽象层尽量保持稳定，一旦确定即不允许修改；

        为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。在Java、C#等编程语言中，可以为系统定义一个相对稳定的抽象层，而将不同的实现行为移至具体的实现层中完成。想要达到这样的效果，我们需要使用接口和抽象类，可以通过它们定义系统的抽象层，再通过具体类来进行扩展。如果需要修改系统的行为，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，实现在不修改已有代码的基础上扩展系统的功能，达到开闭原则的要求。

3.里氏代换原则（Liskov Substitution Principle）

        任何基类可以出现的地方，子类一定可以出现。

        LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

        遵循里氏替换原则时，子类尽量不去重写基类的方法，如果需要大量重写时，建议再创造一个基类的基类，并继承之，使得其和之前的基类是兄弟关系，而不是父子关系；

        里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。

作用

1. 里氏替换原则是实现开闭原则的重要方式之一。

2. 它克服了继承中重写父类造成的可复用性变差的缺点。

3. 它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。

4. 加强程序的健壮性，同时变更时可以做到非常好的兼容性，提高程序的维护性、可扩展性，降低需求变更时引入的风险。

实现方法（继承）

        里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。

根据上述理解，对里氏替换原则的定义可以总结如下：

1. 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法

2. 子类中可以增加自己特有的方法

3. 当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松

4. 当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的的输出/返回值）要比父类的方法更严格或相等

        通过重写父类的方法来完成新的功能写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。如果程序违背了里氏替换原则，则继承类的对象在基类出现的地方会出现运行错误。这时其修正方法是：取消原来的继承关系，重新设计它们之间的关系。

        关于里氏替换原则的例子，最有名的是“正方形不是长方形”。当然，生活中也有很多类似的例子，例如，企鹅、鸵鸟和几维鸟从生物学的角度来划分，它们属于鸟类；但从类的继承关系来看，由于它们不能继承“鸟”会飞的功能，所以它们不能定义成“鸟”的子类。同样，由于“气球鱼”不会游泳，所以不能定义成“鱼”的子类；“玩具炮”炸不了敌人，所以不能定义成“炮”的子类等。对于正方形和长方形最好的做法是再添加一个父类，他们同时继承自这个父类。

4.依赖倒置原则

        抽象（接口/抽象类）不应该依赖于细节，细节应该依赖于抽象（接口/抽象类）。 高层模块不应该依赖于低层模块，两者都应该依赖其抽象。

这个原则是开闭原则的基础，具体内容：

1. 抽象指的是接口或者抽象类。细节指的是具体实现类。
2. 中心思想是面向接口编程；针对接口编程，依赖于抽象而不依赖于具体。

        比如有接口ICar，子类有Car1和Car2.我们在处理逻辑的时候，直接调用ICar的方法，而不是在代码里调用Car1或者Car2.

如何在项目中使用这个规则呢？

• 每个类尽量都有接口或者抽象类，或者都有
• 变量的表面类型尽量是接口或者抽象类

作用

1. 依赖倒置原则可以降低类间的耦合性。

2. 依赖倒置原则可以提高系统的稳定性。

3. 依赖倒置原则可以减少并行开发引起的风险。

4. 依赖倒置原则可以提高代码的可读性和可维护性。

实现方法

        依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性，所以我们在实际编程中只要遵循以下4点，就能在项目中满足这个规则。

1. 每个类尽量提供接口或抽象类，或者两者都具备。

2. 变量的声明类型尽量是接口或者是抽象类。

3. 任何类都不应该从具体类派生。

4. 使用继承时尽量遵循里氏替换原则。

5.接口隔离原则

        客户端不应该依赖它不需要的接口，类间的依赖关系应该建立在最小的接口上。

        接口隔离原则（Interface Segregation Principle，ISP）要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。2002 年罗伯特·C.马丁给“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法（Clients should not be forced to depend on methods they do not use）。该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上（The dependency of one class to another one should depend on the smallest possible interface）。以上两个定义的含义是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

        接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：

1. 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。

2. 单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。

优点

接口隔离原则是为了约束接口、降低类对接口的依赖性，遵循接口隔离原则有以下 5 个优点。

1. 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。

2. 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。

3. 如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。

4. 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。

5. 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。

实现方法

在具体应用接口隔离原则时，应该根据以下几个规则来衡量。

1. 接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。

2. 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。

3. 了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。

4. 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

类A：
{
    类B b;
}
 
类B：
{
    Fun1();
    Fun2();
}

        一个类A，即使只需要类B的某些功能时，还是会持有一个类B的实例。这样相当于把整个类B的所有功能都暴露给了外部，这样是不好的，我们可以修改为类A只持有需要功能的接口实例。因此需要将类B的所有功能拆分为N个接口，继承接口并实现方法。

6.迪米特法则，又称最少知道原则（Demeter Principle）

        一个对象应该对其他对象有最少的了解。

一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。迪米特法则对类的低耦合提出的明确的要求，包含了以下含义：

1. 只和朋友交流：朋友类的定义是这样的：出现在成员变量、方法的输入输出参数中的类称为成员朋友类，而出现在方法体内部的类不属于朋友类。
2. 朋友也是有距离的：迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、package-private、protected等访问权限。
3. 是你自己的就是你自己的：在实际应用中经常会出现这样一个方法：放在本类中也可以，放在其他类中也没有错，那怎么去衡量呢？正确做法：如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。

迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高。

优点

迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点。

1. 降低了类之间的耦合度，提高了模块的相对独立性。

2. 由于亲合度降低，从而提高了类的可复用率和系统的扩展性。

        但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。

实现方法

从迪米特法则的定义和特点可知，它强调以下两点：

1. 从依赖者的角度来说，只依赖应该依赖的对象。

2. 从被依赖者的角度说，只暴露应该暴露的方法。

所以，在运用迪米特法则时要注意以下 6 点。

1. 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。

2. 在类的结构设计上，尽量降低类成员的访问权限。

3. 在类的设计上，优先考虑将一个类设置成不变类。

4. 在对其他类的引用上，将引用其他对象的次数降到最低。

5. 不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。

6. 谨慎使用序列化（Serializable）功能

引用

设计模式的六大原则是什么-Java基础-PHP中文网

设计模式的6大原则 - 知乎 (zhihu.com)