Python工程之设计模式总结Python之23种设计模式

Posted 2022-11-10

Python之23种设计模式

目录

• ​​设计模式介绍​​
• ​​    GoF该书设计了23个设计模式​​
• ​​    设计模式（Design Patterns）——可复用面向对象软件的基础​​
• ​​    设计模式分类​​
• ​​        1 创建型模式​​
• ​​        2 结构型模式​​
• ​​        3 行为型模式​​
• ​​设计模式6大原则​​
• ​​实战示例​​
• ​​    创建型​​
• ​​         0. 简单工厂模式（Simple Factory）​​
• ​​        1.工厂方法模式（Factory Method）​​
• ​​        2.抽象工厂模式（Abstract Factory）​​
• ​​        3.创建者模式（Builder）​​
• ​​        4.原型模式（Prototype）​​
• ​​        5.单例模式（Singleton）​​
• ​​    结构型   ​​
• ​​        6.适配器模式（Adapter）​​
• ​​        7.代理模式（Proxy）​​
• ​​        8.装饰模式（Decorator） ​​
• ​​        9.桥模式（Bridge、多维度）​​
• ​​        10.组合模式（Composite） ​​
• ​​        11.外观模式（Facade）​​
• ​​        12.享元模式（Flyweight）​​
• ​​    行为型​​
• ​​        13.观察者模式（Observer）​​
• ​​        14.状态模式（State）​​
• ​​        15.策略模式（Strategy）​​
• ​​        16.职责链模式（Chain of Responsibility）​​
• ​​        17.命令模式（Command）​​
• ​​        18.访问者模式（Visitor）  ​​
• ​​        19.调停者模式（Mediator）​​
• ​​        20.备忘录模式（Memento） ​​
• ​​        21. 迭代器模式（Iterator） ​​
• ​​        22. 解释器模式（Interpreter） ​​
• ​​        23.模板方法（Template Method）​​

 

---

设计模式介绍

    GoF该书设计了23个设计模式

Python一切皆对象解释：我们用到的每个数字和字符串还是集合还是..本质都有相应的类对应如：name = “axc”可以通过点进行调用：name.strip()

    设计模式（Design Patterns）——可复用面向对象软件的基础

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因。

    设计模式分类

经典的《设计模式》一书归纳出23种设计模式，这23种模式又可归为，创建型、结构型和行为型3大类

        1 创建型模式

前面讲过，社会化的分工越来越细，自然在软件设计方面也是如此，因此对象的创建和对象的使用分开也就成为了必然趋势。因为对象的创建会消耗掉系统的很多资源，所以单独对对象的创建进行研究，从而能够高效地创建对象就是创建型模式要探讨的问题。这里有6个具体的创建型模式可供研究，它们分别是：

    0. 简单工厂模式（Simple Factory） #说明：严格来说，简单工厂模式不是GoF总结出来的23种设计模式之一。
    1.工厂方法模式（Factory Method）
    2.抽象工厂模式（Abstract Factory）
    3.创建者模式（Builder）
    4.原型模式（Prototype）
    5.单例模式（Singleton）

        2 结构型模式

在解决了对象的创建问题之后，对象的组成以及对象之间的依赖关系就成了开发人员关注的焦点，因为如何设计对象的结构、继承和依赖关系会影响到后续程序的维护性、代码的健壮性、耦合性等。对象结构的设计很容易体现出设计人员水平的高低，这里有7个具体的结构型模式可供研究，它们分别是：

    6.适配器模式（Adapter）
    7.代理模式（Proxy）
    8.装饰模式（Decorator） 
    9.桥模式（Bridge、多维度）
    10.组合模式（Composite）   
    11.外观模式
    12.享元模式（Flyweight）

        3 行为型模式

