编程是一种思想，而不是敲代码

编程是一个先思考再编码的过程&＃xff0c;思考是优于编码技能的&＃xff0c;在思考过程中我们会考虑代码的可重用性、可靠性、更容易被他人理解&＃xff0c;这时就会使用到设计模式让代码编写工程化&＃xff0c;这篇文章整理了设计模式的六大原则。

单一职责原则

单一职责原则&＃xff08;Single Responsibility Principle&＃xff09;

There should never be more than one reason for a class to change.&＃xff08;有且仅有一个原因可以引起类的变更&＃xff09;

不管让我干啥&＃xff0c;我都只干一件事&＃xff0c;你让我下楼取快递&＃xff0c;顺便将垃圾带下去&＃xff0c;对不起&＃xff0c;我不干&＃xff0c;我只取快递。

优点&＃xff1a;

• 类的复杂性降低&＃xff0c;实现什么职责都有清晰明确的定义&＃xff1b;

• 可读性提高&＃xff0c;复杂性降低&＃xff0c;那当然可读性提高了&＃xff1b;

• 可维护性提高&＃xff0c;可读性提高&＃xff0c;那当然更容易维护了&＃xff1b;

• 变更引起的风险降低&＃xff0c;变更是必不可少的&＃xff0c;如果接口的单一职责做得好&＃xff0c;一个接口修改只对相应的实现类有影响&＃xff0c;对其他的接口无影响&＃xff0c;这对系统的扩展性、维护性都有非常大的帮助。

接口隔离原则

接口隔离原则&＃xff08;Interface Segregation Principle&＃xff09;

1、Clients should not be forced to depend upon interfaces that they don&＃39;t use.&＃xff08;客户端不应该依赖它不需要的接口&＃xff09;

2、The dependency of one class to another one should depend on the smallest possible interface.&＃xff08;类间的依赖关系应该建立在最小的接口上&＃xff09;

举个例子&＃xff0c;类A 通过 Interface1 依赖类B&＃xff0c;方法1&＃xff0c;方法2&＃xff0c;方法3&＃xff1b;类B 通过 Interface1 依赖D&＃xff0c;方法1&＃xff0c;方法4&＃xff0c;方法5&＃xff0c;看下未使用接口隔离原则和使用了接口隔离原则发生了什么变化。

依赖倒置原则

依赖倒置原则&＃xff08;Dependence Inversion Principle&＃xff09;

1、High level modules should not depend upon low level modules.Both should depend upon abstractions. &＃xff08;高层模块不应该依赖低层模块&＃xff0c;两者都应该依赖其抽象&＃xff09;

2、Abstractions should not depend upon details. &＃xff08;抽象不应该依赖细节&＃xff09;

3、Details should depend upon abstractions. &＃xff08;细节应该依赖抽象&＃xff09;

举个例子&＃xff0c;类A 直接依赖 类B&＃xff0c;假如要将 类A 改为依赖 类C&＃xff0c;则必须通过修改 类A 的代码来达成。这种场景下&＃xff0c;类A一般是高层模块&＃xff0c;负责复杂的业务逻辑&＃xff1b;类B 和类C 是低层模块&＃xff0c;负责基本的原子操作&＃xff1b;假如修改类A&＃xff0c;会给程序带来不必要的风险。

解决方案&＃xff1a;将 类A 修改为依赖 接口Interface1&＃xff0c;类B 和 类C 各自实现 接口Interface1&＃xff0c;类A 通过 接口Interface1 间接与 类B 或者 类C 发生联系&＃xff0c;则会大大降低修改 类A 的几率。

里氏替换原则

里氏替换原则&＃xff08;Liskov Substitution Principle&＃xff09;

1、If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.&＃xff08;如果对每一个类型为 S 的对象o1&＃xff0c;都有类型为 T 的对象 o2&＃xff0c;使得以 T 定义的所有程序 P 在所有的对象 o1 都代换成 o2 时&＃xff0c;程序 P 的行为没有发生变化&＃xff0c;那么类型 S 是类型 T 的子类型&＃xff09;

2、Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.&＃xff08;所有引用基类的地方必须能透明地使用其子类的对象&＃xff09;

