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)适用场景：
- 系统需要与现有的代码或第三方库进行交互，但它们的接口与系统的要求不符。
- 系统需要将同一接口的多个实现进行统一，提高系统的可维护性和可扩展性。
优点：
- 提高了系统的灵活性，使得系统具备更好的可扩展性和可移植性。
- 增强了系统的兼容性，使得原本不兼容的类可以合作无间，降低了系统维护成本。
- 降低了系统耦合度，减少了系统间的依赖关系。
缺点：
- 适配器模式增加了代码的复杂度，可能会影响系统性能。
- 在适配器模式中，适配器本身会成为系统的一个单点故障。
行为模式
分类
- 策略模式
- 责任链模式
- 命令模式
- 中介者模式
- 模板模式
- 迭代器模式
- 访问者模式
- 观察者模式
- 解释器模式
- 备忘录模式
- 状态模式
责任链模式
责任链模式许多个对象以链式的形式依次处理请求，直到请求被处理或者无处理对象为止。责任链模式由多个处理器组成，每个处理器都可以处理一种请求。如果当前处理器无法处理请求，它将把请求传递给下一个处理器，直到请求被处理或者没有处理器可以处理为止。
案例 假设我们正在开发一个电子商务平台，现在需要实现一个购物车功能。当用户添加商品到购物车中时，需要进行以下验证：
- 商品是否存在
- 商品库存是否充足
- 商品是否已经下架
使用举例：
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，它们实现了抽象处理者定义的接口，并具体地处理请求。如果它们不能处理请求，则将请求转发给下一个处理者。
使用场景
多个对象需要处理同一种请求，但处理的顺序和方式不同。例如，一个在线商店需要对订单进行风险评估，评估过程包括多个步骤，如检查订单是否来自欺诈用户、检查收货地址是否存在风险等。每个步骤可以使用一个处理器来处理，这些处理器可以组成一个责任链，对订单进行逐步风险评估。