【项目设计的经验分享】结合设计模式的七大原则来谈

项目设计的经验分享（结合设计模式的七大原则来谈）

[本文缘由]（非必要内容，读者可忽略，直接看正文）：

忽然发现已经有段时间没写博客了，如今，独立开发过的项目大大小小也有十几个了，眼看着马上就在走向全栈工程师的道路上回不来了，每次项目的数据采集和前端部分都会耗费我较多的精力，使我对于后台开发的思考似乎少了一些，因此，近期打算再次回顾一下面向对象软件设计的指导支柱与最佳实践——设计模式，本文是结合我自己的项目经验以及设计模式七大原则而总结的一篇经验分享。

设计模式的七大原则包括：单一职责原则、接口隔离原则、依赖倒置原则、里氏替换原则、开闭原则、迪米特法则（又称最少知道原则）、合成复用原则。

以下是我自己对这七大原则在项目开发中的一些体会以及对于设计模式再次学习后的一些总结（会用到一些必要的面向对象程序设计语言方面的术语，这里我们以 Java 为例）：

1、一个类只负责一种职责：一个类应该只专注于自己的一项或是一种职责，是单一职责原则的一种思想，可显著降低类的复杂度，提高类的可维护性于可读性，若逻辑功能足够简单，并且可以保证可扩展性，那么我们可以将类界别的单一职责原则降级为方法级别。

2、一个类对另一个类的依赖应该建立在最 “小” 的接口：这是接口隔离原则对我们的劝言，一个类A在依赖一个接口I时，那么势必会在间接意义上依赖此接口的一个实现类，如果这个实现类中有类A用不到的 “实现”，那么这个类就不是最 “小” 的，对应接口I也不是最小接口，这种情况就违背了接口隔离原则，我们应该避免这种情况，从而简化代码复杂度。

3、用 “抽象” 构建框架，用 “实现” 扩展细节：高层的功能模块不能直接依赖低层的功能模块，二者都应依赖于抽象类或接口来建立依赖关系，“抽象” 不能依赖 “细节”，否则，将违背依赖倒置原则，因此，抽象类或接口应专一于指定规范，而细节的实现，应交由实现类去完成。

4、所有引用基类的地方必须能透明地使用其子类的对象：继承的一个重要目的，是最大化地统一规范，子类应在符合父类 “规范” 的基础上进行功能扩充，因此，在子类中尽量不要重写父类的方法，否则就破坏了继承体系的统一规范，上述思想是里氏替换原则对我们的建议，我们应根据项目的实际情况进行遵守。

5、用 “扩展” 代替 “修改”：在需要实现新的功能时，我们的系统应通过创建新的类，模块或方法来实现，而不是通过修改某处已有代码来进行新功能的实现，这也是开闭原则的一种体现。

6、一个类对自己依赖的类知道的越少越好：尽量将功能类的实现细节进行对外屏蔽，而只将必要提供的方法用 public 修饰符对外公开，这样可以对外屏蔽此功能类的非必要对外公开的实现细节，从而尽可能地减少这个类与其使用类之间的可耦合切入点，进而避免不必要的耦合关系，这便是迪米特法则，也叫做最少知道原则。

7、尽量使用合成/聚合的方式，而不是使用继承：当一个类需要用到另一个类的功能时，尽量不要使用继承来实现（根据实际情况），那样会让这两个类的耦合性增大，且代码不易维护，而且，这种继承的原因是功能的复用，而不是由于对象有面向对象思想中的实际继承情况，或者说是有实际含义的父子级关系出现的继承，所以，并不推荐这样的方式，取而代之，我们应使用组合/聚合的方式，或者说是 UML 中关联或依赖的思路来实现，这便是合成复用原则。