举个例子&＃xff0c;有一功能 P1&＃xff0c;由 类A 完成&＃xff0c;现需要将功能 P1 进行扩展&＃xff0c;扩展后的功能为 P&＃xff0c;其中 P 由原有功能 P1 与新功能 P2 组成&＃xff0c;新功能 P 由 类A 的 子类B 来完成&＃xff0c;则 子类B 在完成新功能 P2 的同时&＃xff0c;有可能会导致原有功能 P1 发生故障。

解决方案&＃xff1a;当使用继承时&＃xff0c;遵循里氏替换原则。类B 继承 类A 时&＃xff0c;除添加新的方法完成新增功能 P2 外&＃xff0c;尽量不要重写 父类A 的方法&＃xff0c;也尽量不要重载父类A的方法。

继承包含这样一层含义&＃xff1a;父类中凡是已经实现好的方法&＃xff0c;实际上是在设定一系列的规范和契约&＃xff0c;虽然它不强制要求所有的子类必须遵从这些契约&＃xff0c;但是如果子类对这些方法任意修改&＃xff0c;就会对整个继承体系造成破坏&＃xff0c;而里氏替换原则就是表达了这一层含义。

继承作为面向对象三大特性之一&＃xff0c;在给程序设计带来巨大便利的同时&＃xff0c;也带来了弊端。比如使用继承会给程序带来侵入性&＃xff0c;程序的可移植性降低&＃xff0c;增加了对象间的耦合性&＃xff0c;如果一个类被其他的类所继承&＃xff0c;则当这个类需要修改时&＃xff0c;必须考虑到所有的子类&＃xff0c;并且父类修改后&＃xff0c;所有涉及到子类的功能都有可能会产生故障。

优点&＃xff1a;

• 代码共享&＃xff0c;减少创建类的工作量&＃xff0c;每个子类都拥有父类的方法和属性&＃xff1b;

• 提高代码的重用性&＃xff0c;可扩展性。

• 提高产品或项目的开放性。

迪米特法则

迪米特法则&＃xff08;Law of Demeter&＃xff09;

1、Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.&＃xff08;每个单元对于其他的单元只能拥有有限的知识&＃xff1a;只是与当前单元紧密联系的单元&＃xff09;

2、Each unit should only talk to its friends; don&＃39;t talk to strangers.&＃xff08;每个单元只能和它的朋友交谈&＃xff1a;不能和陌生单元交谈&＃xff09;

3、Only talk to your immediate friends.&＃xff08;只和自己直接的朋友交谈&＃xff09;

举个例子&＃xff0c;我们通过 手机 阅读 微信读书 APP 内的 书籍&＃xff0c;如何设计类的编写&＃xff1f;

手机类 和 书籍类&＃xff0c;这两个不能直接发生调用关系&＃xff0c;需要 手机类 和 微信读书 APP 类先发生调用关系&＃xff0c;然后微信读书 APP 类 再和 书籍 类可以发生调用关系&＃xff0c;这样才遵循迪米特法则。

开闭原则

开闭原则&＃xff08;Open Closed Principle&＃xff09;

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.&＃xff08;软件中的对象&＃xff08;类&＃xff0c;模块&＃xff0c;函数等等&＃xff09;应该对于扩展是开放的&＃xff0c;但是对于修改是封闭的&＃xff09;

在软件的生命周期内&＃xff0c;因为变化、升级和维护等原因需要对软件原有代码进行修改时&＃xff0c;可能会给旧代码中引入错误&＃xff0c;也可能会使我们不得不对整个功能进行重构&＃xff0c;并且需要原有代码经过重新测试。

解决方案&＃xff1a;当软件需要变化时&＃xff0c;尽量通过扩展软件实体的行为来实现变化&＃xff0c;而不是通过修改已有的代码来实现变化。

小结

• 单一职责原则告诉我们实现类要职责单一&＃xff1b;

• 接口隔离原则告诉我们在设计接口的时候要精简单一&＃xff1b;

• 依赖倒置原则告诉我们要面向接口编程&＃xff1b;

• 里氏替换原则告诉我们不要破坏继承体系&＃xff1b;

• 迪米特法则告诉我们要降低耦合&＃xff1b;

• 开闭原则是总纲&＃xff0c;告诉我们要对扩展开放&＃xff0c;对修改关闭&＃xff1b;