問題タブ [strategy-pattern]

古いレガシー プレゼンテーション ライブラリが何年にもわたって維持されており、性急な修正のプロセスと適切なアーキテクチャ上の監視の欠如によって、ますます多くのビジネス ロジックがコード化されているという架空の状況を考えてみてください。あるいは、アセンブリの境界によってプレゼンテーションから分離されていないビジネス クラスまたは名前空間を考えてみてください。したがって、参照を強制的に追加することなく System.Windows.Forms のようなものを参照できます (単純な using 句よりもはるかに冷静なアクションです)。 .

このような状況では、この UI コードで使用されるビジネス コードが最終的に再利用のために呼び出されることは想像に難くありません。これを可能にするために2つのレイヤーをリファクタリングする良い方法は何ですか?

私は設計パターンに大まかに精通しています - とにかく少なくとも原則として。しかし、私は実務経験が豊富ではないので、直感に自信がありません。私はこれに Strategy パターンを使用する道を歩み始めました。アイデアは、ビジネス ロジックが UI コンポーネントを呼び出してユーザーに質問し、データを収集する場所を特定し、それらを一連のインターフェイスにカプセル化することです。そのインターフェイスの各メソッドには、元のワークフローの UI 指向のコードが含まれ、UI クラスはそのインターフェイスを実装します。

問題のビジネス ロジックを再利用する新しいコードもこのインターフェイスを実装しますが、UI コンポーネントによって最初に回答された質問に対する新しいウィンドウ、または場合によってはプレハブまたはパラメーター化された回答のいずれかを置き換えます。このようにして、いくつかのメソッドに渡されたやや厄介なインターフェイス パラメーターを使用しても、biz ロジックを実際のライブラリとして扱うことができます。

これはまともなアプローチですか？これについてどうすればよいですか？私はあなたの集合的なインターネットの知恵に従います。

ありがとう！

私は基本クラスを持っています：

および 2 つの派生クラス:

これらの型は、コードの別の部分で次のように使用されます。

処理はメッセージの一部ではないため、これらのメソッドはクラス Message 内にはありません。

ここで、メッセージの種類が多いため、if/else/switch 構造は避けたいと思います。ここで使用するのに最適な設計パターンは何ですか?

1つのオプションは、戦略パターンを使用してカプセル化することです(少なくとも私が理解しているように):

しかし、すべての処理メソッドが基本型 Message を受け入れ、内部でキャストすることは本当にベスト プラクティスでしょうか? もう 1 つの問題は、メッセージの動的タイプ (単純または複雑) が実際にはこのクラスの 2 つの場所 (メッセージとプロセス アルゴリズム) に格納されていることです。

より良い解決策はありますか？

ありがとう！！
アサフ

GoogleAndroidブログのImageDownloaderを採用しています。ImageDownloaderアプリケーションの複数の場所で使用するため、シングルトンになりたいです。Bitmapsまた、さまざまな方法を使用して操作できるようにしたいStrategies（たとえば、透明なビットマップを作成する）。

コンテクスト：

ImageDownloaderあるアクティビティで使用して透明なビットマップを設定し、別のアクティビティで同じImageDownloaderものを使用して、異なる戦略オブジェクトを使用して白黒のビットマップを取得できるようにしたい。

ストラテジーを使用することは、if / elseをファクトリーに延期しているように見えるのはなぜですか？ストラテジーを使用すると、ファクトリはインスタンス化する具体的なクラスを把握する必要はありません。また、if / elseによって把握する必要はありませんか？

どういうわけかマップ/リストを使用し、キーをインスタンス化するクラスの名前にし、ファクトリを使用するクラスに名前を渡す別のオプションはありますか？

私はphp 5.2.6を使用しています。戦略パターンがあり、戦略には静的メソッドがあります。戦略の 1 つを実際に実装するクラスでは、インスタンス化する戦略クラスの名前を取得します。ただし、次のように、インスタンス化の前に静的メソッドの 1 つを呼び出したいと思いました。

しかし、それは与えT_PAAMAYIM_NEKUDOTAYIMます。

これは 5.3 で動作しますか?

私は戦略パターンについて読んでいて、質問があります。私が求めていることを説明するために、以下の非常に基本的なコンソール アプリケーションを実装しました。

