K.Maebashi's BBS

ここで言っても仕方ない事かもしれないけど、理解するのはあとだと思う あーだこーだ説明されるよりまず、こう書けばクラスが作れるっていう書き方が重要 書き方覚えてあとから理解した方がいい Ｃの#include<stdio.h>がいい例じゃないすかね

　件名付けました。 >ここで言っても仕方ない事かもしれないけど、理解するのはあとだと思う >あーだこーだ説明されるよりまず、こう書けばクラスが作れるっていう書き方が重要 >書き方覚えてあとから理解した方がいい >Ｃの#include<stdio.h>がいい例じゃないすかね 　いや、私はまったく同意するんですが(実際、体当たり学習～では、#include <stdio.h> について、そういうことを書いてるし)。 　唐突にこう言われても何がなんだかわからないんですが、いったい何を おっしゃりたいんでしょうか? 「疑り深い～」に対する反論なのかなあ。 ただ、これについて言えば、CプログラマにJava教えるとき、 なんでもstaticメソッドで書かせればすぐ理解できると思うけど、 いざインスタンスを作るときには、やっぱり「なんでこんなことしなきゃ いかんの?」という疑問を持つはずで、それには答えなきゃいかんと思うんですがねえ。

>いざインスタンスを作るときには、やっぱり「なんでこんなことしなきゃ >いかんの?」という疑問を持つはずで、それには答えなきゃいかんと思うんですがねえ。 とりあえずそうしときなさい、いずれ分かるから ってことじゃダメっすかね 実際オレがそうだったし それでも分からんやつは才能がないと諦めた方がいいんじゃないの

で、結局何をおっしゃりたいんでしょうか? この部分にレスが付いたって事は、「疑り深い～」に対する反論や感想の類と 思っていいのかなあ。 >>いざインスタンスを作るときには、やっぱり「なんでこんなことしなきゃ >>いかんの?」という疑問を持つはずで、それには答えなきゃいかんと思うんですがねえ。 > >とりあえずそうしときなさい、いずれ分かるから >ってことじゃダメっすかね たとえば「hello, world.」を表示するときの#include <stdio.h>は、 「とりあえずそうしときなさい。ほら、hello, world.って表示されたでしょ」 と言えます。この例では、「とりあえずそうしとく」ことで、 hello, world.が表示されるという短期的な見返りがあるわけです。 でも、「クラスを作る」のケースでは、すぐにわかる見返りがないでしょう。 なにせCとかに慣れた人なら、staticメソッドの塊で何でも書いちゃうでしょうから。 だから、「なんでこんなことしなきゃいかんの?」という疑問に答える必要がある、 と私は考えています。

結局問題なのはマルチプルインスタンスによる、多様性、つまりコンストラクタ等で設定した値によって振る舞いが違うと ならそれの超簡単版でも作ればいいんじゃないかな >だから、「なんでこんなことしなきゃいかんの?」という疑問に答える必要がある 前も言った気がするけど、そのうち分かるからとりあえずそうしときなさい じゃまずいっすかね VC++のSDKとかいちいち全部説明してたら死ぬし やっぱ最初は「そのうち分かるからとりあえずこういう風にやっとけばいい」 これの一言に尽きると思う

で、結局何が言いたいんですか? >結局問題なのはマルチプルインスタンスによる、多様性、つまりコンストラクタ等で設定した値によって振る舞いが違うと >ならそれの超簡単版でも作ればいいんじゃないかな 具体的には? >>だから、「なんでこんなことしなきゃいかんの?」という疑問に答える必要がある >前も言った気がするけど、そのうち分かるからとりあえずそうしときなさい >じゃまずいっすかね で、それに対する私の意見は書いたわけで、さらに反論があるのなら書けばいいし、 ないのならそれでいい。あるいは私の言っていることが意味不明だというのなら それも、そう書けばいい。 >VC++のSDKとかいちいち全部説明してたら死ぬし VC++のSDKをいちいち全部説明しろ、と誰か言っていますか? 対話する気がないのなら、掲示板なんぞに出てこないで、自分でWebページでも 立てて好きなことを言っていればいいでしょう。