在对象的结构和对象的创建问题都解决了之后，就剩下对象的行为问题了，如果对象的行为设计的好，那么对象的行为就会更清晰，它们之间的协作效率就会提高，这里有11个具体的行为型模式可供研究，它们分别是：

   13.观察者模式（Observer）  #典型的发布订阅
   14.状态模式（State）
   15.策略模式（Strategy）
   16.职责链模式（Chain of Responsibility）
   17.命令模式（Command） 
   18.访问者模式（Visitor）  
   19.调停者模式（Mediator）
   20.备忘录模式（Memento） #如：虚拟机快照  #没讲（克隆：深copy、快照：浅copy）
   21. 迭代器模式（Iterator）   
   22. 解释器模式（Interpreter） 
   23.模板方法（Template Method）

 

设计模式6大原则

1、开闭原则（Open Close Principle）

开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。

2、里氏代换原则（Liskov Substitution Principle）

里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科

3、依赖倒转原则（Dependence Inversion Principle）

这个是开闭原则的基础，具体内容：是对接口编程，依赖于抽象而不依赖于具体。

4、接口隔离原则（Interface Segregation Principle）

这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。

5、迪米特法则（最少知道原则）（Demeter Principle）

为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。

6、合成复用原则（Composite Reuse Principle）

原则是尽量使用合成/聚合的方式，而不是使用继承。

 

实战示例

    创建型

         0. 简单工厂模式（Simple Factory）

说明：严格来说，简单工厂模式不是GoF总结出来的23种设计模式之一。

在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。

意图：

定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。 

适用性：

当一个类不知道它所必须创建的对象的类的时候。
当一个类希望由它的子类来指定它所创建的对象的时候。
当类将创建对象的职责委托给多个子类中的某一个。

示例代码：

执行结果：

Shape（父类 or 基类）：提取出所有子类的重复方法代码
Circle（Shape子类 or 派生类）：作用为画圆形
Rectangle（Shape子类 or 派生类）：作用为画矩形
ShapeFactory（新式类）：该类作用为用户可根据该类对象创建指定的Shape子类对象（Circle or Rectangle）
优点：客户端不需要修改代码。
缺点： 当需要增加新的运算类的时候，不仅需新加运算类，还要修改工厂类，违反了开闭原则。

        1.工厂方法模式（Factory Method）

这个和简单工厂有区别，简单工厂模式只有一个工厂，工厂方法模式对每一个产品都有相应的工厂
好处：增加一个运算类（例如N次方类），只需要增加运算类和相对应的工厂，两个类，不需要修改工厂类。
缺点：增加运算类，会修改客户端代码，工厂方法只是把简单工厂的内部逻辑判断移到了客户端进行

示例代码：

执行结果:

ShapeFactory（父类 or 基类）：提取出所有子类的重复方法代码
Circle（Shape子类 or 派生类）：作用为画圆形
Rectangle（Shape子类 or 派生类）：作用为画矩形
ShapeInterfaceFactory（父类 or 基类）：提取出所有子类的重复方法代码
ShapeCircle（ShapeInterfaceFactory的子类 or 派生类）：作用为创建指定的Circle对象
ShapeRectangle（ShapeInterfaceFactory的子类 or 派生类）：作用为创建指定的Rectangle对象

        2.抽象工厂模式（Abstract Factory）

每一个模式都是针对一定问题的解决方案。抽象工厂模式与工厂方法模式的最大区别就在于，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式则需要面对多个产品等级结构。

　　在学习抽象工厂具体实例之前，应该明白两个重要的概念：产品族和产品等级。

所谓产品族，是指位于不同产品等级结构中，功能相关联的产品组成的家族。比如AMD的主板、芯片组、CPU组成一个家族，Intel的主板、芯片组、CPU组成一个家族。而这两个家族都来自于三个产品等级：主板、芯片组、CPU。一个等级结构是由相同的结构的产品组成，示意图如下：

显然，每一个产品族中含有产品的数目，与产品等级结构的数目是相等的。产品的等级结构与产品族将产品按照不同方向划分，形成一个二维的坐标系。横轴表示产品的等级结构，纵轴表示产品族，上图共有两个产品族，分布于三个不同的产品等级结构中。只要指明一个产品所处的产品族以及它所属的等级结构，就可以唯一的确定这个产品。

