クラスライブラリとは違う
デザインパターンを知っていると、どういう役に立つのか。いまいち分かりにくいかもしれない。「今度、Javaで開発をすることになったので、Swingを勉強しているのだが、デザインパターンも覚えた方が良いだろうか」という疑問をもらうこともある。
デザインパターンを、クラスライブラリのようなもの、と思っている人もいるようだ。ソフトウェアを作る時に使える、便利な道具(または部品)のようなイメージがあるかもしれない。
クラスライブラリは、覚えたらどんどん使ってみて良いだろう。MFCを覚えたら、画面を作る時にはCListBoxクラスやCComboBoxクラスを使えば良い。そうすれば、リストや選択肢などのGUIコンポーネントを、わざわざ自力で開発しなくて済む。
だが、デザインパターンは、クラスライブラリとはずいぶん趣が違う。ただ使えば良い、というものでもないし、使ったからといって、必ずしも良い結果にならない場合もある。数多くのパターンを覚えれば、それだけソフトウェア作りが楽になる、ということもない。
デザインパターンとは
デザインパターンとは、ソフトウェアの設計を分類し、文書化して残した、ノウハウの財産である。すべてのパターンについて、作るべきクラスの形が(大抵はUMLのクラス図として)示されているが、その他に、以下のような情報が付随している。
- そのパターンを利用すべき状況。
- そのパターンを利用した時に生じる利点(効果)。
- そのパターンを利用した時に生じる欠点(問題)。
重要なのは、クラスの形そのものではなく、付随された情報の方である。
教科書に書かれているパターンの形の通りに、自分のクラスを作れば、それで正しい設計、となる訳ではない。ソフトウェアの目指している目標や利点と、パターンを利用した時に生じる効果や利点とが一致して、初めて正しい設計となる。逆に、これらが一致しない場合は、デザインパターン通りの見事なクラスを作っても、それは最悪の設計をした、ということになってしまう。
だから、デザインパターンを学ぶ時は、クラスの形を丸暗記しても、あまり意味がない。
それなりにデザインパターンを学んでいれば、ソフトウェアのコードを見て、どんなパターンが使用されているか、読み取ることは、そう難しくないと思う。だが、大切なのは、使われているパターン名の正解を答えることではなくて、そのソフトウェアで重視すべき利点を意識した上で、そのパターンを使っていることが正しいのかどうか、どういう欠点には目をつむっているのかを、判断できるかどうか、である。
どんなソフトウェアにも、設計の仕方にはたくさんの選択肢がある。どのような点を重視するか、何を優先するかによって、採用すべき設計の形は決ってくる。言い換えると、どんなソフトウェアにも、機能と、設計とともに、長所・短所がある。デザインパターンとは、その典型的な例を集めたものである。
デザインパターンを学ぶ意義
デザインパターンを学んでおくことで、ソフトウェアの設計をした時に、その長所と短所を、自分で理解できるようになれば良いと思う。ソフトウェア開発者でも、自分が考えた設計が(動くことは分かっているだろうが)どういう短所に目をつむっているのか、意識していない(つまり、自分が何をやっているのか、ちゃんと理解していない)ことが多いのだから。
また、より多くのデザインパターンを学べば、ソフトウェアの設計をする際に、よりたくさんの設計を思い浮かべることができるだろう。そうすれば、それぞれの設計の長所と短所を踏まえた上で、(動く、ということ以上の利点を持った)最適な設計を選択することができるだろう。