Flex、AIR、Java、Androidなど

Archive for 1月 11th, 2009

11 1月, 2009

Builderパターンの理解

Posted by: tachibana In: 未分類

※この記事は私が本を読み、頭で考えたことを将来完全に理解してから見直して笑ったりするためにそのまま羅列したものです。故に間違った理解や意味不明なこともたくさん出てくると思います。プログラミングを教えるような立場の方には有益かも(笑)?
Builderパターンの理解
まずメインクラスがあり、メインクラスがやりたいことは2つの異なるオブジェクトの生成。その際、オブジェクトの生成はBuilderクラスのサブクラスが行う。
メインクラスがオブジェクトを生成したい時は条件により違う処理が必要。条件によりサブクラスをインスタンス化しDirectorクラスに渡す。あとはメインクラス上ではサブクラスのインスタンスを渡されたDirectorクラスのメソッドでもってインスタンスが生成される。
Directorのコンストラクタの引数にはBuilderクラスが。なのでサブクラスを親クラスに代入するいつものパターン。これにより依存しない関係となる。サブクラスであれば親の抽象メソッドが定義されているのであとはDirectorクラスが共通のメソッドで持って処理を行う。
これだと新たな種類のBuilderのサブクラスを実装する必要がでてきた時も設計を変えるのはメインクラスだけでよい(条件を追加するだけでよい)。Directorクラスがなかった場合はサブクラスが独自の仕様を持つことが可能になり管理が難しくなる。
ものをBuildするのはbuilderクラスだということが重要。
自分なりの結論:

分かりにくかったので料理で例える。
例えばボタンを押せば冷奴と湯豆腐を作れる機械をプログラミングしたいと仮定する。この際の手順は命令役(機械の押されたボタンによって冷奴か湯豆腐のレシピを選択し、豆腐を送る)と、レシピ管理役(冷奴と湯豆腐のレシピを管理している)に分ける。処理の流れは冷奴のボタンが押されたとき命令役はレシピ管理役に豆腐と冷奴が注文されたという情報を渡し、作れと命令する。レシピ管理役は冷奴のレシピを取り出し、その通りに料理し返す。こんな感じ。こうしておくことで豆腐をいいものや安いものに変えたり、マーボー豆腐をメニューに加えたりということも簡単にできる。
だめな例は、命令役とレシピ管理役を置かず、冷奴係と湯豆腐係を置くこと。こうしてしまうと豆腐を変えようと思った時には全員を集めて通知しないといけないし、新しくマーボー係を入れても豆腐をどこから仕入れるかから教えないと(プログラミングしないと)いけなくなる。豆腐がどれかなどとなどにこだわらず、ただ渡された豆腐にレシピ管理役に言われた通り料理せよというのが一番上手な管理方法となる。

コメントは受け付けていません。

Categories

 

2009年1月
« 1月   2月 »
 1234
567891011
12131415161718
19202122232425
262728293031  

About

Author: tachibana

  • ちょっとしたことはTwitterに書いています。こっちはアプリの公開等の時に更新されます。
  • 最近はもっぱらJavaとObjective Cです。AS3は飽きました。
  • スクリプト言語ではPerlが好きでしたが最近はGAE/Jで何でもやってます。
  • Linuxは自宅サーバー建てるのがやっとのレベルです。前の会社で何日も徹夜してやったのはいい思い出です。
  • アプリへのご要望などご意見等ありましたらお気軽にご連絡下さい。

Alternative content here