K.Maebashi's BBS

大変な長文失礼します 興味深く読ませていただきました。 世の中の多くの解説は 「クラスとインスタンス、そして継承。及びパッケージ化」があればオブジェクト指向である。それがオブジェクト指向の本質である・・・かのような誤った物が多いです。 クラスや継承、ブラックボックス化は、たしかにオブジェクト指向の重要な構成要素になる「事がある」かもしれませんし、便利な物かもしれませんが、それがすべてではありません。 現在存在するオブジェクト指向言語と呼ばれる物もそういった意味では不十分な物ばかりです。 そのような中で、前橋さんのＨＰの解説はとてもすばらしい物と思いました。 ただ、「なぜわからなくなってしまうか」のページの説明で 「オブジェクト指向をわかりにくいものにしている最大の要因として、「メッセージ」という言葉が挙げられます。」 とあります。 もちろん、これは「現在存在するオブジェクト指向と呼ばれる言語では、実質関数呼び出しなのだからわかりずらい」と言われているのだと思います。 しかし、オブジェクト指向の世界では「メッセージは非常に重要な要素」ですから、この表現では、「オブジェクト指向の世界ではメッセージは重要でない」と誤解されてしまうおそれがあります。 あと、 「カプセル化とは、「実装詳細の隠蔽」のことです。外部に対しては必要最低限のインターフェースのみを公開し、それ以外は隠蔽することで、実装の変更を可能にしたり、そのモジュールを他でも使いまわすことを可能にする、という概念です。」 と有りますが、これは誤りです。 「実装詳細の隠蔽」は、確かに良い事ですし重要ですが、カプセル化の本質は「メッセージのやりとりを行う単位を作成する」ことです。そして、これがオブジェクト指向の根本です。 オセロの例がありますが、「石を置く」「置けるかチェックする」「盤面を初期化する」「マスの状態を返す」の関数をサンプルとしてありますが、これでは不十分です。 何が足りないかというと、「マスそのもののオブジェクト」です。 ８ｘ８＝６４のマスすべてをオブジェクトとする必要があります。 すると、「え？８ｘ８の配列で良いでしょう！？」と思われるかもしれません。 それでは、次のような話を持ちかけられたらどうしますか？ 「オセロゲームの新しいルールを作ったので、それを反映してください。そのルールとは、４隅が無い物です」 実際、４隅が無いオセロなんてつまらない物かもしれませんが、まあ、例と言う事で・・。 このような話が持ちかけられたら、残念ながら前橋さんのサンプルでは大きなプログラム修正が必要になってきます。 たとえば、盤の初期化。 真ん中の４石以外はすべてクリアすると思いますが、おそらくＣ言語的に書くと for (y = 0; y < 8; y++) for (x = 0; x < 8; y++) ban(y,x) = 0 みたいに書くのだと思いますが、これでは、この処理を大きく変更しなければ成りませんね。 何しろ４隅が無いのですから。（まあ、「４隅の分データを無視すれば良いのでは」とか言う話は置いて置いてください。） 石が置けるかチェックする処理なども同じです。 本来のオブジェクト指向の考えでは、たとえば盤のマス一つ一つをオブジェクトにします。 そして、それらのマスに「あなた（たち）の中身をクリア（石がない状態にする）しなさい！」と「メッセージ」を送ればよい事になります。 そう、８ｘ８－４＝６０のマスすべてにメッセージを送るのです。 「結局６０のマスに送るとき、ループ処理するのでは？」と思われるかもしれませんが、それは、現在のオブジェクト指向言語の不備の問題であり、本来のオブジェクト指向の考えでは、６０のオブジェクトに大号令すればよい事になります。 たとえば、　　masu(all): message (CLR)　みたいに。 もちろんこのような例で書ける言語はありません。私の勝手な文法です。 ６０人いる保育所の子供全員に「みんなー！クリアしなさい！」と叫ぶ先生のようです。 この方法だと、盤が８ｘ８だろうが、４隅が欠けていようとも、６ｘ１０のマスであろうが、コーディングを変える必要はなくなります。６０人の子供たちは、必死に自分のマスをクリアする事に専念します。 盤の形の変更はマスの初期配置処理（インスタンス生成）さえ変えればよい事になります。 「石を置けるかどうかチェックする」ルーチンも同じです。 ６０のオブジェクトたちは、互いにメッセージをやりとりしあい、石をひっくり返す事ができるか確かめて答えを返す事になります。 たとえば、「マスに石が置けるかチェックする」は、自分の８方の隣のマスに問いかけます。「今、僕のマスに白を置こうとしているけど、君のところは黒かい？そして、盤が切れるまでの間に、白有るかい？」「僕のところは黒だけど、隣については聞いてみるね」などなど・・・。 この方法だと、たとえ、隣に突然穴があいていたとしても関係有りません。盤の形が変わっても関係有りません。オブジェクト同士がメッセージのやりとりで処理しますから。（もっと根本のルール変更が有ればこのオブジェクトも修正が必要になりますが、修正はこのオブジェクトのみになります。） とても回りくどい、面倒な方法に思われますが、実際のコーディングで表せば、一般的なやり方と量はさほど変わりません。 「’石を置く’、’置けるかチェックする’、’盤面を初期化する’、’マスの状態を返す’の処理を一つにまとめてオブジェクトにしただけで、根本は変わらないのでは？」という声が聞こえてきそうですが、違います。 「マス」というオブジェクト（部品）が作成されています。この部品を利用して、オセロに似た別のゲームができるかもしれません。たとえば、時間とともに盤に穴があくオセロとか・・・。 その例ですと、「時間とともに盤に穴をあける」という処理を追加すればよいだけですが、従来のやり方では、おそらく全面書き直しでしょう。 すると、「結局は穴があくのを前提にマスのオブジェクトを記述しなければならないのでは？」という声が聞こえてきそうです。 たしかにそうです。また、白、黒の他に「赤」という石が追加になったら記述を追加する必要があります。 しかし、その追加はオブジェクト（クラス）についてすればよい事になります。その際は、それこそ「継承」を使って派生クラスを作り、赤石の処理のみを追加すればよいかもしれません。 これで、部品の組み合わせにより「白黒６４マスの昔ながらのオセロ」「４隅のないオセロ」「白黒赤石のある６４マスのオセロ」「時間とともに穴のあくオセロ」など、様々なバリエーションを作る事ができます。 しかし、従来のコーディング技術では、おそらくバリエーションの数だけプログラムを全面書き直す事になるでしょう。もしくは、ｉｆ文の嵐になるでしょう。 今度は、「じゃあ、そのマスを関数やサブルーチンにすれば良いのでは？」と疑問があがるかもしれません。 はい、それでかまいません。オブジェクト指向の「本質」は、クラスやインスタンス、継承やブラックボックス化することではなく、「オブジェクト単位で扱うことの考え方」ですので。 場合によっては、昔ながらのBasicでも、その本質は記述する事はできます。（読みづらいでしょうが） オブジェクト指向におけるオブジェクトとメッセージの重要性、わかっていただけたでしょうか？ なお、この意見は私の個人的な意見ではありません。２０年以上オブジェクト指向に携わってきた経験により他の人からのアドバイス、文献から得た物であります。 ところで、私の文章の中には 「本来のオブジェクト指向の考え」という言葉があります。 「本来の・・・って、誰がいつ考えた物が本来なんだ？」とつっこまれそうですね・・・ただ、現在主流のＯＯＰでは、生産性の向上なんてあり得ない気がするのは確かです。 蛇足ですが、２０年以上前から有るＧＰＳＳ等のシミュレーション言語では、オブジェクトを複数生成してメッセージをやりとりしながら、すべてのオブジェクトが（論理的に）同時進行で処理を行います。 内部的に関数コールでしょ！？って・・・いえ違います。

