一文吃透python常见设计模式

已于 2023-10-12 20:04:16 修改
阅读量179 收藏
点赞数 1
分类专栏： # python进阶 文章标签： python 设计模式 后端
于 2023-10-11 21:43:18 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_43745578/article/details/133779552
版权

目录

六大设计原则（ SOLID ）

单一职责原则

单一职责原则（Single Responsibility Principle）：一个类应该只有一个发生变化的原因。

主要为了不要让一个类承担过多的职责。避免职责耦合在一起，避免一个职责的变化影响到其他职责。

举个例子：一个视频播放系统，一个客户端类有两个功能接口，视频播放接口和音频播放接口。虽然这样的设计很常见，但却不满足单一职责原则的。原因是，如果对视频播放有变更需求或者对音频播放有修改需求，都会变更视频客户端的类结构。符合单一原则的设计是，将视频播放单元和音频播放单元各建一个类，播放客户端继承两个类，构成客户端。

单一职责原则的最大难点在于职责的划分，试想，以上划分是否是符合单一职责了？既是，也不是。试想，如果将视频传输和音频传输的协议信息和数据信息区分开，为符合这种粒度的单一职责原则就必须要有协议传输类和数据传输类的划分。如果接着细分，可能一个简单的小模块，都要设计非常多的类。因此，单一职责原则粒度的选择，应该根据业务流程和人员分工来进行考虑。一些基本的划分，似乎已经成了行业规范性的内容，比如，业务逻辑与用户信息管理的划分等。

单一职责的好处：

  1. 类的复杂性降低，实现什么职责都有清晰明确的定义；

  2. 可读性高，复杂性降低，可读性自然就提高了；

  3. 可维护性提高，可读性提高了，那自然更容易维护了；

  4. 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

里氏替换原则

里氏替换原则（Liskov Substitution Principle）：所有引用基类的地方必须能透明地使用其子类的对象。

通俗点讲，就是只要父类能出现的地方，子类就可以出现，而且替换为子类也不会产生任何错误或异常。

可以理解为子类继承父类时，尽量不要修改父类方法预期的行为，也就是尽量不要重写父类方法。

在运用里氏代换原则时，我们尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法，在运行时再确定其子类类型，用子类实例来替换父类实例。

迪米特法则

迪米特法则（Law of Demeter）：只与你的直接朋友交谈，不跟“陌生人”说话。

通俗的讲，一个类对自己需要耦合的类应该知道的最少，你内部多么复杂和我没关系，我只对你提供的public方法感兴趣。这样的话，如果一个系统符合迪米特法则，那么当其中某一个类发生修改时，就会尽量少地影响其他模块，降低系统的耦合度，使类与类之间保持松散的耦合关系。

接口隔离原则

接口隔离原则（Interface Segregation Principle）：建立单一接口而不是建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。

也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

比如说，定义了一个接口MyInterface。

public interface MyInterface{
    public void method1();  
    public void method2();  
    public void method3();  
}

但是实现类A只想实现接口中的method1方法，而实现类B只想实现接口中的method2、method3方法。此时只写一个接口让A、B都去实现该接口的话，会导致AB中会实现不需要的方法，这样设计接口会导致接口比较臃肿，因此我们应该要把这个接口拆分开来写。

接口隔离原则跟之前的单一职责原则很相似，但其实不同。单一职责原则注重的是职责，针对的是程序中的实现和细节；而接口隔离原则注重的是对接口依赖的隔离，主要针对抽象。

依赖倒置原则

依赖倒置原则（Dependence Inversion Principle）：上层模块不应该依赖底层模块，它们都应该依赖于抽象。

即接口或抽象类不依赖于实现类，而实现类依赖接口或抽象类。

就是说如果类与类直接依赖细节，那么就会直接耦合，那么当修改时，就会同时修改依赖者代码，这样限制了可扩展性。依赖倒置就是为了解决耦合。让程序依赖于抽象。

依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。

开闭原则

开闭原则（Open Closed Principle）：一个软件实体，如类、模块和函数应该对扩展开放，对修改关闭。

在开发过程中，需求的变化如果要通过修改原有的代码来完成，那么就很可能将新的错误引入到旧的代码中。因此才有了开放封闭原则。就是说，需求改变时，我们应该尽量通过拓展的方式、即加入新代码来实现变化。

开闭原则是最基础的一个原则，前面介绍的5个原则都是开闭原则的具体形态，而开闭原则才是其精神领袖。

单例模式（创建型）

概述

单例模式（Singleton Pattern）属于创建型模式。为了确保一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

单例模式应该是所有设计模式中结构最简单的一个。

通过单例模式可以保证系统中一个类只有一个实例而且该实例易于外界访问，从而方便对实例个数的控制并节约系统资源。

优点

1、由于单例模式要求在全局内只有一个实例，因而可以节省比较多的内存空间；
2、全局只有一个接入点，可以更好地进行数据同步控制，避免多重占用；3、单例可长驻内存，减少系统开销。

缺点

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

应用场景

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

实现

使用装饰器

def singleton(cls):
    instances = {}
    def wrapper(*args, **kwargs):
        if cls not in instances:
            instances[cls] = cls(*args, **kwargs)
        return instances[cls]
    return wrapper


@singleton
class Foo(object):
    pass


if __name__ == "__main__":
    foo1 = Foo()
    foo2 = Foo()
    print(foo1 is foo2)

使用基类

