Python 设计模式

【设计目的：】 

1. 目标：维护性。
2. 标准：扩展性、重用性、高内聚、低耦合。
3. 原则：7 大基本原则。
4. 模式：23 + N 种设计模式

【7 大基本原则：】 

• 单一职责原则：

  • 单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。
  • 我们不必要拘泥于类，该原则的根本目的是控制职责所在的个体复杂度。只需要明白单一个体只需要做好一件事，个体越简单则可读性越好，职责划分越明确，则改动发生时，越不会影响其他个体。
  • 比如这种职责拆分可以发生在函数粒度，也可以发生在函数的聚合层面（类或者更外层的函数），职责和个体理想状态下应该是一对一的。
  • 这个原则要求我们能清晰的认识到代码逻辑中的多重职责，从而才能进行划分。

• 接口隔离原则：

  • 客户端不应该被迫依赖于它不使用的方法。一个类对另一个类的依赖应该建立在最小的接口上。
  • 即对于依赖者，被依赖者应该只提供他关心的功能。当体现在接口上时，就是接口隔离原则，将有冗余的接口拆分。
  • 可以避免由于依赖者的增多导致接口膨胀，影响到其他的依赖者。
  • 相对于单一职责原则可以理解为单一职责原则是对内做最少承诺，而接口隔离原则是对外做最少的承诺。

• 依赖倒置原则：

  • 高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。
  • 即面向接口编程。我们只需要对低层进行接口定义，高层只需要关注有哪些接口并进行调用，低层实现时只要实现了这些接口，那么传给高层的实例发生变化时，高层就不需要修改。降低了耦合度。

• 开闭原则：

  • 软件实体应当对扩展开放，对修改关闭。
  • 在软件修改时，尽量通过扩展而实现而不是通过修改来实现，避免对现有逻辑的影响。

• 合成复用原则：

  • 在复用时，要尽量先使用组合（实例化是就存在）或者聚合（通过 API 调用添加为成员变量）等关联关系来实现，其次才考虑使用继承关系来实现。
  • 继承强耦合，组合聚合是弱耦合。

• 里氏替换原则：

  • 继承必须确保超类所拥有的性质在子类中仍然成立。即子类可以扩展父类的功能，但不能改变父类原有的功能。

• 迪米特法则：

  • 只与你的直接朋友交谈，不跟“陌生人”说话，又叫最少知识原则。即一个类对自己依赖的类知道的越少越好。
  • 耦合是无法完全避免的。
  • 被依赖的类不论多复杂，都应该将细节封装在内部，对外暴露 API。
  • 应该避免类中出现非直接的朋友关系（直接朋友关系：成员变量、参数、返回值）的依赖。

【设计模式】 

•