特に「建築とデザインパターン」コースの新しいセットの開始のために、私はGRASPパターンに関する一連の出版物を続けています。
前書き
CraigLarmanの著書「ApplyingUMLand pattern、3rd edition」で説明されているように、GRASPパターンはGoFパターンの一般化であり、OOP原則の直接的な結果でもあります。これらは、OOPの原則からGoFパターンを導出できるようにする論理ラダーの欠落しているラングを補完します。GRASPパターンは（GoFのような）設計パターンではなく、クラス間で責任を割り当てるという基本原則です。実践が示すように、それらはあまり人気がありませんが、GRASPパターンのフルセットを使用して設計されたクラスを分析することは、優れたコードを作成するための前提条件です。
GRASPテンプレートの完全なリストは、次の9つの要素で構成されています。
- 情報エキスパート
- クリエイター
- コントローラ
- 低結合
- 高い凝集性
- 多形性
前回、コントローラーのパターンについて説明しました。今日は、リストの残りのパターンを検討することを提案します。
多形性
タイプに基づいてさまざまな動作を処理し、システムパーツの交換を可能にする必要があります。
多態的な操作を使用してクラス間で責任を分散し、各外部システムに独自のインターフェースを残すことが提案されています。例として、さまざまな顧客のニーズに応じて特定のプラグインを接続することにより、標準化されたライブラリまたはアプリケーション構成を引用できます。
コード内にスイッチ構造が存在することは、この原則の違反であり、スイッチであり、リファクタリングの対象となります。
多態性の乱用はコードの過度の複雑化につながり、一般的には推奨されません。
純粋な製造
低結合と高凝集性を確保する必要があります。この目的のために、人工エッセンスを合成する必要があるかもしれません。Pure Fabricationパターンは、これを行うことを躊躇しないことを示唆しています。例として、データベースのファサードについて考えてみます。これは純粋に人工的なオブジェクトであり、対象領域に類似物はありません。一般に、ファサードはすべてPure Fabricationです（もちろん、対応するアプリケーションのアーキテクチャファサードでない限り）。
間接
直接的な拘束を避け、オブジェクト間で責任を分散する必要があります。これを行うには、コンポーネントまたはサービス間の通信の責任を中間オブジェクトに割り当てることができます。
ロシア語に翻訳すると、このパターンは次のことを意味します。コード内のすべてのオブジェクトは、そのインターフェイス（同じ中間オブジェクト）を介して呼び出す必要があります。
間接性は、この記事に記載されている最も重要なパターンです。まず、セキュリティの面で非常に簡単です。第2に、最初のポイントによる時期尚早な最適化を行うことなく、コードに多くの柔軟性を与えます。すべてのクラスがインターフェイスを介して相互に呼び出す場合、これにより、システムから任意の部分を「リッピング」して、他の場所で再利用できるようになります。さらに、Indirectionを使用すると、クラスに負担をかけたりリファクタリングしたりすることなく、4人のギャングのほぼすべてのテンプレートを追加できます。
保護されたバリエーション
一部の要素の変更が他の要素に影響を与えないようにシステムを設計する必要があります。解決策として、起こりうる変化や不安定さのポイントを特定し、システムの安定した運用を保証するような方法で責任を割り当てることが提案されています。
実際、これはパターンではなく、残りのパターンに従うことによって達成される目標です。
出力
GRASPテンプレートは、次の8つのパターンで構成されています。
- 情報エキスパート-情報が含まれている場所で情報を処理します。
- 作成者-必要な場所にオブジェクトを作成します。
- コントローラ-マルチスレッドロジックを別のクラスまたはコンポーネントに移動します。
- 低結合5）高凝集性-同種のビジネスロジックと最小数の接続を備えたクラスを設計します。
- 多態性-必要に応じて、システムの動作に関するさまざまなオプションを多態性呼び出しの形式で配置します。
- Pure Fabrication — , , Low Coupling High Cohesion.
- Indirection — .
- Protected Variations — , .
: