美文网首页
[Python-设计模式] 创建型模式- 工厂方法模式

[Python-设计模式] 创建型模式- 工厂方法模式

作者: 紫藤lvy | 来源:发表于2022-08-10 11:51 被阅读0次

    创建型模式

    创建型模式提供了创建对象的机制, 能够提升已有代码的灵活性和可复用性。

    工厂方法模式

    工厂方法模式是一种创建型设计模式, 其在父类中提供一个创建对象的方法, 允许子类决定实例化对象的类型。

    工厂方法模式结构

    产品 (Prod­uct) 将会对接口进行声明。 对于所有由创建者及其子类构建的对象, 这些接口都是通用的。

    具体产品 (Con­crete Prod­ucts) 是产品接口的不同实现。

    具体创建者 (Con­crete Cre­ators) 将会重写基础工厂方法, 使其返回不同类型的产品。

    注意, 并不一定每次调用工厂方法都会创建新的实例。 工厂方法也可以返回缓存、 对象池或其他来源的已有对象。

    创建者 (Cre­ator) 类声明返回产品对象的工厂方法。 该方法的返回对象类型必须与产品接口相匹配。

    你可以将工厂方法声明为抽象方法, 强制要求每个子类以不同方式实现该方法。 或者, 你也可以在基础工厂方法中返回默认产品类型。

    注意, 尽管它的名字是创建者, 但它最主要的职责并不是创建产品。 一般来说, 创建者类包含一些与产品相关的核心业务逻辑。 工厂方法将这些逻辑处理从具体产品类中分离出来。 打个比方, 大型软件开发公司拥有程序员培训部门。 但是, 这些公司的主要工作还是编写代码, 而非生产程序员。

    实现方式

    1,让所有产品都遵循同一接口。 该接口必须声明对所有产品都有意义的方法。
    2,在创建类中添加一个空的工厂方法。 该方法的返回类型必须遵循通用的产品接口。

    3,在创建者代码中找到对于产品构造函数的所有引用。 将它们依次替换为对于工厂方法的调用, 同时将创建产品的代码移入工厂方法。

    4,你可能需要在工厂方法中添加临时参数来控制返回的产品类型。

    5,工厂方法的代码看上去可能非常糟糕。 其中可能会有复杂的 switch分支运算符, 用于选择各种需要实例化的产品类。 但是不要担心, 我们很快就会修复这个问题。

    6,现在, 为工厂方法中的每种产品编写一个创建者子类, 然后在子类中重写工厂方法, 并将基本方法中的相关创建代码移动到工厂方法中。

    7,如果应用中的产品类型太多, 那么为每个产品创建子类并无太大必要, 这时你也可以在子类中复用基类中的控制参数。

    8,如果代码经过上述移动后, 基础工厂方法中已经没有任何代码, 你可以将其转变为抽象类。 如果基础工厂方法中还有其他语句, 你可以将其设置为该方法的默认行为。

    工厂方法模式优缺点

    √ 你可以避免创建者和具体产品之间的紧密耦合。

    √ 单一职责原则。 你可以将产品创建代码放在程序的单一位置, 从而使得代码更容易维护。
    √ 开闭原则。 无需更改现有客户端代码, 你就可以在程序中引入新的产品类型。

    × 应用工厂方法模式需要引入许多新的子类, 代码可能会因此变得更复杂。 最好的情况是将该模式引入创建者类的现有层次结构中。

    main.py: 概念示例

    
    from __future__ import annotations
    from abc import ABC, abstractmethod
    
    
    class Creator(ABC):
        """
        The Creator class declares the factory method that is supposed to return an
        object of a Product class. The Creator's subclasses usually provide the
        implementation of this method.
        """
    
        @abstractmethod
        def factory_method(self):
            """
            Note that the Creator may also provide some default implementation of
            the factory method.
            """
            pass
    
        def some_operation(self) -> str:
            """
            Also note that, despite its name, the Creator's primary responsibility
            is not creating products. Usually, it contains some core business logic
            that relies on Product objects, returned by the factory method.
            Subclasses can indirectly change that business logic by overriding the
            factory method and returning a different type of product from it.
            """
    
            # Call the factory method to create a Product object.
            product = self.factory_method()
    
            # Now, use the product.
            result = f"Creator: The same creator's code has just worked with {product.operation()}"
    
            return result
    
    
    """
    Concrete Creators override the factory method in order to change the resulting
    product's type.
    """
    
    
    class ConcreteCreator1(Creator):
        """
        Note that the signature of the method still uses the abstract product type,
        even though the concrete product is actually returned from the method. This
        way the Creator can stay independent of concrete product classes.
        """
    
        def factory_method(self) -> Product:
            return ConcreteProduct1()
    
    
    class ConcreteCreator2(Creator):
        def factory_method(self) -> Product:
            return ConcreteProduct2()
    
    
    class Product(ABC):
        """
        The Product interface declares the operations that all concrete products
        must implement.
        """
    
        @abstractmethod
        def operation(self) -> str:
            pass
    
    
    """
    Concrete Products provide various implementations of the Product interface.
    """
    
    
    class ConcreteProduct1(Product):
        def operation(self) -> str:
            return "{Result of the ConcreteProduct1}"
    
    
    class ConcreteProduct2(Product):
        def operation(self) -> str:
            return "{Result of the ConcreteProduct2}"
    
    
    def client_code(creator: Creator) -> None:
        """
        The client code works with an instance of a concrete creator, albeit through
        its base interface. As long as the client keeps working with the creator via
        the base interface, you can pass it any creator's subclass.
        """
    
        print(f"Client: I'm not aware of the creator's class, but it still works.\n"
              f"{creator.some_operation()}", end="")
    
    
    if __name__ == "__main__":
        print("App: Launched with the ConcreteCreator1.")
        client_code(ConcreteCreator1())
        print("\n")
    
        print("App: Launched with the ConcreteCreator2.")
        client_code(ConcreteCreator2())
    
    输出结果:
    App: Launched with the ConcreteCreator1.
    Client: I'm not aware of the creator's class, but it still works.
    Creator: The same creator's code has just worked with {Result of the ConcreteProduct1}
    
    App: Launched with the ConcreteCreator2.
    Client: I'm not aware of the creator's class, but it still works.
    Creator: The same creator's code has just worked with {Result of the ConcreteProduct2}
    
    

    相关文章

      网友评论

          本文标题:[Python-设计模式] 创建型模式- 工厂方法模式

          本文链接:https://www.haomeiwen.com/subject/putawrtx.html