设计模式的六大原则

前言

最近感觉自己越发无知，学习不能停，写博客仍然是我觉得一个好的总结与检验学习成果的一个好方法，准备花功夫继续更新下去了。最近学习计划是设计模式，希望和大家多多交流，有错误的地方请不吝赐教，期待和你共同进步。

设计模式的准则有哪些？

• 单一原则（Single Responsibility Principle）
• 开闭原则 (Open Closed Principle)
• 里氏替换原则 (Liskov Substitution Principle)
• 迪米特原则 （Law of Demeter）
• 接口隔离原则 (Interface Segregation Principle)
• 依赖倒置原则 (Dependence Inversion Principle)

单一原则

就是一个类只能做一件事。
我所理解的就是如果这个类是用来计算优惠的类，那怎么添加商品就不该放在这个类中。

开闭原则

开闭是指对扩展开放，对修改关闭。
我之前看到的一篇博客，感觉对这个事情解释的比较清楚，他说开闭原则更像是其他五个准则的衡量标准，前面写好的，就自然很符合开闭原则

里氏替换原则

为什么叫里氏替换原则，是因为这个理论是由Barbara Liskov女士在1987年针对“我们该如何度量继承关系的质量”这一问题提出的一个原则。

“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”——“继承必须确保超类所拥有的性质在子类中仍然成立。”

换成大白话讲，任何使用父类实例的地方，可以用子类实例替换，它们之间才具有良好的继承关系。
为了实现这个原则，需要满足以下几点：

1. 子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法。（很显然，设计者如果需要继承就会设计成抽象方法，没有设计成抽象方法是想不希望被修改的。）
2. 子类中可以新增方法。（这个是允许的，子类允许拥有这个自由。）
3. 当子类的方法重载父类的抽象方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。（例如父类抽象方法要求入参是个List ,子类如果改成 ArrayList，那么传递 LinkedList 参数的方法在父类可以正常使用，替换成子类就会报错。)
4. 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。 例如父类返回的是ArrayList,子类如果是List，虽然不会报错，但是会破坏父类的约束条件。

这里我当初有个问题：子类应该比父类设计的宽松，那么返回值为什么要比父类严格，比他宽松不就好了吗？如果这是破坏约束，那么入参宽松就不算破坏了吗？

后来给自己的答案是：

1. 如果重写方法，子类不要破坏父类的约束，这个方面IDE会直接编译报错。
2. 重载方法父类方法，可以修改，但是要遵守以上的规则。

迪米特法则

迪米特法则还有另外一个名字，就是最少知道原则。意思是隐藏多余的细节，只提供给使用方应该知道的内容，减少认知成本和不必要的错误使用。

接口隔离原则

这里的接口是代指接口和抽象类，并非是单纯的接口。这个原则的含义有两个：

• 尽量小的接口设计。
• 使用方不应该依赖不需要的接口。

这个原则的本质是想对一个职责的方法做更为细致的划分，这样的做的好处是具有更好的封装性。

依赖倒置原则

这个原则是高层模块与底层模块之间的纠葛，是抽象与细节之间的缠绕，总结起来是

• 高层模块不应该依赖底层模块，两者都应该依赖其抽象。
• 抽象不能依赖细节
• 细节应该依赖于抽象

换成大白话，两个模块之间的通信，不建议直接调用，应该使用接口或抽象类，这样可以降低耦合，更加通用。你走他来，只要通信接口不变，相互之间就没有感知，面向接口编程。

原则之间的联系

以上是我对这些设计原则的理解。虽然理论知识是基本理解了，但是在实际工作中的运用，因为业务的复杂度，有些原则不能全面兼顾，还是需要多加斟酌和取舍。

愿我们在现实中多做尝试，不要只是纸上谈兵，加油，下篇博客见。