　はじめまして。ご意見ありがとうございます。 >しかし、オブジェクト指向の世界では「メッセージは非常に重要な要素」ですから、 >この表現では、「オブジェクト指向の世界ではメッセージは重要でない」と >誤解されてしまうおそれがあります。 　何があればオブジェクト指向か、という点についてはいろいろ議論があって、 http://www.shiro.dreamhost.com/scheme/trans/reesoo-j.html | オブジェクト指向というものが動く標的であるため、オブジェクト指向の熱心な | 支持者はこのメニューのうちの適当なサブセットを気まぐれに選んで、それを以って | 他の言語はオブジェクト指向ではないと説得しようとする。 という議論もあったりしますね。Ruby作者のまつもとゆきひろさんによれば、 http://www.rubyist.net/~matz/20030807.html 　『最低限の条件は「アイデンティティがある」こと』だそうですが、これはだいたい 私と同じことを言っているように感じています(違うかもしれないけど)。もっとも私の 説明だとクラスが前提になっているので、まつもとさんの定義の方が範囲が広いですけど。 　オブジェクト指向というものがこのように「動く標的」であるとして、 私が件のページで書いているのは、対象言語をJavaとした範囲のものである、 ということをまずご理解ください。 　さて、その上で、実際のモデリングをどのように行うかですが。 >オセロの例がありますが、「石を置く」「置けるかチェックする」「盤面を >初期化する」「マスの状態を返す」の関数をサンプルとしてありますが、 >これでは不十分です。 >何が足りないかというと、「マスそのもののオブジェクト」です。 マスそのもののオブジェクトを作るかどうかの議論は、かつてこのへんで したことがあります(現在過去ログが読めない状態のようなので、 Internet archiveより)。 http://web.archive.org/web/20041114033519/http://www.ogis-ri.co.jp/otc/otc2/oosquare-ml/Archive/200205.month/2713.html 私の結論は、マスなんぞのクラスを持ち込んでもしょうがない、8×8の列挙の 配列にすべきだ、というものです。 >それでは、次のような話を持ちかけられたらどうしますか？ >「オセロゲームの新しいルールを作ったので、それを反映してください。 >そのルールとは、４隅が無い物です」 　これは結構わざとらしい例だと思いますが、そういう例でも、私が公開している オセロのソースをいじるとして、Board#checkPutPossibility()とBoard#isFull()と reverseDiscs()あたりをちょっと直せば十分なんじゃないかしら…と適当に試したら なんか動いたっぽいです。 なお、(修正前の)ソースはこちらで公開しています http://kmaebashi.com/javaworld/index.html 4隅が(空欄として)存在するのは気に食わないかもしれませんが、そもそものお題が 「４隅が無いオセロ」と定義されているのだからそんなに変とも思えません。 >そう、８ｘ８－４＝６０のマスすべてにメッセージを送るのです。 ... >６０人いる保育所の子供全員に「みんなー！クリアしなさい！」と叫ぶ >先生のようです。 で、結局「先生」は、最低でも「真ん中の4つのマス」を把握していなければ いけません。 石を打つ人は、先生にお願いするのかもしれませんけど、もしそうなら 結局先生はすべての子どもの座標を把握している必要があるでしょう。 そりゃま(x, y)で引けるmapと考えてもいいですが、見るからに格子である あの「盤面」をわざわざそんなふうに捉えることが果たして自然かどうか。 >たとえば、「マスに石が置けるかチェックする」は、自分の８方の隣のマスに >問いかけます。 「8方の隣のマス」という時点で、構造が2次元の格子であることに規定されて いますね。たとえば三角格子や3次元に対応できない点において、sionさんの モデルも二次元配列も似たようなものであるように私には見えます。 ところでもしsionさんのモデルが、各マスが8方の隣のマスへの参照を保持する、 というものであれば、「斜めでは挟めない」という新ルールのオセロにおいて (隅がない、というのよりはありそうなのでは)、無駄になりますよね。 逆もまた真です。 >とても回りくどい、面倒な方法に思われますが、実際のコーディングで表せば、 >一般的なやり方と量はさほど変わりません。 一度ソースを見せていただけないでしょうか。いや、皮肉ではなく。 オセロの盤面は、よっぽど奇妙な拡張を考えない限り、2次元配列で十分だし、 なにしろもとが格子なので2次元配列にするのが自然です。 上で挙げたoosquareの投稿にあるように、以前勉強会でオセロを例にしたときに、 >たとえば、「マスに石が置けるかチェックする」は、自分の８方の隣のマスに >問いかけます。 というモデルで作ってみようとした人はいました。隣のマスを見つける方法が わからなくて挫折してましたけど。 # 彼の名誉のために言っておけば、もちろん全部参照持てばできることは # わかっていたでしょう。「本当にそんなアホなことするの?」と思ったから # やらなかっただけで。 私がああいう文章を書いたのは、オブジェクト指向といえばメッセージだ、 という言葉に惑わされて、そういう変な設計が「オブジェクト指向的」で、 なにやらありがたいものであるかのように思い込まされ、混乱してしまった人が 周囲に結構いたためです。 >たしかにそうです。また、白、黒の他に「赤」という石が追加になったら記述を >追加する必要があります。 >しかし、その追加はオブジェクト（クラス）についてすればよい事になります。 どのクラスについて追加すればよいとお考えでしょうか? >蛇足ですが、２０年以上前から有るＧＰＳＳ等のシミュレーション言語では、 シミュレーションにおいて、actor的なオブジェクト指向がうまくいくケースが あるのは確かでしょう。他にもうまく適用できる分野はあるのかもしれません。 でもたとえば最適値を計算しなければならないようなケースで、こっちのオブジェ クトがちょっと最適じゃないから隣のオブジェクトにメッセージを送って… なんてことやってると、無限ループに陥ることもありますよね。 何事も適材適所。少なくともオセロにおいて、隣のマスにメッセージを送って… などという設計が適切であるとは思えません。

