GoF本

異動していく上司の荷物整理によって、唐突に譲り受けたので読み始めてみる。

オブジェクト指向における再利用のためのデザインパターン

オブジェクト指向における再利用のためのデザインパターン

●自分の設計において、何が変動要素なのかを考える。(1.7)
設計に変更を強いるのではなく、再設計することなしに変更できる方法を検討する。ここでの焦点は、“変化する概念をどのようにカプセル化するか”であり、これは多くのデザインパターンの主題でもある。
デザインパターンには、“独立に変更できる設計要素”が対応付けられる。これによって、再設計することなしに、その要素だけを変更することができる。
フレームワーク(1.6)
ツールキット(サブルーチン)を用いる場合は、アプリケーションのメインプログラムを書き、再利用したいコードを呼ぶ。一方、フレームワークを利用する場合は、メインプログラムを再利用し、それが呼ぶコードを書くことになる。特定の名前および呼び出し規約を用いてオペレーションを書かなければならないことになるが、その分、設計上において決定すべき項目は少なくなる。
デザインパターンを用いて設計したフレームワークは、設計やコードの高度な再利用がしやすくなる。一般に、成熟したフレームワークはさまざまなデザインパターンを常に含んでいる。再設計なしでさまざまなアプリケーションに適合させるようなフレームワークの構築には、パターンが大いに役立つのである。

フレームワークを使ったときに、本質的に嬉しいことが何なのかが今ひとつ納得できていない。Strutsも自分で使ってみたことはないし、Ruby on Railsも、インストールしてみて、30秒で動くウェブアプリの雛形が出来た!と喜んだ状態で理解は止まっている。
「サブルーチンは呼ぶ先を再利用、フレームワークは呼ばれる元を再利用」というので、表面的な理解は正しいのだろうけれど、きっとフレームワークがここまで広まった本質は、「再利用性」への期待によるものなのだろう。デザインパターンによって、フレームワーク自身が柔軟に変化できる可能性を期待させるから、バッドノウハウを覚え込むときの、やるせなさを感じずに済むのではないかと。
オブジェクト指向カプセル化だとかを理解したつもりになりながら、ずっとJAVAでプログラムを書いていた。「受け取ったオブジェクトの属性値に基づいてソートする」クラスを作ったものの、ソートの条件となる属性値や、ソート対象のオブジェクトの型ごとに、次々に似たようなクラスをコピペで再生産しながら、効率の悪さを感じていた(職業プログラマではないので、実損失はないけど)。
そんな不満を解消し、再利用に対する柔軟性を担保するのがデザインパターンの意義で、かつオブジェクト指向の強みなのか。「動物クッキーがインスタンスで、動物クッキーの金型がクラスです」という、大学2年次のときに演習で聞いた話だけを頼りに、これまでプログラムを書いてきたのが、いかに脆弱な知識だったかを理解できそうな気がする。