设计模式六大原则

设计模式的六大原则（SOLID）‌是软件工程中的基本原则，它们指导我们如何设计和构建可维护、可扩展的软件系统。

这六大原则分别是：

1. Single Responsibility Principle：单一职责原则
2. Open Closed Principle：开闭原则
3. Liskov Substitution Principle：里氏替换原则
4. Law of Demeter：迪米特法则
5. Interface Segregation Principle：接口隔离原则
6. Dependence Inversion Principle：依赖倒置原则

‌一.单一职责原则

定义：一个类应该只有一个引起它变化的原因。

  这意味着一个类应该只负责一项功能或责任，如果类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或抑制该类完成其他职责的能力。

好处：

          1）更有利于代码高内聚，低耦合，降低类的复杂度。

          2）可读性更高，每个类职责清晰。

          3）可维护性更高，出现bug或者业务变更，都可以快速锁定修改代码范围，提高工作效率，降低改动风险。

二.开闭原则

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

软件实体（类、模块等）应当对扩展开放，对修改关闭。这意味着我们应当在不影响已有功能的前提下添加新功能，而不是修改现有的代码结构。

‌开放‌：指的是软件实体应该能够接受新的功能或特性的扩展，而不需要修改现有的代码。

‌关闭‌：指的是软件实体一旦完成，其内部实现细节应该保持稳定，不再允许被随意修改，除非是为了修正错误。

重要性

‌提高可维护性‌：减少因修改现有代码而引入新错误的风险。

‌增强灵活性‌：通过扩展而非修改来添加新功能，使系统更加灵活。

‌促进复用‌：设计良好的、遵循开闭原则的组件更易于被复用。

实现方式

‌抽象化‌：通过定义抽象类或接口来指定软件实体的行为，让子类或实现类具体实现这些行为。

‌策略模式‌：使用策略模式可以根据需要动态地改变对象的行为，而无需修改对象本身。

‌依赖注入‌：通过依赖注入技术，可以在不修改代码的情况下替换组件的依赖项，从而实现扩展。

三、里氏代换原则

定义：里氏代换原则(Liskov Substitution Principle, LSP)：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

继承优点

代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；提高代码的重用性；子类可以形似父类，但又异于父类；提高代码的可扩展性，实现父类的方法就可以“为所欲为”了;提高产品或项目的开放性。

继承缺点

继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法；降低代码的灵活性。子类必须拥有父类的属性和方法；

增强了耦合性。当父类的常量、变量和方法被修改时，必需要考虑子类的修改，而且在缺乏规范的环境下，这种修改可能带来非常糟糕的结果；大片的代码需要重构。

克服继承的缺点——里氏替换原则

里氏替换原则对继承的约束规则：

          1）子类必须实现父类抽象方法，但不得重写（覆盖）父类的非抽象（已实现）方法。

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

          3）当子类覆盖或实现父类的方法时，方法的前置条件（即方法入参）要比父类方法的输入参数类型更宽松。

          例如：父类方法fun(HashMap map)入参是HashMap，那子类同名方法fun(Map map)可以定义入参为Map，反之则不行。

          4）当子类的方法实现父类的抽象方法时，方法的后置条件（即方法返回值）要比父类返回值类型更严格。

          例如：父类方法fun(HashMap map)#Map返回值是Map，则子类方法fun(HashMap map)#HashMap可以定义为HashMap，反之则不行。

四、依赖倒置原则

定义：

高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象，其核心思想是：要面向接口编程，不要面向实现编程。

依赖倒置原则的作用：

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

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

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

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

依赖倒置原则的实现方法：

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

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

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

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

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

五、接口隔离原则

定义：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

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

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

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

接口隔离原则的优点

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

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

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

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

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

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

接口隔离原则的实现方法

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

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

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

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

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

六、迪米特法则

定义：迪米特法则(Law of  Demeter, LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用。

迪米特法则的优点

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

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

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

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

迪米特法则的实现方法

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

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

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

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

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

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

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

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

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

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

总结

单一职责原则告诉我们实现类要职责单一。

里氏替换原则告诉我们不要破坏继承体系。

依赖倒置原则告诉我们要面向接口编程。

接口隔离原则告诉我们在设计接口的时候要精简单一。

迪米特原则告诉我们要降低耦合。

开闭原则是总纲，告诉我们要对扩展开放，对修改关闭。