【55】パターンの病理学

　デザインパターンは、ソフトウェア・アーキテクトが使えるツールの中でももっとも価値の高いものです。パターンを使えば、説明しやすく理解しやすい一般的なソリューションを作ることができます。デザインパターンは、優れた設計と直接結びついたコンセプトです。そのため、プロジェクトに無数のパターンを投げ込んで、自分たちのアーキテクチャー設計能力をひけらかしたいという誘惑から逃れるのは難しいとも言えます。パターンを適用すべきでない問題空間にお気に入りのパターンを突っ込もうとしている自分に気付いたら、自分がパターン病の患者になっていないか疑った方がよいかもしれません。

　多くのプロジェクトがこの病気のために傷ついてきました。最初のアーキテクトがパターン本の最後のページを見て、「さあ、どれから使おうかな」と言っていたんだろうなあと目に浮かぶようなプロジェクトは、確かにあります。これは、クラスを書き始めたばかりのデベロッパーが、「次はどのクラスを拡張しょうかな」と考えるのに似ています。デザインパターンは、複雑さを緩和するためのすばらしいツールですが、ツールの常として、誤用、濫用される場合もあります。「金槌しか持っていなければ、すべての問題が釘に見えてくる」という格言がありますが、デザインパターンをそのような金槌にして、釘に見えるものをたたきまくるのは問題です。パターンを賞賛するあまり、心酔しきってしまって、必要以上に複雑なソリューションを作ってしまわないように注意しなければなりません。

　プロジェクトのあちこちに不必要にパターンを使うと、作りすぎになります。デザインパターンは魔法ではありませんから、パターンを使えば自動的にソリューションが優れたデザインになるというわけではありません。パターンは、繰り返し発生する問題に対して再利用できるソリューションです。私たちがすでに発明済みの車輪を見かけたときに、私たちがそれに気付くように、パターンを見つけて記録してくれた人たちがいるのです。私たちは、それらのソリューションで解決できる問題が現れたときにそれを見抜き、デザインパターンを適切に適用しなければなりません。デザインパターンの知識をひけらかしたいという邪念であなたの現実的なビジョンを曇らせてはなりません。効果的なビジネスソリューションを提供してくれるシステムを設計するということに集中し、パターンは適切な問題を解くために使うようにしましょう。