戦略パターンを実装する際に「switch」ステートメントを使用することは危険信号であると読みました。ただし、この例では switch ステートメントを使用することから逃れられないようです。何か不足していますか？Pencilからロジックを削除することができましたが、Mainには switch ステートメントが含まれています。新しいTriangleDrawerクラスを簡単に作成でき、 Pencilクラスを開く必要がないことは理解しています。これは良いことです。ただし、鉛筆に渡すIDrawerのタイプを知るためにMainを開く必要があります。. ユーザーの入力に頼っている場合、これは必要なことですか? switch ステートメントを使用せずにこれを行う方法があれば、ぜひ試してみたいと思います。

以下に示す実装済みのソリューション(回答してくれたすべての人に感謝します!) このソリューションにより、新しいIDrawオブジェクトを使用するために必要な唯一のことは、それを作成することであるという点に到達しました。

どちらの設計パターンもアルゴリズムをカプセル化し、実装の詳細を呼び出しクラスから分離します。私が認識できる唯一の違いは、Strategy パターンは実行用のパラメーターを受け取るのに対し、Command パターンはそうしないことです。

コマンドパターンは、作成時に実行のためのすべての情報が利用可能である必要があり、その呼び出しを遅らせることができるようです (おそらくスクリプトの一部として)。

どちらのパターンを使用するかの判断基準は何ですか?

私は現在ソリューションを開発しており、戦略/プロバイダー パターンを強力に実装するように設計しました。そのため、このソリューションは多数のインターフェイスを公開し、これらのインターフェイスのデフォルトの実装を含みます。これらのインターフェイスは、DI タイプの方法論で置き換えることができます。

ホスト アプリケーションがこれらのインターフェイスを多数使用する場合、発生する可能性のある特定の例外を処理することが期待されます。たとえば、IDataRetrieverインターフェイスにはメソッドがあり、ホストはやSomeDataType GetData(int timeout);などのカスタム例外を処理できます。 DataRetrievalTimeoutExceptionNetworkConnectionException

私の質問は、開発者がそれを実装するときに、特定の例外がスローされ、ホストによって処理されることがわかるように、インターフェイス クラスをマークアップする最良の方法は何ですか?

現時点では、メソッドの xml コメントに例外 xml タグを追加したところですが、これで十分でしょうか?

戦略を注入するためにDIコンテナを使用するアプリケーションを作成しています。デプロイ時に、これらのストラテジーを変更する必要がある場合、新しいストラテジーを使用して新しいアセンブリをデプロイし、どのストラテジーを使用するかをDIコンテナーに指示するために構成ファイルを修正することは有効なデプロイメント戦略ですか？

私の懸念は、異なるdllのバージョン番号が異なるため、マシン上のアプリケーションのバージョン管理が少しあいまいになることです。

ユーザーが20または30の一意の戦略オブジェクトのリストから4つの戦略を選択する戦略パターンを作成する必要があります。プロジェクトが成熟するにつれて戦略のリストが拡張され、ユーザーはいつでも選択した戦略を変更できます。

選択したストラテジー名を文字列として保存し、このようなメソッドを使用して、選択したストリングに対応するストラテジークラスをロードする予定です。

大きなswitchステートメントを避けようとしています。私の懸念は、これがちょっとそうだということですStringly Typed。条件付きまたは大きなswitchステートメントを使用せずにこの目標を達成するためのより良い方法はありますか？

ところで：ユーザーは4つの戦略を選択するときに文字列を入力しません。選択ボックスでユーザーに表示する文字列のリストを維持し、新しい戦略オブジェクトを追加するときにリストに新しい文字列を追加する必要があります。

説明
ircmaxellは、私がやろうとしていることに関して少し混乱を示しました。上記の例では、ユーザーはリストから4つの戦略を選択し、それらは文字列の配列としてStrategyManagerコンストラクターに渡されます。対応するストラテジーオブジェクトが作成され、内部配列に格納されます。$this->selectedStrategies

「first」、「second」、「third」、「fourth」は、選択した4つの異なる戦略の内部配列の配列キーです。StrategyManagerオブジェクトが構築された後、アプリケーションはexecute、プロセスの存続期間中のさまざまな瞬間に4つの戦略のメソッドを使用します。

つまり、一言で言えば...アプリケーションがストラテジー番号「1」のメソッドを実行する必要があるたびに実行され、ストラテジー「1」に対してユーザーが選択したストラテジーによって結果が異なります。