设计模式 · SOLID原则

SOLID原则是指：

• Simple Responsibility Principle，SRP单一职责原则
• Open Close Principle，OCP开闭原则
• Liskov Substitution Principle，LSP里式替换原则
• Interface Segregation Principle，接口隔离原则
• Dependency Inversion Principle，依赖反转原则

SRP单一职责原则

单一职责原则是指，一个类或者模块应该包含一种职责或者功能，以此来保证类或者模块的高内聚、低耦合。也就是说，在进行面向对象设计时，不要试图设计一个大而全的类，而要设计粒度更细的类，在里面包含一个单一的职责。然而，在具体的实践过程中，一般都会有意无意地违反这条职责。因为就算开始时设计了一个只有单一职责的类，但随着业务逻辑的发展变化，会不自觉的在现成的类中加入一些不那么相关的逻辑，这就造成这个类越来越复杂，代码越来越多，逻辑越来越难懂。因此，拆分就变得在所难免，这就是持续重构。那么具体到什么时候该进行重构代码呢？可以借鉴这几条：

• 类中的代码行数越来越多，已经严重影响到代码的可读性和可维护性；
• 类依赖的其他类太多，已经丧失了高内聚低耦合的设计思想；
• 类中的私有方法太多，很多操作都依赖于某些属性；
• 已经起不出一个比较合适的类名。

同时，也要理解并不是把类的粒度设计的越细越好，因为粒度太细会引起很多额外的维护成本，类和类之间的联系和交互也会变得越多。所以，要合理设计类的粒度大小，这是一个高度依赖经验的能力，需要多实践，多思考。

OCP开闭原则

开闭原则说的是在软件开发中，要“对修改关闭，对扩展开放”，这条原则是软件开发中最重要的一条。其实，开闭原则主要解决的是如何解决程序的扩展性问题，这也是所有的设计思想、原则、规范共同要解决的问题。在实际的项目中，对于修改和扩展的界定是个最大的问题，因为观察的维度不同，得出的结果也不同。比如，给一个类添加一个方法，从类的角度来看，是在修改类的定义，但是从类的行为能力，也就是方法层面来看，是在扩展类的能力。所以，要完美的解决这一问题，需要一定的实战经验来衡量，我们应该做的就是在真正动手之前，先用抽象思维、封装思维等顶层设计理念，尽可能预留出程序的扩展点，为自己留点后路。除过开闭原则，在23条设计模式中，最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分设计模式。

俗话说，唯一不变的就是变化，我们要正确对待用户需求的频繁改变，因为这是我们的本性。那么，又如何在项目中合理的使用这条原则呢？为了防止两头的极端情况，烂代码和过度设计，最合理的做法是，对一些确定的、短期内需要扩展的业务功能或者需求，在设计时就预留出扩展点，对于还不确定的、比较复杂的功能点，等到需求明确之后再通过重构的方式进行完善。对扩展开放是为了应对需求的变化和增加，对修改关闭是为了保证已有功能的稳定运行，最终是为了让系统更加有弹性。

LSP里式替换原则

里式替换原则是说，在程序中子类对象能够替换父类对象出现的任何地方，并且保证程序的原有逻辑不变以及正确性不受影响。从表面上看，里式替换原则和多态貌似很相似，但其实不然。

多态是OOP的一大特性，需要PL的提供三种特殊的语法机制：

1. 父类对象可以引用子类对象；
2. 继承；
3. 子类可以重写父类中定义的方法。

除此之外，还有两个 方式，一种是基于接口编程，另一种是duck-typing。多态主要解决的是代码的复用问题，让开发者尽可能地写出优雅的代码。

实际上，里式替换原则的实质是”按照协议来设计，Design by Contract”，在设计子类时，要按照父类的约定去实现，而不能逾越父类给出的限制，比如父类在没有类型检测的情况下执行了后续代码，而在子类中却直接抛出异常，这就违反了父类的规定，也就是没有遵循里式替换原则。具体地，这里的规定有：

• 函数声明要实现的功能；
• 对输入参数类型、数量，以及返回值类型、数量的规定；
• 对异常处理的规定；
• 注释中列出的任何特殊说明。

总的来说，里式替换原则和开闭原则一样，都是“对扩展开放，对修改关闭”，这样才能在不破坏原有逻辑的情况下，增加或者改善程序的内部实现细节。

ISP接口隔离原则

接口隔离原则是说，接口调用者或者使用者不应该被强迫使用它不需要的接口。为什么要这么做？是为了让程序更加高内聚，只在一个接口内实现在逻辑上独立的事情。这里的接口可以指三种不同的接口：

• 一组API接口集合
• 单个API接口或者函数
• OOP中的接口

对于一组API接口集合来说，ISP要求这组接口具有很强的关联性。比如说在某个UserService中可以获取用户各种信息，进行相关操作，但是还有一个比较特殊的操作——比如删除用户的数据。一般而言，删除操作都是非常危险的，如果非要进行就一定要通过某些验证流程，或者只有一小部分人才有资格使用。那么在这种情况下，到底该如何做呢？如果坚持要把这个特殊操作和一般的操作放在一起，那么在一定程度上就违反了接口隔离原则。正确的做法是在设计一个RestrictedUserService，里面包含所有具有一定权限的用户服务。对于单个API接口或者OOP中的接口概念，原理也是类似的，核心思想就是不要把逻辑上不相关的服务放在一起，这样只会让程序越来越乱、越来越烂。

从意思上看，接口隔离原则和单一职责原则貌似说的是同一件事，但实际上它们之间还是有一些区别。单一职责原则是从模块、类和接口的设计角度来说，要尽可能让一个接口、类和模块只包含一个职责功能；而接口隔离原则一方面是只注重接口的设计，另一方面，ISP为单一职责原则提供了一个标准，从接口调用者的使用角度来看，如果调用者只使用了一部分，那么接口设计就没有遵循ISP。

DIP依赖反转原则

控制反转Inversion of Control

控制反转是一个设计思想，主要用来指导框架的设计。这里的“控制”指的是对程序执行流程的控制，“反转”指的是在没有使用这一思想之前，程序设计者需要自己控制程序的执行流程，而在使用这一思想和框架之后，反而让框架来控制程序的执行流程，从而让程序设计者致力于程序核心逻辑功能的设计和实现。

依赖注入Dependency Injection

依赖注入和控制反转恰好相反，它是一种具体的编码技巧。当一个对象需要依赖另一个对象时，不要在对象内部通过通过new创建一个，而是通过在外部创建好，然后传递进去的方式来实现。这样的话，程序的扩展性将会更好。基于这一具体的编码技巧而形成的依赖注入框架，则从框架的层面为程序设计者提供了更多的便利性。通常，依赖注入框架会在对象之间有依赖关系时，自动创建、管理、销毁被依赖对象，比如Java Spring。

依赖反转原则

DIP的定义为：高层模块（high-level modules）不要依赖低层模块（low-level）。高层模块和低层模块应该通过抽象（abstractions）来互相依赖。除此之外，抽象（abstractions）不要依赖具体实现细节（details），具体实现细节（details）依赖抽象（abstractions）。模块层次的划分是从调用关系上说的，如果A调用B，那么A就是高层模块，B为低层模块。实际上，在平时的业务开发中，高层模块依赖低层模块是没有任何问题的。实际上，这一思想主要用于框架层面的设计。比如Java Web应用和Tomcat之间的关系，只要Web运行在Tomcat容器中，就可以保证程序的正常执行，这就是因为它们之间共同依赖“抽象”的Servlet规范，而不是具体的实现细节。