戦略パターンと依存性注入を使用して継承を完全に置き換えることはできますか？

例えば：

var duckBehaviors = new Duckbehavior();
duckBehaviors.quackBehavior = new Quack();
duckBehaviors.flyBehavior = new FlyWithWings();
Duck mallardDuck = new Duck(DuckTypes.MallardDuck, duckBehaviors)

Duckクラスにはすべての動作（抽象）が含まれているため、新しいクラスMallardDuck（拡張Duck）を作成する必要はないようです。

参照：ヘッドファーストデザインパターン、第1章。

もちろん、その構成と委任を呼び出します。戦略パターンと依存性注入は構造的に似ているように見えるかもしれませんが、それらの意図は異なります。

戦略パターンを使用すると、同じインターフェースで動作をランタイムで変更できます。私はマガモに飛ぶように言って、羽ばたくのを見ることができました。次に、それをジェットパイロットのアヒルと交換して、デルタ航空で飛ぶのを見てください。プログラムの実行中にそれを行うのは戦略パターンのことです。

依存性注入は、ハードコーディングの依存関係を回避して、クライアントが変更されたときにクライアントを変更することなく、独立して変更できるようにする手法です。クライアントは、彼らがどのように満たされるかを知らなくても、単に彼らのニーズを表明します。したがって、それらがどのように満たされるかは、他の場所（通常はメイン）で決定されます。この手法を利用するために2羽のカモは必要ありません。どのアヒルを知らないか気にせずにアヒルを使うものだけです。アヒルを構築したり探したりはしませんが、手にしたアヒルを何でも使って喜んでくれるもの。

具体的なアヒルのクラスがある場合は、フライの動作を実装することができます。状態変数に基づいて、fly-with-wingsからfly-with-Deltaに動作を切り替えることもできます。その変数は、ブール値、int、またはifでテストすることなく、あらゆる飛行スタイルを実行FlyBehaviorするflyメソッドを持つa である可能性があります。これで、アヒルのタイプを変更せずに飛行スタイルを変更できます。マガモはパイロットになることができます。これは構成と委任です。アヒルはFlyBehaviorで構成されており、飛行要求をそれに委任できます。この方法ですべてのアヒルの動作を一度に置き換えるか、各動作または何かの間の任意の組み合わせに対して何かを保持できます。

これにより、継承には1つを除いて同じ力がすべて与えられます。継承を使用すると、DuckサブタイプでオーバーライドしているDuckメソッドを表現できます。構成と委任では、最初からサブタイプに明示的に委任する必要があります。これははるかに柔軟ですが、より多くのキーボード入力を必要とし、Duckはそれが起こっていることを知る必要があります。

ただし、継承は最初から明示的に設計する必要があると多くの人が考えています。継承されていない場合は、継承を許可しないようにクラスをシール/最終としてマークする必要があります。あなたがその見方をすると、継承は本当に構成と委任に勝るものはありません。それは、どちらの方法でも、最初から拡張性を考慮して設計するか、後で物事を分解していく必要があるためです。

物事を壊すことは実際に人気のあるオプションです。問題がある場合があることに注意してください。次のリリースで更新するつもりのないコードのライブラリーまたはモジュールを独立してデプロイした場合、現在の状況について何も知らないクラスのバージョンを処理することに行き詰まる可能性があります。

後で物事を分解してもかまわないということは、設計のやり直しから解放されますが、アヒルを使用したときに実際に何が行われるかを知らなくても、アヒルを使用して何かを設計できるという点で非常に強力です。知らないことは強力なものです。これにより、しばらくの間アヒルについて考えるのをやめ、コードの残りの部分について考えることができます。

「できるか」と「すべきか」は異なる質問です。継承よりも構成を優先しても、継承を使用しないとは限りません。継承が最も理にかなっている場合がまだあります。私のお気に入りの例を紹介します。

public class LoginFailure : System.ApplicationException {}

継承を使用すると、より具体的でわかりやすい名前の例外を1行で作成できます。

作曲でそれをやってみてください、あなたは混乱を得るでしょう。また、継承の連鎖を再利用および促進するデータやメソッドがないため、継承のヨーヨー問題のリスクはありません。このすべてが良い名前です。良い名前の価値を過小評価しないでください。

ほとんどすべての方法論を他の方法論に置き換えても、機能するソフトウェアを作成できます。それでも、一部の問題は他の問題よりも特定の問題に適しています。

それは多くの事柄に依存しています。アプリケーションの先行技術、チームでの経験、期待される将来の発展、個人的な好み、そしていくつか例を挙げると、新人が頭を悩ませるのはどれほど難しいでしょう。

あなたがより経験を積み、他の人々の創造物により頻繁に苦しむにつれて、最後の熟考をより強調するようになるでしょう。

継承は依然として有効で強力なモデリングツールであり、必ずしも最も柔軟であるとは限りませんが、問題ドメインへの明確なマッピングに感謝している可能性がある新しい人々に強力なガイダンスを提供します。

継承はかつて考えられていたほど重要ではありません。それはまだ重要であり、それを削除することは悪い間違いです。

極端な例は、すべてがNSObjectのサブクラスであるObjective-Cです（コンパイラーは、実際にはベースクラスを持たないクラスを宣言することを許可しないため、コンパイラーに組み込まれていないものはすべて何かのサブクラスでなければなりませんコンパイラに組み込まれています）。NSObjectには、見逃してはいけない便利なものがたくさんあります。

もう1つの興味深い例は、UIKitのiOS開発用の基本的な「ビュー」クラスであるUIViewです。これは、一方ではサブクラスが埋める機能を宣言する抽象クラスに少し似ていますが、それ自体でも有用です。UIKitが提供するサブクラスがあり、そのまま使用されることがよくあります。ビューにサブビューをインストールする開発者による構成があります。また、多くの場合、開発者が定義したサブクラスがあり、それらはしばしばコンポジションを使用します。厳密な単一のルールやルールさえありません。要件に最も適したものを使用します。

[私は定評のある質問に対する生意気な答えを危険にさらします。]

戦略パターンと依存性注入を使用して継承を完全に置き換えることはできますか？

はい...ただし、戦略パターン自体は継承を使用します。戦略パターンは、インターフェースの継承で機能します。継承を構成+戦略で置き換えると、継承が別の場所に移動します。それにもかかわらず、階層を分離することができるので、そのような置換はしばしば行う価値があります。

いいえ。マガモのインスタンス化に別の種類のダックとは異なるパラメータが必要な場合、変更するのは悪夢になります。また、アヒルをインスタンス化できる必要がありますか？それはマガモまたはマンダリンのアヒル、あるいはあなたが持っている他の種類のアヒルです。

また、型の周りにいくつかのロジックが必要になる可能性があるため、型の階層の方が良いかもしれません。

コードの再利用が一部の機能で問題になる場合は、コンストラクターを介して関数を渡すことにより、コードを再構成できます。

繰り返しますが、それは本当にあなたのユースケースに依存します。アヒルとマガモだけの場合、クラス階層ははるかに単純なソリューションです。

しかし、これは戦略パターンを使用する例です：顧客クラスがあり、ハッピーアワー請求戦略または通常の請求戦略である可能性がある請求戦略（インターフェース）を渡したい場合、それを渡すことができますコンストラクタで。この方法では、2つの異なる顧客クラスを作成する必要がなく、階層も必要ありません。顧客クラスは1つだけです。