class Singleton(object):

    _instance = None

    def __new__(cls, *args, **kwargs):
        if not hasattr(cls, '_instance'):
            cls._instance = super(Singleton, cls).__new__(cls, *args, **kwargs)
        return cls._instance


# 继承Singleton
class Foo(Singleton):
    pass


if __name__ == "__main__":
    foo1 = Foo()
    foo2 = Foo()
    print(foo1 is foo2)

使用元类

class Singleton(type):
    # 元类必须继承type
    def __call__(cls, *args, **kwargs):
        if not hasattr(cls, '_instance'):
            cls._instance = super(Singleton, cls).__call__(*args, **kwargs)
        return cls._instance


class Foo(metaclass=Singleton):
    pass


if __name__ == "__main__":
    foo1 = Foo()
    foo2 = Foo()
    print(foo1 is foo2)

工厂模式（创建型）

参考：https://www.cnblogs.com/Zzbj/p/15778464.html

概述

工厂模式（Factory Pattern）属于创建型模式，它提供了一种创建对象的最佳方式。

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

**意图：**定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。

**主要解决：**主要解决接口选择的问题。

**何时使用：**我们明确地计划不同条件下创建不同实例时。

简单工厂

统一使用一个类作为对外接口，根据参数的不同，去选择实例化不同的类。

"""
两个产品(两种类型的书)
"""


class TechnicalBooks(object):
    """技术书籍"""

    def publish(self):
        return "Python-Book"


class LiteraryBooks(object):
    """文学书籍"""

    def publish(self):
        return "Black Hole Book"


# 现在我们有两种类型的书，分别是TechnicalBooks和LiteraryBooks的书
# 按照我们平常的方法来实例化的话，此时创建对象时是会对客户端暴露真正创建的类
it_books = TechnicalBooks()
ly_books = LiteraryBooks()


# 这时我们就可以构造一个"简单工厂"把所有实例化的过程封装在里面，把真正实例的类隐藏起来
class SimpleFactory(object):
    """简单工厂"""

    @staticmethod
    def publish_book(name):
        if name == 'technical':
            return TechnicalBooks()
        elif name == 'literary':
            return LiteraryBooks()


it_books2 = SimpleFactory.publish_book('technical')
ly_books2 = SimpleFactory.publish_book('literary')

简单工厂的好处在于，把不同类的实例化统一到一个"工厂"，即不对外暴露真正的创建类，也提供了一个对外的统一接口。

但是简单工厂也有一个缺点，那就是违背了solid的 “开闭原则”，假如我们还需要增加一种书籍，那就必须要对简单工厂SimpleFactory进行源码的修改。

简单工厂使用场景：

  • 已经确定有多少具体的类，不会再增加的情况下使用。

例如：某个系统，已经明确就只会有MySQL、Redis、MongoDB三个数据库的情况下，可以直接使用简单工厂模式。

工厂方法

上面的简单工厂我们已经知道了，如果新增一些类型的时候会违背软件设计中的开闭原则，但是我们希望在扩展新的类时，不要修改原有的代码。这个时候我们可以在简单工厂的基础上把SimpleFactory抽象成不同的工厂，每个工厂对应生成自己的产品，这就是工厂方法。

"""
两个产品(两种类型的书)
"""
import abc


# 真正进行实例化的类
class TechnicalBooks(object):
    """技术书籍"""

    def publish(self):
        return "Python-Book"


class LiteraryBooks(object):
    """文学书籍"""

    def publish(self):
        return "Black Hole Book"


# 抽象工厂：先定义抽象类，然后每种类型的书籍都有自己对于的工厂
class AbstractFactory(metaclass=abc.ABCMeta):
    """抽象工厂"""

    @abc.abstractmethod
    def publish_book(self):
        pass


class TechnicalFactory(AbstractFactory):
    """技术书籍工厂"""

    def publish_book(self):
        return TechnicalBooks()


class LiteraryFactory(AbstractFactory):
    """文学书籍工厂"""

    def publish_book(self):
        return LiteraryBooks()


it_books2 = TechnicalFactory().publish_book()
ly_books2 = LiteraryFactory().publish_book()

这样每个工厂就只负责生产自己的产品，避免了在新增产品时需要修改工厂的代码，遵循了"开闭原则"，如果需要新增产品时，只需要增加相应的工厂即可。

比如要新增一种小说类型的书籍，只需新增一个NovelBooks类和NovelFactory类。

工厂方法的使用场景：

  • 当系统中拥有的子类很多，并且以后可能还需要不断拓展增加不同的子类时。
  • 当设计系统时，还不能明确具体有哪些类时。

在工厂方法中，使用者不需要知道具体的产品类名，只需要知道其对应的工厂即可。

抽象工厂

工厂方法解决了"开闭原则"的问题，但是我们出版书籍之前肯定还会有其他的步骤，比如印刷。
如果每一个步骤我们就要写一个对应的工厂类，那我们就会需要创建很多很多类了。
因此为了解决这个问题，我们就要需要抽象工厂类，让一个工厂可以生产同一类的多个产品或多个动作(步骤)，这就是抽象工厂。

"""
两个产品(两种类型的书)
"""
import abc


# 印刷书籍
class PrintingTechnicalBooks(object):
    """印刷技术书籍"""

    def printing(self):
        return "Print-Python-Book"


class PrintingLiteraryBooks(object):
    """印刷文学书籍"""

    def printing(self):
        return "Print Black Hole Book"


# 出版书籍
class TechnicalBooks(object):
    """出版技术书籍"""

    def publish(self):
        return "Python-Book"


