GRASP

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索

GRASPGeneral Responsibility Assignment Software Pattern あるいは ~Principle とは、オブジェクト指向設計において用いられる、クラスやオブジェクトに責務を割り当てる方針を導くパターンや原則である。Craig Larmanが著書「実践UML」で示した。

GRASP で例として示される様々なパターンや原則として、「情報エキスパート (Information Expert)」、「生成者 (Creator)」、「コントローラ(Controller)」、「疎結合 (Low Coupling)」、「高凝集性 (High Cohesion)」、「多態性 (Polymorphism)」、「純粋人工物 (Pure Fabrication)」、「変動からの保護 (Protected Variations)」、「間接化 (Indirection)」がある。

これらのパターンは全て何らかのソフトウェアの課題に対する回答であり、大半のものはソフトウェア開発プロジェクトのほとんどに共通である。したがって、これらのパターンは新しい情報を導き出すのではなく、これまでに実証されたオブジェクト指向設計におけるプログラミングの原則をよりよく記述し、標準化するためにある。

「ソフトウェア開発において決定的な設計技術となるのは、設計の原則の中で磨き上げられた考え方である。UML やその他の技法ではない」(Larman, CraigApplying UML and Patterns - Third Edition. [1]). つまり、GRASP はオブジェクト指向ソフトウェアの設計を助ける、純粋に考え方そのものである。

パターン[編集]

情報エキスパート[編集]

情報エキスパートパターンは、オブジェクトに責務を割り当てる際の一般的な原則である。情報エキスパートパターンは、情報のエキスパート、すなわち必要な情報を全て持っているクラスに責務を割り当てるべきとする。

この原則は、ソフトウェアシステムにおいての責務と演算を集中させない(Big ball of mudとは対照的である)。責務と意思決定の分散が進むと情報の隠蔽化が促進され、他のクラスと情報エキスパートクラスの実装との結合の度合いが小さくなる。

情報エキスパートパターンを適切に使いこなしたシステムは理解しやすく、維持・拡張が簡単で、また将来の開発で再利用できる可能性が高まる[1]

マーティン・ファウラーは、Web の記事 「GetterEradicator」でラーマンの情報エキスパートを参照している[2]

生成者[編集]

生成者パターンは、クラスの新しいインスタンスを作成することに責任を持つのは誰かという問題を解決する。オブジェクトの作成は、オブジェクト指向のシステムではあらゆるところで行われる活動であるから、生成者パターンは重要である。生成者パターンを有効に用いるシステムは、疎結合性が高くなり、理解のしやすさ、カプセル化が促進され、オブジェクトが今後再利用できる可能性が増加する。たとえば、二つのクラスA,Bがあったとき、B が A を包含する、A を合成・集約する、A を密接に使用する、A の初期化情報を持っているといった場合、クラス B がクラス A の作成に責任を持つべきであり、B は A の生成者として自然なオブジェクトと言える。Factoryパターンは、複雑なオブジェクト作成ロジックなど、特別な検討が必要な場合に、「生成者」の替わりになる方法である。この方法では、Factoryと呼ばれる「純粋な人工的」(後述)であるオブジェクトを作ってオブジェクトの作成を行わせることで目的を達する。 [3]

コントローラ[編集]

コントローラ パターンでは、システム全体や、ユースケースシナリオを表現するユーザインタフェースでないクラスにシステムイベントを扱う責務を割り当てる。ユースケースのコントローラはユースケースの全てのシステムイベントを扱い、複数のユースケースで使用できる(例えば、「ユーザーの作成」「ユーザーの削除」というユースケースで、それぞれUserControllerオブジェクトを持たずに一つのオブジェクトを共有してよい)。コントローラは、UI層以上にあって、システムに対する操作を受け取り調整する(制御する)最初のオブジェクトとして定義される。コントローラは、他のオブジェクトに必要な作業の実施を委譲する。他のオブジェクトの活動を制御し、連携させる。一般的なレイヤ構造を持ったオブジェクト指向のシステムでは、GRASP コントローラはアプリケーションやサービス層の一部と考えられる[4] (アプリケーション層/サービス層、ドメイン層を明確に区別している場合)。

疎結合性[編集]

疎結合性 パターンとは、

  • クラス間の依存を小さくする
  • 他のクラスの変更の影響を小さくする
  • 再利用の可能性を高める

を実現するための責務の割り当て方法を決定付けるための尺度である。

高凝集性[編集]

高凝集性 (High Cohesion)パターンとは、オブジェクトが適切に責務を集中させており、管理・理解が可能な状態を保つための尺度である。高凝集性とは、ある要素の責務が強く関連しており、またその要素に集中していることを意味する。クラスやサブシステムにプログラムを分解するのは、システムの凝集性を高める活動の例だと言える。逆に凝集性が低いということは、関連のない責務を持ちすぎている場合である。凝集性が低い要素は理解が難しく、再利用・維持管理が困難で、変更も行いづらい。[5]

多態性[編集]

多態性のパターンでは、型に基づいて振る舞いの変動部分を定義する責務を、変動が起きる型に割り当てる。これは、ポリモルフィックな操作を持たせることで実現できる。

純粋人工物[編集]

純粋人工物とは、問題領域に登場する概念を表すクラスではなく、疎結合や、高凝集性、それらから得られる再利用可能性を実現するために作られるクラスである(情報エキスパートで実現できない場合)。

この種類のクラスはドメイン駆動設計ではサービスと呼ばれる。

間接化[編集]

間接化パターンは、二つの要素の中間にオブジェクトを設け両者の仲介を行う責務を割り当てることで、二つの要素間の疎結合性(および再利用の可能性)を促進する。Model View Controllerにおいてコントローラがデータ(モデル)と表現(ビュー)の仲介を行うのはその一例と言える。

変動からの保護[編集]

変動からの保護(Protected Variations)パターンでは、周辺の要素(オブジェクト、システム、サブシステム)の変動から注目する要素を保護するために、不安定な部分をインタフェースを用いて収束させ、ポリモーフィズムを用いてインターフェイスを実装させる。

関連項目[編集]


引用した資料[編集]

  • Larman, Craig (2005) [2004]. Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd ed.). Prentice Hall PTR. ISBN 0-13-148906-2. 

参考文献[編集]