Entry

デザパタは設計部品じゃないという話

2009年10月20日

ちと私用でパソコンが使えないところにいたので,久しぶりの更新になってしまいました。そのときの話は,またエントリを改めて。

あたしゃ普段,デザパタをゴリゴリ意識して開発しているわけじゃないし,GoF 教の信者でもないんですけれど,「OOP ができます」と他人に言うことができる(ぶっちゃけて言えば,履歴書に書くことができる)ためには,少なくとも GoF の知識があることがその前提だと思っています。例えば,C++ の場合,いわゆる POD(Plain Old Data)とか better C とかいったスタイルだけで書ききることもできるし,Java や Ruby のような OOP に特化した言語だって,手続志向でゴリ押しすることもできちゃいます。んなもんで,C++ や Java の文法を知っているだけでは,「OOP ができる」とまでは言えない。

と,こんなことを書くのは,どうもこの頃,デザパタというか OOP そのものについて,微妙に認識のずれがあるように思うからです。あたしゃこの頃,新人さんの採用面接に参加してたりするんですけれど(このご時世にもかかわらず,なぜかうちは採用を続けている),「Java ができる」という方は多いものの,「OOP ができる」と思える方は極端に少ないように思います。そして,「OOP ができる」という方の中でも,デザパタを正しく認識していると思える方は,もっと少ない。

ま,あたしもへなちょこなので,偉そうなことは書けないんですけどね。けど,少なくとも,「デザパタ使って開発してました」という方は,その真偽について,かなり警戒しないといけないと思っていたりします。

なお,ここでは,代表的なデザパタとして GoF を挙げているけれども,これは J2EE 周りの有名なパターンについても当てはまります。J2EE 周りにも,MVC とか Composite View とか DAO とか,有名なパターンがたくさんありますよね。

デザパタというと,「パターン」という言葉から,設計部品のようなイメージを想起する方もいると思います。「この部分は Proxy パターンで作る」とかいったら,一義的に実装まで確定するようなイメージです。たしかに,パターンによってはそういう種類のものもある。しかし,一般的に,ここにいわゆるデザイン=設計というのは,かなり抽象度が高い「発想」に近いもので,そのまま実装に移せるものではありません。つことで,デザインパターンの名前と実装例を知ってるだけ,とかいうのは,あまり役に立たない。

また,GoF 教の人と話していて特に思うんですけれど,GoF に書かれている機能分類を絶対視してしまう傾向もしばしば見られます。GoF 本は学的に体系化されているので,仕方がないとも思えるんですけどね。しかし,例えば,Singleton パターンは,本に書かれている通り,必ず1つのインスタンスしか生成しちゃいけないかというとそういうわけでもないし,Facade パターンと State パターンの関連が本に書かれていないからといって,まったく縁がないかというとそういうわけでもない。Facade に状態を持たせたいときに,State パターンを使っちゃいけない法律なんてないですしね。

要するに,パターンは設計問題を解決するためのアイデアであり解法なわけで,こう設計したら自動的にうまくいくとかいった話じゃなかったりします。それはちょうど数学の問題に似ています。ひとつの例題で,一般的な解法を身につけたからといって,すべての問題に適用できるわけじゃない。それをどのように応用して他の問題を解決するための手段に結びつけるのか,といったところがキモだと思うわけです。

つことで,「デザパタできます」と人に言うためには,少なくとも次のようなことを踏まえておく必要があるはずです。結局のところ,OOP 的なデザインなり実装なりの「美しさ」を知ってるってことなんですけれど,それじゃあまりにも抽象的なので,もう少し具体的に書くとこんな感じ。

  • 有名どころのパターンがどのようなものなのか,理解していること。
  • あるパターンが直面している設計問題を正しく理解していること。
  • 「解決された状態」がどのような状態なのか理解していること(「○○パターンを使っているから正しい設計」という議論はありえない)。
  • パターンを使った解決方法について,それを評価する方法(改修効率,処理効率,開発効率等々)を理解していること。
  • 具体的な設計問題を抽象化して,デザインパターンを適用する(あるいは適用しない)ことができること。
  • 設計に基づいて実装できること。

特に,3番目の要素は非常に重要だと思います。よくある議論に「この設計は厳密に Command パターンじゃないから正しい/正しくない」みたいな話があるけれども,ほんと,ナンセンスだと思います。設計問題は,具体的な問題との関係ではじめて解法がありうるわけで,デザパタ内部で閉じた議論は無意味というほかありません。

で,結局のところ,こういう話をきちんと踏まえているということは,反対側から見て,一般的な設計上/実装上の各議論を踏まえているということだったりもします。あるデザインとその実装が,パフォーマンスにどのような影響を与えるのか見積もるには,プログラミング言語(コンパイラを含む)やハードウェアの特性を踏まえている必要があるし,改修時の工数を見積もるときにも,デザパタ内部にとどまらない設計上の議論を踏まえている必要があるからです。

ま,だからなんだってなわけでもないんですけどね。デザパタってちゃんと理解するには案外難しいわけで,軽々とできますという方には警戒感を持った方がよさそうだ,とかゴニョゴニョ。また,デザパタでなんぼでもうまくいくとか吹聴する向きにも警戒した方がよさそうだ,ともゴニョゴニョ。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN