Python 设计模式
【设计目的：】
- 目标：维护性。
- 标准：扩展性、重用性、高内聚、低耦合。
- 原则：7 大基本原则。
- 模式：23 + N 种设计模式
【7 大基本原则：】
-
单一职责原则：
- 单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。
- 我们不必要拘泥于类，该原则的根本目的是控制职责所在的个体复杂度。只需要明白单一个体只需要做好一件事，个体越简单则可读性越好，职责划分越明确，则改动发生时，越不会影响其他个体。
- 比如这种职责拆分可以发生在函数粒度，也可以发生在函数的聚合层面（类或者更外层的函数），职责和个体理想状态下应该是一对一的。
- 这个原则要求我们能清晰的认识到代码逻辑中的多重职责，从而才能进行划分。
-
接口隔离原则：
- 客户端不应该被迫依赖于它不使用的方法。一个类对另一个类的依赖应该建立在最小的接口上。
- 即对于依赖者，被依赖者应该只提供他关心的功能。当体现在接口上时，就是接口隔离原则，将有冗余的接口拆分。
- 可以避免由于依赖者的增多导致接口膨胀，影响到其他的依赖者。
- 相对于单一职责原则可以理解为单一职责原则是对内做最少承诺，而接口隔离原则是对外做最少的承诺。
-
依赖倒置原则：
- 高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。
- 即面向接口编程。我们只需要对低层进行接口定义，高层只需要关注有哪些接口并进行调用，低层实现时只要实现了这些接口，那么传给高层的实例发生变化时，高层就不需要修改。降低了耦合度。
-
开闭原则：
- 软件实体应当对扩展开放，对修改关闭。
- 在软件修改时，尽量通过扩展而实现而不是通过修改来实现，避免对现有逻辑的影响。
-
合成复用原则：
- 在复用时，要尽量先使用组合（实例化是就存在）或者聚合（通过 API 调用添加为成员变量）等关联关系来实现，其次才考虑使用继承关系来实现。
- 继承强耦合，组合聚合是弱耦合。
-
里氏替换原则：
- 继承必须确保超类所拥有的性质在子类中仍然成立。即子类可以扩展父类的功能，但不能改变父类原有的功能。
-
迪米特法则：
- 只与你的直接朋友交谈，不跟“陌生人”说话，又叫最少知识原则。即一个类对自己依赖的类知道的越少越好。
- 耦合是无法完全避免的。
- 被依赖的类不论多复杂，都应该将细节封装在内部，对外暴露 API。
- 应该避免类中出现非直接的朋友关系（直接朋友关系：成员变量、参数、返回值）的依赖。
【设计模式】
