python万里长征第二站（非教程）

一、概述

找个对象！面向对象开发

二、详情

不想当总工程师的架构设计师，不是一个好的程序员！不想当CTO的总工，不是好的对象。（虾皮胡累累，当个玩笑，一笑而过）

2.1 六大原则

solid五大基础原则 + 迪米特原则
s：单一原则
o：开闭原则
l：里式替换原则（里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。）
i：接口隔离原则
d：依赖倒置原则
d：迪米特（最少知道）原则

2.2 UML设计

待补充！

2.3 设计模式

设计类关系划分需要参考的概念点

2.3.1 口诀一

5个创建型，7个结构型，11个行为型

抽工单建原
桥代理组装适配器，享元回家装饰外观。
访问者写好策略备忘录，观察模板迭代的状态，命令中介解释责任链。

2.3.2 口诀二

设计模式分为三种类型：
（1）创建型模式5种：单例模式，抽象工厂模式，工厂模式，原型模式，建造者模式。
（口诀：单原建造者，东西二厂）
（2）结构型模式7种：适配器模式，桥接模式，装饰模式，组合模式，外观模式，享元模式，代理模式。
（口诀：一器一桥一元一代理；装饰组合外观）
（3）行为型模式11种：观察者模式，中介者模式，访问者模式，解释器模式，迭代器模式，备忘录模式，责任链模式，状态模式，策略模式，命令模式，模板模式。
（口诀：三者两器、一录一链一模板，状态策略命令）

2.3.3 详情分三类

2.3.3.1 创建型模式

• 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
• 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
• 工厂方法（FactoryMethod）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
• 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。

以上 5 种创建型模式，除了工厂方法模式属于类创建型模式，其他的全部属于对象创建型模式

2.3.3.2 结构模式

• 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
• 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
• 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现的，从而降低了抽象和实现这两个可变维度的耦合度。
• 装饰（Decorator）模式：动态地给对象增加一些职责，即增加其额外的功能。
• 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
• 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
• 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。

其中对象的适配器模式是各种模式的起源。

2.3.3.3 行为行模式

行为型模式是 GoF 设计模式中最为庞大的一类，它包含以下 11 种模式。

• 模板方法（Template Method）模式：定义一个操作中的算法骨架，将算法的一些步骤延迟到子类中，使得子类在可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
• 策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
• 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
• 职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
• 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。
• 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
• 中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
• 迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
• 访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
• 备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
• 解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

以上 11 种行为型模式，除了模板方法模式和解释器模式是类行为型模式，其他的全部属于对象行为型模式。
11中模式的关系：
第一类：通过父类与子类的关系进行实现。
第二类：两个类之间。
第三类：类的状态。
第四类：通过中间类

2.4 禅

The Zen of Python, by Tim Peters
Beautiful is better than ugly.

优美胜于丑陋（Python 以编写优美的代码为目标）

Explicit is better than implicit.

明了胜于晦涩（优美的代码应当是明了的，命名规范，风格相似）

Simple is better than complex.

简洁胜于复杂（优美的代码应当是简洁的，不要有复杂的内部实现）

Complex is better than complicated.

复杂胜于凌乱（如果复杂不可避免，那代码间也不能有难懂的关系，要保持接口简洁）

Flat is better than nested.

扁平胜于嵌套（优美的代码应当是扁平的，不能有太多的嵌套）

Sparse is better than dense.

间隔胜于紧凑（优美的代码有适当的间隔，不要奢望一行代码解决问题）

Readability counts.

可读性很重要（优美的代码是可读的）

Special cases aren’t special enough to break the rules.

Although practicality beats purity.

即便假借特例的实用性之名，也不可违背这些规则（这些规则至高无上）

Errors should never pass silently.

Unless explicitly silenced.

不要包容所有错误，除非你确定需要这样做（精准地捕获异常，不写 except:pass 风格的代码）

In the face of ambiguity, refuse the temptation to guess.

当存在多种可能，不要尝试去猜测

There should be one-- and preferably only one --obvious way to do it.

而是尽量找一种，最好是唯一一种明显的解决方案（如果不确定，就用穷举法）

Although that way may not be obvious at first unless you’re Dutch.

虽然这并不容易，因为你不是 Python 之父（这里的 Dutch 是指 Guido ）

Now is better than never.

Although never is often better than right now.

做也许好过不做，但不假思索就动手还不如不做（动手之前要细思量）

If the implementation is hard to explain, it’s a bad idea.

If the implementation is easy to explain, it may be a good idea.

如果你无法向人描述你的方案，那肯定不是一个好方案；反之亦然（方案测评标准）

Namespaces are one honking great idea – let’s do more of those!

命名空间是一种绝妙的理念，我们应当多加利用（倡导与号召）