【设计模式】七大原则介绍

单一职责原则

定义：就一个类而言，应该仅有一个引起它变化的原因。一个类/接口/方法只负责一项职责。
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会消弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。设计真正要做的就是发现这些职责并把它们相互分离。
优点：降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险。
缺点：如果多度执行单一职责，那么会出现类爆炸的情况。
建议：接口和方法尽量做到单一职责。
举例：手机的拍照功能，不如相机；俄罗斯方块的界面展示和算法分离；
修改前：

修改后：

开闭原则

定义：软件实体（类、模块、函数等等）应该可以扩展，但不可以修改。
通俗的讲就是对扩展是开放，对修改是封闭。
在我们最初编写代码时，假设变化不会发生，当变化发生时，我们就应该创建抽象来隔离以后发生的同类变化。
用抽象构建框架，用实现扩展细节。
举例：香港一国两治，在原来的社会主义制度上在扩展一个制度。工作8小时是闭合的，对于几点来是开放的；
优点：提供软件系统的可复用性及可维护性。
缺点：过度抽象也是不好的，造成类爆炸；
举例：课程接口，课程实现，新增打折，做法是新增一个课程实现类的子类。

依赖倒置原则

定义为：抽象不应该依赖细节，细节应该依赖于抽象。
大白话：就是要面向接口编程，不要对实现编程。高层模块不应该依赖低层模块，两个都应该依赖抽象。
不使用依赖倒置原则

使用依赖倒置原则

举例：电脑的内存，CPU，主板等都是针对接口设计的。但是收音机就是一个反例。

里氏替换原则

定义：子类型必须能够替换掉它们的父类型。
只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。
因为这个原则使用继承复用成为了可能，该原则也使得开闭原则成为可能。
举例：

迪米特法则

也叫最少知识原则（尽量使用private，protected，少用public，对外部引入的类越少越好）
定义：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。每一个类都应当尽量降低成员的访问权限。
一个类包装好自己的private状态，不需要让别的类知道的字段或行为就不要公开。类之间的耦合越弱，越有利于复用，一个处于弱耦合的类被修改，不会对有关系的类造成波及。
优点：降低类之间的耦合
强调只和朋友交流，不和陌生人说话
朋友：出现在成员变量、方法的输入、输出参数中的类称为成员朋友类，而出现在方法体内部的类不属于朋友类。
举例：
修改前


修改后

合成/聚合复用原则

定义：尽量使用对象组合，而不是继承来达到复用的目的。
聚合：表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分；
合成：表示一种强的‘拥有’关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。
优点：类的继承会比较少，不会出现继承关系比较长的情况。
如：大雁与翅膀是合成关系；大雁与雁群是聚合关系；

举例：
修改前：

修改后：

接口隔离原则

定义：用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口。
一个类对一个类的依赖应该建立在最小的接口上
建立单一接口，不要建立庞大臃肿的接口
尽量细化接口，接口中的方法尽量少
优点：符合我们常说的高内聚低耦合的设计思想，从而使得类具有很好的可读性、可扩展性和可维护性。
缺点：注意适度原则，一定要适度，否则导致接口过多，增加系统复杂性。
举例：
修改前

修改后：

总结

这些原则最终的目的就是为了实现：高内聚低耦合。
但这些原则并不是死板的教条，我们也经常会因为其他的权衡（例如可读性、复杂度等）违背或者放弃一些原则。比如子类拥有特性的方法时，我们很可能打破里氏替换原则。再比如，单一职责原则跟接口隔离原则有时候是冲突的，我们通常会舍弃接口隔离原则，保持单一职责。

重要的原则

1、开闭原则
2、单一职责原则
3、依赖倒置原则

上面示例源码