class LiteraryBooks(object):
    """出版文学书籍"""

    def publish(self):
        return "Black Hole Book"


# 抽象工厂：先定义抽象类，然后每种类型的书籍都有自己对于的工厂
class AbstractFactory(metaclass=abc.ABCMeta):
    """抽象工厂"""

    @abc.abstractmethod
    def print_book(self):
        pass

    @abc.abstractmethod
    def publish_book(self):
        pass


class TechnicalFactory(AbstractFactory):
    """技术书籍工厂"""

    def print_book(self):
        return PrintingTechnicalBooks()

    def publish_book(self):
        return TechnicalBooks()


class LiteraryFactory(AbstractFactory):
    """文学书籍工厂"""

    def print_book(self):
        return PrintingLiteraryBooks()

    def publish_book(self):
        return LiteraryBooks()


# 实例化工厂对象
it = TechnicalFactory()
ly = LiteraryFactory()

# 印刷书籍
it_print = it.print_book()
ly_print = ly.print_book()
# 出版书籍
it_publish = it.publish_book()
ly_publish = ly.publish_book()

抽象工厂模式与工厂方法模式的区别：抽象工厂中的一个工厂对象可以负责多个不同产品对象的创建 。

抽象工厂的使用场景：

  • 当多个产品(步骤)集合在一起，组成产品族时。
  • 对于一个产品族，如果只想显示接口而不是实现时。

建造者模式（创建型）

参考：https://blog.csdn.net/songpeiying/article/details/131902497

概述

如果我们想建造一个由多个部分构成的对象，而且它的构成需要一步接着一步完成，只有当各个部分都创建好，这个对象才算是完整的。这就是建造者模式(Builder Pattern)。

建造者模式是一种创建型设计模式，它可以将复杂对象的构造与表现分离，这样同一个构造过程可用于创建多个不同表现形式。该模式通过一步一步创建复杂对象，将对象的构造过程与表示过程解耦。

例如快餐店使用的就是建造者模式。即使存在多种汉堡和不同包装，但是准备一个汉堡及打包的流程是相同的。经典汉堡和奶酪汉堡之间的区别在于表现，而不是建造过程。指挥者是出纳员，将需要准备什么产品传达给工作人员，建造者是工作人员的个体，关注具体的顺序。

优点

  • 将对象的构造过程与其表现形式解耦，可以灵活地组合不同的构造过程来得到不同的表现形式。
  • 使得代码结构更加清晰，易于维护和扩展。
  • 可以有效地控制对象的创建过程，生成符合设计要求的对象。

缺点

  • 建造者模式需要编写较多的代码，且在构造对象时需要一定的时间和精力。
  • 如果需要创建的对象较少或者结构较简单，则建造者模式可能会增加代码的复杂性。

应用场景

一个对象经过多个步骤来创建，并且要求构建过程可以产生不同的表现。

例如，在 Web 开发中，我们可以使用建造者模式来构建复杂的 HTML 页面、邮件消息等。在游戏开发中，我们可以使用建造者模式来生成游戏场景、角色等。在数据库开发中，我们可以使用建造者模式来构建 SQL 查询语句等。

实现

通常来说，建造者模式包括以下几个组成部分：

  • 产品类（Product）：表示被构造的复杂对象。
  • 抽象建造者类（Builder）：声明抽象方法来构建不同部分的复杂对象。
  • 具体建造者类（Concrete Builder）：实现抽象建造者类中的方法来构建对象的各个部分，并返回构建好的对象。
  • 指挥者类（Director）：负责调用具体建造者类中的方法来构建复杂对象。

具体的工作流程如下：

  1. 创建一个产品类，该类表示待构建的复杂对象，可以包含多个部分。
  2. 创建一个抽象的建造者类，该类声明了构建不同部分的抽象方法。
  3. 创建具体的建造者类，该类实现抽象建造者类中的方法，构建对象的各个部分，并返回构建好的对象。
  4. 创建一个指挥者类，该类负责调用具体建造者类中的方法来构建复杂对象。
  5. 在应用程序中，创建具体建造者类的实例，并将其传递给指挥者类。指挥者类使用具体建造者类中的方法来构建复杂对象。
  6. 最后，应用程序可以使用构建好的复杂对象。

假设我们需要构建一个计算机，计算机包含CPU、内存、硬盘、显卡等部件。我们可以使用Python建造者模式来构建这个复杂对象。具体实现步骤如下：

  1. 首先创建一个产品类——计算机类，它包含CPU、内存、硬盘、显卡等部件，并提供各个部件的设置和获取方法。
  2. 然后创建一个抽象建造者类——计算机建造者类，它声明了构建不同部分的抽象方法：
  3. 接着创建具体的建造者类——台式机建造者类和笔记本建造者类，它们实现了抽象建造者类中的方法，构建对象的各个部分，并返回构建好的对象：
  4. 由于计算机建造的过程比较复杂，我们需要创建一个指挥者类——计算机装配员类，它负责调用具体建造者类中的方法来构建复杂对象：
  5. 最后，我们可以使用以上代码来创建不同的计算机

代码如下：

 
# 创建产品类
class Computer():
    def __init__(self):
        self.cpu = None
        self.memory = None
        self.hark_disk = None
        self.graphics_card = None
 
    def set_cpu(self, cpu):
        self.cpu = cpu
    def set_memory(self, memory):
        self.memory = memory
    def set_hard_disk(self, hard_disk):
        self.hark_disk = hard_disk
    def set_graphics_card(self, graphics_card):
        self.graphics_card = graphics_card
    def get_specs(self):
        specs = f'CPU:{self.cpu}\nMemory:{self.memory}\nHard Disk:{self.hark_disk}\nGraphics Card:{self.graphics_card}'
        return specs
 
