【程序设计】设计模式与设计原则

设计模式与设计原则，基本符合规则与原则的关系：

 设计模式是一个个具体问题的解决方案，设计模式是程序设计方法的形。

 设计原则反映了这些设计模式的指导思想，设计原则是程序设计方法的神。

设计原则可衍生出的设计模式，任何一种针对特定业务场景中的解决方法，虽然找不到对应的设计模式与之匹配，但若符合设计原则，也可以认为是一种全新的设计模式。

设计原则：

单一职责原则：

 单一职责原则英文原名为Single
Responsibility Principle，简称SRP原则。
 含义：应该有且仅有一个原因引起类的变更。
 例子：一个视频播放系统，一个客户端类有两个功能接口，即视频播放接口和音频播放接口。虽然这样的设计很常见，但却不满足单一职责原则的。原因是，如果对视频播放有变更需求或者对音频播放有修改需求，都会变更视频客户端的类结构。符合单一原则的设计是，将视频播放单元和音频播放单元各建一个类，播放客户端继承两个类，构成客户端。
 单一职责原则的最大难点在于职责的划分

里氏替换原则：

 里氏替换原则英文原名为Liskov
Substitution Principle，简称LSP原则。
 面向对象设计的最为基本原则之一
 含义：任何基类可以出现的地方，子类一定可以出现。
 LSP是继承复用的基石，只有当子类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，子类也能够在基类的基础上增加新的行为。
 举例：对于一个鸟类，可以衍生出麻雀、喜鹊、布谷等子类，这些子类都可继承鸟类的鸣叫、飞行、吃食等接口。而对于一个鸡类，虽然它在生物学上属于鸟类，但它不会飞，那么符合LSP设计原则的情况下，鸡就不应该是鸟的一个子类：在鸟类调用飞行接口的地方，鸡类并不能出现。如果鸡类要使用鸟类的接口，应该使用关联关系，而不是继承关系。

依赖倒置原则：

 依赖倒置原则英文原名为Dependence
Inversion Principle，简称DIP原则。
 含义：高层模块不应该依赖于低层模块，两者都应该依赖其抽象，高层模块和低层模块都应该由各自的抽象模块派生而来，同时接口设计应该依赖于抽象，而非具体模块。
 抽象不应该依赖于细节，细节应该依赖于抽象。
 将每个不可细分的逻辑叫作原子逻辑，原子逻辑组装，形成低层模块，低层模块组装形成高层模块。
 例子：司机与汽车是依赖的关系，司机可以有实习司机类、老司机类等派生；汽车可以有轿车、SUV、卡车等派生类。如果司机中设计一个接口drive，汽车是其参数，符合DIP设计原则的参数，应该是在基类司机类中，将基类汽车类作为参数，而司机的派生类中，drive的参数同样应该为基类汽车类，而不应该是汽车类的任一个派生类。

接口隔离原则：

 接口隔离原则英文原名为Interface
Segregation Principle，简称ISP原则。
 含义：类间的依赖关系不应该建立一个大的接口，而应该建立其最小的接口，即客户端不应该依赖那些它不需要的接口。
 接口可以指一些属性和方法的集合；
 接口可以指特定业务下的接口（如函数，URL调用等）。
 接口应该尽量小，同时仅留给客户端必要的接口，弃用没有必要的接口。
 举例：如果要根据具体的数据，生成饼图、直方图、表格，这个类该如何设计？如果将生成饼图、直方图、表格等“接口”（这里的接口就是“操作”的集合的概念），写在一个类中，是不符合接口隔离原则的。符合ISP原则的设计应该是设计三个类，每个类分别实现饼图、直方图、表格的绘制。
 接口隔离原则和单一职责原则一样，涉及到粒度的问题，解决粒度大小，同样依赖于具体的业务场景，需要读者根据实践去权衡。

迪米特法则（最少知识原则）：

 迪米特法则（Law of Demeter）也叫最少知识原则，英文Least
Knowledge Principle，简称LKP原则。
 含义：一个对象应该对其它对象有最少的了解。
 举例：一个公司有多个部门，每个部门有多个员工，如果公司CEO要下发通知给每个员工，是调用接口直接通知所有员工么？其实不然，CEO只需和它的“朋友”类部门Leader交流就好，部门Leader再下发通知信息即可。而CEO类不需要与员工进行“交流”。
 迪米特法则要求对象应该仅对自己的朋友类交流，而不应该对非朋友类交流。
 朋友类具有以下特征：
  1）当前对象本身（self）；
  2）以参量形式传入到当前对象方法中的对象；
  3）当前对象的实例变量直接引用的对象；
  4）当前对象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友；
  5）当前对象所创建的对象。

开闭原则（重要）：

 开闭原则英文原名为Open Closed
Principle，简称OCP原则。
 含义：一个软件实体，如类、模块、函数等，应该对扩展开放，对修改关闭。
 开闭原则是非常基础的一个原则，也有人把开闭原则称为“原则的原则”。
 对扩展开放：意味着模块的行为是可以扩展的，当高层模块需求改变时，我们可以对低层模块进行扩展，使其具有满足高层模块的新功能；
 对修改关闭：高层模块和低层模块都应该由各自的抽象模块派生而来，同时接口设计应该依赖于抽象，而非具体模块。，即对低层模块行为进行扩展时，不必改动模块的源代码。
 最理想的情况是：业务变动时，仅修改业务代码，不修改依赖的模块（类、函数等）代码，通过扩展依赖的模块单元来实现业务变化。
 举例：假设一个原始基类水果类，苹果类是它的派生类，苹果中包含水果的各种属性，如形状、颜色等；另有两个类，农民类和花园类，最高层次（业务层次）为农民在花园种苹果。如果此时，农民决定不种苹果了，改种梨，符合OCP原则的设计应该为基于水果类构建一个新的类，即梨类（对扩展开放），而并不应该去修改苹果类，使它成为一个梨类（对修改关闭）。
 修改应仅在最高层，即业务层中进行。

设计原则的好处：

由于设计原则是设计模式的提炼，因而设计原则的好处与设计模式是一致的，即：代码易于理解；更适于团体合作；适应需求变化等。

1、创建类设计模式与设计原则

 工厂模式：工厂方法模式是一种解耦结构，工厂类只需要知道抽象产品类，符合最少知识原则（迪米特法则）；同时符合依赖倒置原则和里氏替换原则；
 抽象工厂模式：抽象工厂模式具有工厂模式的优点，但同时，如果产品族要扩展，工厂类也要修改，违反了开闭原则；
 模板模式：优秀的扩展能力符合开闭原则。

2、结构类设计模式与设计原则

 代理模式：代理模式在业务逻辑中将对主体对象的操作进行封装，合适的应用会符合开闭原则和单一职责原则；事实上，几乎带有解耦作用的结构类设计模式都多少符合些开闭原则；
 门面模式：门面模式不符合开闭原则，有时不符合单一职责原则，如若不注意，也会触碰接口隔离原则；
 组合模式：符合开闭原则，但由于一般在拼接树时使用实现类，故不符合依赖倒置原则；
 桥梁模式：桥梁模式堪称依赖倒置原则的典范，同时也符合开闭原则。

3、行为类设计模式与设计原则

 策略模式：符合开闭原则，但高层模块调用时，不符合迪米特法则。行为类设计模式多少会符合些单一职责原则，典型的如观察者模式、中介者模式、访问者模式等；
 责任链模式：符合单一职责原则和迪米特法则；
 命令模式：符合开闭原则。

原文：https://yq.aliyun.com/articles/71197?spm=a2c4e.11153940.blogcont280715.31.175692aawkXRdB