K.Maebashi's BBS

はじめまして。 むつかしい議論をしている最中恐縮ではありますが・・・ 僕は大学生なのですが、プログラムの先生がhogeを多様していました。 それどころかfugaなるものをも使用していました。 これはほげ学に新風を巻き起こすのでは、と思い、書き込みをしました。 よければ参考にしてください。

>で、そーいう入門段階を既に過ぎた人でないと >| 継承は確たる「設計思想」が無い場合、スーパークラスが単なる「ごみ置き場」 >| と化していることが多いようです。 >なんて議論は理解できないでしょう。 これはそう思います。 ># 今この場では「入門」の話に限定、していい？のですよね。 了解です。 ちょうどoosquare-mlで継承の話が出てたので[283]のように書きましたけど、 「継承の問題点」のような話は入門者にわかりにくいのは確かだと思いますので、 そういう話は別スレ立てることにして、今この場は「入門」の話に限定、しておきましょう。 まあ入門者相手でも、継承が「ソースの再利用のためのテクニック」だと言われれば それは変だと思いますが、774RRさんの出されている >「ほらほら、『使うほう』はその実体が具体的に何であるか気にしなくていいんだよ」 という例は、継承の使い方としてまっとうだと思いますし。

仕事中の現実逃避で、前橋さんが紹介されたoosquare-mlを読んでました。 読んだ感想なんですが、僕の中では、ただ単に「手抜きのために継承は使うな」って いうだけのような気がします。（考えなさ過ぎ？） 委譲を使ったとしても、やたらと関連が集中しているクラスを作ってしまったら、 結局ごみ置き場になってしまいますし。 > 「ぴゅあＯＯ」を学んでも、それが明日役立つか、って言われるとキツイものがあります。 > 「入門者でも即、目に見える価値」が無いと教える側としては困るのです。 僕はそれほど教える立場にはいないんですけど、確かにそれは感じますね。 2年ほど前にあったSun Super Tech DaysのBOFを覗いた時、どなたかが 「インドではプログラマを養成する際、UMLなどを使用して、まずオブジェクト指向から 叩き込む。実際のプログラムを教えるのはその後。日本のIT業界もそうでなければ。」 といった趣旨の発言をされていました。 その時は、「あー、そーなんだー。」ぐらいに思っていたんですけど、今になって 思えば、全然そんな事はないんじゃないかと。プログラマなんだから、まずプログラムを 覚えろと。 オブジェクト指向が有効かどうかという判断は、その後なんじゃないかと、最近では 思います。 例えばデザインパターンなんて教えるものじゃなくて、試行錯誤や見よう見真似で、 「気が付いたら使ってた」ぐらいが理想だよなぁ、なんて思ったりします。 で、教える側は、そこに到ることの出来る基礎を身につけさせてあげれば良いのでは、 そしてその基礎というものは、オブジェクト指向というよりも、「プログラムを組む ための地力」となる知識と経験なのでは、と思います。

飴と鞭、って鞭ぢゃないですけど、既に kei さまが [278] で述べられているとおり > 結局、「それが出来ると何がうれしいのか」ってことを実感してからじゃないと、 これが端的に直感できるのが「使うほうは基底クラス、実装するほうは派生クラス」 だと *個人的には* 思います。 飴が無ければ、鞭で叩かれないと新しい知識の勉強なんてしないでしょ？ # そーいうのに興味が無い人の場合。放っておいていい子は教えなくても勝手にやってるし。 C++ の場合 <algorithm> だけでも学ぶ価値＆即戦力になる実力があるのですが 「ぴゅあＯＯ」を学んでも、それが明日役立つか、って言われるとキツイものがあります。 「入門者でも即、目に見える価値」が無いと教える側としては困るのです。 で、そーいう入門段階を既に過ぎた人でないと | 継承は確たる「設計思想」が無い場合、スーパークラスが単なる「ごみ置き場」 | と化していることが多いようです。 なんて議論は理解できないでしょう。 # 今この場では「入門」の話に限定、していい？のですよね。

>従って、あらかじめ辞書を記憶媒体に作成するのは不可能で、全ての >メッセージについて、試行するしかありません。 >これに要する計算コストは、O(M*D) となり、M が大きければ、 >O(N) や O(D) よりも有意に大きな値になります。 納得しました。計算量はM倍ですよね。 うちの掲示板ではMがそんなに大きくないので、「全てのsaltに対応する 辞書を作成する」というのが現実的と思えず、「探索空間が salt のビット数分 広がる」のところで混乱していました。 丁寧な説明ありがとうございました。

