秋ってば、だんだん深くなって、木々も色づき、少しずつ厚着に変わっていくものだと思いきや、一気に寒くなりましたね〜{{(>_<)}}ちょっと寒すぎて、さっそくもうこたつを出してしまいました(^^;まあ、もう確かに10月も後半とはいえ、天気もあいかわらずはっきりしないまま、秋を飛び越えもう冬に突入というところでしょうか。寒いなら寒い方がい い！と言いつつ、やっぱり寒いと寒い！(x_x)
さて、デザインパターンをもとにUI系を整備して、コピペであっと言う間に似たようなリスト表示−コマンド表示部分を作ってしまいました(^o^)ただ、コピペでいい、と言いつつ、使ったデザインパターンは以前お話したAbstractFactoryというパターンです。これで表示タイプごとにオブジェクトを作るので、ものすごい勢いでオブジェクトの原型＝クラスが増えていきます。あまりに増えすぎて、今度は見通しが悪くなりそうです(~_~;)
かといって、いろんな操作をひとつの「表示」オブジェクトに詰め込むと、今度はそのごった煮オブジェクト自体の見通しが悪くなるんでしょう。いずれにせよ量が多いということは、それだけで見通しが悪くなるものです。それでも、クラス＝オブジェクトの数量による分割は、ぱっと見ではわかりにくいながら、エラーが出たときにエラーの特定が容易です。なんといっても、小さなオブジェクトの連携プレイですから、数が多くともエラーにかかわりになりそうな部分は特定されやすいのです。また、多すぎて見通しが悪ければ、プログラムをまとめる単位であるユニットを分ければ終わりです。
と、いいつつ、なかなかそう割り切れないところが新しい方法というものです(^^;;ＵＩ操作系ができれば、今度は実際のコマンド内容を実装していくことになります。今のところ、マウスの右クリックメニューでコマンドを与えようというＵＩになってます。しかし、いろいろなコマンドを組み合わせたいために、コマンドの内容を最初から決めておかず、プログラム中で書いていくことにしています。常に同じコマンド一覧で、押してから、できません、という結果を返すより、できないなら最初から選択できないようにしといた方が親切でしょ(^^;
ただ、その作りの場合、ユーザーがどのコマンドを選んだかについては、たとえば移動なら「移動」という選んだ部分の文字列しか利用できないんですね。もちろん、コマンドごとにその次に進むべき手順を指示することはできます。けれどもそうすると、オブジェクト指向プログラムのはずが、単に順を追って進むだけの手続指向型プログラムと変わらなくなります。ここはデザインパターンを使ってまとめなければ、同じような、けど状況によってちょっとだけ違う内容のものが増えていきそうな予感がします…(~_~;)
あてはめるべきデザインパターンは、先程のAbstractFactoryだったり、FactoryMethodだったりするのかな、という気はします。しかし、それでいいかどうか確証が持てません(-_-;)何が問題かというと、まず、ＵＩの所でも経験したように、状況ごとにオブジェクト＝クラスの数がものすごく増えるということです。ついでに、たとえば同じ「移動」でも、軍団の移動と武将の移動は異なります。それでも、とりあえずユーザーが選択したコマンドということでわかることは、「移動」という文字情報だけです。これではどちらの移動かがただちには判別できません。
これについては、先程の軍団の移動にせよ、武将の移動にせよ、移動する先はおそらく城で一致するので、位置情報に関わる情報の保持や操作方法を共通化させていれば、軍団だろうが武将だろうが、移動コマンドの結果を共通化することができます。ここはオブジェクト指向の本領発揮で、継承を使っていれば簡単にできます。移動できるものをコマという名称のオブジェクトとして作り、軍団や武将というオブジェクトはそれを継承します。移動はコマの操作内容ということにしておけば、軍団や武将はコマの移動操作をそのまま利用できる、というものです。
そう考えていくと、移動などの操作自体のプログラムは、武将や軍団などのオブジェクト内部にあることの方が自然な気がします。とはいえ、移動だけでなく訓練や徴兵などの細かいコマンドをどんどこ武将や軍団オブジェクトに詰め込めば、あっという間に肥大化した巨大オブジェクトになってしまいます。それはそれで問題ですね。というより、それが問題なのでデザインパターンを利用しようと思ったんでしたっけ？(^^;
ただ、なんだか煮えきらない気分になるのは、オブジェクト指向におけるオブジェクトが、本来名詞、まさにものを対象として、もののうふるまいを操作としてプログラムするところからスタートしているので、移動とか徴兵とか、こういったコマンド自体は、武将や軍団というオブジェクトのふるまいであると考えるべきなのです。たとえ巨大肥大オブジェクトになろうとも…(ToT)
逆に、デザインパターンからのアプローチでは、巨大オブジェクトを解体し、小型オブジェクトのデザインパターン化された組み合わせで表現する、というものです。名詞の動詞という考え方ではなく、やりたいことにデザインパターンのパターンをあてはめていくことです。たとえ無理矢理はめている、といわれようとも、型にはめてこそ自我流から美しいふるまいになるのです…(^^;
大分混乱してきたので、もうちょっとよく何をしたいか考えてみましょう。まず、武将などに命令を与えることをオブジェクト化したい、と。それから移動などのように、移動する者と移動する先がある場合は、改めて移動する先を選択する操作が必要なので、武将などのオブジェクトの内部に持たせず、切り離して考えたい、と。コマンド内容はそれこそコマンドごとに違う内容でありながら、基本的に同じコマンドは同じコマンドとして変化しない、と。これはなんだかよくわからないかもしれませんが、移動というコマンドに複数の意味をもたせないということです。つまり、移動なら、味方の城への移動であって、敵の城に潜入するための移動は別のコマンドとして取り扱うべき、ということです。そうしないと、移動コマンドのはじめに条件分岐が生じて、複雑になってしまうからです。
この条件分岐、Javaならswitch、Delphiならcaseが出るならば、デザインパターンでなんらかの処置が必要なポイントになっています。流動性があるならば、操作を抽象化したインターフェースと、具体化したオブジェクトを分けるべきというのです。同じなのだけどまったく同じでない、違うというには同じところがありすぎる、というのが条件分岐を必要とさせるところで、その、違う部分が流動性です。たとえば、同じ移動でも、味方の城に移動するのと、敵の城に潜入する移動とでは、移動できる先が違う、というのは、流動性です。
それならそれで、移動という大きいインターフェースと、軍団の移動、武将の移動、軍団の戦争移動、武将の潜入移動など、細かい具体的な移動という形で分けれます。あれ、これだと移動という単位ですね。なんだ、これでよかったんじゃあないですか(^^;Aコマンドという大枠で考えていたから共通のインターフェースが出てこなくて難しくなったのかもしれません。むむ…！
となると、やっぱり移動や徴兵というふるまいを武将オブジェクトが持つという集約形態であっさりコマンド問題が解決します。あれれ、何を悩んでいたんだろう……(^^;A現時点では、細かい細かいコマンド体系を取らず、できるだけ太守や軍団長が勝手に、いや、自力であれこれしていくことを考えていますので、それほどユーザーコマンド量が多くならないとはいえ、将来の追加や変更などは簡単にできるようにしておきたい、とするならば、コマンドごとに手順を作ったりだとか、コマンドごとに1、２、３と番号をふってcaseで分岐したりだとか、直感的でない方法は取りたくなかったんですよね。
オブジェクト指向を採用する前は、そもそもコマンドの山と、コマンドを１つづつ実装していくというプログラム手法でした。似たような処理をサブルーチンとして外に出していくわけですが、必ずしも似ているからといってまったく同じでなく、最初に作ったサブルーチンの仕様に、後の処理を無理やり合わせたりだとか、なかなかわかりにくいことになっていたのです。また、サブルーチン自体の名称もある意味恣意的で、サブルーチン名称を忘れて探したりだとかをしていました(i_i)かといって、サブルーチンを集合させて数字で分岐するようなことになると、今度は数字に意味があるわけでもないので、何がどうなのかそこばっかり見に行ったりする、という、苦労をしてきたわけです(T-T)また、数字に意味を持たせても、ちょっと違うだけのオブジェクトを追加でつくると、あっと言う間に数字の整合性が崩れます。それがオブジェクト指向なら、オブジェクト単位なので、どこにどういうふるまいを持たせたか、ということが比較的わかりやすいのです。よさは、徹底的に利用しなければ！
やっぱりわかりやすい、変更しやすいというのは大事ですね。いつだって仕様はすぐ変更したくなります(^^;A自分で作っているときでさえそうなんだから、人に作ってもらうときなんてもっとそうでしょうね。デザインパターンの本質は再利用しやすいということです。いくら仕様を変更しようとも、影響をできるだけ抑えることができるという発想で作られたものは、あっさり作りやすくなります。あっさり作って、後で変えてもいいわけです。ただ、デザインパターンに沿っていなければ、結局全部消して作りなおすことになるので、ここは理解して、きっちり作らねばなりません。まだ、これからです(^-^)
｜index｜
このページへのリンクはフリーです。