>>「オセロゲームの新しいルールを作ったので、それを反映してください。 >>そのルールとは、４隅が無い物です」 > >　これは結構わざとらしい例だと思いますが、 全く本筋と関係ない話ですが、４隅の無いオセロは現実に存在します。 http://www.google.co.jp/search?hl=ja&c2coff=1&q=%22%EF%BC%98%EF%BC%98%E3%82%AA%E3%82%BB%E3%83%AD%22&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

>>　これは結構わざとらしい例だと思いますが、 > >全く本筋と関係ない話ですが、４隅の無いオセロは現実に存在します。 > >http://www.google.co.jp/search?hl=ja&c2coff=1&q=%22%EF%BC%98%EF%BC%98%E3%82%AA%E3%82%BB%E3%83%AD%22&btnG=Google+%E6%A4%9C%E7%B4%A2&lr= ややっ。 知りませんでした。情報ありがとうございます。 盤面の絵とかがなかなか見つからなかったのですが、10×10の盤面で、 4隅の3つのマスが存在しないわけですね。 Javaアプレット版88オセロ： http://www.eb.waseda.ac.jp/murata/~kami/othello/othello.html というわけで、 >>　これは結構わざとらしい例だと思いますが、 この部分に関しては、撤回いたします。

全然、話の本筋とは関係ないのですが、オセロみたいなボードゲームに 六角形や三角形のマスを使うものがあるじゃないですか。 あぁいうのをプログラムで実現するとしたら、 いったいどう言う形で情報を記憶するんでしょう? 二次元配列じゃ、素直に考えると、うまくない...かな? 三角形のマスなら二次元目の方向を斜め方向にするのかしら? マス一つ一つがオブジェクトになっていて、 最初に隣り合うマスの情報をマスオブジェクトにあたえるんでしょうか。 初期化や、プレイヤーからの指定が、ちょっとめんどくさそう。