>とりあえず俺的には入門者に最初に教えたいのが継承派生です。 ちょうど今、oosquare-mlで継承の是非に関する議論が白熱しています。 http://www.ogis-ri.co.jp/otc/otc2/oosquare-ml/Archive/thread.html なんかもう、「言葉の上だけの議論は空しい」状態になってる気もしますが… まあ継承には色々な問題があると私も思うんですが、一連の議論の中で、 http://www.ogis-ri.co.jp/otc/otc2/oosquare-ml/Archive/200501.month/4468.html | 継承は確たる「設計思想」が無い場合、スーパークラスが単なる「ごみ置き場」 | と化していることが多いようです。 これ、具体的にはどういう例なんだろう… あるクラス群が共通に使うメソッドを、それらのクラスのスーパークラスに 山ほど押し込んでいる、ってことかなあ。 スーパークラスには「外から見て」そのクラスに必要なメソッドが入っていれば よいわけで、サブクラスが共通に使うメソッドなんか持つ必要はないと 思うんですが。共通処理があるのなら、Utility.javaみたいな「関数」を 書けばいい。 >「ほらほら、『使うほう』はその実体が具体的に何であるか気にしなくていいんだよ」 >ある程度プログラム経験がある人だと、これで結構ぐらぐらしてくれます。 これはJavaならinterfaceですよね。 ただ、interfaceには実装がまったく書けないので、やっぱりデフォルトの挙動が 欲しい、とか思ったときに、DefaultHogeとかSimpleHogeとかAbstractHogeとか 作っちゃうわけで… これがよいのかどうか。 http://struts.apache.org/api/org/apache/struts/action/Action.html これなんかはどうなんだろう。私なら、こういうのは反射的にinterfaceにしますが。 クラスにした結果、結構ごみ置き場になってるような気も。

> また、異なるメッセージであっても、同一ユーザーは同じパスワードを > 使い回すと仮定します。 この仮定は本質的ではないので、N==M とおいて、 Sとして十分大きなビット数を用いると、辞書攻撃に必要な計算量が、 min(M*D/M, M*D/D) == min(D, M) 倍程度になるわけです。 と書いた方が分かりやすかったですね。

> saltがばれてる状態では、「探索空間が salt のビット数分広がる」 > ことはないように思いますが…まだ何か勘違いしてますでしょうか。 D: 辞書のサイズ S: salt のビット数 N: ユーザ数 M: メッセージ数 とします。 ここで、一つのMD5ハッシュ値から辞書を引いてパスワードを得るコスト を O(1) とします。 また、異なるメッセージであっても、同一ユーザーは同じパスワードを 使い回すと仮定します。 なお、2^S は、M より有意に大きいため、ほぼ全てのメッセージについて、 異なる salt が使われているものとします。 ここで、salt なしの場合、辞書作成に必要なコストは O(D)、辞書攻撃に 必要なコストは O(N) です。 では、salt ありの場合は、どうでしょう。 全てのありうる salt に対して辞書を作成するのに必要な計算コスト および記憶コストは O(D * 2^S) ですが、これは S が十分大きければ (例えば S=64) 計算量的にも、あるいは記憶容量的にも実現不能になります。 従って、あらかじめ辞書を記憶媒体に作成するのは不可能で、全ての メッセージについて、試行するしかありません。 これに要する計算コストは、O(M*D) となり、M が大きければ、 O(N) や O(D) よりも有意に大きな値になります。 すなわち、Sとして十分大きなビット数を用いると、辞書攻撃に必要な 計算量が、min(M*D/N, M*D/D) == min(M*D/N, M) 倍程度になるわけです。

