Delphi モード プログラミングのストラテジー モード
劉毅
1.1 モードの説明
Strategy パターンの目的は、一連のアルゴリズムを定義し、各アルゴリズムを共通のインターフェイスを持つ独立したクラスにカプセル化して、相互に置き換えることができるようにすることです。 Strategy パターンでは、それを使用するクライアントに関係なくアルゴリズムを変更できます。戦略パターンを使用する動機と重要性を理解するには、興味深い例から始める必要があります。資材管理システムでは、アウトバウンドモジュールとインバウンドモジュールがシステムの中核部分です（以下ではアウトバウンドを分析の例として取り上げます）。オブジェクト指向プログラミングの経験がないプログラマーは、多くの場合、アウトバウンド注文のすべてのロジックをクライアント (アウトレット注文インターフェイス) に配置し、クライアントで条件付き分岐ステートメントを使用して、アウトバウンド注文タイプがピッキングであるかどうかを判断します。図 1-1 に示すように、さまざまなアウトバウンド決済方法を選択するには、資料を借用するか損失を報告します。その結果、クライアントのコードは複雑になり、保守が困難になります。たとえば、倉庫から新しい転送オーダー タイプを追加する必要がある場合、判定条件を変更し、クライアントを再コンパイルして公開する必要があります。状況がますます複雑になると、条件分岐が増えたり、プログラムコードが増えたりするため、クライアントが大きくなり保守が難しくなり、相互影響やエラーが発生する可能性が高くなります。 。図 1-1 プロセス指向の考え方に基づいて設計されたアウトバウンド モジュール2 表示します。このように、アウトバウンド ドキュメントはドキュメントの基本クラスとして機能し、ドキュメントに共通のインターフェイスを提供し、継承を使用してサブクラスでさまざまなアウトバウンド動作を実装します。これは実際、オブジェクト指向の重要な概念であるポリモーフィズムを利用しています。ただし、この設計には依然として欠点があり、それは、環境と動作が密接に結びついていることです。言い換えれば、文書と特定の送信アルゴリズムは密接に結びついています。結合が強いと、2 つが独立して進化することができなくなり、再利用性と拡張性が制限されます。図 1-3 は、戦略パターンを使用して再設計されたアウトバウンド モジュールです。アウトバウンド文書オブジェクトは、アウトバウンド操作オブジェクト (つまり、ストラテジ モードのコンテキスト) を通じてアウトバウンド ポリシー オブジェクトを参照します。さまざまな特定のアウトバウンド戦略が、アウトバウンド戦略クラスの派生クラスによって実装されます。アウトバウンド文書は、アウトバウンド操作と文書スタイルによって、それぞれアウトバウンド決済方法と文書表示インターフェースを提供できます。このように、ストラテジー モードはアウトバウンドの動作をアウトバウンド ドキュメント環境から分離し、アウトバウンド アルゴリズムの増加、減少、変更は環境やクライアントに影響を与えません。図 1-2 オブジェクト指向の考え方に基づいて設計されたアウトバウンド モジュール 図 1-3 デザイン パターンの考え方に基づいて設計されたアウトバウンド モジュール ストラテジ パターンの利点は、アルゴリズムと環境が分離され、両者が独立して進化できることです。アルゴリズムと環境を分離する利点をよりよく説明するには、図 1-4 の設計を見てみましょう。この設計では、すべてのアウトバウンド/インバウンド ドキュメントを抽象化し、実行時にドキュメントのインターフェイスと動作を動的に組み合わせるため、アウトバウンド モジュールとインバウンド モジュールの概念はありません。アウトバウンド/インバウンド操作クラスを通じて、さまざまな動作クラスを維持、クエリ、および構成できます。抽象化されたアウト/インバウンド動作は、さまざまなタイプのインバウンドおよびアウトバウンド文書の操作を完了するために、対応するアルゴリズムを戦略クラスの形式でカプセル化します。これにより、システムの再利用性と拡張性が明らかに向上し、メンテナンスの困難さが軽減されます。図 1-4 戦略パターンの利点は、アルゴリズムと環境を分離できることです。この 2 つは、次の状況に適していることがわかります。 · 多くの関連するクラス間に違いがある場合。彼らの行動においてのみ。 Strategy パターンを使用すると、オブジェクトは多数の動作の中から 1 つを動的に選択できます。 · 異なるトレードオフに基づいて定義したアルゴリズム (つまり、異なる戦略を適用したもの) など、目標を達成するための代替アルゴリズムが複数ある場合。これらの特定のアルゴリズムは、抽象アルゴリズム クラスの派生クラスにカプセル化でき、抽象アルゴリズム クラスの統一インターフェイスを利用できます。ポリモーフィズムにより、クライアントは、抽象アルゴリズム クラスのオブジェクトを保持している限り、任意の特定のアルゴリズムを選択できます。 · クライアントが利用できないデータをアルゴリズムが使用する場合。 Strategy パターンを使用すると、複雑なアルゴリズム関連のデータ構造が公開されるのを回避できます。実際、クライアントはアルゴリズムに関する知識やデータを知る必要はありません。 · クラス定義に多くの動作があり、これらの動作の選択を決定するために複数の条件ステートメントが使用される場合。戦略パターンは、これらの動作を対応する特定の戦略クラスに転送することで、維持が困難な複数の条件選択を回避し、オブジェクト指向プログラミングのアイデアを具体化します。
1.2 構造と使い方
戦略パターンの構造を図 1-5 に示します。これには次の参加者が含まれます。 · 抽象戦略 (TStrategy) - サポートされているすべてのアルゴリズムの共通インターフェイスを宣言します。 TContext は、このインターフェイスを使用して、TConcreteStrategy によって定義およびカプセル化されたアルゴリズムを呼び出します。 · 具体的な戦略 (TConcreteStrategy) - 特定のアルゴリズムまたは動作をカプセル化します。 TStrategy インターフェイスを実装します。 · コンテキスト (TContext) – TStrategy への参照を保持します。 TStrategy インターフェイスを呼び出して、特定のアルゴリズムまたは動作を動的に構成します。図 1-5 ストラテジ パターンの構造 ストラテジ パターンでは、TStrategy と TContext の相互作用を通じて、選択されたアルゴリズムが実装されます。アルゴリズムが呼び出されると、TContext はアルゴリズムに必要なすべてのデータを TStrategy に渡すことができます。あるいは、TContext 自体をパラメータとして TStrategy オペレーションに渡すこともできます。 TContext がクライアント要求をその TStrategy に転送するとき、クライアントは通常、この方法で TConcreteStrategy オブジェクトを作成して TContext に渡します。クライアントは TContext とのみ対話します。通常、クライアントが選択できる一連の TConcreteStrategy クラスがあります。 -------------------------------------------------- --------------------------------------
その他の関連記事やサンプル プログラムのソース コードは、著者の Web サイトからダウンロードできます: http://www.liu-yi.net
