Python——设计原则

单一职责原则

对类来说的，即一个类应该只负责一项职责。如类A负责两个不同职责（职责1和职责2），当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为 A1和A2。总体来说，单一职责可以降低类的复杂度，一个类只负责一项职责；单一职责可以提高类的可读性，可维护性；单一职责可以降低变更引起的风险。通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则。

接口隔离原则

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。例如，类A通过接口Interface1依赖类B，类C通过接口Interface1依赖类D，如果接口 Interface1对于类A和类C来说不是最小接口，那么类B和类D必须去实现他们不需要的方法。将接口Interface1拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系，也就是采用接口隔离原则。

依赖倒转原则

高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象；依赖倒转的中心思想是面向接口编程。相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

里氏替换原则

父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合、组合等关系代替。

开闭原则

一个软件实体，如类，模块和函数对扩展开放，对修改关闭。用抽象构建框架，用实现扩展细节。当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

迪米特法则

一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息。

合成复用原则

找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。针对接口编程，而不是针对实现编程，最终实现交互对象之间的松耦合。