设计原则小记

设计原则大家都不陌生，现在简介下自己的简介

设计模式是设计原则的实现，所有设计原则最终都是为了 高内聚低耦合

设计原则共有7种 下面从理解、总结、场景三个角度简单阐述下自己简介

 

S 单一职责原则

理解：不同的类具备不同的职责，各司其职。做系统设计时，如果发现有一个类拥有了两种职责，那么就要问一个问题：可以将这个类分成两个类吗？如果真的有必要，那就分开，千万不要让一个类干的事情太多

总结：一个类只承担一个职责

场景：单个类 职责单一

0 开闭原则

理解：类、模块、函数，可以去扩展，但不要去修改。如果要修改代码，尽量用继承或组合的方式来扩展类的功能，而不是直接修改类的代码。当然，如果能保证对整个架构不会产生任何影响，那就没必要搞的那么复杂，直接改这个类吧。

总结：对类的的改动，最好用扩展而非修改的方式。（对已创建类，尽量避免改动—闭。取而代之的是继承或者扩展或者协议—开）

场景：单个类 对类的修改尽量避免本类的修改 用扩展或继承来达到修改的目的

L 里氏替换原则

理解：一个对象在其出现的任何地方，都可以用子类实例做替换，并且不会导致程序的错误。换句话说，当子类可以在任意地方替换基类且软件功能不受影响时，这种继承关系的建模才是合理的。 总结：子类可以扩展方法，但不应该重写父类的方法。

场景：继承 子类尽量不重写父类的方法 只是使用功能

I 接口隔离原则

理解：一个类实现的接口中，包含了它不需要的方法。将接口拆分成更小和更具体的接口，有助于解耦，从而更容易重构、更改。

总结：对象不应被强迫依赖它不使用的方法。 对我们来说主要是协议中方法注意opttion 标记。 非必要 不声明（ 扩展：类.h文件中不需要外界知道的不暴露）

场景：协议 、类.h文件 避免臃肿

D 依赖倒置原则

理解：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

总结：面向接口编程，提取出事务的本质和共性。通用方法或者基类（高层）尽量避免 依赖底层模块（具体业务）二者之间应该有中间件（抽象层/接口层）

场景：类与类之间 要发生关联的类 保证高层的 独立 重点在强调高低依赖

L 迪米特法则

理解：一个对象对另一个对象了解得越多，那么，它们之间的耦合性也就越强，当修改其中一个对象时，对另一个对象造成的影响也就越大。

总结：一个对象应该对其他对象保持最少的了解，实现低耦合、高内聚。低耦合高内聚

场景：类与类之间 跟D比较相似 （D强调的是高低的依赖问题，而这个就是强调类与类之间，该法则包含D）

C 组合/聚合复用原则

理解：合成/聚合复用原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。它的设计原则是：要尽量使用合成/聚合，尽量不要使用继承。

总结：就是说要少用继承，多用合成关系来实现。继承复用有一定的缺点：比如如果基类发生了改变，那么派生类的的实现就不得不发生改变。使用组合/聚合复用原则就解决了继承复用的缺点。也就是组件化

场景：各个组件高度独立 彼此能够相互组合

参考资料：https://www.jianshu.com/p/e5c69c7b8c00