>六角形や三角形のマスを使うものがあるじゃないですか。 >いったいどう言う形で情報を記憶するんでしょう? >二次元配列じゃ、素直に考えると、うまくない...かな? あ、何か複雑なこと考えすぎていたみたいです。 例えば六角形のマスでも 普通に二次元で値を保持しておけばいいんですね。 ／＼ ｜xy｜として、下の様に座標を与えておいて ＼／ 表示するときに工夫すればいい...のかな? ／＼／＼／＼ ｜00｜01｜02｜ ＼／＼／＼／＼ ｜10｜11｜12｜ ／＼／＼／＼／ ｜20｜21｜22｜ ＼／＼／＼／＼ ｜30｜31｜32｜ ＼／＼／＼／ 隣り合うモノかどうかの計算もちょっとズレるけど 四角形のマスと大きく変わるわけじゃないんですね。 三角形も同じように出来ますね。 Catanみたいなボードゲームは、どうやって実装するのか、想像できないですけど。

>例えば六角形のマスでも >普通に二次元で値を保持しておけばいいんですね。 昔ASCIIに載っていた国産初のRPG「アルフガルド」なんかでも、そういう形で 座標を表現していたはずです。ユーザに見せるのがこの形式の座標なので、 内部的にもたぶんそうだったんじゃないかしら。 六角オセロの場合は、3次元の配列にすると、はさむところの判定が 楽にできるかもしれませんね。各添え字の上限が一定しないですけど。 >Catanみたいなボードゲームは、どうやって実装するのか、想像できないですけど。 これですか。 http://www.hanayamatoys.co.jp/catan/index.html ミソは、ゲーム板をばらばらにして組みなおせる、ってところでしょうか。 その場合は、「隣接するマスを知っている」モデルが使えるかもしれませんね。 表示の際の位置決めとか面倒そうですけど。