　　上面所给出的三个不同的等级结构具有平行的结构。因此，如果采用工厂方法模式，就势必要使用三个独立的工厂等级结构来对付这三个产品等级结构。由于这三个产品等级结构的相似性，会导致三个平行的工厂等级结构。随着产品等级结构的数目的增加，工厂方法模式所给出的工厂等级结构的数目也会随之增加。如下图：

那么，是否可以使用同一个工厂等级结构来对付这些相同或者极为相似的产品等级结构呢？当然可以的，而且这就是抽象工厂模式的好处。同一个工厂等级结构负责三个不同产品等级结构中的产品对象的创建。

    可以看出，一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象。显然，这时候抽象工厂模式比简单工厂模式、工厂方法模式更有效率。对应于每一个产品族都有一个具体工厂。而每一个具体工厂负责创建属于同一个产品族，但是分属于不同等级结构的产品。

抽象工厂模式结构

　　抽象工厂模式是对象的创建模式，它是工厂方法模式的进一步推广。

　　假设一个子系统需要一些产品对象，而这些产品又属于一个以上的产品等级结构。那么为了将消费这些产品对象的责任和创建这些产品对象的责任分割开来，可以引进抽象工厂模式。这样的话，消费产品的一方不需要直接参与产品的创建工作，而只需要向一个公用的工厂接口请求所需要的产品。

　　通过使用抽象工厂模式，可以处理具有相同（或者相似）等级结构中的多个产品族中的产品对象的创建问题。如下图所示：

 

　　由于这两个产品族的等级结构相同，因此使用同一个工厂族也可以处理这两个产品族的创建问题，这就是抽象工厂模式。

　　根据产品角色的结构图，就不难给出工厂角色的结构设计图。

 

可以看出，每一个工厂角色都有两个工厂方法，分别负责创建分属不同产品等级结构的产品对象。

 

抽象工厂的功能是为一系列相关对象或相互依赖的对象创建一个接口。一定要注意，这个接口内的方法不是任意堆砌的，而是一系列相关或相互依赖的方法。比如上面例子中的主板和CPU，都是为了组装一台电脑的相关对象。不同的装机方案，代表一种具体的电脑系列。

由于抽象工厂定义的一系列对象通常是相关或相互依赖的，这些产品对象就构成了一个产品族，也就是抽象工厂定义了一个产品族。

　　这就带来非常大的灵活性，切换产品族的时候，只要提供不同的抽象工厂实现就可以了，也就是说现在是以一个产品族作为一个整体被切换。

 

在什么情况下应当使用抽象工厂模式

　　1.一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。

　　2.这个系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。

　　3.同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。（比如：Intel主板必须使用Intel CPU、Intel芯片组）

　　4.系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于实现。

抽象工厂模式的起源

　　抽象工厂模式的起源或者最早的应用，是用于创建分属于不同操作系统的视窗构建。比如：命令按键（Button）与文字框（Text)都是视窗构建，在UNIX操作系统的视窗环境和Windows操作系统的视窗环境中，这两个构建有不同的本地实现，它们的细节有所不同。

　　在每一个操作系统中，都有一个视窗构建组成的构建家族。在这里就是Button和Text组成的产品族。而每一个视窗构件都构成自己的等级结构，由一个抽象角色给出抽象的功能描述，而由具体子类给出不同操作系统下的具体实现。

 

抽象工厂模式的优点

• 分离接口和实现

　　客户端使用抽象工厂来创建需要的对象，而客户端根本就不知道具体的实现是谁，客户端只是面向产品的接口编程而已。也就是说，客户端从具体的产品实现中解耦。

• 使切换产品族变得容易

　　因为一个具体的工厂实现代表的是一个产品族，比如上面例子的从Intel系列到AMD系列只需要切换一下具体工厂。

抽象工厂模式的缺点

• 不太容易扩展新的产品

　　如果需要给整个产品族添加一个新的产品，那么就需要修改抽象工厂，这样就会导致修改所有的工厂实现类。

示例代码：

执行结果：

