读「SOLID」的设计原则记录

阅读连接：https://xueyuanjun.com/post/9719

单一职责原则（Single Responsibility Principle）

        一个类只作某一件事。

        例：操做订单时咱们须要查询数据进行验证 若是在订单类中直接查询MySql数据库就意味着 数据存储方式发生改变这里也须要改代码 这时咱们能够另起一个订单资料类进行调用保存数据 这样咱们的代码就 更清晰、更容易维护、更加解耦、更容易测试

 

开放封闭原则（Open Closed Principle）

        对扩展是开放的，对修改是封闭的。

        例：咱们须要验证订单，订单验证又随着业务规则改变，随着业务的增加就须要增长一大推新规则，代码必须随着每次业务规则的改变而改变 这样是对修改开放的就违反了开放封闭原则。咱们能够：定义订单验证接口 --> 封装订单处理器 --> 每个订单验证接口的实例注入到订单处理器中 --> 订单操做时调用订单处理器

 

里氏替换原则（Liskov Substitution Principle）

        对象能够被其子类的实例所替换，而且不会影响到程序的正确性。

        例：原来的订单数据存储到了 CSV 格式的文件系统中（CsvOrderRepository ），如今须要更换存储方式，存到关系数据库中（DatabaseOrderRepository ）。原来的CSV文件系统不须要帐户密码而关系数据库须要，若是在OrderProcessor处验证是否调用了关系型数据并传帐号密码，就违反了里氏替换原则。DatabaseOrderRepository须要本身接管数据库帐号密码以及链接，这样咱们就能够在 CsvOrderRepository 和 DatabaseOrderRepository 实现之间进行切换了，不用对 OrderProcessor 作任何修改

若是不遵照里氏替换原则，那么可能会影响到咱们以前已经讨论过的其余原则。不遵照里氏替换原则，那么开放封闭原则必定也会被打破。由于，若是调用者必须检查实例属于哪一个子类，则一旦有了新的子类，调用者就得作出改变。

 

接口隔离原则（Interface Segregation Principle）

        不该该强制接口的实现依赖于它不使用的方法。在实际操做中，这个原则要求接口必须粒度很细，且专一于一个领域。调用方只须要依赖它就能够了，而没必要去依赖包含多个领域的接口。

 

依赖反转原则（Dependency Inversion Principle）

        高层次的代码不该该依赖低层级的代码，高层次的代码应该依赖抽象接口。低层次代码用于实现一些底层的基本操做，好比从磁盘读文件、操做数据库等。高层次代码用于封装复杂的业务逻辑而且依靠低层次代码来实现功能，但不能直接和低层次代码耦合在一块儿。

       反转的思想：使用这一原则会反转不少开发者设计应用的方式。再也不将高层次代码直接和低层次代码以「自上而下」的方式耦合在一块儿，这个原则规定不论高层级仍是低层次代码都要依赖于一个高层次的抽象，从而使得低层次代码依赖于高层次代码的需求抽象。

 

 

全部五个「SOLID」原则都是相关的，也就是说违背了其中一个原则，一般意味着也违背了其余的原则。当你违背了接口隔离原则，确定也违背了单一职责原则。