java设计模式01-----设计原则

前言

近期一直再学习设计模式，现主要对组件协作模式以及设计原则进行知识梳理。学习设计模式核心就是看见代码中的变与不变，变化是复用的天敌。我对设计模式的理解就是更好地实现复用。设计模式的使用也不宜先入为主，一上来就使用设计模式是对设计的最大误用，没有一步到位的设计模式。敏捷开发实践所提倡的“Refactoring to Patterns”（重构到设计模式）是目前普遍公认的最好的使用设计模式的方法。

设计原则

设计原则我所见到的几个有些细微的差别，但核心都是不变的，现总结如下。

1. 开闭原则（Open Close Principle，OCP）

定义：对扩展开放，对修改关闭
作用：保证以前代码的准确性，使开发者更专注于新扩展的代码上，从而使得整个系统的鲁棒性。用通俗的话说就是：代码写好了，就不要修改源代码了，而是进行扩展。

2. 单一职责原则（Single Responsibility Principle）

定义：一个类只负责一个功能领域的职责。
作用：降低类的复杂度，当修改一个功能时，降低对其他功能的影响，提供类的可读性。当然也是为了低耦合。

3.里氏代换原则（Liskov Substitution Principle）

定义：任何基类出现的地方，子类一定可以出现
作用：在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象，开闭原则实现的手段之一。里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，**尽量不要重写父类的方法。**如果通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。如果程序违背了里氏替换原则，则继承类的对象在基类出现的地方会出现运行错误。这时其修正方法是：取消原来的继承关系，重新设计它们之间的关系。¹
也就是说，如果继承之后再重写父类中已经实现的方法，就已经证明，这个子类不应该继承这个父类，父类中具体的方法，应该是所有子类所具有的共同特点。

4.依赖倒转原则（Dependence Inversion Principle）

定义：高层模块（稳定）不应该依赖于低层模块（变化），二者都应该依赖于抽象（稳定）。抽象不应该依赖于实现细节，实现细节应该依赖于抽象。这里的抽象就是稳定的意思，实现就是变化。换句话说：针对接口编程
作用：依赖倒置原则可以降低类间的耦合性。
依赖倒置原则可以提高系统的稳定性。
依赖倒置原则可以减少并行开发引起的风险。
依赖倒置原则可以提高代码的可读性和可维护性。
依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性，所以我们在实际编程中只要遵循以下4点，就能在项目中满足这个规则。

1. 每个类尽量提供接口或抽象类，或者两者都具备。
2. 变量的声明类型尽量是接口或者是抽象类。
3. 任何类都不应该从具体类派生。
4. 使用继承时尽量遵循里氏替换原则^[1]
   设计时所画的UML图，里面的依赖关系，依赖的对象不应该是一个具体的对象，而是一个抽象的东西。

5.接口隔离原则（Interface Segregation Principle）

定义：使用多个专门的接口，不使用单一的总接口。现假设有一个接口有12345,5
个方法，第一个实现类只使用123，第二个实现类只使用145，那么这个接口就应该进行隔离。隔离层三个接口，分别包含1,23,45。
接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：
单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。

6.迪米特法则（Law Of Demeter）

定义：一个实体应当尽量少的与其他实体发生相互作用。**如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。**其目的是降低类之间的耦合度，提高模块的相对独立性。
没必要直接通信，而又需要调用，就是用一个中间件进行过渡。

7.合成复用原则（Composite Reuse Principle）

定义：它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
**如果要使用继承关系，则必须严格遵循里氏替换原则。**合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。
使用方式：就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分，新的对象通过这些对象的委派达到复用已有功能的目的。

在后面的设计模式中会有体现。

参考文献

[1]http://c.biancheng.net/view/1324.html
[2]https://blog.csdn.net/zy52002520/article/details/80577607

---

1. 1 ↩︎