K.Maebashi's BBS 投稿フォーム

ハンドル名
件名
Link

>　はじめまして。ご意見ありがとうございます。
>
>>しかし、オブジェクト指向の世界では「メッセージは非常に重要な要素」ですから、
>>この表現では、「オブジェクト指向の世界ではメッセージは重要でない」と
>>誤解されてしまうおそれがあります。
>
>　何があればオブジェクト指向か、という点についてはいろいろ議論があって、
>
>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的なオブジェクト指向がうまくいくケースが
>あるのは確かでしょう。他にもうまく適用できる分野はあるのかもしれません。
>でもたとえば最適値を計算しなければならないようなケースで、こっちのオブジェ
>クトがちょっと最適じゃないから隣のオブジェクトにメッセージを送って…
>なんてことやってると、無限ループに陥ることもありますよね。
>何事も適材適所。少なくともオセロにおいて、隣のマスにメッセージを送って…
>などという設計が適切であるとは思えません。
>

spamよけのため、ここに「ほげぴよ」と入力してください。

削除パスワード : クリック！