>>例えば六角形のマスでも >>普通に二次元で値を保持しておけばいいんですね。 >六角オセロの場合は、3次元の配列にすると、はさむところの判定が >楽にできるかもしれませんね。各添え字の上限が一定しないですけど。 この場合、最初の2次元は私の書いたx,y座標ですか? 3つめの座標はどういう方向になるんですか? >>Catanみたいなボードゲームは、どうやって実装するのか、想像できないですけど。 >ミソは、ゲーム板をばらばらにして組みなおせる、ってところでしょうか。 六角形のマス自身における駒もあり、6個の角における駒もあり、 6個の辺における駒もあって、それぞれどのマスに隣接してるかが 重要になるゲームなので、マスだけに2次元座標を与えちゃダメなんでしょうね。 辺や角に座標を与えたら、それこそワケわからんのですけど(@_@) >その場合は、「隣接するマスを知っている」モデルが使えるかもしれませんね。 おそらくそういうモデルを適用するのでしょうけど、 初期化がすごく大変そうです。 友人や家族でこのゲームを良くやるのですけど、 いつもどうやってプログラムするのかなって考えていたりします＜－職業病?(^^;) そういう融通が効く人間ってすごいなぁとか思います。

>>六角オセロの場合は、3次元の配列にすると、はさむところの判定が >>楽にできるかもしれませんね。各添え字の上限が一定しないですけど。 > この場合、最初の2次元は私の書いたx,y座標ですか? > 3つめの座標はどういう方向になるんですか? 各マスの中心から、各辺に対して伸ばした線を軸とする、というイメージです。 ＼ ＼ ＼ ／＼／＼／＼ ―｜00｜01｜02｜ ＼／＼／＼／＼ ― ｜10｜11｜12｜ ／＼／＼／＼／ ―｜20｜21｜22｜ ＼／＼／＼／＼ ― ｜30｜31｜32｜ ＼／＼／＼／ ／　 ／　 ／ 4角形だと、辺の数が4だから、軸の数は2, 6角形だと、辺の数が6だから、軸の数は3, この方法だと、ある軸の数値を変化させることで、次々と隣のマスが現れますから、 はさむところの判定が楽にできるのではないかと。 >友人や家族でこのゲームを良くやるのですけど、 >いつもどうやってプログラムするのかなって考えていたりします＜－職業病?(^^;) >そういう融通が効く人間ってすごいなぁとか思います。 昔は「コンピュータがチェスで人間に勝てたら、そのコンピュータには知能が あるとみなしてよいのではないか」という議論があったそうですが、 今じゃ誰もそんなこと言いませんもんねえ。 人間の「知能」って不思議です。

>>>六角オセロの場合は、3次元の配列にすると、はさむところの判定が >>>楽にできるかもしれませんね。各添え字の上限が一定しないですけど。 >> 3つめの座標はどういう方向になるんですか? >各マスの中心から、各辺に対して伸ばした線を軸とする、というイメージです。 >4角形だと、辺の数が4だから、軸の数は2, >6角形だと、辺の数が6だから、軸の数は3, >この方法だと、ある軸の数値を変化させることで、次々と隣のマスが現れますから、 >はさむところの判定が楽にできるのではないかと。 なるほどぉ。勉強になります。 ありがとうございます。 ...とは言っても実際にゲームを作ったりはしないのですが 何しろ時間がなくて...能力も?(^^;) >>友人や家族でこのゲームを良くやるのですけど、 >>いつもどうやってプログラムするのかなって考えていたりします＜－職業病?(^^;) >>そういう融通が効く人間ってすごいなぁとか思います。 >人間の「知能」って不思議です。 最近、コンピュータなしだとほとんど仕事ができないので 考えるのは全てコンピュータの方で私自身はコンピュータの (特殊な)入力補助装置になりさがっているのではないかなどと 感じ出しているのですが、そう錯覚することが「知能」なのでしょうか。

