Python与设计模式--设计原则

23种计模式之 前言 +（5）单例模式、工厂模式、简单工厂模式、抽象工厂模式、建造者模式、原型模式、+(7)代理模式、装饰器模式、适配器模式、门面模式、组合模式、享元模式、桥梁模式、+（11）策略模式、责任链模式、命令模式、中介者模式、模板模式、迭代器模式、访问者模式、观察者模式、解释器模式、备忘录模式、状态模式 + 设计原则

23-Python与设计模式–设计原则

一 六大设计原则

在法理学中，法律规则与法律原则都是法律规范的重要构成。但二者也会有些不同：法律规则是指采取一定的
结构形式具体规定人们的法律权利、法律义务以及相应的法律后果的行为规范，内容比较明确，比如，
交通法规中规定，禁止闯红灯；法律原则是指在一定法律体系中作为法律规则的指导思想，基本或本原的、
综合的、稳定的原理和准则，内容上只包含“大方针”，而并未有具体规则，比如，如果车上有马上临产的孕妇，
闯红灯不会被处罚，这是符合重视生命的原则。设计模式与设计原则，基本符合规则与原则的关系，
设计模式是一个个具体问题的解决方案，设计原则则反映了这些设计模式的指导思想；
同时，设计原则可衍生出的设计模式也不仅限于上述介绍到了23种设计模式，任何一种针对特定业务场景中的
解决方法，虽然找不到对应的设计模式与之匹配，但若符合设计原则，也可以认为是一种全新的设计模式。
从这个意义上来说，设计模式是程序设计方法的形，而设计原则是程序设计方法的神。

1、单一职责原则

单一职责原则英文原名为Single Responsibility Principle，简称SRP原则。
其含义为：应该有且仅有一个原因引起类的变更。举个例子来说明单一职责原则：一个视频播放系统，
一个客户端类有两个功能接口，即视频播放接口和音频播放接口。虽然这样的设计很常见，
但却不满足单一职责原则的。原因是，如果对视频播放有变更需求或者对音频播放有修改需求，
都会变更视频客户端的类结构。符合单一原则的设计是，将视频播放单元和音频播放单元各建一个类，
播放客户端继承两个类，构成客户端。单一职责原则的最大难点在于职责的划分，试想，以上划分是否是符合单一职责了？既是，也不是。
试想，如果将视频传输和音频传输的协议信息和数据信息区分开，为符合这种粒度的单一职责原则就必须要有
协议传输类和数据传输类的划分。如果接着细分，可能一个简单的小模块，都要设计非常多的类。
因此，单一职责原则粒度的选择，应该根据业务流程和人员分工来进行考虑。一些基本的划分，
似乎已经成了行业规范性的内容，比如，业务逻辑与用户信息管理的划分等。

2、里氏替换原则

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

3、依赖倒置原则

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

4、接口隔离原则

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

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

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

6、开闭原则

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

二 遵循设计原则的好处

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

三、设计原则与设计模式

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

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

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

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

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

策略模式：符合开闭原则，但高层模块调用时，不符合迪米特法则。
行为类设计模式多少会符合些单一职责原则，典型的如观察者模式、中介者模式、访问者模式等；责任链模式：符合单一职责原则和迪米特法则；命令模式：符合开闭原则。在不同的业务逻辑中，不同的设计模式也会显示出不同的设计原则特点，从这个意义上来说，
设计模式是设计原则的体现，但体现不是固定的，是根据业务而有所不同的。