Summer SALE
Factory Method

Factory Method を Python で

Factory Method 生成に関するデザインパターンの一つで 具象クラスを指定することなく プロダクト 訳注 本パターンでは 生成されるモノのことを一般にプロダクトと呼びます のオブジェクトを生成することを可能とします

Factory Method では オブジェクトの生成において 直接のコンストラクター呼び出し new 演算子 代わりに使用すべきメソッドを定義します サブクラスにおいてこのメソッドを上書きすることにより 生成されるオブジェクトのクラスを変更します

もし各種ファクトリー系のパターンやコンセプトの違いで迷った場合は ファクトリーの比較 をご覧ください



使用例 Factory Method パターンは Python コードでは広く使われます コードに高度の柔軟性を持たせたい時にとても役に立ちます

見つけ方 具象クラスで具象オブジェクトを作成し それを抽象型またはインターフェースのオブジェクトとして返すような生成メソッドの存在により Factory Method を識別できます


この例は Factory Method デザインパターンの構造を説明するためのものです 以下の質問に答えることを目的としています

  • どういうクラスからできているか
  • それぞれのクラスの役割は
  • パターンの要素同士はどう関係しているのか 概念的な例

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.

    def factory_method(self):
        Note that the Creator may also provide some default implementation of
        the factory method.

    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.

    def operation(self) -> str:

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.")

    print("App: Launched with the ConcreteCreator2.")

Output.txt: 実行結果

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}

他言語での Factory Method

Factory Method を C# で Factory Method を C++ で Factory Method を Go で Factory Method を Java で Factory Method を PHP で Factory Method を Ruby で Factory Method を Rust で Factory Method を Swift で Factory Method を TypeScript で