Hatena::ブログ(Diary)

winplusの日記 このページをアンテナに追加 RSSフィード

2009-10-03

デザインパターン?なにそれ?おいしいの?

楽しいアプリ制作の会 #07(終了)テーマ「デザインパターン(続)」に参加して思ったこと。

最後の方で、WEBフレームワーク Struts の ActionServlet がリクエストを振り分けるところは、Strategyパターンの適用例だという発表者に対して、参加者からCommandパターンに見えるという発言があり、結局、見かた次第、複数のパターンを同時に適用することもあるし、という流れになった。WEBアプリケーションを考えるとき、リクエストをレスポンスへ「変換するもの」と見なせば、Strategyパターンの適用例というのが妥当だと思える。リクエストを「処理の指示」と見なせば、多様なパラメータを同じように扱うためにCommandパターンを適用しているようにも思える。この「見かた次第」というところを、もう少し考えてみたい。

ところで、そもそも、なぜデザインパターンを使うの?という参加者からの質問があった。Strategyパターンを使うとどんなメリットがあるのか、と。

それに対して、レストランの例でこたえる発表者。

「お客さんからの注文はいろいろで、厨房にも和食専門とかパティシエとかいろいろな料理人がいる。注文を受けたウェイターは、注文と料理人の組み合わせをすべて把握して、的確に指示を出す必要がある。Strategyパターンをつかうと、ウェイターは厨房にむかって注文を伝えるだけでよい。新しいメニューが増えても、ウェイターは楽々。プログラム的に言えば、ウェイターの中に注文ごとに分岐する大量のIF文が必要となるところを、Strategyパターンを使うとごっそり無くしてしまえる。」

もう一つ納得しない質問者。

「新しいメニューが増えれば、注文と料理人の組み合わせを一覧表に追記すれば済む。」と回答者。

やっと質問者が納得したようで「やっぱり一覧表を用意する必要があるんですね」。

それまでのやりとりのなかで「デザインパターンが省力化につながる」というような話もあったので、質問者の方は、Strategyパターンを使うと「注文と料理人の組み合わせ」をどこにも記述することなしに処理が可能で、それはものすごい省力化だけど、そんなことできるの?と疑問に思われたようす。

もちろん「注文と料理人の組み合わせ」は、どこかに記述する必要があって、それが一覧表なのかウェイターそのものなのか、という違いしかない。とすれば、記述する場所が変わっただけで、たいして楽にも省力化にもなってないじゃない、ということにもなる。実際、Struts とかだと設定ファイルがとんでもなく複雑になってしまうという問題もあって、だからRails以降のフレームワークは・・・、という話はあちこちで読むことができる。

デザインパターンを適用することで重複する記述を減らすことができる場合もあるけれど、Interface や AbstractClass が追加されたりして逆に記述量が増える場合もあるだろう。そして結局のところ、先の例の一覧表のような業務ロジックはどこかに記述する必要がある。だとすれば、端的に楽になると答えるより、記述する場所が変わって何がうれしいの?という点に答えることが、適切だと思う。

Q:記述する場所が変わって何がうれしいの?

A:クラスの責務を明確にすることができるから。

回答の詳細は、no titleをはじめ、参考となる文書がいろいろと公開されている。「Interface・AbstractClass の導入=>記述量がふえる=>楽にならない」という意見には、「Interface・AbstractClass の導入=>Classの責務が明確になる=>読みやすい・メンテナンスしやすい=>楽になる」という流れで。

 設計するということは、単純にいえば、クラスの責務を決め、クラス間のインターフェイスを決めることともいえる。で、デザインパターンは、設計と実装をつなぐ糊の使い方のベストプラクティスみたいな感じですかね。そもそも、この抽象化されたインターフェイスでプログラミングを行うというところを視野にいれないと、デザインパターンのメリットって感じられないような気がします。

という訳で、「見かた次第」というのは、結局、どのように抽象化するのかによるよね、ということだと思います。

デザインパターン?なにそれ?おいしいの?」と聞かれて、端的に「おいしいよ」と答えるのは難しい、という感想でした。だから発表するのは大変だったと思います。お疲れさまでした。

あと、ものすごく間違っているとは思いつつ、書きます。

発表者の方がデザインパターンの例として最初に Singletonを 取り上げられていました。このパターンには、Interfaceとか登場しません。Singleton はデザインパターンのひとつというより、イディオムやテクニック(Effective Javaに取り上げられてそうなもの)に近い気がします。少なくとも、典型的なデザインパターンとは、いいづらいような。

kayakayakayakaya 2009/10/11 00:20 「結局、どのように抽象化するのかによるよね」に同感です。責務を決めたりインターフェースを決めることは、契約に基く設計の話になってゆくのかな?と思いました。結局、うまく抽象化すれば楽できるよ、を感じられるか否かでデザインパターンの捉え方も変わるのでしょうね。

winpluswinplus 2009/10/12 22:47 たしかに「契約に基く設計」に近づきそうですね。
じつは、システム内でレイヤーを分けてAPIを明確に規程していく、という「はてな」での開発方法が、この記事を書いたときに頭にありました(WEB+DB PRESS Vol.49 「はてなブックマーク構築ノウハウ大公開」)。メイヤーの提唱するようなガチガチの方法ではありませんが、この手法も「契約に基く設計」の延長線上に位置付けられそう。

List a = new ArrayList();
という一行をみて「左項がなぜ List になっているのか」が腑に落ちれば、「うまく抽象化すれば楽できるよ」という実感まで、そう遠くないと思うのですが。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/winplus/20091003/1254566735
Connection: close