なんか分かってないっつーか理解力がないっつーか。。 「なんでこんなことしなきゃいかんの？」 っていう人に対して 「とりあえずそうやっとけばいずれ分かる」 って言えばいい、って２回も言ったのにそれに対して何も返事が返ってきてない 下にコピーした返事らしきものがあるけど、ちゃんとした答えじゃない >でも、「クラスを作る」のケースでは、すぐにわかる見返りがないでしょう。 いずれ分かる >なにせCとかに慣れた人なら、staticメソッドの塊で何でも書いちゃうでしょうから。 最初は黙ってpublicとかいときなさい >だから、「なんでこんなことしなきゃいかんの?」という疑問に答える必要がある、 それもいずれ分かる いずれ分かると言っても納得してもらえないのか、 ちゃんと最初に説明しないといずれもクソも分からないのか、 単に意地で最初から説明したいのか、 そこらへんどうなんですか？ ちなみに例としてはこんなん class Car { 　private int mileage 　public Car(int mil) { 　　this.mileage = mil; 　} 　//引数：ガソリン注入 　public int run (int gas) { 　　return (gas * this.mileage); 　} }

>いずれ分かると言っても納得してもらえないのか、 >ちゃんと最初に説明しないといずれもクソも分からないのか、 … >そこらへんどうなんですか？ いずれ分かる

横槍失礼します。 プログラミングセンスを上達させるには、ある種の悟り体験というか、 「あー、そういうことなのか！」っていう感動を覚える体験が必要なんだと 思います。 norgeさんがおっしゃるように、本当にセンスのある奴は放っておいても、 そういった悟りを開くのかもしれないですけど。 「そのうちわかる」的教え方では、僕のようなその他大勢のへっぽこ コード書きは、感動を覚える前に挫折していってしまうのが目に見えています。 そういったへっぽこであっても、ある程度はセンスを磨くことのできる教え方 ってものもあるはずです。 前橋さんの本やこのサイトのドキュメントは、まさに「それだ」と感じます。 導入部分で、感動の一端が垣間見れるように導いてあげるのが、一番良い教え方 だと思うのですが。

>>そこらへんどうなんですか？ > >いずれ分かる 　これだけではあんまりなのでちょっと書き足しときますか。 　根拠も挙げず、イカれたレコードか何かのように、「いずれ分かる」と言い続ける だけなら、バカにでもできるわけです。 　まあ、それでもnorgeさんの最初の投稿には、 >Ｃの#include<stdio.h>がいい例じゃないすかね と書いてあったから、私はこれを 「Cの#include <stdio.h>は『とりあえずこう書いとけ』と言われても理解できたでしょ? 　だからクラスを書くことについても、同様に『とりあえずこう書いとけ』と 　言ってもいずれ理解できるのではないか」 という意味だと解釈しました。つまり「#include <stdio.h>」が、 「とりあえずこう書いとけ」と教えればよいというnorgeさんの主張の根拠であると 解釈したわけです。 そう解釈した上で、反論を書きました。[253]はわかりにくかったようなので、 [255]で改めて説明しています。それでもまだわかりにくかったとか、 再反論があるとか、あるいは最初の私の解釈が間違っていたとかなら拝聴いたしますが、 norgeさんはあいかわらず >そのうち分かるからとりあえずそうしときなさい と繰り返すばかり。だから、 >対話する気がないのなら、掲示板なんぞに出てこないで、自分でWebページでも >立てて好きなことを言っていればいいでしょう。 と言っているのです。 それからね、 >>でも、「クラスを作る」のケースでは、すぐにわかる見返りがないでしょう。 >いずれ分かる んで、こんなクラスを書かせるわけ? > class Car { > 　private int mileage > 　public Car(int mil) { > 　　this.mileage = mil; > 　} > 　//引数：ガソリン注入 > 　public int run (int gas) { > 　　return (gas * this.mileage); > 　} > } 「先生! 書けました」 「ではjavacでコンパイルしてください」 「Car.classってファイルができたんですけど、これってなんですか?」 「いずれ分かる」 ( ﾟдﾟ)ﾎﾟｶｰﾝ そもそもこのCarクラスってのは、いったい何をするためのプログラム(の一部?) なんですかね? 何をするためのクラスでもない、というのなら、私が 「疑り深い～」で批判している「犬」や「猫」のクラスと同じです。 私は「疑り深い～」において「犬」「猫」でクラスを説明することを批判して いますが、それを批判したいのなら、そう書けばいい。もちろん根拠を挙げた上で。 ついでに書いといきますと、句読点の使い方の変な文章は、ﾃﾞﾑﾊﾟに見えますぜ。

私も横からすんません。 norge さんは「プログラミング自体初めての人」と「オブジェクト指向は初めての人」を一緒くたにしちゃって るんだと思うんですけど。推測ですが。 まぁ、「Java (オブジェクト指向言語) を学ぶ前に、C 言語 (手続き指向言語) で得た知識は一度きれいに忘れ てください」って入門書もあったりしますし、私も読んだことがあります。 そういうやり方も、アリかなぁとは思うのですが。一応書けるようにはなるし。 でもですねぇ…、Java で得た知識と C 言語で得た知識がきれいに結びつかないのは苦痛でした。 入門書を読み、サンプルをグジグジいじくっては、覚えているだけで 3 回は挫折してしまいました。 とにかく、自分が何をやっているのかを、感覚としてさっぱり捕まえられなかった。 # こういう感覚はプログラマとして「まっとう」だと思ってます。 # 挫折しといてナンですが…。 「プログラミングは Java が初めて」という人ならこういう経験をしなくて済むかもしれません。 何しろ邪魔する前知識が無いですから。 かと言って、C 言語経験者を「古い知識に縛られたロートル」だとも思いません。 低レベルな概念と高レベルな概念がきれいに結びついた知識体系を獲得した時、飛躍的に応用が利くようになる からです (ちょっと大げさかな…)。 # アセンブラ上がりの高級言語プログラマであれば、また違ったセンスや発想を持っているように思います。 知識というのは、互いに結び付けられて意識下で体系化されてこそ意味を持ちうるわけで、その結びつきを強化 したり手繰り寄せたりしないと、新しい知識や発想に行き着けないと思ってます。私。 あれ、これ、前橋さんの意見の要約にしかなってないかも…。

どうもどうも、返事がアレだけだったんでしばらく見てなかった 単刀直入に言うと 「ゴチャゴチャ長ったらしい。いずれわかるものを余計にわからなくしてるんじゃないか」 と思ったもんで で、ちょっとこう説明すればいいんじゃないかってのを書いたんで見てください http://kill.s31.xrea.com/object.html あくまで「こんな感じに説明すればいいんじゃないか」というわけなんで実際に初心者に見せるときはもうちょい細かくわかりやすく書いた方がいいと思う

>単刀直入に言うと >「ゴチャゴチャ長ったらしい。いずれわかるものを余計にわからなくしてるんじゃないか」 繰り返し確認ですが(3回目くらいかしら)、これは、私が書いた 「疑り深いあなたのためのオブジェクト指向再入門」 http://kmaebashi.com/programmer/object/index.html に関する言及ですか? (Y/N) >で、ちょっとこう説明すればいいんじゃないかってのを書いたんで見てください >http://kill.s31.xrea.com/object.html で、こっちの説明のほうが、「疑りぶかい～」の説明よりも優れている、という 主張であると。 まあねえ、初心者向けにどんな説明がよいか、なんてことは、実際に初心者を大量に 連れてきてアンケートでもしないとわからないことなので、どっちが優れているかは 私にはなんとも言えませんが。 まあ、初心者としての感想は初心者の人に任せるとして、一応初心者ではないつもりの 私の目から、norgeさんの説明を見ると。 >結論：クラスは構造体としても使える 12～13年前のC++の入門書では、こういうふうに、クラスを構造体の拡張として 説明しているものが多かったですね。 で、getterとsetterをつけて、「ほらカプセル化できてるでしょ」とやるわけです。 が、この説明じゃ、norgeさん自身が書いているように、 >実際はこんなバカな事は誰もやらないだろうが、 と思われるだけでしょう。ていうか私がPointの例で言っているように、 setterを解放しといてカプセル化もクソもないもんだ。 おそらくnorgeさん自身そう思うからこそ、getter/setterの話より先に、 >構造体ではなくクラスを使う意味 として、 >public int attack() { > return power + weapon; //攻撃力と武器の攻撃力の和を返す >} これを出したんでしょうが… 「なぜattackすると整数値が返ってくるの?」 [258]の例: >public int run (int gas) { >　return (gas * this.mileage); >} 「なぜrunすると整数値が返ってくるの?」 「オブジェクト指向的に考えてこんなメソッドはおかしい」的な議論は私自身 嫌いなわけですが、そんな私から見ても、こんな設計、仮に仕事で若いのが書いてきたら コードレビューの段階で却下します。 void attack(Enemy) ならともかく。 だいたい、attack()みたいなメソッドをCharcterに入れるのは、ポリモルフィズムを 期待するのでもない限り無意味で、「char1.power + char.weapon」をあちこちに 分散させるのが嫌なら void attack(Character, Enemy) という「関数」を作ってもいいはずだから、「 >結論：簡単に記述できるようになる にはなりませんね。

attack() を動詞ととるなら確かに「設計がヘン」です。 こんな設計見せられたら、私も却下します。 int get_attack_point() const { return power+weapon; } int get_defence_point() const { return vitality+armor; } ならとりあえず許します。 初心者に最初に見せるサンプルというのはきわめて大事です。 「適切なサンプル」を見せるのなら良い。 「テキトーなサンプル」は見せるだけ有害です。 孵ったばかりの雛鳥と同じく、そのサンプルが刷り込まれてしまいます。 トンデモ系の設計を刷り込まれてしまった初心者のコードは手がつけられなくなります。

>int get_attack_point() const { return power+weapon; } >int get_defence_point() const { return vitality+armor; } >ならとりあえず許します。 　これは同意です。 　私があちこちに書いている「Shapeにdraw()メソッドを入れてはいけない原則」に 則れば、attack(Enemy)よりもget_attack_point()の方が良いような気もします。 　Shapeと違ってCharacterは、そのRPGでしか使わないから、attack(Enemy)でも 良いような気もしますが、RPGではきっと「周囲にいる複数の敵にいっせいに ダメージを与える技」ってのがありそうですし。

>　Shapeと違ってCharacterは、そのRPGでしか使わないから、attack(Enemy)でも >良いような気もしますが、RPGではきっと「周囲にいる複数の敵にいっせいに >ダメージを与える技」ってのがありそうですし。 　これもまた面倒で、明らかに敵のグループを選択して魔法を撃つ場合と、フィールド上で「ボカーン！」と爆発する魔法を撃つ場合を考えないといけないでしょうね。（後者は味方の巻き添えもありえますし） 　前者も炎とかを出すのであれば後者のルーチンと共通化した関数にすることができそうですが、マインドアタックなどの場合は直接効果を与える処理（ステータスなども弄る処理）になるでしょうし。 　あとはGetAttckPoint()メソッドを作る場合でも、内部ステータス的にアイテム攻撃になる場合もありますし、アンデッドのように属性で効果が変わる場合もあります。 　ですからAttackTo(Enemy)と書いた場合でも、内部的にはEnemy.DamageFrom(This)と書いて、Enemy側で「その攻撃が本当にダメージになるか」などを判断する必要があるのじゃないかと思います。 　・・・などとOOPでRPGを作成したことがないので自信なしですが(^-^;)

「はてな」で書くときの癖で改行入れるの忘れました・・・orz

>　・・・などとOOPでRPGを作成したことがないので自信なしですが(^-^;) 作成したことのある人のほうが少なそうに思えますが。さて。 >　あとはGetAttckPoint()メソッドを作る場合でも、内部ステータス的にアイテム攻撃になる場合もありますし、アンデッドのように属性で効果が変わる場合もあります。 攻撃の効果が相手によって変わるなんてのは 関数Attack()の実装を オブジェクト(攻撃対象)によって 異なる様に記述したいのだから、 継承なり仮想関数なりを使うのが自然なんでしょうかねぇ。 使う側は全体魔法の場合は、こう書く...かなぁ? for( i=0; i<number_of_enermy; i++) Attack( enermy[i], magic); なんかちょっと違う気がする...よーく考えないとあかんかなぁ。 でも、やっぱりattack()がintを返すのは問題かなぁ。 enermyのステータスなり何なりに効果を与えるのが自然...かな？

>「はてな」で書くときの癖で改行入れるの忘れました・・・orz これなんですが、この掲示板では当初発言内容をすべて<pre>で囲んでいたため、 手で改行を入れないと改行されなかったのですが、 現在は、<tt>で囲み、かつ空白を&nbsp;に置換することで、 改行を行いつつ、ソースを貼っても極端にインデントが崩れないようにしています。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=25&range=1 # 要するに、OTDの時は<pre>で囲む以外手がなかったんだけど、今はスクリプト # 自体が自作なんだから、空白を&nbsp;に置換することなんて簡単なのに # しばらくそれに気付かなかった私がアホだったわけで。 よって、現在は、ことさら手作業で改行を入れる必要はなくなっています。 私は、返信の際にうまく「>」が入るように、改行を入れていますけど。 ということでお気になさらず。

私はそもそもRPGをろくすっぽやったこともないんですが。 # 家庭用ゲーム機持ってないもんで… # 大昔、PC1500版labyrinthを作ろうとして挫折した記憶が(以下略) >　これもまた面倒で、明らかに敵のグループを選択して魔法を撃つ場合と、 > フィールド上で「ボカーン！」と爆発する魔法を撃つ場合を考えないと > いけないでしょうね。（後者は味方の巻き添えもありえますし） 　プロのゲームプログラマさんの投稿ありがとうございます。 　こういうのは、いわゆる「教科書的なOO」が適用できないケースですよね。 RPGに限らず、CADなどでも、例外的な事象はいくらでもあるわけで。 　ユーザが画面上である座標をクリックしたとき、最寄の図形を選択したいわけですが、 ・「折れ線」の上に「中間点(vertex)」がある場合、vertexを優先して検出したい。 ・せっかく直線を選択したのなら、クリックした座標から下ろした垂線の足も 　検出したい。 　とかの要望も出てきて、 　Shape#distance(double x, double y) 　をいろんなShapeでオーバーライドすれば完璧! とはなかなかならないのが現実です。 >　ですからAttackTo(Enemy)と書いた場合でも、内部的にはEnemy.DamageFrom(This)と >書いて、Enemy側で「その攻撃が本当にダメージになるか」などを判断する必要が >あるのじゃないかと思います。 　このへんは、ダブルディスパッチ(いや、Character→Arm→Enemyのトリプル ディスパッチかな)でいけそうな気がしますが、どうなんでしょうか。

>使う側は全体魔法の場合は、こう書く...かなぁ? > for( i=0; i<number_of_enermy; i++) Attack( enermy[i], magic); 「全体魔法の場合は」というif文が出てくるのが、本来は美しくないんでしょうけど。 現実問題そこの場合分けなしではうまく書けないのかもしれませんし。 >でも、やっぱりattack()がintを返すのは問題かなぁ。 >enermyのステータスなり何なりに効果を与えるのが自然...かな？ ということで、条件分岐は避けられないとするのなら、いっそget_attack_point() にして後の判断は上位に任せるという方法もあるかとは思います。OO的ではないですが。 もちろん、そのメソッド名が「attack()」では全然ダメですけどね。

　ゲームプログラマじゃないですって(^-^;) 大昔に書いたと思いますがバリバリC/S系です。 # 確かに趣味ではゲーム作ってますけど・・・ 　Cでも関数は書き方、作り方にある程度の定石がありますが、結局のところは適材適所になって例外はいくらでもあるわけで、この辺りは悩みどころかもしれませんね。CADに関してはやったことないのであまり深く言及できませんが、ShapeのZオーダだけで単純に判定できなそう、くらいの認識です。 >　このへんは、ダブルディスパッチ(いや、Character→Arm→Enemyのトリプル >ディスパッチかな)でいけそうな気がしますが、どうなんでしょうか。 　そうですね・・・アイテム攻撃でも「武器を選択すれば殴れる」ような場合とか「魔法が発動してしまう」場合もあるのでもう1回くらいディスパッチが必要になるかもしれませんね。 　あとは「僧侶が使うと魔法が発動するが、勇者が使うと武器になる」とか「フィールドによっては効果が封印されてしまう」など作り込み次第で例外はいくらでもありそうです。 　ひと昔前のRPGであれば、攻撃が0、魔法が1などになっていて、引数でどの武器、どの魔法なんて指定していましたが、それをしっかりOOPで纏めるほどディスパッチの回数が多くなりそうな気がします。 　あとはリフレクトされるカウンターなんかがあると更に面倒になるのでしょうね。そしてそのカウンターに「反応」できるとなると・・・考えるだけで目が回りそうです。

>　ゲームプログラマじゃないですって(^-^;) ありゃりゃ、すみません。旧掲示板でゲームのフレームワークの話をしておられたので ゲーム系の人かと思ってました。失礼しました。 >　あとは「僧侶が使うと魔法が発動するが、勇者が使うと武器になる」とか >「フィールドによっては効果が封印されてしまう」など作り込み次第で例外は >いくらでもありそうです。 … >　あとはリフレクトされるカウンターなんかがあると更に面倒になるのでしょうね。 >そしてそのカウンターに「反応」できるとなると・・・考えるだけで目が回りそう >です。 うわあ。なるほど。 これで、武器や職業の種類が少なければ、いっそif文べたべたでやってしまえという ことになりそうですが、おそらくそうでもないんでしょうね。 大筋はポリモルフィズムで、例外的なのはif文で場合分け、とかするのかな。 何にせよ大変そうです。