Python设计模式

设计模式是面对各种问题进行提炼和抽象而形成代码实现方式。这些设计方案是前人不断试验，考虑了封装性、复用性、效率、可修改、可移植等各种因素的高度总结。和JAVA类型，py也有23种设计模型，这些设计模式可分为3大类，分别是创建型、结构型、行为型。

创建型模式

分类

• 单例模式
• 简单工作模型
• 抽象工作模式
• 工作模型
• 建造者模式
• 原型模式

其中属单例模式很是常用。

单例模式

单例模式是指：保证一个类仅有一个实例，并提供一个访问它的全局访问点。具体到此例中，总线对象，就是一个单例，它仅有一个实例，各个线程对总线的访问只有一个全局访问点，即唯一的实例。

使用方式：直接由import导入的包为单例模式

import ... #即为单实例模式，导入多次也被当成一次使用

原理：利用类属性不会随实例变化而变化，实现多个实例共享(moonstate)一个属性。 代码如下：

class MyClass:
    __class_variable = None

    def __init__(self, var):
        self.get_variable = var

    @property
    def get_variable(self):
        return self.__class_variable

    @get_variable.setter
    def get_variable(self, var):
        self.__class__.__class_variable = var

    def display(self):
        return self.get_variable


C1 = MyClass(1)
C2 = MyClass(2)

类属性赋值:
C2 = get_variable = ...

# C1与C2的get_variable 的值永远会相同
print(C1.get_varible)
print(C1.display()) 

应用举例

• 生成全局唯一的序列号；
• 访问全局复用的唯一资源，如磁盘、总线等；
• 单个对象占用的资源过多，如数据库等；
• 统全局统一管理，如Windows下的Task Manager；
• 网站计数器

单例模式的缺点

• 单例模式的扩展是比较困难的
• 赋予了单例以太多的职责，某种程度上违反单一职责原则
• 单例模式是并发协作软件模块中需要最先完成的，因而其不利于测试；
• 单例模式在某种情况下会导致“资源瓶颈”

结构型模式

分类

• 代理模式
• 装饰器模式
• 适配器模式
• 门面模式
• 组合模式
• 享元模式
• 桥梁模式

最实用的是适配模式，通常用来解决兼容问题

适配模式

适配器模式(Adapter Pattern) 是一种结构型设计模式，用于将不兼容的接口转换为另一种接口，以便系统间的协同工作。其主要功能是将一个类的接口转换成客户端所期望的另一种接口，以满足系统间接口的兼容性需求。

原理：配器模式主要由适配器、待适配接口和目标接口三个部分组成。

• 适配器：通过继承或组合待适配接口，实现目标接口，使得待适配接口可以转换为目标接口。
• 待适配接口：需要被转换的原始接口。
• 目标接口：系统期望的兼容接口，适配器将待适配接口转换为目标接口，以满足系统间接口的兼容性需求。

例

#  定义接口
class PaymentInterface:
    def pay(self, amount):
        pass
        
        
class Alipay:
    def do_pay(self, amount):
        print(f"使用支付宝支付了{amount}元")
 
class WeChatPay:
    def make_payment(self, amount):
        print(f"使用微信支付了{amount}元")
 
 
# 适配器类实现支付接口，并将支付宝和微信支付接口适配到支付接口上
class PaymentAdapter(PaymentInterface):
    def __init__(self, payment):
        self.payment = payment
 
    def pay(self, amount):
        if isinstance(self.payment, Alipay):
            self.payment.do_pay(amount)
        elif isinstance(self.payment, WeChatPay):
            self.payment.make_payment(amount)

适用场景：

1. 系统需要与现有的代码或第三方库进行交互，但它们的接口与系统的要求不符。
2. 系统需要将同一接口的多个实现进行统一，提高系统的可维护性和可扩展性。

优点：

1. 提高了系统的灵活性，使得系统具备更好的可扩展性和可移植性。
2. 增强了系统的兼容性，使得原本不兼容的类可以合作无间，降低了系统维护成本。
3. 降低了系统耦合度，减少了系统间的依赖关系。

缺点：

1. 适配器模式增加了代码的复杂度，可能会影响系统性能。
2. 在适配器模式中，适配器本身会成为系统的一个单点故障。

行为模式

分类

• 策略模式
• 责任链模式
• 命令模式
• 中介者模式
• 模板模式
• 迭代器模式
• 访问者模式
• 观察者模式
• 解释器模式
• 备忘录模式
• 状态模式

责任链模式

责任链模式许多个对象以链式的形式依次处理请求，直到请求被处理或者无处理对象为止。责任链模式由多个处理器组成，每个处理器都可以处理一种请求。如果当前处理器无法处理请求，它将把请求传递给下一个处理器，直到请求被处理或者没有处理器可以处理为止。

案例 假设我们正在开发一个电子商务平台，现在需要实现一个购物车功能。当用户添加商品到购物车中时，需要进行以下验证：

• 商品是否存在
• 商品库存是否充足
• 商品是否已经下架

使用举例：

class Handler:
    def __init__(self, successor=None):
        self.successor = successor

    def handle_request(self, request):
        if self.successor is not None:
            return self.successor.handle_request(request)

class ConcreteHandlerA(Handler):
    def handle_request(self, request):
        if request == 'A':
            print('ConcreteHandlerA: Handling request.')
        else:
            super().handle_request(request)

class ConcreteHandlerB(Handler):
    def handle_request(self, request):
        if request == 'B':
            print('ConcreteHandlerB: Handling request.')
        else:
            super().handle_request(request)

class ConcreteHandlerC(Handler):
    def handle_request(self, request):
        if request == 'C':
            print('ConcreteHandlerC: Handling request.')
        else:
            super().handle_request(request)

handler_a = ConcreteHandlerA()
handler_b = ConcreteHandlerB(handler_a)
handler_c = ConcreteHandlerC(handler_b)

handler_c.handle_request('A')
handler_c.handle_request('B')
handler_c.handle_request('C')
handler_c.handle_request('D')

在上面的示例中，我们定义了一个抽象处理者 Handler，它定义了一个接口 handle_request()，用于处理请求，并维护一个对下一个处理者的引用。然后，我们定义了三个具体处理者 ConcreteHandlerA、ConcreteHandlerB 和 ConcreteHandlerC，它们实现了抽象处理者定义的接口，并具体地处理请求。如果它们不能处理请求，则将请求转发给下一个处理者。

使用场景
多个对象需要处理同一种请求，但处理的顺序和方式不同。例如，一个在线商店需要对订单进行风险评估，评估过程包括多个步骤，如检查订单是否来自欺诈用户、检查收货地址是否存在风险等。每个步骤可以使用一个处理器来处理，这些处理器可以组成一个责任链，对订单进行逐步风险评估。