# 创建抽象的建造者类
class ComputerBuilder():
    def build_cpu(self): # 声明构建不同部分的抽象方法
        pass
    def build_memory(self):
        pass
    def build_hard_disk(self):
        pass
    def build_graphics_card(self):
        pass
    def get_computer(self):
        pass
 
# 创建具体的建造者类
class DesktopBuilder(ComputerBuilder): # 继承抽象的建造者类
    def __init__(self):
        self.computer = Computer() # 初始化产品类
    def build_cpu(self): # 实现抽象建造者方法
        self.computer.set_cpu("Intel Core 7") # 设置产品类方法值
    def build_memory(self):
        self.computer.set_memory("16GB DDR4")
    def build_hard_disk(self):
        self.computer.set_hard_disk("1TB HDD")
    def build_graphics_card(self):
        self.computer.set_graphics_card("NVIDIA GTX 1050")
    def get_computer(self):
        return self.computer
 
class LaptopBuilder(ComputerBuilder):
    def __init__(self):
        self.computer = Computer()
    def build_cpu(self):
        self.computer.set_cpu("Intel Core i5")
    def build_memory(self):
        self.computer.set_memory("8GB DDR4")
    def build_hard_disk(self):
        self.computer.set_hard_disk("256GB SSD")
    def build_graphics_card(self):
        self.computer.set_graphics_card("Intergrated")
    def get_computer(self):
        return self.computer
# 创建指挥者
class ComputerAssembler:
    def __init__(self,builder):
        self.builder = builder
    def assemble(self):
        self.builder.build_cpu() # 调用具体建造者类方法
        self.builder.build_memory()
        self.builder.build_hard_disk()
        self.builder.build_graphics_card()
        return self.builder.get_computer()
# 创建台式计算机
desktop_builder = DesktopBuilder()
desktop_assembler = ComputerAssembler(desktop_builder)
desktop = desktop_assembler.assemble()
print(desktop.get_specs())
 
# 创建笔记本计算机
laptop_builder = LaptopBuilder()
laptop_assembler = ComputerAssembler(laptop_builder)
laptop = laptop_assembler.assemble()
print(laptop.get_specs())

策略模式（行为型）

参考：https://blog.csdn.net/songpeiying/article/details/131939340

概述

策略模式（Strategy）是一种行为型策略模式。定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化，从而达到代码的可扩展性、灵活性和可维护性。

优点

  1. 代码可扩展性和灵活性好，能够适应不同的需求。
  2. 降低模块之间的耦合度，提高代码的可维护性和可读性。
  3. 具有良好的可扩展性，可以动态地增加、删除或替换算法。

缺点

  1. 会增加一定的复杂度，需要额外的类定义。
  2. 可能会导致系统中出现较多的类，增加系统的复杂度
  3. 需要客户端了解不同策略的差异，才能选择合适的策略。

应用场景

1.需要在运行时根据不同情况选择不同算法的场景。

2.需要封装业务逻辑的场景。

3.需要对同一种算法进行多次修改的场景。

实现

策略模式实现通常需要以下三个角色：

  1. 抽象出一个策略接口，定义策略的方法。
  2. 将不同的算法分别封装为具体的策略类，并实现策略接口的方法。
  3. 创建一个策略上下文类，负责调用不同的策略，根据不同的需求选择合适的策略。

以电商中的出校策略为例，客户可以根据自己需要选择不同的促销策略，比如有满减策略和折扣策略。

代码如下：

# 定义促销策略接口
class PromotionStrategy():
    # 定义促销活动方法
    def do_promotion(self, price):
        pass


# 定义具体促销策略
class ReductionPromotion(PromotionStrategy):  # 满减
    def do_promotion(self, price):
        if price >= 200:
            return price - 50
        return price


class DiscountPromotion(PromotionStrategy):  # 折扣
    def do_promotion(self, price):
        return price * 0.8


# 定义上下文类，负责调用不同的促销策略
class PromotionContext():
    def __init__(self, promotion_strategy: PromotionStrategy):
        self._promotion_strategy = promotion_strategy

    def execute_promotion_strategy(self, price):
        return self._promotion_strategy.do_promotion(price)


# 使用满减策略计算价格
promotion_context = PromotionContext(ReductionPromotion())
print(promotion_context.execute_promotion_strategy(200))
# 使用折扣策略计算价格
promotion_context = PromotionContext(DiscountPromotion())
print(promotion_context.execute_promotion_strategy(200))

观察者模式（行为型）

参考：https://blog.csdn.net/songpeiying/article/details/131945036

概述

观察者模式（Observer Pattern）又叫做发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式。

观察者模式定义了对象间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新。

例如在MVC模式中有这样一个非常常见的例子，假设在两个视图(例如，一个饼图和一个电子表格)中使用同一个模型的数据无论何时更改了模型，都需要更新两个视图。这就是观察者设计模式要处理的问题。

观察者模式描述单个对象（发布者，又称为主持者或可观察者）与一个或多个对象（订阅者又称为观察者）之间的发布-订阅关系。在MVC例子中，发布者是模型，订阅者是视图。然而.MVC并非是仅有的发布-订阅例子。信息聚合订阅(比如，RSS或Atom)是另一种例子。许多读者通常会使用一个信息聚合阅读器订阅信息流，每当增加一条新信息时，他们就能自动地获取到更新。