なんだかすごく初心者な発言をしている気がしますが、聞くは一時の恥ということで。 >データベース中には複数のMD5化されたパスワードが存在する >わけですが、salt がないと、単一の辞書を使って、全ての >パスワードに対する試行を行うことができます。これに対し、 >salt があると、2 の salt のビット数乗 の辞書が必要になる >わけです。 つまりこういうことでしょうか。 ・パスワード候補となりうる文字列に「秘密」を連結し、MD5ハッシュ値を算出する。 　大量の文字列に対してこれを行い、辞書を作る。 ・辞書が何らかの記憶媒体に載るとしたら、ハッシュ値がばれればパスワードもばれる。 　ハッシュ値の方から逆引きできるようなしかけにしておけば一瞬。 ・辞書を作るにはひとつのパスワードを抜くのと同じ計算量が必要だけど、 　「秘密」方式では、その計算量で、全てのパスワードがばれる。 うーん、でも、 >salt があると、探索空間が salt のビット数分広がるため、 saltがばれてる状態では、「探索空間が salt のビット数分広がる」ことはない ように思いますが…まだ何か勘違いしてますでしょうか。 >これを気にするのであれば、salt とプログラム埋め込みのsecret >の両方を使うのが良いと思います。どちらか片方だけであれば、 >salt の方を選ぶのが良い習慣だと思います。 両方使うようにして、今までの分はsaltを空文字にしておけば、 今までの投稿については、以前のパスワードが変わらず使えるかなあ、と 一瞬考えたのですが、D/B流出の時にパスワードがばれる危険性を考えて いるのだからそれじゃ本末転倒ですね (^^; 今までの投稿が削除できなくなってもおそらく誰も困らないでしょうから (いまさら「しくじったので書き直し」はないでしょうから)、今度時間が できたときに修正しておきます。

http://cpan.org/ に行って「PDF」で検索してみるのもよいかも。

# どこにぶら下げようか迷いました。。 僕の職場の新人研修は、いきなりJavaです。 会社的には「今はJavaの案件が一番多いから」ぐらいの理由で選んでいるんだと 思います（情けない。。） で、そんな新人研修をしてきた後輩を見る限り、「オブジェクト指向から入れば 簡単」ということでは無さそうです。 確かに、概念的な部分の吸収は早いように感じます。 でもそれって、ただ単に「何も疑問を持たないから」ってだけなんですよね。 しかも、実際のコードでは、オブジェクト指向を「使えない or 使わない」んです。 結局、「それが出来ると何がうれしいのか」ってことを実感してからじゃないと、 使いこなすことが出来ないんじゃないかと思います。

>とりあえず俺的には入門者に最初に教えたいのが継承派生です。 あ、ここでの「入門者」は「プログラム経験があって、でもオブジェクト指向は入門者」です。 今年の新入社員君がプログラム経験無いようなら、いきなり C++ など逝ってみたいと思います。

ウチは組み込み屋さんなのでアセンブラ経験はほぼ全員が、C 経験は半数が、もっています。 C++ を本格的に使っているのは俺だけです。 次のプロジェクトでは後輩君に C を飛ばして C++ をいきなり使わせようとたくらみ中です。 # どうなることやら... とりあえず俺的には入門者に最初に教えたいのが継承派生です。 「ほらほら、『使うほう』はその実体が具体的に何であるか気にしなくていいんだよ」 ある程度プログラム経験がある人だと、これで結構ぐらぐらしてくれます。

あら、私のネタ振りから別スレッドに。 前橋さん> 自分自身がオブジェクト指向から入った人、またはそういう人を身近にたくさん 前橋さん> 見てきた人の経験を聞いてみたいです。 サンプルが少なくて申し訳ないですが、友人に 1 人、Java から本格的にプログラミングを始めた人がおります。 それ以前も C 言語を触ったことがあるのですが、"Hello, World." 程度でした。 私>「プログラミングは Java が初めて」という人ならこういう経験をしなくて済むかもしれません。 私> 何しろ邪魔する前知識が無いですから。 実はこれ、その友人のことなんです。 今度彼と会う機会があるので、もっと詳しくインタビューしてみますね。

> これですが、辞書攻撃を、Webで稼動中の掲示板に対して行うことを想定して > いますでしょうか。それとも、既にテーブル内容が流出していることを > 前提に、辞書攻撃でパスワードを解析しよう、というお話でしょうか。 テーブル内容が流出していることを前提にしています。 > 後者だとすると、テーブルが流出した時点でsaltはだだ漏れです。 そうです。 > これは、ひとつのパスワードがばれても、同じハッシュになっている他の > パスワードが芋づる式にばれることはない、ということでしょうか? 違います。辞書攻撃に必要な計算量が増えるという意味です。 > 同時間で、ほぼ同数のパスワードが抜かれてしまいそうに思う > のですが。 salt があると、探索空間が salt のビット数分広がるため、 辞書攻撃に要する時間が長くなります。以下のページにも、 同様な示唆があります。 http://www.itmedia.co.jp/enterprise/0307/24/epn09.html http://www.microsoft.com/japan/msdn/library/ja/f_and_m/html/vxconprotectingpasswordcredentials.asp データベース中には複数のMD5化されたパスワードが存在する わけですが、salt がないと、単一の辞書を使って、全ての パスワードに対する試行を行うことができます。これに対し、 salt があると、2 の salt のビット数乗 の辞書が必要になる わけです。 > 別の場所に置いてあるだけ"秘密"の方がまだマシかも。 これを気にするのであれば、salt とプログラム埋め込みのsecret の両方を使うのが良いと思います。どちらか片方だけであれば、 salt の方を選ぶのが良い習慣だと思います。

すみません、風呂の中で考えてたらちょっとわからなくなりました。 >今のやり方だと、仮に異なるユーザが同一のパス >ワードを利用していた場合、その事実を管理者は >知ることができるわけですが、salt を使えばその >心配もありません。 これはその通りだと思います。また、クラッカーにD/Bを継続的に監視されて いる場合、いろいろなパスワードで書き込んでみることで、パスワードを 推測することもできることになります。 >また、仮に "秘密" や salt が洩れた場合に、辞書 >攻撃への耐性が若干高くなります。(salt があると、 >同じ辞書は一つのメッセージにしか使えないため、 >探索空間が広くなる) これですが、辞書攻撃を、Webで稼動中の掲示板に対して行うことを想定して いますでしょうか。それとも、既にテーブル内容が流出していることを 前提に、辞書攻撃でパスワードを解析しよう、というお話でしょうか。 前者だとすると、"秘密"やsaltが漏れていようがいまいが関係なさそうですし (そもそもレンタルサーバ業者にプロセス止められそうですが)、 後者だとすると、テーブルが流出した時点でsaltはだだ漏れです。 別の場所に置いてあるだけ"秘密"の方がまだマシかも。 >同じ辞書は一つのメッセージにしか使えないため、 >探索空間が広くなる) これは、ひとつのパスワードがばれても、同じハッシュになっている他の パスワードが芋づる式にばれることはない、ということでしょうか? しかし、実際問題こんな掲示板の投稿が消されてもさしたる実害はないわけで、 問題は「お金が絡むようなところと共通のパスワードを使う人がいたケース」だと 思っています。 そんなユーザは投稿ごとにパスワードを変えたりしそうにないですし(そんな ユーザに限らずともそうなんじゃないかと思いますが)、同一ハンドルの人は 1回しか調べない、程度のことで、同時間で、ほぼ同数のパスワードが抜かれて しまいそうに思うのですが。 どちらが安全か、という問題以前に、まず私の認識は合ってますでしょうか?

