python设计模式

设计模式

设计模式与面向对象介绍

• 软件工程：写代码前进行模型的构建

• 设计模式：对软件设计中普遍存在的问题所提出的解决方案

• 面向对象：

  • 封装：把数据属性封装到类内
  • 继承：继承是使用已存在的类的定义作为基础建立新类的技术，新类的定义可以增加新的数据或新的功能，也可以用父类的功能，但不能选择性地继承父类
  • 多态：指向子类的父类引用由于向上转型了，它只能访问父类中拥有的方法和属性，而对于子类中存在而父类中不存在的方法，该引用是不能使用的，尽管是重载该方法。若子类重写了父类中的某些方法，在调用该些方法的时候，必定是使用子类中定义的这些方法
  • 接口：若干抽象方法的集合，限制实现接口的类必须按照接口给定的调用方式实现这些方法，对高层模块隐藏了类的内部实现

面向对象设计原则

• 开放封闭原则：一个软件实体如类、模块和函数应该对拓展开放，对修改关闭。即软件实体应在尽量不修改原有代码的情况下进行扩展
• 里氏替换原则：所有引用父类的地方必须能够透明的使用其子类的对象
• 依赖倒置原则：高层模块不应该依赖底层模块，二者都应该依赖其抽象，抽象不应该依赖细节，细节应该依赖抽象，换言之，要针对接口编程
• 接口隔离原则：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口
• 单一职责原则：不要存在多余一个导致类变更的原因，即一个类只负责一项职责

设计模式分类

创建型模式

• 关注在怎么创建对象

结构型模式

• 关注在怎么让几个类协同工作

行为型模式

• 关注在类的行为，方法上面

创建型模式

简单工厂模式

• 内容：不直接向客户端暴露对象创建的实现细节，而是通过一个工厂类来负责创建产品类的实例

• 角色：

  • 工厂角色
  • 抽象产品角色
  • 具体产品角色

• 优点：

  • 隐藏了对象创建的实现细节
  • 客户端不需要修改代码

• 缺点：

  • 违反了单一职责原则，将创建逻辑集中到一个工厂里
  • 当添加新产品时，需要修改工厂代码，违反了开闭原则

工厂方法模式

• 内容：定义一个用于创建对象的接口（工厂接口），让子类决定实例化到哪个产品类
• 角色：
  • 抽象工厂角色
  • 具体工厂角色
  • 抽象产品角色
  • 具体产品角色
• 优点：
  • 每个具体产品都对应一个具体工厂类，不需要修改工厂类代码
  • 隐藏了对象创建的实现细节
• 缺点：
  • 每增加一个具体产品类，就必须增加一个相应的具体工厂类

抽象工厂模式

• 内容：定义一个工厂类接口，让工厂子类来创建一系列相关或相互依赖的对象

• 相比工厂方法模式，抽象工厂模式中的每个具体工厂都生产一套产品

• 优点：

  • 将客户端与类的具体实现相分离
  • 每个工厂创建了一个完整的产品系列，使得易于交换产品系列
  • 有利于产品的一致性（即产品之间的约束关系）

• 缺点：

  • 难以支持新种类的（抽象）产品

建造者模式

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

单例模式

• 内容：保证一个类只有一个实例，并提供一个访问它的全局访问点
• 角色：
  • 单例
• 优点：
  • 对唯一实例的受控访问
  • 单例相当于全局变量，但防止了命名空间被污染

创建型模式小结

• 抽象工厂模式和建造者模式相比与简单工厂模式和工厂方法模式而言更灵活也更复杂
• 通常情况下、设计以简单工厂模式或工厂方法模式开始，当你发现设计需要更大的灵活性时，则像更复杂的设计模式演化

结构型模式

适配器模式

• 内容：将一个类的接口转换成客户希望的另一个接口，适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作

• 两种实现方式：

  • 类适配器：使用继承
  • 对象适配器：使用组合

• 角色：

  • 目标接口
  • 待适配的类
  • 适配器

桥模式

• 内容：
  • 将一个事物的两个维度分离，使其都可以独立的变化
• 角色：
  • 抽象
  • 细化抽象
  • 实现者
  • 具体实现者
• 应用场景：
  • 当事物有两个维度上的表现，两个维度都可能扩展时
• 优点：
  • 抽象和现实相分离
  • 优秀的扩展能力

组合模式

• 内容：将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性

• 角色：

  • 抽象组件
  • 叶子组件
  • 复合组件
  • 客户端

• 适用场景：

  • 表示对象的“部分-整体”层次结构，特别是结构是递归的
  • 希望用户忽略组合对象与单个对象的不同，用户统一地使用组合结构中的所有对象

• 优点：

  • 定义了包含基本对象和组合结构对象的类层次结构
  • 简化客户端代码，即客户端可以一直地使用组合对象和单个对象
  • 更容易增加新类型的组件

外观模式

• 内容：为子系统的一组接口提供了一个一致的界面，外观模式定义了一个高层接口，这个接口使得这个子系统更加容易使用
• 角色：
  • 外观
  • 子系统类
• 优点：
  • 减少系统相互依赖
  • 提高了灵活性
  • 提高了安全性

代理模式

• 内容：为其他对象提供一种代理以控制对这个对象的访问

• 应用场景：

  • 远程代理：为远程的对象提供代理
  • 虚代理：根据需要创建很大的对象
  • 保护代理：控制对原始对象的访问，用于对象有不同访问权限时

• 角色：

  • 抽象实体
  • 实体
  • 代理

• 优点：

  • 远程代理：可以隐藏对象位于远程地址空间的事实
  • 虚代理：可以进行优化，例如根据要求创建对象
  • 保护代理：允许在访问一个对象时有一些附加的内务处理

行为型模式

责任链模式

• 内容：使多个对象都有机会处理请求，从而避免请求的发送者和请求的接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

• 角色：

  • 抽象处理者
  • 具体处理者
  • 客户端

• 适用场景：

  • 有多个对象可以处理一个请求，哪个对象处理由运行时决定
  • 在不明确接收者的情况下，向多个对象中的一个提交请求

• 优点：

  • 降低耦合度：一个对象无需知道是其他哪一个对象处理其请求

观察者模式

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

策略模式

• 内容：定义一系列的算法，把它们一个个封装起来，并且使它们可以相互替换。本模式使算法可独立于使用它的客户变化
• 角色：
  • 抽象策略
  • 具体策略
  • 上下文
• 优点：
  • 定义了一系列可重用的算法和行为
  • 消除了一些条件语句
  • 可以提供相同行为的不同实现
• 缺点：
  • 客户必须了解不同的策略

模板方法模式

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