AbstractFactory（父类or基类 ）
    IntelFactory（AbstractFactory的子类or派生类）：作用为进行了创建自定品牌的零件
    AmdFactory（AbstractFactory的子类or派生类）：作用为进行了创建自定品牌的零件
AbstractCpu（父类or基类 ）
    IntelCpu（AbstractCpu的子类or派生类）：作用为记录cup的型号
    AmdCpu（AbstractCpu的子类or派生类）：作用为记录cup的型号
AbstractMainboard（父类or基类 ）
    IntelMainBoard（AbstractMainboard的子类or派生类）：作用为记录主板的型号
    AmdMainBoard（AbstractMainboard的子类or派生类）：作用为记录主板的型号
ComputerEngineer（新式类）：作用为根据工厂对象（如IntelFactory()）让其组装自身型号的零件

抽象工厂和工厂模式的对比区别：
抽象工厂：规定死了，依赖限制，假上面实验，你用intel的机器只能配置intel的CPU不能配置AMD的CPU（由各自的工厂指定自己的产品生产品牌）
工厂模式：不是固定死的，举例：你可使用intel的机器配置AMD的CPU

        3.创建者模式（Builder）

意图：

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

适用性：

当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。

当构造过程必须允许被构造的对象有不同的表示时。

示例代码：

执行结果：