便乗して・・・ Javaを教えるほうにC言語などを知らないで育った方が 一体どれくらいいるのかも知りたいかも。 （あくまで参考として）

まったく違う話題にシフトします。件名とスレッド変えました。 >「プログラミングは Java が初めて」という人ならこういう経験をしなくて済むかもしれません。 >何しろ邪魔する前知識が無いですから。 「Cなどの言語を知っている人は、今までの知識が邪魔をしてオブジェクト指向の習得が 難しいけど、最初からオブジェクト指向を覚えるのなら簡単だ」 とたまに聞きますけど、これはどの程度事実なんでしょうか。 たまに、上の言葉の後ろに「なにしろオブジェクト指向は自然だから～」というのが 続いたりすると、どうも眉に唾をつけたくなります。私の場合。 古い知識が邪魔をするという傾向はもちろんありますが(FORTRAN屋やCOBOL屋が設計した Cプログラムにどれほど泣かされたことか)、じゃあまったくの初心者がJavaから 入門したとして、最初に動かすプログラムがhello, world. だったら、結局のところ 手続き指向→オブジェクト指向の流れで習得することになるように思います。 Javaの場合、hello, world.といってもアプレットから入るんでしょうか。 その場合、#include <stdio.h>なんかとは比べ物にならないくらい「とりあえず こう書いとけ」的な記述が増えてしまいますが、まあ、それは「いずれ分かる」と 言っておけばよいでしょう。 んで、ただブラウザにhello, world.と表示されるだけのプログラムから 順次発展していく場合、どの辺で「オブジェクト指向」を意識することになるんでしょうか。 クラスがアプレットしかなければ、メソッドも単なる関数ですし、インスタンスフィールドは グローバル変数と同じです。 GUIのボタンを作ったりするところは、「決まり文句」としか思ってもらえない気も するんですが、こういうところから、だんだんオブジェクト指向になじんでいったり するのかな。 私自身はBASICから入ったクチですし、新人にJavaを教えたことは何度となくありますが うちの会社では新人はまずCの研修を受けてくるので、「オブジェクト指向から入門」 した人の観察例が私にはほとんどありません。 自分自身がオブジェクト指向から入った人、またはそういう人を身近にたくさん 見てきた人の経験を聞いてみたいです。