横から失礼します。 >>>六角オセロの場合は、3次元の配列にすると、はさむところの判定が >>>楽にできるかもしれませんね。各添え字の上限が一定しないですけど。 >> この場合、最初の2次元は私の書いたx,y座標ですか? >> 3つめの座標はどういう方向になるんですか? > >各マスの中心から、各辺に対して伸ばした線を軸とする、というイメージです。 ええと、あるマスが位置(i, j, k)にあったとします。 このとき周りのマスは 右隣 : (i+1, j, k) 右下 : (i, j+1, k) 左下 : (i, j, k+1) 右隣の左下 : (i+1, j, k+1) にあるはずですよね？(とは限りませんけど、気にしないことにします) 右下 と 右隣の左下 のマスは同一のはずなので、別の場所にあるのはまずいのではないかと。 何か勘違いしてたらすいません。 ＃ こんなの思いつきました。直方体を斜めから見たら6角形になることを利用する訳ですが、 ＃ どっち向きでも添字を2つ動かさなければならない・・・。 ／ ＼ ／ ＼ ／ ＼ |＼ ／|＼ ／|＼ ／| ＼|／ ＼|／ ＼|／ ＼ 　 |＼ ／|＼ ／|＼ ／| ／ ＼|／ ＼|／ ＼|／ |＼ ／|＼ ／|＼ ／| ＼|／ ＼|／ ＼|／ ＼ 　 |＼ ／|＼ ／|＼ ／| 　 ＼|／ ＼|／ ＼|／

>>各マスの中心から、各辺に対して伸ばした線を軸とする、というイメージです。 > >ええと、あるマスが位置(i, j, k)にあったとします。 >このとき周りのマスは ... >右下 と 右隣の左下 のマスは同一のはずなので、別の場所にあるのはまずいのではないかと。 あれっ? 確かにおっしゃる通りです。よく考えずに書いていました。 いやそのマスと座標値が1:1対応しなきゃいかんよね、とは考えていて、 三角格子の交点をつまんでひっぱり挙げるとついて来る線は3本に決まるから、 1:1対応だよな、とか思っていましたが、この時三角格子の各線は座標値を 表しているのであって、軸を表しているわけではないですからね。 とここまでは実は考えていたつもりなんですが、同じだよな、となぜか (2次元の座標系のイメージにひきずられていたのでしょう)考えて 先の投稿のように書いてしまったわけなんですが、 三角格子の各線を(軸でなく)座標値とすれば、隣に行くにはふたつの値を いじらなければいけませんから、これはNykRさんのものと同じになるのでしょうか。

>三角格子の各線を(軸でなく)座標値とすれば、隣に行くにはふたつの値を >いじらなければいけませんから、これはNykRさんのものと同じになるのでしょうか。 えーっと、各線に座標値を割り当てて、 　　 ｜　　　　　｜ 　　 x0　　　　　x1 　　 ｜　　　　　｜ 　　／＼　　　　／＼ 　y0　 z0　　y1　　z1 ／　　　 ＼／　　　　＼ 「各マスの中心から、各辺に対して伸ばした線を軸とする」と、 x0＝x1, y0≠y1, z0≠z1 だから 隣に行くためにいじる値は2つになりますね。 私のと同じになるみたいです。 んーと、でも三角格子の各線を軸とする方法もあると思いますよ。 私の方法をもう少しまじめに書きます。 んーと、 上から下へのラインを x軸 右上から左下へのラインを y軸 左上から右下へのラインを z軸 とすると、あるマスから例えば左右のマスへ移動するとき、 x軸方向に0、y軸方向に±1、z軸方向に±1 (× 辺の長さ分) 動かさなきゃいけません。 他の2方向についても2つの値をいじらなきゃいけませんよ、と。 で、この場合は、辺と座標軸が1対1に対応しています。 (ぱ)さんの最初の方法は、本来同一平面上にあるマスを別の平面にある要素(配列の)として表そうとしたところに問題があったのではないかと。