設計といえばデザインパターン？

objectoriented

softwareengineering

研究のほうは順調に推移していて、方向性もだいぶ定まりつつあります。

後輩のI君、Y君、Iさんも基礎的なことはだいぶできるようになってきたので「本実験用のシステム設計を始めてみよぅ！」・・・・・・と、いってみたのいいものの、普段何気なく自分がやっていることをどうやって教えてよいかわかりません。とりあえず、自分がシステムの一部をモデリング、設計して見せることにしました。

簡単なクラス図を書いて見せたのですが、何気なくCompositeパターンなんかが使ってあったりしたので彼らにはとても不可解なクラス図に見えたようです。わかりやすいかどうかは甚だ疑問ですが、このあたりを理解するための参考書としてGoFのデザインパターンを薦めておきました。

まさしく意地悪な先輩になっていますね。。。。。。

† この本に対するhsurの見解（というか戯言です）

個人的には読むたびに新しいことが発見できる、深い洞察が込められた良著だと思っていますが、解説は難解でオブジェクト指向の初心者を寄せ付けないような感があるのもまた事実だと思います。

オブジェクト指向になじみがない場合には、独習ではなく輪読会などの上級者のサポートが期待できる状況で読破されることをお勧めします。それでも読破するのはかなりつらいと思いますが、それだけの価値がある本だと思います。

† この本の対象って誰だろう？

この本は読む人を選ぶ本で、少なくとも初心者向けの本はないということは確かです。それではこの本の対象となる読者はどのような人なのかということについては僕もよくわかりません。

たとえば、例題がGUIに偏っているから事務処理には使えないというような話はよく聞きますが、本質的にパターンは例題にとらわれるものではないので、オブジェクト指向の上級者であればそのような貧弱な例からでも、パターンという抽象的な概念を自分なりに感じ取って、現実の問題に適用することができていると思います。

ただ、そこまでできる人はこの本を読む必要はないわけで、このあたりの微妙なバランスが、この本のストライクゾーンの狭さのようなものを表していると思います。このことが、わかる人はすんなりわかるがわからない人はいつまでやってもわからないという二極化を生じさせているのではないでしょうか。

† 難点

ダイアグラムの表記が現在主流のUMLではなくOMTになっていることや、言語はC++(とSmalltalkだったかな？)になっていることでしょうか。hsurは両方OKなので問題ないのですが、このあたりを改定してもらえると喜ぶ人^*1も多いと思います。

使ったことはないのですが、こういう本もあるようですね。