zxy1013 / creat_mode Goto Github PK

设计模式：
对软件设计中普遍存在(反复出现)的各种问题所提出的解决方案--类之间的协作方案

面向对象：
封装(data和方法)、继承(代码复用)、多态(python是一门多态的语言)

接口：
若干抽象方法的集合。限制实现接口的类必须按照接口给定的调用方式实现方法，对高层模块隐藏了类的内部实现
(不需要去看Alipay WechatPay的内部实现 只需要p.pay(100)调用即可)

面向对象设计SOLID原则：
开放封闭原则：
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展
里氏替换原则：
所有引用父类的地方必须能透明的使用其子类的对象(即传User对象不报错的情况下 传VIPUser对象也不能报错)
依赖导致原则：
高层模块不应该依赖低层模块，二者都应该依赖其抽象(接口)；抽象不应该依赖细节，细节应该依赖抽象；要针对接口编程，而不是针对实现编程
接口隔离原则：
使用多个专门的接口，而不使用单一的总接口，高层不应该依赖那些他不需要的接口。用多继承实现多个接口
单一职责原则：
不要存在多于一个导致类变更的原因，即一个类只负责一项职责

设计模式分类：
创建型模式：(如何创建对象 隐藏低层模块的逻辑)
工厂方法模式、抽象工厂方法模式、创建者模式、原型模式、单例模式
结构型模式：(类之间的协同工作)
适配器模式、桥模式、组合模式、装饰模式、外观模式、享元模式、代理模式
行为型模式：(类中方法的完成)
解释器模式、责任链模式、命令模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、访问者模式、模板方法模式
interface.py


一、创建型模式 creat_mode
1.简单工厂模式：
创建对象时，不直接向客户端暴露对象创建的实现细节，而是通过一个工厂类来负责创建产品类的实例。
角色：
抽象产品角色 工厂角色 具体产品角色
优点：
隐藏了对象创建的实现细节
客户端不需要修改代码
缺点：
违反了单一职责原则，将创建逻辑几种合并到一个工厂类里
当添加新产品时，需要修改工厂类代码，违反了开闭原则(当Alipay添加新的支付方式时 需要修改工厂类)
factory.py

2.工厂方法模式：
一个工厂生产一个产品。定义一个用于创建对象的接口，让其子类决定实例化哪一个产品类
角色：
抽象工厂角色 具体工厂角色 抽象产品角色 具体产品角色
优点：
每个具体产品都对应一个具体工厂类，不需要修改工厂类代码
隐藏了对象创建的实现细节
缺点：
每增加一个具体产品类，就必须增加一个相应的具体工厂类
factory_method.py

3.抽象工厂模式：
定义一个工厂类接口，让工厂子类来创建一系列相关或相互依赖的对象，相比工厂方法模式，抽象工厂模式中的每个具体工厂都生产一套产品
eg:生产一部手机 需要手机壳 cpu 操作系统三类对象进行组装 对于每个具体工厂 分别生产一部手机需要的三个对象
角色：
抽象工厂角色 具体工厂角色 抽象产品角色 具体产品角色 客户端
优点：
将客户端与类的具体实现相分离
每个工厂创建了一个完整的产品系列，有利于产品的一致性(及产品之间的约束关系)
缺点：
难以支持新种类的(抽象)产品
abstract_factory.py

4.建造者模式：
将一个复杂对象的构建与他的表示分离，使得同样的构建过程可以创建不同的表示
角色：
抽象建造者 具体建造者 指挥者 产品
建造者模式与抽象工厂模式类似，也用于创建复杂对象。主要区别是建造者模式着重一步步构造复杂对象(顺序)，而抽象工厂模式着重于多个系列的产品对象
优点：
隐藏了一个产品的内部结构和装配过程
将构造代码和表示代码分开
可以对构造过程进行更精细的控制
builder.py

5.单例模式：
保证一个类只有一个实例，并提供一个访问他的全局访问点。
角色：
单例
优点：
对唯一实例的受控访问
单例相当于全局变量，但防止了命名空间被污染，全局变量有名字 单例a b用完换下一个就行 不会冲突
singleton.py

