设计模式-设计原则（Design Principle）

本文由@呆代待殆原创，转载请注明出处。

 

写在前面：所谓设计原则并不是一定要遵守的法则，只是一种建议，因为保持这些原则本身会有一定代价，若是这些代价超过了带来的好处就得不偿失了，所以一切还是以简单为准。

 

原则一：分离变与不变的部分。

定义：找出代码中会发生变化的部分，并将其和保持不变的部分分离。

作用：提升可维护性。将会变化的部分分离后，在以后的修改过程中就不会影响到其他不变的部分。

 

原则二：面向接口编程。

定义：面向接口编程，而不是面向某个实现。

作用：降低耦合。这里的接口有多个含义，并不仅仅只java中的interface，更准确的表达应该是面向超类编程。这样的话只要接口不发生改变，依赖接口的部分就不用发生改变，我们都知道，接口发生改变的可能性比接口的某个实现发生改变的可能性小很多。

 

原则三：开闭原则（The Open-Closed Principle）。

定义：类需要支持扩展而拒绝修改。

作用：增加可修改性和可维护性。

 

原则四：Dependency Inversion Principle（依赖倒置原则，之后简称DIP）。

定义：不要依赖实例（concrete classes）编程，依赖抽象（abstractions，指依赖抽象类和接口）。

关于倒置（inversion）的理解：通常我们的高层组件都会依赖于低层组件（指某个低层具体实例类），而DIP是不允许这样的，在DIP的指导下，我们会创建一个抽象类，让它处于高层组件与低层组件之间，打破这种依赖，这时不仅高层组件会依赖于这个抽象类，低层组件会依赖于这个所处位置比它高层的抽象类，所以会出现“倒置”这个说法。

此原则的几个指导方针（并不是一定要准守，只是在开发的时候当成一个参考而已）

1，不要有指向一个具体实例（concrete class）的引用。

2，不要有从具体实例（concrete class）派生出的类。

3，不要覆盖父类中已经实现的方法。

4，低层组件尽量都要有共同的接口或者抽象类。

与原则二的区别：比原则二更加严格，它增加了高层组件不能直接依赖低层组件这一条。

作用：降低耦合。只要定义好了高层组件和低层组件间的接口，他们的开发可以同步进行，在多人开发中的意义也很大。

 

原则五：最少至少原则（The Principle of Least Knowledge）[又称迪米特法则（Law of Demeter）]

定义：一个对象应该对其他对象保持最少的了解。

此原则的几个指导方针

1，只调用自己的成员方法。

2，只调用当做参数传递进来的对象的成员方法。

3，只调用自己的方法实例化的对象的成员方法。

4，只调用组合对象（成员变量的一部分）的成员方法。

作用：降低复杂度，提高可维护性。

 

原则六：好莱坞原则（The Hollywood Principle）

定义：别调用我们，我们会调用你。

作用：防止依赖腐败（dependency rot），当高层组件和低层组件组件相互依赖的时候，通常组件之间的关系会过于复杂，这时，就可以运用这个原则，拒绝低层组件调用高层组件，而是等待高层组件来调用低层组件，这样可以降低编程的复杂程度。

 

原则七： 单一责任原则（Single Responsibility）

定义：一个类只有一个引起变化的原因

作用：高内聚，提高可维护性。每个类只有一个职责，只有这个职责发生改变的时候这个类才应该被修改。

 

 

参考资料：《Head First 设计模式》