「ファクトリーメソッドはテンプレートメソッドの特殊化」です。どうやって？

2つの間の類似点と相違点：

テンプレートメソッド

• 継承に依存します。
• アルゴリズムのステップを定義し、それらを実装するタスクをサブクラスに任せます。

ファクトリーメソッド

• 継承に依存します。
• スーパークラスは、オブジェクトを作成するためのインターフェースを定義します。サブクラスは、インスタンス化する具象クラスを決定します。

2つ並べて：

「ファクトリーメソッドはテンプレートメソッドの特殊化」というフレーズの意味がわかりません（Head First Design Patternsブックにあります）。ではBeverage、私たちの方法持ってprepareいるfinalと一連の手順を定義します。にPizzaStoreあるメソッドがありabstract、サブクラスがそれを再定義します。後者は前者を特化したものですか？

ではBeverage、私たちは（「テンプレート」）法持つprepareようないくつかの抽象メソッドを呼び出しますboilWater、brewサブクラス内で実装されているなど。テンプレートメソッドを基本クラスに配置することは、基本的にパターンではなく、抽象メソッドがパブリックであると想定して、他の場所でも可能です。しかし、本質的には、オーバーライドする必要があり、「アルゴリズムテンプレート」のギャップを埋める抽象メソッドがあるということです。

ファクトリーメソッドは、抽象メソッドが上書きされるクラスにも関係します。コアポイントは、そのメソッドの呼び出し元が、作成されたオブジェクトの正確なタイプを知る必要がないことです。PizzaStoreでは、抽象メソッドcreatePizzaはどこかから呼び出されなければならないことに注意してください-メソッドと言いましょうcreateLotsOfPizza。

これにより、後者がテンプレート方式になり、「ピザを作成するアルゴリズム」の特定のステップは、埋められるギャップになります。現在、「ファクトリメソッドパターン」は「テンプレートメソッド」パターンの特殊なケースであると言って、それはおそらく言葉の不正確な使い方です。特に「ファクトリメソッド」は「テンプレートメソッド」ではありませんが、テンプレートメソッドから呼び出される場合があります。より正確に言うと、

「ファクトリメソッドパターンは通常、テンプレートメソッドパターンの特殊なケースと組み合わせて使用​​されます。」

その本の著者が表現したかったのはそれだと思います。

「ファクトリーメソッドはテンプレートメソッドの特殊化」であると私は思います。テンプレートメソッドのパターンはファクトリーメソッドのパターンのバリエーションに過ぎないと言う方がより正確だと思います。

さらに、テンプレートメソッドのパターンは、継承とメソッドのオーバーライドによって自然に発生するので、実際には（Gang of Fourの意味で）まったくパターンではないと主張します。上の図のテンプレートパターンの図では、子孫クラスが独自の動作で基本クラスのメソッドをオーバーライドしているだけであることがわかります。

全体として、ソフトウェアパターン（ギャングオブフォーバラエティの）は、プログラミング言語の欠陥の回避策に過ぎず、テンプレートパターンは、オブジェクト指向言語がすでにネイティブで利用できる機能を再表現するだけです。

この特徴付けでは、ヘッドファーストは単に間違っていると思います。

ウィキペディアでは、テンプレートメソッドを次のように定義しています。

ソフトウェアエンジニアリングでは、テンプレートメソッドパターンは動作のアルゴリズムのプログラムスケルトンを定義する動作設計パターンであり、サブクラスにいくつかのステップを延期します。

（それはGoFを参照しています。）

また、ファクトリーメソッドは次のように定義されます。

クラスベースのプログラミングでは、ファクトリメソッドパターンは、作成されるオブジェクトの正確なクラスを指定せずに、ファクトリメソッドを使用してオブジェクトの作成の問題に対処する作成パターンです。

C ++では継承が両方の重要な部分であることを除いて、2つの間に重複はありません。ただし、実装の継承（extendsJava）とインターフェースの実装（Java）を区別する言語でimplementsは、インターフェースの実装でファクトリメソッドは十分ですが、テンプレートメソッドでは十分でないため、この共通性さえ存在しません。また、C ++では、前者には純粋な実装継承（インターフェース継承なし、つまりプライベート継承またはCRTPなし）を使用できますが、後者には使用できません。

それとは別に？1つは行動パターン、もう1つは創造パターンです。1つは操作の概要を説明するもので、一部の重要な部分は省略して、特殊なサブクラスで埋めます。もう1つは非常に単純なコントラクトを指定し、実装全体を具体的なインスタンスに任せます。それらは完全に異なります。

私の意見では、引用された行は単に間違っています。これは本の明白なエラーであるか、または（可能性は低いですが）コンテキスト外であり、異なる解釈が必要です。