小结：
抽象工厂模式和建造者模式相比于简单工厂模式和工厂方法模式更灵活更复杂
通常情况下，设计以简单工厂模式或工厂方法模式开始，当发现设计需要更大的灵活性时，再向更复杂的设计演化


二、结构型模式 structural_mode
1.适配器模式：
将一个类的接口转换成客户希望的另一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的类可以一起工作
两种实现方式：
类适配器：使用多继承
对象适配器：使用组合
角色：
目标接口 待适配的类 适配器
应用场景：
类适配器：想使用一个已经存在的类，而他的接口不符合要求
对象适配器：想使用一些已经存在的子类，而他的接口不符合要求，对象适配器可以适配它的父类接口
adapter.py

2.桥模式：
将一个事物的两个维度分离，使其都可以独立的进行变化
eg：画图软件画出的图画的形状颜色分别为一个维度
角色：
抽象 细化抽象 实现者 具体实现者
应用场景：
当事物有两个维度上的表现，两个维度都有可能扩展时
优点：
扩展和实现相分离
优秀的扩展能力
bridge.py

3.组合模式：
将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
角色：
抽象组件 叶子组件 复合组件 客户端
应用场景：
表示对象的“部分-整体”层次结构(特别是当结构是递归的)
希望用户忽略单个对象和组合对象的不同，统一的使用组合结构中的所有对象
优点：
定义了包含基本对象和组合对象的类层次结构
简化客户端代码，即客户端可以一致的使用组合对象和单个对象
更容易增加新类型的组件(直接添加叶子组件即可)
composite.py

4.外观模式：
为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用
角色：
外观 子系统类
优点：
减少系统相互依赖
提高了灵活性
提高了安全性 客户端不需要操作子系统
facade.py

5.代理模式：
为其他对象提供一种代理以控制对这个对象的访问
应用场景：
远程代理：为远程的对象提供代理
虚代理：根据需要创建或访问对象 浏览器的无图模式，图片会显示成小方框，当点击时才会发送查看图片的请求
保护代理：控制对原始对象的访问，用于对象有不同访问权限时
角色：
抽象实体 实体 代理
优点：
远程代理：可以隐藏对象位于远程地址空间的事实
虚代理：可以进行优化 例如根据要求创建对象 节省不必要的内存开销
保护代理：允许在访问一个对象时有一些附加的内务处理 做验证等等
agent.py


三、行为型模式 Behavioral_mode
1.责任链模式：
使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理他为止。
角色：
抽象处理者 具体处理者 客户端
应用场景：
有多个对象可以处理一个请求。哪个对象处理由运行时决定
在不明确接受者的情况下，向多个对象中的一个提交请求
优点：
降低耦合度，一个对象无需知道是哪一个对象处理器请求
chain_of_responsibility.py

2.观察者模式：发布-订阅模式
定义对象之间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于他的对象都能得到通知并被自动更新。可订阅已可以取消订阅
角色：
抽象主题 具体主题(发布者) 抽象观察者 具体观察者(订阅者)
应用场景：
当一个抽象模型有两方面，其中一个方面依赖于另一个方面。将这两者封装在独立对象中以使他们可以各自独立的改变和复用
当对一个对象的改变需要同时改变其他对象时，而不知具体有多少个对象有待改变
当一个对象改变必须通知其他对象，而他又不知道具体是谁。换而言之，这些对象不是紧耦合的
优点：
目标和观察者之间的抽象耦合最小
支持广播通信
observer.py

3.策略模式：
定义一系列算法。把他们一个个封装起来，并且使他们可以相互替换。使得算法可独立于使用它的客户而发生变化
eg：滴滴打车 有两个算法 一个是慢结果精确 一个是快不那么准确 平时可能需要一起使用
角色：
抽象策略 具体策略 上下文
优点：
定义了一系列可重用的算法和行为
消除了一些条件语句
可以提供相同行为的不同实现
缺点：
客户必须了解不同的策略
strategy.py

4.模板方法模式：
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤
角色：
抽象类 定义抽象的原子操作(钩子操作) 实现一个模板方法作为该算法的框架
具体类 实现原子操作
应用场景：
一次性实现一个算法的不变的部分
各个子类的公共行为应该被提取出来并集中到一个公共父类中以避免代码重复
控制子类扩展