程序设计六大原则-概况与举例

总结设计原则其实很早以前就在想了，但是起初我认为固定的原则会局限人的创新思维，陈旧的定律不一定是最好的。实际上随着代码量的沉积，你会发现无形之中你的程序设计会和这六大原则不谋而合。大道至简，前人走过的路，可能也是你将要走的路。

原则一：单一职责

这一块不管你写前端还是后端的项目，你会明白，所谓的设计模式（如MVC，MCP）就是帮助你实现部分代码的单一职责，就像是流水线上工作流程拆分，很多简单的步骤实现庞大的逻辑。当职责变得单一时，复用性提高，个体业务逻辑难度降低。这个原则算是应用最广，也最显而易见的。

原则二：里氏替换

这一原则主要针对继承，子类必须能完美的替换父类，且不影响业务逻辑。

这里只需要注意两件事：

1.避免子类过度重写而失去父类原有能力和属性。
2.避免子类的独有业务逻辑和业务属性侵入父类。（这一块深海颇有感触，当子类业务侵入父类时，不仅使得里氏替换难以实现，而且违背了单一职责的原则和依赖倒置原则）

原则三：依赖倒置

1.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。
2.抽象不应该依赖于具体，具体应该依赖于抽象。

关于这个原则众说纷纭，这里理解成 AOP(面向切面)也可以。

但深海认为这个原则主要注意两个区分：类的高低层级区分和逻辑的具体与抽象区分。

不要倒行逆施，可能是依赖倒置的初衷。

原则四：接口隔离

1.一个类，不应该被强迫实现一些他们不会使用的接口。
2.一个类对另一个类的依赖应该建立在最小的接口上。

应该把胖接口中的方法分组,然后用多个接口替代它,每个接口服务于一个子模块。简单地说,就是使用多个专门的接口比使用单个接口要好很多。

上面的解释时比较官方的说法，深海把他换成具体的实现：

1.假如某类实现了一个接口，却用不到这个接口的任何方法和属性，那么就是程序设计上出了问题，去除强制，或者拆分该接口。
2.一个接口不应该具有多种业务的功能，更不要说交叉的业务，这里违背单一职责的同时，也违背了接口隔离的原则，接口一定是最小单元的抽象，这样使得该接口的功能和职责十分清晰。

原则五：迪米特法则

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

深海认为可以理解为对象隔离，正好和接口隔离想呼应。

通俗一点说就是解耦。为什么要解耦？或者说迪米特原则解决了什么问题呢?

假如对象耦合过高，那么一个对象就可能因为另一个对象的改变而发生较大的改变，这样的程序出问题的概率和业务的扩展难度将会大大提高。

原则六：开放封闭

对扩展开放，对修改封闭。

这个原则也是众说纷纭，有人说时宏观定义，有人说时微观定义。

其实深海认为该原则主要强调两件事：

1.当新增业务或者逻辑时，避免对旧代码的修改，应当在旧代码的基础上扩展实现。
2.旧代码应当具有扩展能力，也就是从设计程序的时候，就应当考虑到将来的业务扩充。