观察者模式背后的思想等同于MVC和关注点分离原则背后的思想，即降低发布者与订阅者之间的耦合度，从而易于在运行时添加/删除订阅者。此外，发布者不关心它的订阅者是谁。它只是将通知发送给所有订阅者。

优点：

  • 提供灵活性，减少类间的耦合度。
  • 可以实现动态的发布-订阅机制，并且观察者可在运行时动态地加入或离开主题。
  • 实现开放-封闭原则，使得主题和观察者可以独立地扩展和修改。

缺点：

  • 观察者过多会导致通知效率等性能问题。
  • 如果观察者与主题相互依赖，修改其中任意一方的代码都需要修改对方的代码，不利于系统的扩展和维护。

应用场景：

  • 当一个对象的改变需要同时改变其他对象时，比如消息订阅模型。
  • 当一个抽象模型有两个方面，其中一个方面需要依赖另外一个方面时。

实现

工作原理：

  • 观察者将自己注册到主题中。
  • 主题维护一个观察者列表。
  • 当主题状态发生改变时，通知所有观察者。
  • 观察者执行相应的操作。

下面我们以一个简单的消息订阅系统为例，详细说明 Python观察者模式实现消息订阅功能。

首先，我们需要定义两个类：主题类和观察者类。主题类包含一个观察者列表和通知观察者的方法，观察者类包含需要执行的方法。，NewsSubject类为新闻主题类，包含observers字典和register_observer、remove_observer、notify_observers、set_news等方法。其中，observers字典的键为订阅主题，值为观察者列表。NewsObserver类为观察者类，包含name属性和update方法。

接下来，我们可以创建主题对象和观察者对象，并将观察者对象注册到主题对象中。创建了一个主题对象subject和三个观察者对象observer_1、observer_2和observer_3，并将观察者对象注册到主题对象中，每个观察者订阅不同的新闻主题。

# *********************************观察者模式实现消息订阅功能
 
# 新闻主题类
class NewsSubject():
    def __init__(self):
        self.observers = {} # 字典
        self.news = None
 
    def register_observer(self, observer, topic):
        if topic not in self.observers:
            self.observers[topic] = []
        self.observers[topic].append(observer)
 
    def remove_observer(self, observer, topic):
        if topic in self.observers:
            self.observers[topic].remove(observer)
 
    def notify_observers(self,topic):
        if topic in self.observers: # if语句，存在观察者订阅的主题新闻，通知观察者
            for observer in self.observers[topic]:
                observer.update(self.news)  # 通知观察者新闻
 
    def set_news(self, news, topic):
        self.news = news
        self.notify_observers(topic)
 
 
 
class NewsObserver():
    def __init__(self, name):
        self.name = name
 
    def update(self, news):
        print(f"{self.name}收到新闻：{news}")
 
subject = NewsSubject()
 
observer_1 = NewsObserver("name1")
observer_2 = NewsObserver("name2")
observer_3 = NewsObserver("name3")
 
subject.register_observer(observer_1, "国内新闻")
subject.register_observer(observer_2, "国外新闻")
subject.register_observer(observer_3, "娱乐新闻")
 
subject.set_news("中国的新闻，中国......", "国内新闻")
subject.set_news("外国的新闻，美国......", "国外新闻")
subject.set_news("明星...","娱乐新闻")
subject.set_news("歌星...","娱乐新闻")

运行结果：

name1收到新闻：中国的新闻，中国......
name2收到新闻：外国的新闻，美国......
name3收到新闻：明星...
name3收到新闻：歌星...

在上述代码中，我们发布了三条新闻消息，并使用set_news方法通知订阅相应主题的观察者。观察者会收到通知并执行相应的操作，例如打印收到通知的信息。

这就是 Python观察者模式实现消息订阅功能的方法。当主题状态发生变化时，通知所有订阅该主题的观察者，执行相应的操作，实现了消息订阅功能。

代理模式（结构型）

参考：https://blog.csdn.net/songpeiying/article/details/131932669

概述

在某些应用中，我们想要早访问某些对象之前执行一些重要操作。例如，访问敏感信息之前，做一些权限认证，或者把一个创建成本较高的对象延迟到用户使用时才真正创建。

这类操作通常使用代理模式实现。

代理模式（Proxy Pattern）是一种结构型设计模式。在代理模式中，代理对象充当了另一个对象的占位符，以控制对该对象的访问。

代理对象和被代理对象实现了相同的接口，因此它们可以互相替代。客户端和代理对象之间的交互是无缝的，因为它们的接口是一样的。

代理模式的主要功能是为其他对象提供一个代理，以控制对对象的访问。代理对象可以在调用被代理对象之前或之后执行一些操作，例如身份验证，缓存等。

优点：

  1. 保护了真实对象的访问，可以对访问进行限制和控制；
  2. 可以提高访问效率，通过代理对象可以缓存数据或者调用其他服务等；
  3. 可以提高系统的灵活性，因为代理对象可以在不影响真实对象的情况下扩展其功能。

缺点：

  1. 可能引入额外的复杂性，因为需要创建代理对象。
  2. 此外，如果代理对象没有正确实现与真实对象相同的接口，可能会导致客户端代码无法正常工作。

