Builder パターン試行 (1)
2008/09/22 23:35 - デザインパターン
今さら言うまでもないことですが、Shape と Sprite（およびそのサブクラスである MovieClip）はプロパティとして Graphics クラスを利用できるので、円や矩形といった抽象図形を簡便な手段で自らに描画することができる表示オブジェクトです。
ワタクシそのような図形を割と良く使う方なので、いちいち beginFill や lineStyle なんぞを記述せずに、もちっと楽チンに図形を描画できぬもんだろうか、と常々考えておりました。
で、SimpleDrawn などというクラスをでっちあげたこともあったんですが、このクラスは、描かれる図形のサイズや塗りのプロパティ、線のプロパティといった図形の必要情報を、コンストラクタで全部入力しなければならないというかなり強引な設計をしてしまいました。
しかも塗りと線のプロパティについては Object で指定するなんて方法とっちゃったものだから、作った本人なのにいちいちクラスファイルを参照しないと、どういう指定をすれば良かったのか思い出せないというアタマ悪過ぎな状態に陥ってしまったわけです。
でもさー、言い訳させてもらうけどさー、基本的にはオレ様の設計ミスなんだろうけど、塗りはあるけど線はない、とか、線はないけど塗りはある、とか、線も塗りも両方必要、とか、状況々々で引数の組み合わせが複雑になるのも混乱をもたらす原因だと思うんだよねー。
で、デザインパターンの本を読んでたら、そのようなシチュエーションを解決するために考案されたとおぼしきパターンに行き当たりました。
その名は Builder パターン。
なんかこのパターンを学習すればこの問題を突破できそうなので、いろいろと試してみたいと思います。
メインの参考書は以下の二冊。
Builder パターンのコード記述に入る前にちょっと回り道して、Java の学習書をいくつか読んで私が悟りを得た話なぞ、ご紹介させていただきとう存じます。
えー、わたくしクラスの作成という行為を少し堅っ苦しく考えすぎていたようです。
ドキュメントクラス以外のクラスは、ある程度の汎用性を持ち、何度も何度も使い回すことができ、最終的にはライブラリに登録できるくらいチューンナップをしなければ、独立したクラスとして作成してはいけないものだと考えていました。
ところが Java の学習書を読んでいると、しばしば、以下のような汎用性の欠片もないコードが「クラス」として紹介されているのに出くわします。
Class MyClass {
String getName() {
return "Suzuki";
}
}
Class MyClass2 {
String getName() {
return "Tanaka";
}
}
「Javaデザインパターン徹底攻略」Decorator パターン より
最初にこんな極限状況なコードを見たときはビックリたまげましたよ。
普通さー引数で文字列指定してそれを return するじゃん？ とか、いくらクラスが「データ」と「手続き」の集合体とは言え、保持するデータがここまでつぶしが効かなくて良いの？ とか、そう考えたものです。
しかしそういったコード群に何度も何度も遭遇しているうちにやっと思い至りましたよ。
ああ、そうか。クラスって使い捨ててもいいんだ、ということに。
そんなわけで、これから始まる「私の Builder パターン試行」では、その場しのぎのクラスが頻出することになる予定です。
