「バケツリレー」のChain of Responsibilityパターン

2009年5月26日(火)
清水 英雄

デザインパターンは、作業して、学ぶことに意味がある。

 本連載も最終回となりました。第1回では生成に関するパターンとしてFactory Methodパターン、第2回では構造に関するパターンとしてAdapterパターンとBridgeパターンを取り上げました。もし、まだよく理解されていないようなら、第1回(http://thinkit.jp/article/931/1/)・第2回(http://thinkit.jp/article/936/1/)を見直してみてください。

 ただサンプルコードを見ているだけでは、理解しにくいところもあると思います。また、理解したつもりになっていても正しく理解できていないこともあります。

 デザインパターンを速習するには、サンプルコードをコピーするのではなく、自分で入力してみて、その動作を体験するのが一番です。また、クラス構造やオブジェクトの関連性などを完全に理解していないと、実践で利用価値を見いだそうとしても難しいものがあります。特にUMLが理解できれば、非常に強力な表現方法を身につけたことになりますので、デザインパターンを理解すると同時にUMLも覚えると、実践での利用は進んでいくと思います。

 GoFのデザインパターンは、この3回の連載だけですべてを紹介できるものではありません。ご紹介できなかったものを含めて23種類のパターンについて、1つ1つを「このクラスの関係はこういうことではないのか?」「このクラスの関係をUMLで書くとこのようになるのでは?」などを考えながら、実際にUMLを記述してみる作業は、理解を進めるために重要なことです。

 私たちは、よくクラス設計のときに、プログラマーの理解度を同じにするために、ホワイトボードを使用します。ホワイトボード上で書かれたUMLクラス図は、添削のたびに書き換えられたり、消されたりしていきます。そして最後に残ったクラス図は、無駄が省かれてすっきりしていることが多いものです。これらの作業は、デザインパターンを学ぶことに、よく似ていることだと思っています。

UML化することでイメージを定着させる。

 少し面倒に感じるかもしれませんが、「自分で入力したコードを実行することによってふるまいを体験し、UML図で構造を理解する方法」は、デザインパターンの速習にぴったりでしょう。

 ただ、デザインパターンを理解していくと、あらゆるプログラムにデザインパターンを適用すればいいということでもないと感じてくるかもしれません。適用したために修正がしにくくなった例も数多く見てきました。

 だからといって、デザインパターンを避けて通ることはできません。デザインパターンは、先人たちの知恵のエッセンスであることは確かなのです。GoFのデザインパターンを最初に学ぶことがプログラミングのセンスアップに大きく役に立つことは事実なのですから。

 少し話が長くなりましたが、本連載「速習!デザインパターン」の最後はChain of Responsibilityパターンを取り上げます。

Rarestyle
MR(医薬情報担当者)・微生物研究員を経て、化学系会社にシステム担当として従事し、システムマネジメントやインフラ整備などを行う。微生物研究員時代から数値解析など通じてプログラミングを学び、現在、Webサイト「Rarestyleへようこそ(http://www.rarestyle.net/)」を立ち上げ、パソコンコミュニティー活動・人材教育にも力を入れている。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています