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

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

　本連載も最終回となりました。第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パターンを取り上げます。