应用场景：

  1. 身份验证：在访问某些敏感数据或操作时，可以使用代理对象执行身份验证，以确保用户有权访问该数据或执行该操作。
  2. 缓存：使用代理对象来缓存数据，以便在下一次访问时可以更快地访问数据。
  3. 远程服务：代理对象可以用作远程服务的本地代表，在使用远程服务时提供更好的用户体验，同时也可以提高访问效率。

实现

代理模式可以通过组合或继承实现。通常，代理对象会继承与真实对象相同的接口，并在继承的方法中调用真实对象的方法。

实现缓存

假设我们正在开发一个网络应用程序，该应用程序可以向外提供图片资源。由于图片资源较大，我们希望通过代理模式来缓存这些数据，以提高程序的性能和响应速度。

 
from abc import ABC, abstractmethod
 
# 定义抽象基类
class Image():
    @abstractmethod
    def display(self):
        pass
 
# 定义具体子类，继承Image，重新display方法
class RealImage(Image):
    def __init__(self, filename): # 构造函数，接收一个参数filename
        self.filename = filename  # 文件名保存在filename实例变量中
        self.load_from_disk()     # 调用load_from_disk()方法，从磁盘中加载图片数据
    '''
    从磁盘中加载图片数据
    子类RealImage独有的方法
    由于这个过程比较耗时，因此我们需要在初始化时进行加载，避免在图片显示时等待。
    '''
    def load_from_disk(self): #
        print("loading " + self.filename)
    # 显示图片
    def display(self):
        print("Displaying " + self.filename)
 
# 定义代理类,继承Image,重写display方法
class ImageProxy(Image):
    def __init__(self, filename):
        self.filename = filename
        # 定义真实图片
        self.real_image = None
    def display(self):
        if self.real_image is None:# 如果没有加载真实图片
            # 调用具体子类RealImage， 创建真实图片对象， 缓存真实对象，避免重复加载图片资源
            self.real_image = RealImage(self.filename)
        # 显示真实图片
        self.real_image.display()
 
image = ImageProxy("test.jpg")
print("第一次调用display方法：图片没有加载真实图片，调用子类RealImage， 创建真实图片对象")
image.display()
print("第二次调用display方法: 直接从缓存中获取图片")
image.display()

运行结果：

第一次调用display方法：图片没有加载真实图片，调用子类RealImage， 创建真实图片对象
loading test.jpg
Displaying test.jpg
第二次调用display方法: 直接从缓存中获取图片
Displaying test.jpg

在上面的示例中，我们定义了一个抽象基类Image，其中包含一个display()抽象方法。接着，我们定义了一个具体子类RealImage，它代表了真实的图片对象，负责从磁盘中加载图片数据，并提供display()方法用于显示图片。

我们还定义了一个代理类ImageProxy，它也实现了Image接口。当客户端调用display()方法时，代理类会检查是否已经加载了真实的图片对象。如果没有，代理会先创建一个真实的图片对象，然后再调用它的display()方法。这样，代理对象就可以缓存真实对象，避免了重复加载图片资源，从而提高程序性能。

使用代理模式时，客户端代码只需要与代理对象交互，并不需要知道真实对象的存在。当代理对象需要访问真实对象时，它会自动创建并调用真实对象，从而实现对真实对象的间接访问。

实现远程服务代理

Python 代理模式实现远程服务功能：

from abc import ABC, abstractmethod
 
# 定义抽象类：远程服务接口
class RemoteService():
    @abstractmethod
    def request(self, param: str) -> str: # 抽象方法：接受字符串类型参数，返回字符串类型结果
        pass
 
# 实现远程服务
class RemoteServiceIml(RemoteService):
    def request(self, param: str) -> str:
        return f"Remote service received {param}"
 
# 实现代理类
class RemoteServiceProxy(RemoteService):
    def __init__(self, remote_service: RemoteService):
        self._remote_service = remote_service
 
    def request(self, param: str) -> str:
        print("Remote service aouthentication...")# 调用远程服务器前，本地操作...，例如：身份认证、参数校验
        if not param:
            raise ValueError("Missing parameter")
        # 调用远程服务，返回结果
        return self._remote_service.request(param)
 
remote_service_impl = RemoteServiceIml()
proxy = RemoteServiceProxy(remote_service_impl)
 
res = proxy.request("test")
print(res)

运行结果：

Remote service aouthentication...
Remote service received test

在上述代码中，我们首先定义了一个远程服务接口RemoteService，其中有一个request方法，用于处理远程服务请求，返回一个字符串类型的结果。同时，我们还实现了RemoteServiceImpl类，该类用于实现具体的远程服务逻辑。在具体的request方法中，简单地将接收到的参数拼接成一条消息，并返回。

接下来，我们使用代理模式实现了RemoteServiceProxy类，该类也实现了RemoteService接口，并接收一个RemoteService实例作为构造函数参数。当我们调用request方法时，代理类先进行身份认证、参数校验等本地操作，然后再调用远程服务，最后将结果返回。

装饰器模式（结构型）

概述

装饰器模式定义如下：动态地给一个对象添加一些额外的职责。在增加功能方面，装饰器模式比生成子类更为灵活。

