ファクトリメソッドは、スーパークラスでオブジェクトを作成するためのインターフェイスを提供する作成デザインパターンですが、サブクラスで作成されるオブジェクトのタイプを変更できます。

ファクトリメソッドを使用する場合

ロジスティック管理アプリケーションがあると想像してください。アプリケーションの最初のバージョンでは、トラックによる輸送を処理できるため、コードの大部分はトラッククラス内に存在します。

1年後、あなたのアプリは毎日かなり人気があり、海上輸送会社から海のロジスティクスをアプリに組み込むように多くの要求があります。それは素晴らしいニュースですよね？しかし、コードはどうですか？職業はなんですか？

トラッククラスをリファクタリングしてShipsをアプリに追加する必要があります。すべてのクラスを変更する必要があり、時間がかかります。

今回は、ファクトリメソッドを使用する場合、以前に作成したすべてのクラスを変更する必要がないという素晴らしいニュースがあります。

因数分解法では、この問題にプロトコルを使用することをお勧めします。しかし、どのように？

たとえば、TruckクラスとShipクラスの両方で、 deliverというメソッドを宣言するTransportプロトコルを実装する必要があります。クラスごとにこの方法の実装方法は異なります。トラックは陸路で貨物を配送し、船は海路で貨物を配送します。

コードで使用するオブジェクトの正確なタイプと依存関係が事前にわからない場合は、ファクトリメソッドを使用してください。

スウィフトコード

長所と短所

➕単一責任の原則。製品作成コードをプログラム内の1つの場所に移動して、コードのサポートを容易にすることができます。

➕開放/閉鎖原則。既存のクライアントコードを壊すことなく、新しいタイプの製品をプログラムに導入できます。

➕作成者と具体的な製品の間の緊密な結合を避けます。

➖パターンを実装するために多くの新しいサブクラスを導入する必要があるため、コードはより複雑になる可能性があります。最良のシナリオは、クリエータークラスの既存の階層にパターンを導入する場合です。

他のパターンとの関係

• 多くの開発者は、ファクトリメソッド（サブクラスを介してそれほど複雑ではなく、よりカスタマイズ可能）から始めて、抽象ファクトリ、プロトタイプ、またはビルダー（より柔軟ですが、より複雑）に進化します。
• 抽象ファクトリクラスは、多くの場合、ファクトリメソッドのセットに基づいていますが、Prototypeを使用してこれらのクラスのメソッドを作成することもできます。