设计原则

开闭原则 拓展开放 修改关闭，注重点是对抽象的定义，提高软件的复用性和可维护性

单一职责原则 类，接口，方法功能单一，预防代码结构臃肿，复杂，不要存在过多导致功能变化的变更，也是低耦合思想。
依赖倒置原则 列举spring中动态注入  高层模块不应该强依赖低层模块，二者都应该依赖抽象。减少类与类之间的耦合，也降低了代码功能扩展的风险，一切基于抽象

迪米特法则 最少知道原则 不关注的类不应当引入,不去关注具体的内部实现，低耦合思想

合成复用原则 黑箱复用 外部类不感知 例如数据库连接 dao层类不适用继承 而是注入 继承属于白箱复用 全部感知

接口隔离原则 接口功能合理隔离，防止多余耦合，只依赖需要依赖的，所以就要要求接口功能的设计上一定要合适，也并不是越少越好。

里式替换原则 是指如果对每一个类型为 T1 的对象 o1,都有类型为 T2 的对象 o2,使得以 T1 定义的所有程序 P 在所有的对象 o1 都替换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。防止混乱父类功能 子类可以扩展功能 但是不能更改父类功能，可以扩展父类的功能，但不能改变父类原有的功能。

 

设计原则只是一种理论的代码设计方向，绝不是要求严格的遵守，一些情况下是不可兼得的，例如代理模式，就是重新了父类的方法，不符合里式替换原则，模板方法模式，因为使用了继承，既不符合合成复用原则，也不符合开闭原则

 

可以不学，切记死学

 

 

附多年前的理解：

设计模式：

初代理解：
开闭原则：对修改关闭，对拓展打开：一个功能的定义，通过顶层接口实现，实际开发中，接口定义方法后，不支持方法修改，client调用改接口实现的功能方法不再支持改变。但是如果想要拓展新的功能，则持续新的实现。
场景：共享单车中，定义关锁接口，分为正常关锁，强制关锁，蓝牙关锁，关锁方法统一定义为park(),三种关锁方式就是对关锁功能的拓展，但是没有修改park（）方法接口，用户端无感知修改，需要实现蓝牙关锁，就需要通过拓展类来完成。

单一职责原则：一个接口，一个方法功能单一，不会出现第二个影响功能
场景：例如关锁和开锁，属于两个功能，不能定义在一个锁操作接口方法中，需要分开定义。不然就就可能出现，修改开关锁共用逻辑的时候，影响了另一个功能。比如锁上报电量为开关锁通用功能，但是现在需要改变下关锁上报电量的阈值，则就影响了开锁上报的阈值。

接口隔离原则：是指接口的设计要专门化，不要过度臃肿；
场景：比如现在定义一个定级业务接口，车辆功能：电量上报，开关锁，油表上报，续电等方法，该接口定义的方法比较多，不论是单车，助力车，还是汽车的功能都定义了，这样助力车需要开关锁和续电的接口时候，实现改接口，则油表上报等根本无效的功能也需要定义，说明接口定于的不够专门化，不符合隔离原则。

迪米特原则（最少知道原则）：一个对象对另一个对象保持最少的了解，只需要知道自己所需要的直接结果所必要的参数，不需要关注中间动作。
场景：共享单车需要绘制骑行路线图，调用方只需要调用服务端提供的接口，提供必要参数，不需要去关注服务端如何通过与车辆部门的交互，计算，获取到提供绘制线路图的坐标列表，而不是我自己去获取车辆的坐标列表，提供给服务端，让它计算，这样实现的话，服务调用链路就比较杂乱了。
通常开发中喜欢说的一句话，你的实现对我来说就是一个黑盒，我不关注，我只要我需要的结果，就是迪米特原则。
里式替换原则：父对象支撑的一段程序，将父对象换成子对象，依旧能够正常运行：这个原则主要是一种约束，开发过程中，支持对父类的扩展，不支持对父类功能的覆盖，当子类重载父类方法的时候，入参要更宽松（父类的所有入参 都要涵盖），子类实现父类方法的时候，方法后置输出要更严格（不能超出父类的输出功能）。
例如父类功能对车辆开锁，子类中可以新增对车辆的响铃功能 ，但是不能修改车辆的关锁功能，例如开锁功能被覆盖成了助力车开锁功能，单车调用的话，就报错了。

合成复用原则：降低类与类之间的耦合度，尽快不通过继承来实现功能复用。使得一个类的变化，对另一个类影响较少，具体类的使用，交由应用层。
场景：数据库连接支持，比如一个连接类，有mysql的连接功能，现在需要实现pgsql的连接，这时候不要实现一个类，去继承mysql连接类，而是选择新实现一个类，去实现pgsql功能，具体使用哪种连接，交由应用层来决定。

依赖导致原则，高层模块，不应该直接依赖底层模块，都应该依赖其抽象，通过依赖抽象，减少类之间的耦合性。
场景：助力车有权益功能红包车，如果代码实现中，车功能定义了红包车权益功能功能，代码结构中直接使用助力车类，后续需要新增订阅权益，需要在助力车类中新增订阅的权益功能，使用时候，上层也需要增加更改，偶尔度高，稳定性，可读性差。
依赖倒置实现方式：定义一个权益接口，分别实现红包车权益逻辑，订阅权益逻辑，助力车类中只需要有个使用权益的方法，外加一个权益引用。扩展的时候，直接将订阅的权益注入，正常调用使用权益接口，代码不需要任何更改。