【设计模式】六大设计原则

接下来打算系统学一遍设计模式，后面会更新一系列的 设计模式 文章，学习资料是小傅哥的《重写Java设计模式》。微信读书链接：https://weread.qq.com/web/reader/bcf32900724708cbbcf08c1kc81322c012c81e728d9d180

关于设计模式

设计模式是系统服务设计中针对常见场景的一种解决方案，可以解决功能逻辑开发中遇到的共性问题。

因为设计模式是一种开发设计指导思想，每一种设计模式都是解决某一类问题的概念模型，所以在实际的使用过程中，不要拘泥于某种已经存在的固定代码格式，而要根据实际的业务场景做出改变。

正因为设计模式的这种特点，所以即使是同一种设计模式，在不同的场景中也有不同的代码实现方式。另外，即便是相同的场景，选择相同的设计模式，不同的研发人员也可能给出不一样的实现方案。

所以，设计模式并不局限于最终的实现方案，而是在这种概念模型下，解决系统设计中的代码逻辑问题。

六大设计原则

单一职责原则

单一职责原则定义单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，是面向对象的五个基本原则（SOLID）之一。它规定一个类应该只有一个发生变化的原因，该原则由罗伯特·C.马丁（Robert C.Martin）在《敏捷软件开发：原则、模式与实践》一书中提出。

如果需要开发的一个功能需求不是一次性的，且随着业务发展的不断变化而变化，那么当一个Class类负责超过两个及以上的职责时，就在需求的不断迭代、实现类持续扩张的情况下，就会出现难以维护、不好扩展、测试难度大和上线风险高等问题。

所谓的职责就是指类变化的原因，也就是业务需求。如果一个类有多于一个的原因被改变，那么这个类就有超过两个及以上的职责。而单一职责约定一个类应该有且仅有一个改变类的原因。

开闭原则

一般认为最早提出开闭原则（Open-Close Principle，OCP）的是伯特兰·迈耶。他在1988 年发表的《面向对象软件构造》中给出的。在面向对象编程领域中，开闭原则规定软件中的对象、类、模块和函数对扩展应该是开放的，但对于修改是封闭的。这意味着应该用抽象定义结构，用具体实现扩展细节，以此确保软件系统开发和维护过程的可靠性。

开闭原则的核心思想也可以理解为面向抽象编程。

里氏替换原则

里氏替换原则（Liskov Substitution Principle，LSP）是由麻省理工学院计算机科学系教授芭芭拉·利斯科夫（Barbara Liskov）于 1987 年在“面向对象技术的高峰会议”（OOPSLA）上发表的一篇文章《数据抽象和层次》（Data Abstractionand Hierarchy）里提出的，她提出：继承必须确保超类所拥有的性质在子类中仍然成立。

里氏替换原则

如果S是T的子类型，那么所有T类型的对象都可以在不破坏程序的情况下被S类型的对象替换。 简单来说，子类可以扩展父类的功能，但不能改变父类原有的功能。

也可以这样认为：当子类继承父类时，除添加新的方法且完成新增功能外，尽量不要重写父类的方法。 这句话包括了四点含义：

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
• 子类可以增加自己特有的方法。
• 当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松。
• 当子类的方法实现父类的方法（重写、重载或实现抽象方法）时，方法的后置条件（即方法的输出或返回值）要比父类的方法更严格或与父类的方法相等。

里氏替换原则的作用

• 氏替换原则是实现开闭原则的重要方式之一。
• 解决了继承中重写父类造成的可复用性变差的问题。
• 是动作正确性的保证，即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。
• 加强程序的健壮性，同时变更时可以做到非常好的兼容性，提高程序的维护性、可扩展性，降低需求变更时引入的风险。

里氏替换原则的目的是使用约定的方式，让使用继承后的代码具备良好的扩展性和兼容性。

迪米特法则原则

1987年秋天，迪米特法则由美国Northeastern University的Ian Holland提出，被UML的创始者之一Booch等人普及。后来，因为经典著作The PragmaticProgrammer而广为人知。

迪米特法则（Law of Demeter，LoD）又称为最少知道原则（Least KnowledgePrinciple，LKP），是指一个对象类对于其他对象类来说，知道得越少越好。也就是说，两个类之间不要有过多的耦合关系，保持最少关联性。

举个学生、老师、校长之间关系的例子来说明迪米特法则。老师需要负责具体某一个学生的学习情况，而校长会关心老师所在班级的总体成绩，不会过问具体某一个学生的学习情况。

接口隔离原则

《代码整洁之道》的作者Robert C.Martin于2002年给“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法（Clients should not be forced todepend on methods they do not use）。该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上（The dependency of one class toanother one should depend on the smallest possible interface）。

接口隔离原则（Interface Segregation Principle，ISP）要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。

接口隔离是为了高内聚、低耦合。在实际的业务开发中，通常会先定义好需要开发的接口，并由各个服务类实现。但如果没有经过考虑和设计，就很可能造成一个接口中包括众多的接口方法，而这些接口并不一定在每一个类中都需要实现。这样的接口很难维护，也不易于扩展，每一次修改验证都有潜在的风险。

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

• 接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
• 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
• 了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同，要深入了解业务逻辑。
• 提高内聚，减少对外交互。让接口用最少的方法完成最多的事情。

依赖倒置原则

依赖倒置原则是Robert C.Martin于1996年在C++Report上发表的文章中提出的。

依赖倒置原则（Dependence Inversion Principle，DIP）是指在设计代码架构时，高层模块不应该依赖于底层模块，二者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。

依赖倒置原则是实现开闭原则的重要途径之一，它降低了类之间的耦合，提高了系统的稳定性和可维护性，同时这样的代码一般更易读，且便于传承。

Copyright: 采用 知识共享署名4.0 国际许可协议进行许可 Links: https://lixj.fun/archives/设计模式-六大设计原则