ありゃあ、むしむしはしているんですけど、雨が降りませんね〜(~_~;)どばーっと降ってもらわないと水不足が心配な今日この頃、暑いけど冷房は寒すぎるし、朝は寒くなったり、体調を崩しやすい季節ですよねえ〜(x_x)
さて。どういう三國志がよいかいろいろ検討していましたが、再びプログラムに戻ろうとオブジェクト図を書き換えようとし始めました。ところが、あいもかわらず城とか武将とかのオブジェクトしか書けません。これでは今までとあまり変わらないが、これでプログラムができるんかいな…とやや不安になったところ、あるオブジェクトモデルについて書かれた本を読んでびっくりしました。
会社の入出荷管理システムということで、入荷クラス、出荷クラス、請求クラス、支払クラスというクラス分けになっているのです。これで正しいのかもしれませんし、間違っているのかもしれません。私が気になったのは、入荷や支払いなんてモノじゃないやん！ということです(*_*)
オブジェクト指向についてはなんどかお話してきました。ここでおさらいすると、オブジェクトはモノです………と書くと、先程のモデルと真っ向対立することになることがお分かりいただけるでしょうか(^^;グーグルなんかでオブジェクト指向と検索すると、いろいろ出てきますし、本屋さんでもオブジェクト指向の本は結構売られています。もっとも去年から今年にかけて、いっぱいオブジェクト指向の本が売られていたり、新刊が出たりしているのに、最近は非常に少ない印象がありますね〜(~_~;)
それはともかく(^^;オブジェクト指向は、これまで手続き、処理の流れを順序立てて動かしていたプログラムに対し、オブジェクトという固まりを単位に、そのオブジェクト間のメッセージのやりとりで動かすプログラム方法（だけではないようですが、とりあえず）です。ところが、オブジェクトはモノです、という説明も多く聞かれます。オブジェクト指向に対する手続き指向は昔ながらの方法で、これをオブジェクト指向に変えてプログラムするのは、これまで社会主義だったのが民主主義になるくらい思考の転換を必要とします(^^;;手続き指向の長かった私もまだ本当にオブジェクト指向ができてるかどうかよくわかりません(--;)
特に理解を困難にしているらしい、というのが、いろいろなところで語られる、先程のオブジェクトはモノ、という定義です。突然リンゴやイヌの話が出てきて、リンゴは植物、イヌは動物…と、継承の話に進むのがよくあるパターンです。こんな説明でわけがわからなくなった方で、きちんと勉強したい方は、『憂鬱なプログラマのためのオブジェクト指向開発講座』（Tucker!著、翔泳社、3200円＋税）をご講読ください(^-^)これだけでとりあえずばっちりです。やや古い本なので、大きな書店で見つけたら即ゲットです(^O^)
本格的オブジェクト指向技術者を目指す方はそれで十分といえますが、それ以外の方については私がつたないご説明を(^^;;;オブジェクトは確かにモノですが、物と考えると入荷とかは物ではないのでおかしなことになります。さらに、やっぱりモノ、ですらありませんよね。手続き指向で重要なのは動作、動詞なのに対し、オブジェクト指向で重要なのはモノ、いや、モノを含む名詞である、ということからすると、入荷はどちらにより近いのか。入荷、は動詞的でもあり、名詞的でもあります。入荷する、なら動詞ですし、入荷物、なら名詞です。オブジェクトはモノ、という観念に逆にとらわれているからこそ、あいまいともいえる入荷クラスに、ん？と思ったのかもしれません。名詞としての何か、と考えれば、動名詞だって特に問題はありません。しかし、モノじゃないぞ……！！モノにこだわっているのが実は私自身だからか？
手続き指向と並列して説明するとまたわけがわからなくなりつつなるものの、やっぱりこの比較は大事なので私の勉強のためにもここでもう一度お話することにしましょう(^^;;まず、プログラムという言葉からして、手続き指向的です。動きの連続、という意味ですからね。これやって、あれやって、それやって、終わり、という感じです。つまり、命令の組み合わせです。大昔ＢＡＳＩＣ（ＶＢではなく）という言語を使っていたとき、
10 PRINT "BAKA!"
20 GOTO 10
なんてプログラムを書いたことがあります(^^;;これは、表示せよ、"BAKA!"、移動せよ、10行、ということで、命令があって対象があります。昔懐かしい？英文法のＳＶＯで言えば、ＶＯという序列になっています。Ｓは暗黙のうえにコンピュータですが、プログラム自体はＶＯ、つまり命令文なのです。
で、手続き指向型プログラム言語では、こういう、命令文が延々続きます。延々です。最初から最後まで、ずーーーっと命令しっぱなしです。ちょっとは自分で考えろという気になりますが、コンピュータは命令に沿ってのみずーーーっと動きます。そしてPRINTをPRIMTなんてスペルミスなんかすると、syntax errorというエラーが出て止まります。エラーを出さなかった場合、終わりという命令や、命令がなくなると終わります。いずれにせよ、命令にのみ従うのが手続き指向型プログラムであり、コンピュータです。間違った命令を出すとエラーが出るか、意図しない結果になるか、いずれにせよ形式的にはその（間違った）命令に従うのです。
ところで、いくら命令することが好きな人であっても、命令しなきゃ動かない部下を持つとだんだん腹がたったりするかもしれません(^^;手続き指向型プログラムで動くコンピュータはまさに命令しなきゃ動かない部下であり、プログラマが延々命令しっぱなすことになります。それこそずーーーっと命令するもんですから、途中で命令間の矛盾が出たり、同じ命令なのに違う場面なので同じ命令を繰り返さなければならないこともあります。だんだん邪魔くさくなるわけですね。けれども、あらゆる動作すべてにおいて自分の指示を（誤りを含めて）寸分違わず実行するわけですから、それはそれですべてを支配したい人にとっては楽しいおもちゃかもしれません(^^;;どっかで聞いたような話ですが、そういう思考で作られたゲームは、どんな武将であれ、とにかく一挙手一投足にわたり命令を待ち、命令どおりにしなきゃイライラするたぐいのものができあがったりすることが考えられます(~_~;)
さて、そういう世界が当然であるという思考では、命令＝動作がメインです。こうしてああして、けど、条件によってはそうして……という動きの流れが大事であって、すべてが動きによって表現されます。さて、これに対してオブジェクト指向。今思いつきましたが、このオブジェクト、を、イヌやらリンゴやらと考えると、やっぱりよくわからないことになります。というのは、オブジェクト指向だってプログラムであって、動かなきゃ意味がないのです。まだイヌならましです。リンゴなんて、、、それだけで動きますか？というより、リンゴオブジェクトにどういうプログラム上の意味があるのかが問題です。そこで無理やりにでもオブジェクト指向でリンゴを表現すると、妙なことになります。
いきなりですが、オブジェクトには、属性と操作が含まれます。データと命令が含まれるというオブジェクトの重要な内容ですが、詳細はとりあえずおいておきまして、リンゴオブジェクトには皮を剥くという操作が含まれるとします。リンゴオブジェクト自体に皮を剥くという操作が含まれるのです。妙な感じだと思いませんか？(~_~;)
もひとつ、リンゴを食べると栄養が10ポイント（！）もらえるとします。食べるという操作が、これまたリンゴオブジェクト自体に含まれるのです。さて、オブジェクト指向でプログラムを組むとして、イヌがリンゴを食べてパワーアップするという場面があるとします。現実世界でイヌがリンゴを食べるかどうかは別として(^^;;、イヌオブジェクトにも食べるという操作があります。こちらはイヌを食べる(x_x)のではなく、イヌが食べるという操作です。
さて、イヌオブジェクトは食べ物であるリンゴオブジェクトを見つけ、食べるとします。イヌオブジェクトは食べますというメッセージをリンゴオブジェクトに投げます。で、リンゴオブジェクトが食べ（られ）るという操作を実行します。これにより、食べるイヌオブジェクトに栄養10ポイントを与えるメッセージを投げ、自身を消滅させます。食べたイヌオブジェクトには栄養10ポイントというメッセージが与えられます。
同じように、ヒトオブジェクトが皮を剥く、というメッセージをリンゴオブジェクトに投げると、リンゴオブジェクト側で皮を剥くことになります。リンゴオブジェクトが自分自身の皮を剥くということなのです。妙な雰囲気ですね〜(~_~;)ヒトオブジェクトが皮剥きメッセージを投げるとして、ヒトオブジェクトの持つ皮剥き能力属性数値を一緒に投げると、リンゴオブジェクト側で、きれいに剥けた、とか、皮も実も一緒に剥けたとか、表示したりするわけです。ヒト側でどうこうするわけでなく、対象であるリンゴ側で動かすわけです。これをヒト側でどうこうすると、手続き指向型になり、リンゴ側でどうこうするとオブジェクト指向になります。オブジェクト指向がより常識的と言われ、子どもでも理解できると言われますが、さもありなん、かえって子どもにとって理解でき、子どもにとってより常識的な発想という気がします。
どういうことか。大人とは、なんでもできる人です。なんでもできるとは、自分が、できる、ということです。だからこそ、リンゴの皮が剥けるんでなく、リンゴの皮を剥くんです。リンゴが自分で剥けるんでなく、リンゴを剥くんです。だからこそ動作のほとんどを自分がするものとして持ちます。あらゆることをし、できることなんです。まさに手続き指向型ですね。リンゴかミカンかは、栄養ポイントや見た目の違いだけであって、剥くのはあくまで自分、ヒトです。
で、だからこそヒトが剥き、剥いた結果を自分、ヒト側で持たないといけないことになります。実はこれはこれで妙な雰囲気です。リンゴやミカンだけでなく、ビワや卵、あらゆるものについてヒト側の動作で剥いた結果どうなるかを持っていないといけないのです。ヒトとビワはまったく別物にもかかわらず、ヒトオブジェクトが自分自身でビワやらリンゴやらの剥いた結果も持たないといけない。妙ですよね(~_~;)ところが手続き指向型に影響されたオブジェクト指向のプログラムはこうなりやすいのです。ヒトオブジェクトがやたらと巨大で、リンゴやミカンオブジェクトはデータだけだったりします。
もちろん手続き指向型言語だと、ヒトという固まりでプログラムは組まれませんが、剥く、リンゴ、剥く、ミカン、剥く、ビワ、という動作が条件により分岐されたりして羅列されます。新たに何かを剥くとすると、そういう動作を追加して羅列することになります。その発想が、巨大ヒトオブジェクトの中身ですね。これが正しいオブジェクト指向思考では、逆に、ヒトオブジェクトは、剥く、というメッセージを送るだけで、剥かれる方に、剥かれた結果どうなるかという内容が持たれます。もちろん剥く、というメッセージが送られてから実行されるわけですが、剥くべき対象が自分自身の皮を剥く操作を持つ、つまり単独で見ると勝手に自身で自身を剥くように思えます。ここが妙な印象を与えて手続き指向に影響された巨大ヒトオブジェクトを作ってしまう原因でしょうか。
なお、子どもの方が簡単にわかる、というのは、子どもはなんでも自分でできるわけではなく、大人にしてもらったりする結果、リンゴ自身が勝手に剥けた、というイメージを持ちやすい、ということなのです。魔法みたいな感じですね。逆に大人は、なんでも自分でしなきゃ、と思うがゆえに、リンゴが自分で剥けた、というイメージは持ちづらいのでしょう。
こう考えていくと、やはりオブジェクト指向は一種の技法、思考法であって、それをオブジェクトを単純にモノととらえると、モノが自分で勝手に剥けるわけがなく、モノオブジェクト自身に剥く、という操作を付け加えづらくなります。ところが、モノ自身に剥くという操作を付け加える、そういう技法なんです。だから、普通のその辺にあるモノや動物などをイメージするとおかしな世界になります。もちろんイヌとヒトとで、調教シミュレーションを作ればきちんとオブジェクト指向に沿ったプログラムは作れそうです。ヒトが伏せ、というメッセージを送って、わんワンと吠えるか、伏せるかは、イヌ側で持つ操作と結果なのです。
そうやって考えていくと、他と独立した操作や属性を持つ内容であれば、あくまでモノにこだわらなくともいいとも思えてきます。どういうことかというと、たとえば入荷オブジェクトは、入荷表というモノオブジェクトとして、紙とか帳票をイメージしなくとも、いや、実際の紙とかをイメージするとプログラム作成を阻害することになるので、モノにこだわらずともそのままでよいといえるのです。というのは、入荷表オブジェクトとすると、入荷日を書く、というメッセージに対してする操作が、入荷表自身が紙に書くイメージになって、プログラマに妙な印象を与えるからです。これを入荷オブジェクトとすると、抽象化されていて表やら紙やらをイメージしないため、書くというメッセージに対し、自分自身に書き込む操作を作り込むことがイメージとして、まだ、容易になるからです。
そうこう考えていくと、やはりオブジェクトを具体的なモノととらえるより、操作と属性を持つ独立したひとかたまりと考えた方がよくなります。あくまでモノでなければならない、とこだわると、今度は適切なオブジェクトは見つけられなくなりますし、継承汎化というオブジェクト指向の便利な機能が使いづらくなります。オブジェクト指向は具体化方向にも抽象化方向にも進めるべき内容を持っていますので、モノにこだわっていては、当然抽象化できなくなります。
ここで一気に三國志の話に戻ると、武将はオブジェクト候補として十分成り立ちますが、太守や君主という身分はどうか、ということがありました。モノ、ではありませんが、オブジェクトとして十分考えられます。けれども、武将オブジェクトとは別の、太守オブジェクトが何の意味があるのか、結局武将オブジェクトがないと意味がないんだから、武将オブジェクトに属性として持たせればいいんじゃないかとか考えていました。
しかし、太守としてできること、君主としてできることは違います。もしそういういわば身分オブジェクトを持たなければ、君主としての操作、太守としての操作、在野としての操作はすべて武将オブジェクトが持っていないといけません。そして武将オブジェクト自身の身分属性によって、何ができるかということが変わります。それだと、ひとつひとりの武将オブジェクトが巨大になりすぎます。ところが、別に身分オブジェクトを作れば、モノ、ではありませんが、身分を持つということであって、また、それぞれできることが違うこともありますから、プログラムの作りが非常に楽になりそうです。けども、モノ、じゃない。
この葛藤が、とりあえず、今回の自分自身の説明で、解消されたような、気がします(^-^)結局、モノだけなんじゃなくて、概念だろうが動名詞だろうが、単独でひとかたまりであれば、それで十分なのです。うーむ、奥が深い(^^;;;
｜index｜
このページへのリンクはフリーです。