personBuilder（父类 or 基类）
PersonFatBuilder(personBuilder的子类 or派生类）：作用为创建一个胖子的身体部位
PersonThinBuilder(personBuilder的子类 or派生类）：作用为创建一个瘦子的身体部位
PersonDirector（新式类）：作用为根据personBuilder子类对象（如PersonFatBuilder()）让其创建其身体部位

        4.原型模式（Prototype）

意图：

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

适用性：

当要实例化的类是在运行时刻指定时，例如，通过动态装载；或者为了避免创建一个与产品类层次平行的工厂类层次时；或者当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。

示例代码：

执行结果：

通过执行结果我们可以看出：通过一个类的方法复制a对象，进行a对象的变量赋值

        5.单例模式（Singleton）

意图：

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

适用性：

当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。

当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。

示例代码：

执行结果：

通过执行结果我们可以看出：一个类永远只允许一个实例化对象，不管多少个进行实例化，都返回第一个实例化的对象

    结构型   

        6.适配器模式（Adapter）

意图：

 将一个类的接口转换成客户希望的另外一个接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 

适用性：

 你想使用一个已经存在的类，而它的接口不符合你的需求。

你想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）协同工作。

（仅适用于对象Adapter ）你想使用一些已经存在的子类，但是不可能对每一个都进行子类化以匹配它们的接口。对象适配器可以适配它的父类接口。

示例代码：

执行结果：

Player：(父类or基类）
国内
Forwards（Player的子类or派生类）：作用为国内球员的动作方法
Center（Player的子类or派生类）：作用为国内球员的动作方法
Guards（Player的子类or派生类）：作用为国内球员的动作方法
国外：
ForeignCenter（Player的子类or派生类）：作用为国外球员的动作方法（动作虽然一样但是动作方法的名字和国内动作方法的名字不一样）
Translator（Player的子类or派生类）：作用为适配器，国内球员的动作方法的名字一样（但是方法内调用了国外球员对象的动作方法）

 

        7.代理模式（Proxy）

意图：为其他对象提供一种代理以控制对这个对象的访问。

主要解决：在直接访问对象时带来的问题，比如说：要访问的对象在远程的机器上。在面向对象系统中，有些对象由于某些原因（比如对象创建开销很大，或者某些操作需要安全控制，或者需要进程外的访问），直接访问会给使用者或者系统结构带来很多麻烦，我们可以在访问此对象时加上一个对此对象的访问层。

何时使用：想在访问一个类时做一些控制。

如何解决：增加中间层。

关键代码：实现与被代理类组合。

应用实例： 1、Windows 里面的快捷方式。 2、猪八戒去找高翠兰结果是孙悟空变的，可以这样理解：把高翠兰的外貌抽象出来，高翠兰本人和孙悟空都实现了这个接口，猪八戒访问高翠兰的时候看不出来这个是孙悟空，所以说孙悟空是高翠兰代理类。 3、买火车票不一定在火车站买，也可以去代售点。 4、一张支票或银行存单是账户中资金的代理。支票在市场交易中用来代替现金，并提供对签发人账号上资金的控制。 5、spring aop。

优点： 1、职责清晰。 2、高扩展性。 3、智能化。

缺点： 1、由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。 2、实现代理模式需要额外的工作，有些代理模式的实现非常复杂。

使用场景：按职责来划分，通常有以下使用场景： 1、远程代理。 2、虚拟代理。 3、Copy-on-Write 代理。 4、保护（Protect or Access）代理。 5、Cache代理。 6、防火墙（Firewall）代理。 7、同步化（Synchronization）代理。 8、智能引用（Smart Reference）代理。

代码示例

   执行结果：

sender_base（父类or基类）
send_class（sender_base的子类or派生类）：作用为发送信息
agent_class（sender_base的子类or派生类）：作用为代理（发送信息给接受者）
receive_class（新式类）：作用为实例化一个接受者
 

        8.装饰模式（Decorator） 

意图： 
动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator 模式相比生成子类更为灵活。 
适用性：

 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。

 处理那些可以撤消的职责。

当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。

代码示例：

执行结果：

从代码可以了解执行一个类对象可以通过另外一个类（装饰器）代替其执行（不改变被装饰的类的源码）

        9.桥模式（Bridge、多维度）

示例代码

执行结果：

AbstractRoad（父类or基类）
Street（AbstractRoad的子类or派生类）：作用为执行了车辆对象的方法
SpeedWay（AbstractRoad的子类or派生类）：作用为执行了车辆对象的方法

AbstractCar（父类or基类）
Car（AbstractCar的子类or派生类）：作用为被调用执行
Bus（AbstractCar的子类or派生类）：作为为被调用执行
 

应用设计模式:
       桥接模式（Bridge）来做(多维度变化);
       结合上面的例子,增加一个维度"人",不同的人开着不同的汽车在不同的路上行驶(三个维度);
       结合上面增加一个类"人",并重新调用.
代码实现:

示例代码

执行结果：

AbstractRoad（父类or基类）
Street（AbstractRoad的子类or派生类）：作用为执行了车辆对象的方法
SpeedWay（AbstractRoad的子类or派生类）：作用为执行了车辆对象的方法

AbstractCar（父类or基类）
Car（AbstractCar的子类or派生类）：作用为被调用执行
Bus（AbstractCar的子类or派生类）：作为为被调用执行

People（父类or基类）
Man（People的子类or派生类）：作用为执行了路对象的方法
Woman（People的子类or派生类）：作用为执行了路对象的方法

        10.组合模式（Composite） 

意图：

 将对象组合成树形结构以表示“部分-整体”的层次结构。C o m p o s i t e 使得用户对单个对象和组合对象的使用具有一致性。 

适用性：

 你想表示对象的部分-整体层次结构。

你希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。

示例代码

执行结果：

从执行结果可以看出，通过一个类对象把其他的类对象添加到自身的变量列表，然后循环执行该列表，执行所有对象的相同方法

 

        11.外观模式（Facade）

意图：

 为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

适用性：

当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade 可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过facade层。

客户程序与抽象类的实现部分之间存在着很大的依赖性。引入facade 将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。

当你需要构建一个层次结构的子系统时，使用facade模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过facade进行通讯，从而简化了它们之间的依赖关系。

执行结果：

从执行结果可以看出：一个类被实例化成对象，该对象的初始化进行了实例化所有其他的类对象，通过调用该类的方法执行所有其他类对象的相同方法
   

        12.享元模式（Flyweight）

 

意图：

运用共享技术有效地支持大量细粒度的对象。

适用性：

一个应用程序使用了大量的对象。

完全由于使用大量的对象，造成很大的存储开销。

对象的大多数状态都可变为外部状态。

如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象。 

应用程序不依赖于对象标识。由于Flyweight 对象可以被共享，对于概念上明显有别的对象，标识测试将返回真值。

代码示例：