問題タブ [strategy-pattern]

当座預金口座と普通預金口座を持っています。戦略パターンを使用して撤回メソッドを実装する方法を検討しています。

現在、当座預金口座と普通預金口座はどちらも Account を継承しています。普通預金口座の場合、引き出しによって残高が 100 ドルを下回ってはなりません。当座預金口座では、引き出しには小切手番号が含まれている必要があります。

以下に示すように、「otherArguments」パラメーターは 1 つのシナリオではまったく役に立たないため、このアプローチを使用する自信はありません。そして、私がこのようにした唯一の理由は、戦略パターンの使用を「示す」ことです。

（心配している人のために、これは学校のプロジェクトの一部であり、以下のコードはすべて私が書いたものであり、それを実現するためのより良い方法があるかどうか知りたいです）.

これまでに行ったことは次のとおりです。

「戦略パターン」の概念は理解できましたが、まだ少し混乱しています。

という名前のクラスがあるとしましょうDog。 となることができる（インターフェース）をDog持っています。 どちらにも という名前のメソッドが含まれています。MovementBehaviourMovementBehaviourNormalMovementBehaviourFastMovementBehaviourNormalMovementBehaviourFastmove

質問: メソッドから犬の属性にアクセスする最良の方法は何moveですか? MovementBehaviour犬オブジェクトをデリゲートとして渡すのは悪い考えですか?

私はファクトリパターン（およびストラテジーパターン）と、パターンが持つことができる大きなメリットに慣れてきました。しかし、私は次の状況に苦しんでいます。

以前は、次のようなことをしていました。そこでは、車を作成して保存するマネージャークラスがあります。ここには依存性注入はなく、特に単体テストを試みる場合は実装が不十分です。

Factoriesデータベースからであろうと、どこからであろうと、私のために車を作るためのさまざまな方法がどのようにできるかがわかりました。これは素晴らしい！だから、ここに私の質問があります：

FactoriesQ1：オブジェクトのみをビルドする必要があるというのは私の理解ですが、それは正しいですか？もしそうなら、私の2番目の質問はどうですか？

Q2：オブジェクトをビルドするためにファクトリパターンに従っている場合、オブジェクトを保存するにはどうすればよいですか？これには別のパターンがありますか、それともファクトリパターンを完全に理解していませんか？

戦略パターンと依存性注入の両方により、実行時にオブジェクトを設定/注入できます。戦略パターンと依存性注入の違いは何ですか?

マイクロソフトユニティを取得して、特定のインターフェイスタイプのクラスのリストを「構築」するにはどうすればよいですか。

非常に簡単な例：

ありがとうございました！

私は、これらの設計パターンについて学んだばかりのクラスにいます。しかし、それらの間に違いは見られませんでした。それらは同じように聞こえ、抽象的なクラスの上に具体的なクラスを作成します。誰かがこの疑いを消すのを手伝ってくれませんか? ありがとう （：

私はあなたが私の問題で私を助けることができることを願っています：

私は石鹸の呼び出しをしているクラスを持っています。しかし、soapの定義が変更された場合は、新しいクラスを作成するか、そこから継承する必要があります。そこで、次のようなものを作成するソリューションにたどり着きました。

かなり悪いコードだと思います。それから私はストラテジーパターンについて読みました、そして私はそれが私がこの悪いスイッチケースのものを取り除くために必要なものだと思いました：

しかし、コードで「ifs」を使用したり、大文字と小文字を切り替えたりすることは避けられません。これはOO技術を使用して可能ですか？

編集：GetSoapVersion-関数は静的である必要があります

私はデザインパターンを学び、Go4の本をフォローしようとしています。ページ：179のデコレータパターンの章に、次のような行があります

「..戦略の数を1つから制限のないリストに拡張することで、デコレータを再帰的にネストするのと同じ効果を実現します。」

私はこの声明を完全に理解していませんでした。

戦略は、動的に設定でき、設定されているクライアントについてあまり知らない独立したアルゴリズムを持つことに焦点を当てています。

デコレータは、デコレートするクライアントから完全に独立しているわけではありません。実際、それらはそれらが飾るオブジェクトと同じスーパータイプです。

私はここでポイントを逃していますか？

ポーカー ハンド履歴ファイル パーサー (PHP または Java コード) の戦略パターンを実装しました。いくつかの戦略で使用されるクラスとオブジェクトのクリーンな OOP 方法を作成するのに問題があります。

実生活では ：

Hand(s) を持つクラス Game があります

1 つの戦略は、オブジェクト ゲームと手を作成します。

そして、この戦略にはゲームと各ハンド に特定の属性が必要です。これらの属性をハンドまたはゲームに入れることはできませんが、1 つの戦略でのみ使用され、他の戦略では使用されません。私の質問は次のとおりです。最適な OOP の方法は何ですか? 戦略のための特定のクラスを作成しますか?

それは明らかな答えのように思えますが、もっと良い方法があるかどうかまだ疑問に思っています。さらに、セマンティックに問題があります。クラスにどのような名前を付ける必要がありますか (HandFor... 気分が悪い!)。私は古い学校のプログラマーであり、非常に手続き型であり、「クリーンな」 OOP について考えるのに多くの時間を費やしています。

Spring フレームワークを使用して Java 1.5 で開発された Web アプリケーションがあります。アプリケーションには「ダッシュボード」が含まれています。これは、一連の情報が再グループ化され、ユーザーがステータスを変更できる単純なページです。マネージャーは、これらのダッシュボードのうち 3 つのデータベースにログ システムを追加するように求めています。各ダッシュボードには異なる情報がありますが、ログは日付とユーザーのログインによって追跡する必要があります。

私がやりたいのは、次のような戦略パターンを実装することです:

Appcontext.xml :

したがって、このソリューションでは、依存性注入を使用していません。このようにするのは「正しい」（良い習慣、パフォーマンスなど）ですか？DI を使用できるより良い方法はありますか?

注：コンストラクターやゲッター/セッターなどの基本的なものは書きませんでした。