装饰器模式和上一节说到的代理模式非常相似，可以认为，装饰器模式就是代理模式的一个特殊应用，两者的共同点是都具有相同的接口，不同点是侧重对主题类的过程的控制，而装饰模式则侧重对类功能的加强或减弱。上一次说到，JAVA中的动态代理模式，是实现AOP的重要手段。而在Python中，AOP通过装饰器模式实现更为简洁和方便。先来解释一下什么是AOP。AOP即Aspect Oriented Programming，中文翻译为面向切面的编程，它的含义可以解释为：如果几个或更多个逻辑过程中（这类逻辑过程可能位于不同的对象，不同的接口当中），有重复的操作行为，就可以将这些行为提取出来（即形成切面），进行统一管理和维护。举例子说，系统中需要在各个地方打印日志，就可以将打印日志这一操作提取出来，作为切面进行统一维护。从编程思想的关系来看，可以认为AOP和OOP（面向对象的编程）是并列关系，二者是可以替换的，也可以结合起来用。

在Python语言中，是天然支持装饰器的。

优点：

  1. 增强已有函数的功能，提高代码的复用性和可维护性；
  2. 不修改原函数的代码，避免了可能引入的新问题。

缺点：

  1. 由于装饰器本质上是一个函数，因此会产生额外的函数调用开销；
  2. 如果装饰器过多，会导致代码的可读性降低。

应用场景：

  1. 缓存：可以为一些需要大量计算的函数添加缓存功能，减少函数的计算时间；
  2. 日志：可以为一些需要记录日志的函数添加日志功能；
  3. 计时：可以为一些需要计时的函数添加计时功能。

实现

可参考文章：https://blog.csdn.net/qq_43745578/article/details/128710602

适配器模式（结构型）

概述

适配器模式 (Adapter pattem)是一种结构型设计模式，帮助我们实现两个不兼容接口之间的兼容。首先，解释一下不兼容接口的真正含义。如果我们希望把一个老组件用于一个新系统中，或者把一个新组件用于一个老系统中，不对代码进行任何修改两者就能够通信的情况很少见。但又并非总是能修改代码，或因为我们无法访问这些代码( 例如，组件以外部库的方式提供 )，或因为修改代码本身就不切实际。在这些情况下，我们可以编写一个额外的代码层，该代码层包含让两个接口之间能够通信需要进行的所有修改。这个代码层就叫适配器。

例如，一部智能手机或者一台平板电脑，在想把它(比如，iPhone手机的闪电接口)连接到你的电脑时就需要使用一个USB适配器。如果你从大多数欧洲国家到英国旅行,在为你的笔记本电脑充电时需要使用一个插头适配器。如果你从欧洲到美国旅行，同样如此；反之亦然。适配器无处不在!

适配器模式和装饰模式有一定的相似性，都起包装的作用，但二者本质上又是不同的，装饰模式的结果，是给一个对象增加了一些额外的职责，而适配器模式，则是将另一个对象进行了“伪装”。

优点：

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

缺点：

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

应用场景：

  1. 系统需要与现有的代码或第三方库进行交互，但它们的接口与系统的要求不符。

  2. 系统需要将同一接口的多个实现进行统一，提高系统的可维护性和可扩展性。

工作原理

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

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

实现

假设您有一个现有的类 Logger，它提供了一种将消息记录到文件的方法。 此类需要将文件指定为文件路径字符串：

class Logger:
    def __init__(self, file_path: str):
        self.file_path = file_path

    def log(self, message: str):
        with open(self.file_path, 'a') as file:
            file.write(message + '\n')

现在假设您有一个客户端想要使用 Logger 类，但它希望传递一个文件对象而不是文件路径字符串。 在这种情况下，您可以创建一个适配器类，它接受一个文件对象并使用它来创建一个 Logger 实例：

class FileLoggerAdapter:
    def __init__(self, file: File):
        self.logger = Logger(file.name)

    def log(self, message: str):
        self.logger.log(message)

此适配器类允许客户端代码使用 FileLoggerAdapter 类，就好像它具有与 Logger 类相同的接口一样，但它在幕后将文件对象转换为文件路径字符串。 客户端可以像这样使用适配器类：

# Open a file for writing
file = open('log.txt', 'w')

# Create a FileLoggerAdapter instance
logger = FileLoggerAdapter(file)

# Log a message using the adapter
logger.log('This is a log message')

这个例子展示了如何使用适配器模式来允许两个具有不兼容接口的类无缝地协同工作。

