Head First Design PatternsのDuckの例で示されているように、コンテキストの継承は戦略パターンとは無関係ですか？

でヘッドファーストデザインパターンでは教えて戦略パターンをダックの異なるサブクラスは、実行時に特定の動作を割り当てることができダックの例を使用して。私の理解では、戦略パターンの目的は実行時に単一のオブジェクトの動作を変更することですが、Duckの継承を使用してさまざまなタイプのDuckの動作を変更しています。

関連性？

Duckのコンテキスト継承は戦略パターンと無関係であるか、またはDuckのタイプを変更し、それらの動作も変更することは、戦略パターンを採用する正当な理由ですか？両方を変化させる必要がある状況は、戦略パターンを使用する正当な理由になりますか？なぜこれを戦略パターンの例として含めるのですか？

より簡単な例

Duckクラス（派生クラスなし）だけでこの例をさらに簡略化できますか？次に、1つのduckオブジェクトを実装するときに、独自のオブジェクトタイプに依存しない特定の状況に基づいて、異なる動作を割り当てることができます。例：FlyBehaviorは天気に基づいて変化し、QuackBehaviorは時刻またはアヒルの空腹度に基づいて変化します。これは本の問題とは異なる問題を解決することになると思いますが、私が探しているのは、頼りになる適切な戦略パターンの例です。

上記の私の例も戦略パターンを構成しますか？

編集：

私は、コンテキストを継承しない単なる戦略パターンであるHunter.javaとsolver.pyに厳密に準拠する2つの単純な戦略パターンの例を見つけることに成功しました。

はい、あなたは正しい軌道に乗っていると思います。戦略パターンを使用するクラスは、サブクラスである必要はありません。戦略パターンは、コードを再利用するための継承の代替手段です。これは、継承と構成のさらに広い比較に戻ります。

デザインパターン：再利用可能なOOPの要素から、戦略パターンを使用して

• （動作の組み合わせにより）サブクラスの爆発を回避する
• 実行時に動作を交換する必要がある場合

継承を使用してクワックとフライの動作を実装すると、これらすべてのサブクラスが動作のすべての組み合わせを表すことになります。

• FlyableQuackableDuck
• FlyableSqeakableDuck
• FlyableMuteDuck
• NoFlyQuackableDuck
• NoFlySqueakableDuck
• NoFlyMuteDuck

非常に多くのサブクラスがあると、保守が難しくなるため、この場合は戦略パターンが優先されます。FlyabilityとQuackabilityをカプセル化する2つのプロパティが必要であり、新しいクラスを作成せずにこれらを混合して一致させることができます。

また、天候が変化した場合に、カモのFlyプロパティがNoFlyオブジェクトに置き換えられる可能性があるという、実行時の利点についても既に説明しました。

これは、可能であれば継承よりも構成を優先するというアドバイスと一致しています。

Duckクラス（派生クラスなし）だけでこの例をさらに簡略化できますか？次に、1つのduckオブジェクトを実装するときに、独自のオブジェクトタイプに依存しない特定の状況に基づいて、異なる動作を割り当てることができます。

もちろん。インスピレーションについては、Head First Object-Oriented Analysis and Designをご覧ください。（Rick's Guitars）があり、（音楽的な）Instrumentサブクラスの爆発を示しています。このさまざまな動作をすべて修正するには、さまざまな動作をカプセル化するという原則に従って、「仕様」クラスにラップします。

抽象ファクトリ-コンテキストベースの構築

こちらがパターンです。ところで、それは戦略自体を使用していることに注意してください。

実装ではなく概念に焦点を当てています... 晴れや雨などの条件に基づいて仕様オブジェクトを構築する「WeatherFactory」があるかもしれません。

あなたはそれらの「NoFlyInFogQuackableMallard」ものを構築するための「ファクトリーのファクトリー」を持つことができます。そして実際、これが抽象ファクトリー・パターンに関するものです。したがって、おそらく一般的なアヒル型を作成するDuckFactory、次にそれにアヒル型固有の霧の天気の振る舞いを与えるWeatherFactoryがあります。