asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

パターン適用の確認

あるデザインパターンをシステムに適用したかどうかを知るにはどうすればいいだろう。

デザインパターンのカタログを読み、そこで書かれているあるパターンは今まで知らなかったものだが、今作っているシステムでそのパターンを適用している ような気がする。しかし、本当にそのパターンを適用したことになっているか確信が持てない。

この状況に対する二つの反応が考えられる。

(1)あるパターンを適用しているかどうかを知ることは重要でない。私は設計上の問題を熟考し、現在の解決策を適用した。その解決策がパターンだったかどうかは関係ない。

一方で、パターンを適用したかどうかを知ることが重要だという主張も考えられる。

(2)あるパターンを適用したかどうかを知るのは重要である。パターンは問題と解決策の関係を表現する。パターンの適用を知ることで、どんな設計上の問題があったのかを理解できる。パターンの記述を読むことで、なぜそのような設計になったのかを理解できる。仕様変化などでパターンが適用された構造を変化させなければならないとき、設計の意図を壊さないように安全に変更することができる。

二番目の主張は仮説を含んでいるが、妥当に思える。


もし二番目の主張が妥当だとしたら、あるパターンを適用したかどうかを知るのは重要だということになる。ここでの課題は、適用したかどうかを確認するのが難しい点にある。よく知られたパターン、たとえば、Singleton パターンなどなら確認は簡単かもしれない。しかし、自分の良く知らないパターンである場合、難しい。

難しくなる要因にはいくつか考えられる。

(1)開発者は、そのパターンを十分に理解できるだけの経験がない。

(2)パターンの適用範囲、もしくはバリエーションの範囲が広い。そのため、パターンの記述でカバーされている範囲外に実際に適用したバリエーションが存在している、と開発者は感じている。

(3)パターンの記述形式は、パターンを適用したかどうかをチェックできるのに適した形式ではない。
pattern.png



要因のひとつには、(3)がある気がする。パターンを学ぶのは難しい。パターンをマスターするために GoF のパターンカタログだけを読むのは不十分だったのは、その後入門書が何冊も出版されたことからも分かる。したがって、パターン記述に則った形式に基づき、異なる観点からパターンを記述できると考えられる。

pattern_desc.png


感じるのは、もうすこしフォーマルな記述があってもいいんではないかという点。


関係しそうな文献:

Neil B. Harrison, Paris Avgeriou, Uwe Zdun, "Using Patterns to Capture Architectural Decisions," IEEE Software, vol. 24, no. 4, pp. 38-45, Jul/Aug, 2007

Frank Buschmann, Kevlin Henney, Douglas C. Schmidt, Pattern-Oriented Software Architecture: On Patterns and Pattern Languages, John Wiley & Sons, 2007
スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://asatohan.blog77.fc2.com/tb.php/65-51aaf4d1
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。