Ethan-running
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
一文吃透何为微服务、网关、服务发现/注册
m0_69305074的博客
10-06 564
Web应用程序发展的早期，大部分web工程是将所有的功能模块(service side)打包到一起并放在一个web容器中运行，很多企业的Java应用程序打包为war包。比如构建一个在线商店系统：客户下订单、核对清单和信用卡额度，并将货物运输给客户。可能会构造出如下图所示的系统：单体架构这种将所有功能都部署在一个web容器中运行的系统就叫做单体架构（也叫：巨石型应用）。
一文掌握 Python 密集知识点
12-14
在本文中，我们将深入探讨《从小白到大神，一文掌握 Python 密集知识点》这份资料所涵盖的丰富Python编程知识。Python是一种高级、通用的编程语言，以其易读性、简洁的语法和强大的库支持而备受青睐。无论你是初学者...
一文吃透python面向对象基础+进阶
qq_43745578的博客
01-16 1223
python中的面向对象的基础概念语法，还有进阶的一些内容，包含魔法方法，面向对象三大特征，特别是python里的多继承带来的问题讲解。
一文吃透扫码登录原理
Tyson0314的博客
03-20 429
服务端接受请求后，会将 token 与二维码 ID 关联，然后会生成一个临时token，这个 token 会返回给移动端，临时 token 用作确认登录的凭证。这里的二维码ID一定是唯一的，后续流程会将二维码ID跟身份信息绑定，不唯一的话就会造成你登陆了其他用户的账号或者其他用户登陆你的账号。另外，二维码扫描确认之后，再往用户app或手机等发送登录提醒的通知，告知如果不是本人登录的，则建议用户立即修改密码。扫码登录的最后阶段，用户点击确认登录，移动端携带上一步骤中获取的临时 token访问服务端。
【总结】1147- 一文吃透 Webpack 核心原理
pingan8787
11-19 469
背景Webpack 特别难学！！！时至 5.0 版本之后，Webpack 功能集变得非常庞大，包括：模块打包、代码分割、按需加载、HMR、Tree-shaking、文件监听、sourcem...
【React】946- 一文吃透 React Hooks 原理
pingan8787
05-03 922
一 前言之前的两篇文章，分别介绍了react-hooks如何使用，以及自定义hooks设计模式及其实战，本篇文章主要从react-hooks起源，原理，源码角度，开始剖析react-hoo...
一文吃透Linux提权
<sdffdsfsdfdfs>sfsfsfsdfsdffds</sdfsDS>Fsd
01-01 1180
Python实战社群Java实战社群长按识别下方二维码，按需求添加扫码关注添加客服进Python社群▲扫码关注添加客服进Java社群▲文章作者：dnsill文章来源：https://s....
一文吃透自动化测试实践总结，建议收藏~
HUA1211的博客
07-04 748
1、把人为驱动的测试行为改成机器执行，通过设计的测试用例，由机器按照测试用例的执行步骤对其进行自动操作，输出结果，由测试人员进行比较。2、自动化测试往往通过一些测试工具或框架，编写自动化测试用例，来模拟手工测试。3、自动化测试能极大的节省人力、时间和硬件资源，提高测试效率。
[全文高能] 一文吃透 Webpack 核心原理
frontend_frank的博客
05-12 262
背景Webpack 特别难学！！！时至 5.0 版本之后，Webpack 功能集变得非常庞大，包括：模块打包、代码分割、按需加载、HMR、Tree-shaking、文件监听、sourcem...
一文吃透自动化测试【实践总结】，建议收藏~
xiaojieceo的博客
05-20 788
把人为驱动的测试行为改成机器执行，通过设计的测试用例，由机器按照测试用例的执行步骤对其进行自动操作，输出结果，由测试人员进行比较。
一文吃透电源中的纹波、噪声和谐波
01-13
纹波  纹波：是附着于直流电平之上的包含周期性与随机性成分的杂波信号。指在额定输出电压、电流的情况下，输出电压中的交流电压的峰值。狭义上的纹波电压，是指输出直流电压中含有的工频交流成分。...
一文总结学习Python的14张思维导图.pdf
11-16
一文总结学习Python的14张思维导图.pdf
一文详述 Python 中的 property 语法
09-16
Python中的`property`语法是一种强大的特性，用于封装和控制对象的属性访问。它允许开发者创建具有getter和setter方法的属性，使得在访问或修改属性值时可以进行额外的逻辑处理，而外部代码看起来仍然像直接操作属性...
【Java设计模式】你对单例模式了解多少，一文深入探究
01-20
目录单例模式懒汉式单例模式未初始化问题解决Double Check 双重检查方案一：不让第二步和第三步重排序-DoubleCheck方案二：基于类初始化-静态内部类饿汉式饿汉式与懒汉式最大区别序列化破坏单例模式原理枚举单例基于...
面试题 21：解释 Python 中的 help() 函数和 dir() 函数？
专注于全栈开发领域
07-10 493
在Python中，help()和dir()是两个非常有用的内置函数，它们可以帮助开发者更好地了解Python对象和模块。
Nginx七层（应用层）反向代理：UWSGI代理uwsgi_pass篇
最新发布
jclee95的个人博客
07-10 683
Nginx提供了多种应用层反向代理支持，包括proxy_pass、uwsgi_pass、fastcgi_pass和scgi_pass等。其中，proxy_pass指令可以接受一个URL参数，用于实现对HTTP/HTTPS协议的反向代理；uwsgi_pass用于代理到uWSGI应用服务器；fastcgi_pass用于代理到FastCGI服务器；而scgi_pass则用于代理到SCGI（Simple Common Gateway Interface）应用。这些指令使Nginx能够灵活地处理不同类型的后端服务和应
pandas，dataframe使用笔记
分享计算机视觉，C++，嵌入式等知识。
07-05 487
dataframe属于pandas。
Python28-7.3 降维算法之多维缩放MDS
Argulo的博客
07-05 664
多维尺度分析（Multidimensional Scaling, MDS）是一种用于降维的统计技术，其目标是将高维数据嵌入到低维空间中，同时尽量保持原始数据中点与点之间的距离关系。MDS 的目标是将高维数据中的点嵌入到低维（通常是二维或三维）空间中，使得在低维空间中点之间的距离尽量接近原始高维空间中点之间的距离。这通过最小化一个损失函数（通常是应力函数）来实现，应力函数衡量的是原始距离和降维后距离之间的不一致性。：对原始数据中的距离或相似度进行非度量变换，以保留原始数据中的顺序信息，而不是精确的距离值。
一文精通python
10-01
一文精通Python是指通过一篇文章来全面掌握Python的知识点。Python是一种代表简单主义思想的语言，阅读一个良好的Python程序就感觉像是在读英语一样，使你能够专注于解决问题而不是去搞明白语言本身。因此，通过一篇...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Ethan-running

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值