设计模式——七大原则 – FITA _在线工具

以下所有原则的描述对于已经实操过类似图书管理小项目的盆友会很好理解（大佬请忽略此文哈哈）

一、单一职责原则

一个类只负责一个功能

• 当一个类的方法足够少也会在方法级别上实现各司其责（比如当在类级别上成本较高的时候）
• 当业务代码逻辑很简单时候，才可以违反该原则

二、接口隔离原则

一个classA通过接口implementC依赖于classB，那么classB里面最好不要有A用不到到的僵尸方法

• 就是说，一个类对另一个类的依赖应该建立在最小接口上，减少僵尸代码
• 实际操作就是把一个大接口拆分为几个小接口，然后分别按需要建立依赖关系

三、依赖倒转原则

1.高层模块不依赖于底层模块，而都应该依赖于其抽象（接口、抽象类）

2.细节（具体的实现类）依赖抽象

3.核心思想： 面向接口编程，用接口制定规范

• 建立依赖的三种常见方式：
• 接口套娃
• 构造器
• setter()方法
• 遵循里氏替换

四、 里氏替换

提出的背景或叫做解决的问题

继承其实增加了程序耦合度子类最好不要重写继承的父类方法，这样会破坏其他子类的继承性，如果迫不得已要修改，可以提升原来的子类，让原父类和其要重写它方法的子类共同继承一个更上层抽象的基类，用依赖、聚合、耦合关系代替继承

五、开闭原则

六、迪米特法则（最少依赖法则）

说白了就是谁的事，就在谁自己那里解决，对外只暴露方法

• 一个对象对象其所依赖的对象应该保持最低的了解
• 被依赖的类不不关逻辑多复杂，都应该除了暴露public方法之外，剩余的都封装在自己类的内部
• 类之间关系越大，耦合度越高
• 或者说之和直接朋友（注意是接着盆友！！！）通信，不要跨级

朋友：存在耦合关系的（组合，继承，依赖，聚合。。。）
根据不同的耦合关系，分为一下两种：
直接盆友： 存在在类中的成员变量、参数、方法返回值
非直接朋友： 现在在局部变量

• 陌生的类最好不要以局部变量的形式出现在类的内部

合成复用原则

• 说白了就是多用聚合/合成 ，少继承

小结

• 原则其实都是为了降低耦合
• 把需要改变的部分独立出来，别和不变的混一起
• 面向接口，而不是面向具体实现