次に，GRASPパターンを実際にどのように使うかを説明しよう。ここでは，クライアント・アプリケーションであるワープロ・ソフトを例に挙げる。ワープロ・ソフトではファイルの印刷を実行しようとすると，印刷方法を設定するためのウインドウが画面に表示される。このウインドウは，テキスト，ボタン，テキストボックスからなる。このウインドウがダイアログボックスだ。

　この場合，テキスト，ボタン，そしてテキストボックスという3つのオブジェクトを「生成する」という責務は，どのオブジェクト（クラス）に割り当てるべきだろうか。候補としてダイアログボックス自体とクライアント・アプリケーションの2つが考えられる。

　ここで役に立つのが「Creatorパターン」である。このパターンは，「オブジェクトを生成する責務を誰に（どのオブジェクトに）割り当てるか」を判断する場合に使う。パターンによる解決策は，「そのオブジェクトを集約または包含するオブジェクトに，『オブジェクト生成』の責務を割り当てる」だ。

　テキストやボタンはダイアログボックス上に配置する。つまりテキスト，ボタン，テキストボックスはダイアログボックスに集約されているわけだ。従って，オブジェクト生成という責務を割り当てるべきなのは，ダイアログボックスとなる。

　次にこの設計が適当かどうかを，結合度を低くするためのLow Couplingパターンと，凝集度を高めるためのHigh Cohesionパターンの観点から評価してみよう。

　もしクライアント・アプリケーションにテキスト，ボタン，テキストボックスの生成の責務を持たせると，クライアント・アプリケーションと各オブジェクトの間に「関連」が生じる。つまり，クライアント・アプリケーションを修正すると他のオブジェクトにも影響が及び，結合度が高くなってしまう。同時に，クライアントにとっては本来不要なオブジェクト生成処理を受け持つことになるので，凝集度は低くなってしまう。

　一方，ダイアログボックスに生成の責務を持たせた場合はどうか。クライアント・アプリケーションはダイアログボックスの識別さえできればよい。ダイアログボックスを指定するだけで，データをやり取りできるからだ。不要な関連や生成の責務は生じず，そのダイアログボックスは非常に汎用的なオブジェクトになる。したがって，この設計は適切だと判断してよい。

複数のパターンを考慮する

　GRASPパターンを使って設計する際の注意点は，複数の視点からパターンを検討することだ。実際の開発においては，「あるパターンを満たしているが別のパターンに対しては不適切」という場合も当然起こりうる。1つのパターンだけで判断するのではなく，複数のパターンに照らし合わせることによって，より頑強な設計が得られる。

　また，GRASPパターンはあくまでも原則であるということも念頭に置いておこう。パフォーマンス向上を目指してデータベースを非正規化することと同様，状況によってはあえてGRASPパターンに反する設計を行う方が良い場合もある。このようなトレードオフをどう取り扱うかが，初心者と上級者との差だと言えよう。

渡辺 康隆（わたなべ やすたか）／デュオシステムズ ビジネスソリューション・グループ システムアーキテクト
広島大学工学部卒業後，メーカー系研究開発部門を経て，デュオシステムズに入社。現在，システムアーキテクトとしてオブジェクト指向技術を活用したシステム開発に従事。著書に「分散オブジェクトモデリングガイド（ピアソン・エデュケーション）」，訳書に「J2EEクイックリファレンス（O'REILLY）」など