シナリオ: アヒルのシミュレーション ゲームでは、さまざまな種類のアヒルが鳴いたり泳いだりできます。
予備的な設計計画を以下の UML クラス図に示します。
変更点: この初期段階は完璧に見えましたが、ある日ゲームでアヒルを飛ばす必要がありました。このとき、最も簡単な解決策はそれを追加することでした。親クラス A fly メソッドへの UML 図は次のとおりです:
ある日、災害が起こりました。ゲーム内でたくさんのゴム製のアヒルが飛び回っていました。 。 。 。
現時点での最も簡単な解決策は、RubberDuck クラスの fly メソッドを上書きすることです。クラス図は次のとおりです。
変更: ラバー アヒルに加えて、次のようなゲームがますます普及しています。 DecoyDuck (デコイ アヒル) など、他にも多くの種類のアヒルが追加されていますが、これはクワックも飛行もできません。すべてのクラスで fly メソッドと quack メソッドもカバーする必要がありますか?
解決策:
1. quack と quack をインターフェイスとして設計します。対応する UML クラス図は次のとおりです。(下の図は間違っています。decoyduck では swim メソッドは必要ありません)。
欠点: この解決策はコードの重複を引き起こしやすく、同じ fly メソッドと quack メソッドを再利用しません
2. flyable と quackable をアヒルの属性として独立したクラスにします。対応する UML クラス図は次のとおりです。
このメソッドでは、redheadduck、rubberduck、malardduck、decoyduck は、flyability クラスと quackability クラスの関連メソッドを使用して、それぞれ特定の fly メソッドと quack メソッドを実装する必要があります。このソリューションは、設計哲学における「特定の実装のためのプログラミングではなく、インターフェイスのためのプログラミング」という原則に違反しています。飛行可能性とクワック化可能性のクラスにさまざまなアヒルが必要とする機能が存在することを保証できません
3。 . 具体的な実装は各種飛行スキルや呼び出しスキルによって完了します。
Uml クラス図は次のとおりです。
もちろん、ゴム製アヒルが現在飛べないからといって、将来も飛べなくなるわけではありません。彼の飛行能力、クラス図を次のように設定する方法が必要です:
コードのダウンロード: コードをダウンロード (http://www.walk-sing.com/strategy Strategy mode.zip)
注:実際にコードを書く過程で、quackable メソッドを実装した後に quack が使われていることが分かりました。quack メソッドは携帯電話の quack のコンストラクターでもあるため、書くときに quack クラス名を quack クラスに変更しました。
以上、デザインパターン入門 - 戦略パターン（php版）を様々な側面を含めて紹介しましたが、PHPチュートリアルに興味のある友人の参考になれば幸いです。
