Gang of Fourに依存性注入パターンが含まれていなかったのはなぜですか？

なぜ依存関係の注入パターンが4人のギャングに含まれていなかったのですか？GOFは広範囲に及ぶ自動テストに先行していたのですか？依存性注入は現在、コアパターンと見なされていますか？

Gang of Fourの本が出版されたとき、私はSoftware Development誌の編集者でしたが、Design Patternsが最初に発行された1994年には、ユニットテストは広く行われていなかったと確信できます。

1994年、C ++は最も一般的に使用されるオブジェクト指向言語であり、C ++をプログラミングするほとんどの人はCのバックグラウンドから来ていました。人々が単に持っていなかった「オブジェクトを考える」ことの1つは、プログラムへの数百または数千のエントリポイントのアイデアです。あなたはについて考えましたmain()。大規模なプロジェクトに取り組んでいる場合は、モジュールベースのプログラムを作成するための（通常はかなり複雑な）メイクファイルが必要になる場合があります。しかし、「単体テスト」ですか？メソッドごとにプロセスを開始し、必要なメモリコンテキストを構築し、実行し、破棄しますか？それは非常に急進的でした。

Javaは、複数エントリポイントプログラミングをより明確にしました。元のDot-Comブームの頃には、ユニットテストはよく知られた手法でしたが、実際にJUnit（2001年頃？）に火がつき、普遍的なプラクティスになりました。

が戦略およびインタフェースにプログラミングの一般的な概念は、GoFのの一部であったと90年代半ばには時代精神のアイデア注入はパーティーにかなり遅れて来ました（'03 -'05年頃？）。正直なところ、私の白髪はまだDIのその側面についてかなり疑わしいです（「芝生を下ろしてください、構成ファイルを見てください！」）。

彼らはそれを戦略と呼んだ。

彼らの戦略には、複雑に聞こえる名前のない依存性注入のすべての機能があるようです。

階層で実装を分離する場合、依存性注入がより適切であると思います。依存性注入について考えるもう1つの領域は、単体テストです。そして、あなたの以前の提案は正しいようです。ギャングが2012年にパターンを収集して分離した場合、間違いなく依存性注入が行われます。

戦略は議論の中で登場する可能性がありますが、戦略は依存性注入については話しません。しかし、単一のプロジェクトまたはdll（すべてのクラスとインターフェースが1つのプロジェクトに残る）で戦略パターンを使用すると、依存性注入を行っているように見えます。実際、私たちはそうではありません。

現在、戦略パターンで言及されているクラスとインターフェースが異なるプロジェクトまたは層で分離されている場合、WEは依存性注入技術を使用する必要があります。単一の構成ファイルを使用できます（ただし、ランタイムの変更はできません）。しかし、戦略パターンは、依存関係を注入する方法を示していません。

依存性注入によく似たパターンがある場合、それは抽象ファクトリメソッドパターンです。このパターンは、依存関係を注入するために戦略パターン内で使用できます。

答えの戦略は100％正しいです。私は賛成票を投じましたが、コメントすることができます。

「戦略により、アルゴリズムはそれを使用するクライアントとは独立して変化します。

設計パターンは、その使用に依存しません。依存性注入は、戦略パターンを使用して実装されます。ユースケースに基づいて各パターンに名前を付ける場合、多くのパターンの名前を変更する必要があります。

リポジトリパターンは新しいパターンではなく、テンプレートパターンです。

「この設計パターンのテンプレートメソッドでは、1つまたは複数のアルゴリズムステップをサブクラスでオーバーライドして、異なる動作を許可しながら、包括的なアルゴリズムが引き続き実行されるようにすることができます。」

多くの場合、パターンは、MVCパターンなどの複数のパターンを組み合わせて名前を付けたものです。

GOFには、使用されているPure Abstractクラスのインターフェースがなく、複数のクラスから継承するC ++の機能も利用していました。