>つまり、"秘密" はソース埋め込みにせず、メッ >セージごとに乱数で生成することにし、salt 自体も >message表に記録しておくわけです。 毎度ながらご指摘ありがとうございます。 掲示板のパスワードとしてどこまでの仕様が必要であるかはさておき、 この記事を読んで「パスワードの暗号化はこうすれば万全なんだ」と思ってしまう人が いるとまずいので、取り急ぎ注釈をつけました。

PHPとMySQLで掲示板を作る / 削除 / 削除系ソース の hash_user_password() ですが、"秘密" は、 UNIX パスワードなどで使われている salt の やり方にするのはどうですか？ つまり、"秘密" はソース埋め込みにせず、メッ セージごとに乱数で生成することにし、salt 自体も message表に記録しておくわけです。 今のやり方だと、仮に異なるユーザが同一のパス ワードを利用していた場合、その事実を管理者は 知ることができるわけですが、salt を使えばその 心配もありません。 また、仮に "秘密" や salt が洩れた場合に、辞書 攻撃への耐性が若干高くなります。(salt があると、 同じ辞書は一つのメッセージにしか使えないため、 探索空間が広くなる)

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

>プログラムを始めたばかりのものです。 >Perlで作成する事になりました。 >PDFを表示する仕様があります。 >どの様にすればよいかわかりません。 >教えて頂ければありがたいです。 私はPerlにもPDFにも詳しくないですが… PerlとPDFをキーワードに、Googleで検索しました(日本語限定)。 http://www.google.co.jp/search?hl=ja&q=Perl+PDF&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja 1件目がこれ。 http://www.warpstream.co.jp/package_pdfserver.html?afl=cgirescue1 商品のようです。 お金を出すのが嫌なら、2件目がこれ。 http://hp1.jonex.ne.jp/~nakajima.yasushi/ PDFJというモジュールがあるようです。 PDFJでGoogleすると、結構有名なようですね。 ただ、ざっと見て、ライセンスの規定がよくわかりませんが… また、1件目のページの中に >PDFLibなどのライブラリで作成することはできますが、 とありますから、PDFLibとPerlでGoogleするのも手です。これも商品のようですが。

>>そこらへんどうなんですか？ > >いずれ分かる 　これだけではあんまりなのでちょっと書き足しときますか。 　根拠も挙げず、イカれたレコードか何かのように、「いずれ分かる」と言い続ける だけなら、バカにでもできるわけです。 　まあ、それでも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クラスってのは、いったい何をするためのプログラム(の一部?) なんですかね? 何をするためのクラスでもない、というのなら、私が 「疑り深い～」で批判している「犬」や「猫」のクラスと同じです。 私は「疑り深い～」において「犬」「猫」でクラスを説明することを批判して いますが、それを批判したいのなら、そう書けばいい。もちろん根拠を挙げた上で。 ついでに書いといきますと、句読点の使い方の変な文章は、ﾃﾞﾑﾊﾟに見えますぜ。

>他の掲示板にＤ言語って書いたら、そんなのねーよって言われた。 　で? 　対話をする気もなく、言いたいことを一方的に書き散らすだけなら、掲示板なんぞに 出てこないでください。

他の掲示板にＤ言語って書いたら、そんなのねーよって言われた。

プログラムを始めたばかりのものです。 Perlで作成する事になりました。 PDFを表示する仕様があります。 どの様にすればよいかわかりません。 教えて頂ければありがたいです。

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

D言語万歳

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

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