すっかり寒くなってきて、というよりも、まだ紅葉がどうのとか、台風！！(~_~;)がどうのというまだまだ秋の頃って感じで、それでも暦ははや12月になってしまいました(@_@)2004年も三國志製作のうちにすぎようとしています……(^^;;
さて先日、ふたたびボーランド社からDelphi2005のお知らせがやってきました。プログラム製作ツールとしての機能強化の詳しい紹介が同封されています。たとえば、使いやすいように部品等のレイアウトを変更したりだとか、エラーがより早く発見されやすいようにしたりだとか、こないだ私が散々苦労した変数名の変更を自動でできるようにしたりだとか……んんん、ほ、ほしいっ☆o(^^o) (o^^o) (o^^)o ♪
…と、とはいうものの、あいかわらずの我がＶＡＩＯのメモリ＆ＣＰＵのパワー不足＆どういうわけかＱ＆Ａの内容は全部Win32はこの版ではどうなるかという話、といったところが、以前お話した懸念すべき内容とやはり一致しています(~_~;)
ところで、日経ソフトウェア2005年１月号がフリーの開発ツール特集をしていて、参考までに買ってみました。付録ＣＤにはフリーの.NET製作ツールまで載っているんですよね(^O^)こうなると、わざわざ.NETと統合されたDelphi2005にバージョンアップしなければならない理由が、製作機能強化というだけ、つまり、より便利にする、という感じにしかならないんです。
皆様もお気づきの通り、よいバージョンアップと悪いバージョンアップがあります(~_~;)よいバージョンアップは、思ってもみない便利な新機能の追加、従来機能の強化、高速省リソース化などなど、うわっ！いい！というやつです(^O^)まあ、高速化省リソース化（必要メモリが減ったり、保存すべき容量が減ったり）なんてのはまあほとんどないですね(T-T)プログラム製作の心得としてはよく言われるんですけども、実際のところ使わない機能増加のためにどんどんプログラムが肥大化しています。これが悪いバージョンアップですね(~_~;)まさに肥大化。使わない機能の追加、従来機能の複雑化、要高速ＣＰＵ要大空き容量といったところでしょうか。
その昔、ワード95で保存した文書ファイルは１文字だけなのに数百キロバイトもあって使い物にならなかったのが、最近のワードのそれでは非常に小さくなっています。これなんかはよいバージョンアップですけども、だんだん必要とするマシンスペックが巨大化してますし、ワープロソフトなのになぜこんなにインターネットと結びつくのかわからないくらいインターネットと結びついています。一慨に悪い、とはいいませんが、私には必要はありません(~_~;)WindowsにせよOfficeにせよ2000程度で十分ではないか、という感じが…(-_-)
Delphiにせよ、機能面ではどうやらバージョン６くらいでもう完成しているらしいですね。７なんてどうよくなったかどうかわからないくらい？(^^;;.NETとの結びつきは、どちらかというと新しいセールス手段のような気もしなくもない…？？とはいえ、ここまで書かないと買う買うほしほし☆欲求を抑えきれないのでした(^^;;;要はそういうことです(^^;;;おそらくいいバージョンなんだと思います。しかし、…よく言われるように、Delphiと.NETとＣ＃との融合のような新しいことをした最初のバージョンは注意すべき、ということもあります。
しかしまあ、機能強化としてプラグインの手法を使ったり、ブラッシュアップも既存のバージョンを活かす感じでできないもんなんでしょうかねえ…たいていはどかんとバージョンアップしてしまいます(~_~;)そうしないと売れないということもあるんでしょうけども、古いバージョンがもったいない気はします。とはいえ、開発が進み、きっとものすごく中身は変わっているんでしょうけど。買うときは、どかんとバージョンアップしたのを買ったりしますが(^^;;
さてさて、またも心を惑わすダイレクトメールのおかげで本題から外れました(^^;が、そうそう外れてもいません。現在三國志製作は２本目のコマンドを最初から最後までの通しを開通させました(^O^)そこで思ったのが、共通している感じの処理の多さと、プログラム量の多さ(~_~;)これをなんとかまとめたり縮めたり共通化したり、とにかく同じ処理は別のところでも繰り返し使いたい。
最初のコマンド、これは建設コマンドだったんですけども、これを頭の中で手順を考え、だいたいその通りになるように処理をつくり、最初から最後まで通して走らせて確かめてみる、大概こんな方法でいつもプログラムしています(^^;動かして試すと、文法エラー等で最初から止まる場合もあれば、途中でおかしな動きをしてエラーが出たり、エラーは出ないが思った通りの処理にならない、というこの３パターンくらいのエラーが発生します。まず最初からまともに動くことなんかないですね(^^;;これがDelphi2005では動かす前にエラーを知らせてくれるそうですが…ほ、ほし☆い…o(^o^)o♪
……っていやいや(^^;Aまずもって、思っていること、頭の中で考えている処理の流れを記憶に維持しつつ、それをプログラムに表現しつつ、さらにテストして動かしてみてエラーが出てデバッグしてみて、さらにさらに先に進む……と、かなり頭を使っている気がします(^^;;すぐ眠くなるわけです(^^;A
頭の中で考えている処理の流れ、これがもやもやうにゃうにゃだと、プログラムになんか表現できません。それをプログラムとは別に考えたりきちっとしたものにするのがこの日誌であったり、開発ノートであったりするんですが、こういうのをどうしよう？と種だけ頭に放り込んで、後は発酵するに任せるという方法も結構多用しています(^-^)どこで見たのか忘れましたが、そういう方法もいいようです。疑問や問題点だけ意識して、後は放っておくと、自然と頭の潜在意識が考えてくれるそうです。そうすると、しばらくして改めて考えると、ぽんっといいアイデアが浮かんだりするんですよね。実はこの日誌等では、当初はうーんと考えつつ書いていたんですけども、最近は放置した後、浮かんだアイデアを論理的に説明しようとしていることが多かったりします。その方がはっきりするんですよね。
もちろん、まず最初に何が問題なんだろう？とは考える必要があります。問題が何かわからなければ発酵する種も入れられませんからね。そういう意味でもこの日誌等を活用していたりします。おかげで、内政系に関しては、発酵もすれば新たな種もいっぱい出てきているんで、プログラム化もわりとスムーズに進むんですが、ほとんど検討していない、たとえば外交や人事や軍事なんかは、プログラム化しずらかったりします(~_~;)あらら、ほとんど検討していないなあ〜と今更ながら気づいた次第。そういえば問題点を検討することすらしていない……ですなあ(^^;;;
さて、頭の中のアイデアというかうにゃうにゃしたものと、プログラム化との橋渡しとして、こういった論理的に文章を置くのは効果的でもありややつらい面もあります。効果的というのは、ほとんどそのままプログラム化すればいい内容になることであり、つらい面というのは、うにゃうにゃしているんだから、文章にすらならないというところです。
プログラム化は非常に論理的で、具体的で、意味が明確でなければなりません。世の中には結構それが怪しいものもあるらしいですが(~_~;)少なくともプログラム化される目的部分が明確であればあるほど、プログラムも明確である、少なくとも結果の出来不出来は明確です。しかし、その目的、つまりアイデア部分がうにゃうにゃしていると、できたプログラムもうにゃうにゃ…というか、どうしていいのか検討もつきません(^^;;
それを明確にするのがこの日誌のような文章化することなのですけども、そもそもうにゃうにゃしているものを文章化しずらい面は多いと思います。文章は線的なため、思考の流れも線的です。アイデアに行き着くまで一本道なうえ、その一本道がまっすぐではなくあっちへ行ったりこっちへ行ったり、それでも一本道なのでアイデアにたどり着くまで非常に長い距離が必要だったりします。こう書いている私自身、この文章のゴールはなんとなくイメージできるものの、この今まさに書いている文章はゴールに近づいたり、離れたりしているようなイメージがあります…って、まさにこの文章自体があっちへ行ってますね(^^;
さて、そんなうにゃうにゃしているアイデアをより形に変えるために使われる方法として考えられるのは図表です。それもプレゼンテーションで使われるような論理的な図表ではなく、マッピングという、主題から思いつく内容をどんどん派生させて周辺に散らばらせる方法です。種をまいておけば、どんどんどんどん論理的に膨らむんですけども、私の場合、種をまいたところだと何も思い浮かばず、種が育って発酵まで行ってしまったら文章すらすっ飛ばしていきなりプログラム化したりして、今回の製作ではあまり使っていませんね。それでも中心となる概念はこの方法で思いついています(^-^)
そんなマッピングとは別に、フローチャートのような、要素と線で組み合わされたダイアグラムという図表があります。これでプログラムを描くのが最近の流行りのようです。ＵＭＬという方法基づく方法らしいですが…….NET同様なかなかうとくて(^^;;で、ようやく話がつながりました。コマンドごとの処理を共通化する方法として、図表で表現して認識するのにこれが使えないか？
先程の日経ソフトウェアにＵＭＬ図を作成できるソフトもありましたし、Delphi７にもありました。ただし前者は、Javaが対象で、後者付属のソフトは体験版でなんと2005年１月２日までしか使えない！( °O °;)いやあびっくり(--;)後１月ありません。まあ、Delphi７自体2002年のものなので仕方がない面もありますが、もともと英語版ということもあり、マニュアルもややうすいうえ、ややわかりづらい感じです……というか、どう使っていいのかわからない(*_*)時間切れも間近なため、これはあきらめざるを得ませんね。
Javaが対象の図表作成ソフトは、日本製でうって変わって使いやすいんですけども、いかんせんJavaではなかなか使いづらい(*_*)結局図表作成ソフトはあきらめて、手で描くことにしました……これが意外に難しい(~_~;)
いやはや、幹の部分は簡単です。武将を選んで、コマンドを選んで、対象を選んで、判定して、実行して後処理する、と、それだけです。ところがコマンドに応じて細かい違いをどう表現するかとなると、手で書いているとたちまちぐちゃぐちゃしてきます。まずもって要素が増えるとだんだん書くのが邪魔くさくなりますし、見通しもよくない。これだと共通化どころか細分化です。
しかしまあ、これでひとつわかったことがあります。紙に書いて書きにくいことは、多分ソフトを使っても書けないだろうな、ということです。一要素の多重化だとか、異なる図表の組み合わせだとか、いろいろ工夫しているようですけども、紙より便利で、紙よりわかりやすくならなければなりません。今のところ、まだまだという感じですね(~_~;)こういったソフトは、図表からすぐにプログラムの原形に変換できることを売りにしていますが、そのせいか表現方法がやはり固いのです。
そうやって処理の共通化ということを考えていくと、……、おっと、これはそういえば何度かお話したことのあるオブジェクト指向ではないですか(^^;どうやら図解や文章より前の、思考の問題なのかもしれません。昔恥ずかしながらオブジェクト志向と連呼している時期の日誌を参考にしつつ(^^;;;（恥ずかしいので直しました(^^;;;）けれども継承やら多態性やら多分オブジェクト指向の本来の部分はやっぱりあいかわらずよくわからないまま、けれどもこれを使えればもしかするともっと便利になるかもしれないなあ〜と思いつつ、ここからまた考え出してみましょう。
現在２つのコマンドの流れを作ったところ、さらにこれから新しく作り出す処理の部分の幹の部分の大部分は同じだと思うんですよね。共通化している部分があり、違う部分がある、と。まったく共通なら同じものを使えばよく、まったく違うならまったく違うようにしなければなりません。ところが一部違い、一部同じ、だと。
これまでの（いわゆる手続指向型の）方法なら、どのコマンド処理も共通部分にとりあえず流し、途中で分岐させる、という方法をとります。１つめの流れを作り、２つめの流れは１つめを修正して、同じ流れに乗るところには同じ流れに、途中で分岐させれるところは分岐させました。しかし、なんだかだんだん共通処理の部分が巨大化してきたんですよね(~_~;)まあ、今のところまだ大丈夫とはいうものの、まだ２つのコマンドしか実装していません。これを増やしていくとどんどんどんどん……きゃああぁぁ！(TдT)
これをオブジェクト指向なら、共通化しているものをクラスとしてひとまとめにしてできたクラスに対し、これを継承させた新しいクラスに個別な内容、だけ、を追加する、と。うむ、そうそううまくいくようには思えんが…軍師殿がそこまでおっしゃるならやってみようではないか(-_-)
オブジェクト指向ではとにかくクラスを作りまくります。Ｃ言語が関数の束なら、オブジェクト指向のJavaではクラスの山らしいですね。ってよく知りませんが(^^;ADelphiでは手続（プロシージャ）の山、という感じではあります。ここからオブジェクト指向には後一歩、らしいです。本当でしょうか…？
そのクラス。クラスにはどんどこ手続も関数も変数も詰め込むことができます。で、継承先にはそれにさらに追加する関数やら手続やら変数やらを詰め込めるようです。今回は、共通処理クラスを作っておいて、違うコマンドには継承した個別処理クラスを作ればよいんでしょうか？ただまあ、オブジェクト指向は、処理、を見るんでなく、データ、に着目しなきゃならんようです……データ？
ううむ、こう書いてますが、悲しいことにちゃんとわかってるかどうかよくわからんのですよね(^^;;あいかわらずオブジェクト指向もどきを見ているような気がします。今回またぞろこんな話が現れたのは、どうもこれは異常に邪魔臭いぞ、図表処理とかオブジェクト指向ならもうちょっと楽できるんではないか？と思い至ったからです。悩んだまま３本目のコマンドに進みづらいんですよね…(--;
さてさて、データ、です。これが、処理、に着目するのは簡単です。ユーザーのコマンドに応じて順番に処理していけばよいのですから。で、先程のような主な流れができる、と。コマンドごとにどんどかどんどか処理の流れを作っていけばよろしい。ところが同じような処理の流ればかりだと…嫌んになっちゃうっしょ？(--;)嫌んになっちゃったら、同じ部分を共通に、違う部分を分岐させればよい…という先程の話になります。いやあ、わかっている話なら何度でも簡単に書けます。わからないオブジェクト指向な話に流れないのでだんだん同じ話ばかりでくどくなってますね。ここは無理にでも、データ、に話を持っていかねば…
で、データ。今度こそ分析しますぞ(^^;;Aデータに着目とはいかに？ん、こら、者共逃げるな…！！…と。あるコマンドのデータとは、結局武将がどうするのか、ということです。ユーザーが武将に対して命令して、武将がなんだかかんだかやって、結果を出力する、と。こういうことになりますね。ユーザーが武将に対してする命令は、まあ、言ってみれば何であってもかまいません。そのため、ここで命令に着目すれば、武将がすること、つまり処理に着目することになります。今まではこれでした。
ではデータに着目すると？どうやらデータは武将らしい、という気がしてきました。オブジェクト自体がすること、という処理ではなく、客体、対象、だったりしますので、能力などのデータを持っていてかつ、それをいろいろ処理することになる、まさに武将ですな。プログラム製作に対し、コマンド処理でなく武将に着目することはどういうことにつながるか。ああ、長くなってきました。延長戦に入るか…？
逃げずに頑張ります(;^_^A命令を与えられた武将が行うべき行動に着目するんでなく、武将それ自体に着目してみましょう。その武将クラスは現実の武将をイメージしますが、プログラムに必要な装飾をほどこされたもの、「オブジェクト」です。武将そのものをプログラム化できません。
なんだかわけがわからない感じもしつつ、かつだんだん本質に切り込んでいる気もしてきました(^-^)私が思うに、オブジェクト指向は、言語に近い、表現の技法なんだと思います。水、という言葉が水を指すものの水そのものではないように（う、哲学っぽい(~_~;)）オブジェクト表現された水は水そのものではない、が、別のオブジェクト表現されたプールとの関係で、たまるという結果を返すというような……表現の技法のため、現実の人間の喉を潤すことはできませんが、それは言葉も同じことです。
表現の技法であるから、現実そのもののモデルとして、水、という言葉ですぐさま他との関係で（何か生じる）イメージがわくのと同じように、オブジェクトとしての水にはプログラマーが（必要な）いろいろイメージを付け加えて、これまた他のオブジェクトとの関係で（何か生じる）結果を与える、という表現をしていく。だから、水というオブジェクトには水をモデルにしつつも、他のオブジェクトとの関係で必要な部分だけモデル化すればよい、と。
なんだか抽象的になってきました(^^;私がここで水、といいました。今火事場であるならば、それは消火のための水ということですし、運動の後ならば、飲みたいための水、ということです。ここでは他の状況に応じて水という内容が異なっています。火事場であるのに、水、という言葉で、飲むための水や泳ぐための水を意味するはずはありません。国語の勉強であれば、ここは文脈を読む、というところです。それがプログラムだと、必要な内容を分析する、というところになります。
しかし、水、という言葉にはまさにいろいろな意味が含まれています。どの文脈でもそれぞれの文脈に応じた働きや内容や状況を表します。オブジェクト指向でよくわからないのは、じゃあ水というオブジェクトには、そういったいろいろな働きを表現＝実装せねばならないのか、と考えてしまうところのような気がします。そうではなく、プログラム上必要な、ほんとに必要な内容だけ表現できればよい、ということなのです。水だと三國志のゲームではなかなか使わないですが(^^;ばらばらの水道管をつなげて一定速度で流れる水をスタートからゴールまで流すという水道管ゲームなら、この水オブジェクトは、一定速度で、流れる、ということだけを表現できればいいのです。飲んだり、撒いたり、蒸発したり、冷やしたりすることは考えなくてよいのです。このゲームで、より遅く流れるオイルオブジェクトや、流れた水道管は固まってしまう溶けた鉄オブジェクトなんてものも、水オブジェクトから継承して作成できます。けれども、オイルオブジェクトは、ゲーム上必要がなければ燃えるという要素は考えなくてよいのです。継承された流れるという要素だけが必要なのです。
さらに、水オブジェクトだからといって、水そのものには何の関係もない、水の位置情報なんてものも水オブジェクトには含まれます。これは、ゲーム上必要だから必要なのであって、水そのものとはまったく関係ありません。けれどもこれが水オブジェクトに含まれていないと、この水オブジェクトはゲーム上非常に使いづらいものになります。また、速度という情報も、これまた水だから必須というわけでは全然ありません。それでもゲームでは必要な内容ですね。オブジェクト指向の分析で難しいのは、一見関係ないこれらの要素も含めてオブジェクトで一括りにしてしまうこともあるんだと思います。これも別々に考えることもできると思いますが、水道管ゲームでは水オブジェクトに含めるのが一番すっきりくるんだと思います。
結局、オブジェクトの対象となっている「もの」自体についてあまりに寄り添ってしまうと、プログラム上不要な要素にまどわされ、必要な要素を含められなくなってしまいます。これがオブジェクト指向をよりいっそうわからなくさせてしまってる原因のような気がします。オブジェクト指向のオブジェクトは、そのモデルとなった対象そのものを表現するのではない、だけでなく、単なるモデルだ、ということなのだと思います。まったく無関係だ位考えた方がよいのかもしれません。
よくオブジェクト指向の本では、対象分析として実際の「もの」そのものを対象に、それをモデルとしてオブジェクト化していきます。が、必ずしもオブジェクトは「もの」でなくてもよいのです。そういうプログラム上のまとまり、位に思っていた方がよいのかもしれません。
と、考えていくと、武将オブジェクトは武将そのものとしての武力などのデータだけでなく、コマンドの実行や判定や実行結果を含めて放り込むことができます。結局コマンドを実行するのは、武将なのです。コマンドの成否や実行中かどうかといったデータは、武将オブジェクトに持たせるのが一番しっくりくるのです。 なんだかできそうな気がしてきましたね〜(^-^)
これを、コマンドの実行、成否判定、結果処理といった順番ごとの処理として考えていくと、手続指向型プログラミングに逆戻りです(^^;;こういった内容を全部武将オブジェクトとして持たせるのです。この分析が正しく、ちゃんとプログラムとして成立すれば………すれば…………げげ、また作り直しじゃん！（￣□￣；）
とはいえ、なんとか新しい方法がまとまりそうです(^^;ここはもう少しほりさげて考えてみてまとめてみたいと思います(^^;;;
｜index｜
このページへのリンクはフリーです。