オブジェクト指向の説明について
1 ：デフォルトの名無しさん：
自分も最初その概念がわかるまで少し時間がかかったと思う。
しかし振り返って見ると説明の仕方が悪いとしか思えない。
誰が最初に言い出したのか知らないが、プログラミングの実態からかけ離れた概念の事ばかり説明する。
新しい概念を学ぶ、教える際に最も効果的なのは、身近な具体例を見ることである。
これを取り違えたのか、プログラミングの概念を説明するのに、魚とかりんごとかロボットとか名詞動詞とか、そんな事ばかり書いてある。
大方の入門者はそんな事よりももっとコンピュータの振る舞いに近い例を求めているはずだ。
こういうのを見るたびに思うことは、このような日常生活の例を出してプログラミングの概念を説明するのは、説明するものの自己満足なのではないか？ということ。
CをベースにしてC++に移行（今は少なくなったのかもしれないが）しようとする人間にとってこういう妙な概念化は非常にまどろっこしい、時には馬鹿にされている感じさえ受ける。
続く
しかし振り返って見ると説明の仕方が悪いとしか思えない。
誰が最初に言い出したのか知らないが、プログラミングの実態からかけ離れた概念の事ばかり説明する。
新しい概念を学ぶ、教える際に最も効果的なのは、身近な具体例を見ることである。
これを取り違えたのか、プログラミングの概念を説明するのに、魚とかりんごとかロボットとか名詞動詞とか、そんな事ばかり書いてある。
大方の入門者はそんな事よりももっとコンピュータの振る舞いに近い例を求めているはずだ。
こういうのを見るたびに思うことは、このような日常生活の例を出してプログラミングの概念を説明するのは、説明するものの自己満足なのではないか？ということ。
CをベースにしてC++に移行（今は少なくなったのかもしれないが）しようとする人間にとってこういう妙な概念化は非常にまどろっこしい、時には馬鹿にされている感じさえ受ける。
続く
|
|
|
2 ：デフォルトの名無しさん：03/05/19 20:40
続かせないよ！
3 ：デフォルトの名無しさん：03/05/19 20:44
4 ：デフォルトの名無しさん：03/05/19 20:45
いや、興味深いテーマだ。続けてくれ～。
5 ：デフォルトの名無しさん：03/05/19 20:46
自分が思いついた説明をすると、
デスクトップにあるアイコンが良い例だと思う。
アイコンはオブジェクトのインスタンスである。
メモ帳のアイコンはテキストという内容を含んでおり、動作は右クリックすると確認操作できる。
デスクトップで右クリックすると、ある程度のオブジェクトの雛形、ショートカット、フォルダー、テキストファイルなど、が用意されている。
これに名前をつけて新規作成するのがオブジェクトのインスタンス化に他ならない。
オブジェクト指向以前の操作では、例えばWORDのファイルを開こうとしたときには、WORDを立ち上げ（関数、手続き）そこからファイルを指示選択するという操作だったのが、
オブジェクト指向、アイコンの操作ではそのWORDファイルをクリックすると、自動的にWORDが立ち上がる。
これがよく巷の説明にある、オブジェクト自身が己の振る舞いを知っているということだ。
エクセルファイルはエクセルをたちあげるし、右クリックから別のメソッドを選ぶこともできる。
こういうのをイルカは泳ぐが、車は走るとか書かれるとハア？ってなっちゃうと思うんだけどね。
デスクトップにあるアイコンが良い例だと思う。
アイコンはオブジェクトのインスタンスである。
メモ帳のアイコンはテキストという内容を含んでおり、動作は右クリックすると確認操作できる。
デスクトップで右クリックすると、ある程度のオブジェクトの雛形、ショートカット、フォルダー、テキストファイルなど、が用意されている。
これに名前をつけて新規作成するのがオブジェクトのインスタンス化に他ならない。
オブジェクト指向以前の操作では、例えばWORDのファイルを開こうとしたときには、WORDを立ち上げ（関数、手続き）そこからファイルを指示選択するという操作だったのが、
オブジェクト指向、アイコンの操作ではそのWORDファイルをクリックすると、自動的にWORDが立ち上がる。
これがよく巷の説明にある、オブジェクト自身が己の振る舞いを知っているということだ。
エクセルファイルはエクセルをたちあげるし、右クリックから別のメソッドを選ぶこともできる。
こういうのをイルカは泳ぐが、車は走るとか書かれるとハア？ってなっちゃうと思うんだけどね。
6 ：デフォルトの名無しさん：03/05/19 20:48
7 ：デフォルトの名無しさん：03/05/19 20:51
実際にコーディングして思うことは、
どれくらいの人間がその入門書に書いてある、りんごとかフルーツの継承とかそういう卑近な例を頭に思い浮かべながらやってんだろう？
ということ。
確かに大規模なプロジェクトでモデリングする際はそういうアーティスティックな例みたいなものがパワーを発揮するのかもしれないけど、
普通は、そんな日常生活の動詞みたいな事を思い浮かべながらクラスの設計とかしない。
というかそんな人いる？
どれくらいの人間がその入門書に書いてある、りんごとかフルーツの継承とかそういう卑近な例を頭に思い浮かべながらやってんだろう？
ということ。
確かに大規模なプロジェクトでモデリングする際はそういうアーティスティックな例みたいなものがパワーを発揮するのかもしれないけど、
普通は、そんな日常生活の動詞みたいな事を思い浮かべながらクラスの設計とかしない。
というかそんな人いる？
9 ：デフォルトの名無しさん：03/05/19 20:55
>>7
まあ自治厨も２ちゃんのメソッドというかイベントみたいなもんだな。
まあ自治厨も２ちゃんのメソッドというかイベントみたいなもんだな。
継承というのもアイコンを見ればわかりやすい、自分が見る限りすべてのアイコンにはプロパティがある。
これはすべての親で継承されていると思う。あと切り取り、コピー、削除、ショートカットの作成、開く、アイコンによっていろいろ継承の仕方が異なる。
これはすべての親で継承されていると思う。あと切り取り、コピー、削除、ショートカットの作成、開く、アイコンによっていろいろ継承の仕方が異なる。
11 ：デフォルトの名無しさん：03/05/19 21:04
12 ：デフォルトの名無しさん：03/05/19 21:10
このスレ立て人に禿同。
なんにしろ比喩的な概念や理論というのは、結果や成果の後にくっつけてくる物なんだから
それが分かりやすい説明だと思えるのは実際にそれを実践した事がある人だけであって
何の実践も無いビギナーの人には地に足の付かない分かりにくいものだと俺も思うよ。
なんにしろ比喩的な概念や理論というのは、結果や成果の後にくっつけてくる物なんだから
それが分かりやすい説明だと思えるのは実際にそれを実践した事がある人だけであって
何の実践も無いビギナーの人には地に足の付かない分かりにくいものだと俺も思うよ。
13 ：動画直リン：03/05/19 21:11
14 ：デフォルトの名無しさん：03/05/19 21:11
15 ：デフォルトの名無しさん：03/05/19 21:13
>>1 世の中にはさ、デスクトップの事象とそれのプログラミング上の
メタファーが完全に一致するフレームワークは既に存在するけど、
それでプログラミングの理解が進むかといったら、そういうわけではない
ってのが俺の経験。OS/2のWPSとかね。
メタファーが完全に一致するフレームワークは既に存在するけど、
それでプログラミングの理解が進むかといったら、そういうわけではない
ってのが俺の経験。OS/2のWPSとかね。
16 ：1：03/05/19 21:14
そうだと思うよ。
抽象的な理論まで昇華させるのは、その概念に十分慣れてからで良い。
そもそも、君の言うとおり、OOの創始者もそんなイルカとかロボットの動詞名詞とかから始めたわけがない、と俺は思っている。
それを入門と謳うものが初心者にありがたそうに、その昇華した後の概念を説明する。
抽象的な理論まで昇華させるのは、その概念に十分慣れてからで良い。
そもそも、君の言うとおり、OOの創始者もそんなイルカとかロボットの動詞名詞とかから始めたわけがない、と俺は思っている。
それを入門と謳うものが初心者にありがたそうに、その昇華した後の概念を説明する。
18 ：デフォルトの名無しさん：03/05/19 21:18
じぶんはＭＦＣ使うようになってはじめてＯＯが多少理解できた。
（ここでスーパークラスにキャストすればいいとか）
やっぱり実際にクラスライブラリに触れてみるのがいいんじゃない？
（ここでスーパークラスにキャストすればいいとか）
やっぱり実際にクラスライブラリに触れてみるのがいいんじゃない？
19 ：デフォルトの名無しさん：03/05/19 21:18
そうとう噛み砕いたあげく 「イルカとかロボットの動詞名詞」 になったわけで。
OMT や OOSE 読んで OO がすぐわかるなら、イルカでも分かるだろう。
OMT や OOSE 読んで OO がすぐわかるなら、イルカでも分かるだろう。
>>18
その際に、まず動詞と名詞を抽出するとか、りんごの例は理解の助けになったかい？
その際に、まず動詞と名詞を抽出するとか、りんごの例は理解の助けになったかい？
CとC++の例で比較しながら、どんどんやっていけばいいと思う。具体的に。
それを第一章みたいなのが全部抽象的な概念で、わかったつもりになったか、よくわからないまま、第2章に進むというのがパターン。
たいがいの入門書とかWEB上の入門ページ見ればわかると思うけどね。
それを第一章みたいなのが全部抽象的な概念で、わかったつもりになったか、よくわからないまま、第2章に進むというのがパターン。
たいがいの入門書とかWEB上の入門ページ見ればわかると思うけどね。
22 ：デフォルトの名無しさん：03/05/19 21:29
独習C++で勉強してるんだけどクラスの説明でフルーツがでてきたな。
>>22
でどうよ？
でどうよ？
24 ：デフォルトの名無しさん：03/05/19 21:36
>>23
どうこう言えるレベルまでまだ進んでいないから何ともいえない。
どうこう言えるレベルまでまだ進んでいないから何ともいえない。
25 ：１８：03/05/19 21:45
そういや全然役に立たなかったね（藁
CFrame > CDialog が継承だとか OnPaint()をオーバーライドするとか
言われたほうがよほどわかりやすいとおもう。
CFrame > CDialog が継承だとか OnPaint()をオーバーライドするとか
言われたほうがよほどわかりやすいとおもう。
26 ：デフォルトの名無しさん：03/05/20 12:59
[クラスの継承]
class ギコ猫
∧∧ ・逝ってよし
～′￣￣( ﾟДﾟ) ・ｺﾞﾙｧ
UU￣￣ U U
↓
class フサギコ
,,,,,,,,,,,,,,,∧,,∧ ・逝ってよし
～′,,,,,,,,,,ミ,,ﾟДﾟ彡・ｺﾞﾙｧ
UU"""" U U ・ﾌｻﾌｻだぞ
class ギコ猫
∧∧ ・逝ってよし
～′￣￣( ﾟДﾟ) ・ｺﾞﾙｧ
UU￣￣ U U
↓
class フサギコ
,,,,,,,,,,,,,,,∧,,∧ ・逝ってよし
～′,,,,,,,,,,ミ,,ﾟДﾟ彡・ｺﾞﾙｧ
UU"""" U U ・ﾌｻﾌｻだぞ
27 ：デフォルトの名無しさん：03/05/20 23:47
>>26
ドラクエの転職みたいなもん？
ドラクエの転職みたいなもん？
28 ：デフォルトの名無しさん：03/05/21 10:00
フサギコはギコ猫のサブクラスだから、
フサギコクラスを作るときに「フサフサだぞ」メソッドを記述すれば、
ギコ猫から継承したメソッド「逝ってよし」「ゴルァ」が存在し、
フサギコ特有のメソッド「フサフサだぞ」が存在するクラスになる。
で、よろしいんだろうか。
フサギコクラスを作るときに「フサフサだぞ」メソッドを記述すれば、
ギコ猫から継承したメソッド「逝ってよし」「ゴルァ」が存在し、
フサギコ特有のメソッド「フサフサだぞ」が存在するクラスになる。
で、よろしいんだろうか。
,
30 ：デフォルトの名無しさん：03/05/22 14:10
俺はイルカとかロボットで十分分かりやすかったけど
分からない人も多いんだねぇ
分からない人も多いんだねぇ
31 ：デフォルトの名無しさん：03/05/22 14:11
>>1は説明のしかたを疑う前に自分の頭を疑ったほうが良いよ
32 ：デフォルトの名無しさん：03/05/22 14:17
33 ：デフォルトの名無しさん：03/05/22 16:05
34 ：デフォルトの名無しさん：03/05/22 22:53
とっかかりの説明として、
関数呼び出しに、主語が要る、じゃダメ？
関数呼び出しに、主語が要る、じゃダメ？
>>30,>>33
俺はあの説明でもわかったぜ！と自慢するスレでも、あの説明でわからないのは馬鹿！と見下すスレでもない。
正直、お前らがすんなり、あのりんごの説明でわかったとは俺は信じないし、仮にわかったとしても別のベースというかとっかかりを使ったに決まっている。自分でそれ気がついていないだけ。
俺はあの説明でもわかったぜ！と自慢するスレでも、あの説明でわからないのは馬鹿！と見下すスレでもない。
正直、お前らがすんなり、あのりんごの説明でわかったとは俺は信じないし、仮にわかったとしても別のベースというかとっかかりを使ったに決まっている。自分でそれ気がついていないだけ。
36 ：デフォルトの名無しさん：03/05/22 23:12
＞仮にわかったとしても別のベースというかとっかかりを使ったに決まっている
なんつーか。例えばどんな 「別のベースというかとっかかり」 があるの？
それを議論すべきじゃないのかな。
なんつーか。例えばどんな 「別のベースというかとっかかり」 があるの？
それを議論すべきじゃないのかな。
>>31もだ。
本質を理解してこのスレに書き込んでいるのか？
ああいう一連の例は、概念を具体化して説明しているのではなくて、むしろいたずらに抽象化している。
プログラミングの経験が十分にあり、ある種の感のようなものが働く人間はイルカが泳ぐと書かれていても、何を言わんとしているのか脳内で別の具体化が自動的にできるので問題がないんだろうね、きっと。
しかし、その他の人間にとっては、けしてわかり易い具体例ではない。
俺はわかったよ。というレスではなくて、反論があるならこの論旨にそってして欲しいね。
そうでないなら、へえ、それは良かったねとしか言えないな。
本質を理解してこのスレに書き込んでいるのか？
ああいう一連の例は、概念を具体化して説明しているのではなくて、むしろいたずらに抽象化している。
プログラミングの経験が十分にあり、ある種の感のようなものが働く人間はイルカが泳ぐと書かれていても、何を言わんとしているのか脳内で別の具体化が自動的にできるので問題がないんだろうね、きっと。
しかし、その他の人間にとっては、けしてわかり易い具体例ではない。
俺はわかったよ。というレスではなくて、反論があるならこの論旨にそってして欲しいね。
そうでないなら、へえ、それは良かったねとしか言えないな。
38 ：デフォルトの名無しさん：03/05/22 23:22
>>1はイメージをつかむ能力が低いんだよ
40 ：デフォルトの名無しさん：03/05/22 23:31
難しいことをすぐわからせるのは無理。以上。
41 ：デフォルトの名無しさん：03/05/23 01:14
おれはシナリオを提示して、その中で出てくる物をモデル化する
過程を通じてオブジェクト指向を教えている。
犬もイルカも哺乳類とか言われるよりも、イルカに乗って
南の島に行くまでをプログラミングしてみろと言われた方が
何をすればいいかわかると思う。
ついでに、実験的な取り組みとして、最初に継承を教えないというのを
考えているんだが。
クラス同士の関連の説明は、最初はオブジェクトコンポジションのみ。
次がインタフェースで継承はその次だ。文句あるかｺﾞﾗｧ!
…あるよね…
過程を通じてオブジェクト指向を教えている。
犬もイルカも哺乳類とか言われるよりも、イルカに乗って
南の島に行くまでをプログラミングしてみろと言われた方が
何をすればいいかわかると思う。
ついでに、実験的な取り組みとして、最初に継承を教えないというのを
考えているんだが。
クラス同士の関連の説明は、最初はオブジェクトコンポジションのみ。
次がインタフェースで継承はその次だ。文句あるかｺﾞﾗｧ!
…あるよね…
42 ：デフォルトの名無しさん：03/05/23 01:27
この際 Squeak を触らせて説明するってのはどうだろう。
オブジェクトが目に見えるし、操作できるし。
オブジェクトが目に見えるし、操作できるし。
43 ：デフォルトの名無しさん：03/05/23 02:14
現実世界での具体化が、プログラミングでの抽象化につながってしまってる点が問題なんじゃない？
犬もイルカも哺乳類、と言うだけじゃそりゃおちこぼれも出てくるだろうさ。
だからそれの隣に配列もリストもコンテナ、ってゆー例を書いて、現実世界での具体的な例とプログラミングでの具体的な例を対比させれば良いんで無いか？
犬もイルカも哺乳類、と言うだけじゃそりゃおちこぼれも出てくるだろうさ。
だからそれの隣に配列もリストもコンテナ、ってゆー例を書いて、現実世界での具体的な例とプログラミングでの具体的な例を対比させれば良いんで無いか？
∧＿∧
ﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
ﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
45 ：デフォルトの名無しさん：03/05/31 02:13
＝＝＝＝＝＝＝＝＝＝＝＝終了＝＝＝＝＝＝＝＝＝＝＝＝
46 ：デフォルトの名無しさん：03/06/20 01:23
名スレの予感
47 ：デフォルトの名無しさん：03/06/20 04:51
うーむ。結局、オブジェクト指向の嬉しさを知るためには、
そうではないコードの害を知ることが大切な気がする。
なんとなくは理解できても、じゃあ、なんでそんなことしなければならないの？
ってのまでは理解しがたいし。
初等者がプログラムの勉強で使う程度のプログラムなら
手続き的に書くのが一番早くて、すんなりはまる場合が多いしね。
たくさんコード書いていたら、自然とオブジェクト指向なコードを作ろうとしていたし。
それはC言語のような手続き言語でも同様に。
余事象を感じなきゃ、抽象化の概念とか分かり辛いよね。
そうではないコードの害を知ることが大切な気がする。
なんとなくは理解できても、じゃあ、なんでそんなことしなければならないの？
ってのまでは理解しがたいし。
初等者がプログラムの勉強で使う程度のプログラムなら
手続き的に書くのが一番早くて、すんなりはまる場合が多いしね。
たくさんコード書いていたら、自然とオブジェクト指向なコードを作ろうとしていたし。
それはC言語のような手続き言語でも同様に。
余事象を感じなきゃ、抽象化の概念とか分かり辛いよね。
48 ：デフォルトの名無しさん：03/06/20 09:06
りんごの例は理解を助けるものではない。
その意味が分かったときこそ理解できたという目印。
その意味が分かったときこそ理解できたという目印。
49 ：デフォルトの名無しさん：03/06/20 12:34
まずは「ifやswitchは、多いと無様」という観念を育てるべき。
51 ：デフォルトの名無しさん：03/06/20 13:13
何故、ifやswitchが多いと無様 なんだろうね。
おっしゃっているのは、
ポリモルフィズムを使った処理の切り分けの方が、
いちいち型をチェックするif文やswitch文よりも、
コードの局所性が高く、メンテや拡張が容易だ
ってな文脈だと思うけど。
それは結局実利ベースの価値判断であって、
スマート/無様 などという曖昧な美的判断を
信仰させる必要がほんとにあるのかな？
そりゃ、たしかに美的判断の方が、直感的でわかり易いけど、
んなもんに全面的に頼ったら論理的誤りを排除しにくいし、
価値が逆転する局面では、迷信を信じ込むイタイ人、
になっちゃうんじゃないのかな？
おっしゃっているのは、
ポリモルフィズムを使った処理の切り分けの方が、
いちいち型をチェックするif文やswitch文よりも、
コードの局所性が高く、メンテや拡張が容易だ
ってな文脈だと思うけど。
それは結局実利ベースの価値判断であって、
スマート/無様 などという曖昧な美的判断を
信仰させる必要がほんとにあるのかな？
そりゃ、たしかに美的判断の方が、直感的でわかり易いけど、
んなもんに全面的に頼ったら論理的誤りを排除しにくいし、
価値が逆転する局面では、迷信を信じ込むイタイ人、
になっちゃうんじゃないのかな？
一体全体何故、ifやswitchが多いと無様 なんだろうね。
おっしゃっているのは、
「ポリモルフィズムを使った処理の切り分けの方が、
いちいち型をチェックするif文やswitch文よりも、
コードの局所性が高く、メンテや拡張が容易だ」
ってな文脈だろうと勝手に思うけど。
ポリモルフィズムの件は、実利ベースの価値判断であって、
スマート/無様 などという曖昧な美的判断/信仰とは違うと思うよ。
そりゃ、説明が厄介な事は、全て美的判断で説明しちまえれば楽だろーけど、
んなもんに頼っちまったら、論理的誤りを排除できなくなるし、
価値が逆転するよな局面では、「無様な」馬脚を現す結果になるよ。
おっしゃっているのは、
「ポリモルフィズムを使った処理の切り分けの方が、
いちいち型をチェックするif文やswitch文よりも、
コードの局所性が高く、メンテや拡張が容易だ」
ってな文脈だろうと勝手に思うけど。
ポリモルフィズムの件は、実利ベースの価値判断であって、
スマート/無様 などという曖昧な美的判断/信仰とは違うと思うよ。
そりゃ、説明が厄介な事は、全て美的判断で説明しちまえれば楽だろーけど、
んなもんに頼っちまったら、論理的誤りを排除できなくなるし、
価値が逆転するよな局面では、「無様な」馬脚を現す結果になるよ。
53 ：デフォルトの名無しさん：03/06/20 13:25
俺は簡単なアセンブラしかやったことがないから
オブジェクト指向についてはよくわからない。
とりあえず、ここで>>1の書いた文章読んでもオブジェクト指向に
ついて全然理解が進んでいない。
>>1は既に解っている人に向かって同意を求める為に書いた文だから、
初心者向きで無いのは当然だと思う。
もし元気があったら、初心者にも解るよう書いてくれないか？
2CHでは図が入らないからどこかのＨＰでもいい。
何の説明も無しに「オブジェクト」「インスタンス」「メソッド」
などという用語が出ないような本当の初心者向きの説明。
それが解りやすければ>>1の方法論が優れてると証明も出来ると思うが。
オブジェクト指向についてはよくわからない。
とりあえず、ここで>>1の書いた文章読んでもオブジェクト指向に
ついて全然理解が進んでいない。
>>1は既に解っている人に向かって同意を求める為に書いた文だから、
初心者向きで無いのは当然だと思う。
もし元気があったら、初心者にも解るよう書いてくれないか？
2CHでは図が入らないからどこかのＨＰでもいい。
何の説明も無しに「オブジェクト」「インスタンス」「メソッド」
などという用語が出ないような本当の初心者向きの説明。
それが解りやすければ>>1の方法論が優れてると証明も出来ると思うが。
54 ：デフォルトの名無しさん：03/06/20 13:29
ボトムアップで行くか、トップダウンで行くかの違いを言ってんだろうけど、
両方セットにしないとだめだよ。どっちかだけを見ておかしいとか言っても意味ない。
両方セットにしないとだめだよ。どっちかだけを見ておかしいとか言っても意味ない。
55 ：デフォルトの名無しさん：03/06/20 14:08
>>53
俺はアセンブラわからんのでCで説明させてくれ。
オブジェクト指向の基本は、データと、そのデータを処理する手続きを一緒くたにして管理することから始まるんだ。
#include <stdio.h>
typedef struct tagA{
void (*func)( tagA*pThis );
int data;
} A;
void print_A1( A*pThis ){ printf( "Hello %d\n", pThis->data ); }
void print_A2( A*pThis ){ printf( "Goodbye %d\n", pThis->data ); }
A gen_A1( int num ){ A result = { print_A1, num }; return result; }
A gen_A2( int num ){ A result = { print_A2, num }; return result; }
int main(void){
A a = gen_A1( 10 );
a.func( &a ); // ★１
a = gen_A2( 20 );
a.func( &a ); // ★２
{
A b = a;
b.func( &b ); // ★３
}
return 0;
}
★１と★２を見比べてくれ、まったく同じプログラムなのに出力結果は違う。新しく自分でgen_A3()を作れば、さらに違う動作をさせることも出来る。
★３も見てほしい、bにaを代入して関数を呼ぶと、★２と同じ結果が得られるんだ。もしデータと手続きを二元・三元管理していたら、手間が増えちゃって大変さ。
データと手続きをまとめた型Aをクラスといい、実際にその情報が格納されているaやbをインスタンス（実体）といい、データを処理するための手続きであるfuncをメソッド（手段）、aを初期化するために使ったgen_A1のような手続きをコンストラクタ（建築家）と呼んでる。
★１と★２のように、呼び出すコンストラクタによって振る舞いが代わることを利用して継承（すでにある機能を利用しつつさらに拡張したり異なった処理をすること）を行うんだ。場所が無いから継承については誰かに譲るよ。
俺はアセンブラわからんのでCで説明させてくれ。
オブジェクト指向の基本は、データと、そのデータを処理する手続きを一緒くたにして管理することから始まるんだ。
#include <stdio.h>
typedef struct tagA{
void (*func)( tagA*pThis );
int data;
} A;
void print_A1( A*pThis ){ printf( "Hello %d\n", pThis->data ); }
void print_A2( A*pThis ){ printf( "Goodbye %d\n", pThis->data ); }
A gen_A1( int num ){ A result = { print_A1, num }; return result; }
A gen_A2( int num ){ A result = { print_A2, num }; return result; }
int main(void){
A a = gen_A1( 10 );
a.func( &a ); // ★１
a = gen_A2( 20 );
a.func( &a ); // ★２
{
A b = a;
b.func( &b ); // ★３
}
return 0;
}
★１と★２を見比べてくれ、まったく同じプログラムなのに出力結果は違う。新しく自分でgen_A3()を作れば、さらに違う動作をさせることも出来る。
★３も見てほしい、bにaを代入して関数を呼ぶと、★２と同じ結果が得られるんだ。もしデータと手続きを二元・三元管理していたら、手間が増えちゃって大変さ。
データと手続きをまとめた型Aをクラスといい、実際にその情報が格納されているaやbをインスタンス（実体）といい、データを処理するための手続きであるfuncをメソッド（手段）、aを初期化するために使ったgen_A1のような手続きをコンストラクタ（建築家）と呼んでる。
★１と★２のように、呼び出すコンストラクタによって振る舞いが代わることを利用して継承（すでにある機能を利用しつつさらに拡張したり異なった処理をすること）を行うんだ。場所が無いから継承については誰かに譲るよ。
56 ：デフォルトの名無しさん：03/06/20 14:57
それじゃダメだろ。実装のテクニカルしかないじゃん。
機能のカプセル化とか、インタフェースとか、そういうことを理解しなくちゃオブジェクト指向とはいえない。
機能のカプセル化とか、インタフェースとか、そういうことを理解しなくちゃオブジェクト指向とはいえない。
57 ：デフォルトの名無しさん：03/06/20 15:12
>>56
一レスでそこまで出来ないよ
一レスでそこまで出来ないよ
58 ：デフォルトの名無しさん：03/06/21 01:35
>>55
ちょっと、そのソースを簡単に実行できる環境を探し中ｗ
今C勉強始めたばかりだけどC++のソースって大分違う。
ttp://homepage1.nifty.com/kentake/ のC++版みたいな
やつないですかね。
>>55で、とりあえず解ったこと。
「データと、そのデータを処理する手続きを一緒くたにして管理すると
なんか凄いメリットがあるらしいぞ」ｗ
ちょっと、そのソースを簡単に実行できる環境を探し中ｗ
今C勉強始めたばかりだけどC++のソースって大分違う。
ttp://homepage1.nifty.com/kentake/ のC++版みたいな
やつないですかね。
>>55で、とりあえず解ったこと。
「データと、そのデータを処理する手続きを一緒くたにして管理すると
なんか凄いメリットがあるらしいぞ」ｗ
59 ：デフォルトの名無しさん：03/06/21 06:44
どーーーせ、おいらはバカですよ！！！
60 ：デフォルトの名無しさん：03/06/21 07:11
append(foo, bar); // 非オブジェクト指向
foo.append(bar); // オブジェクト指向
>>58
結果的にはそうだよ。そうなる理由はね、名前空間の拡張があるからなのさ。
foo.append(bar);と、hoge.append(bar);は、別の関数を呼ぶかもしれない。同じかもしれない。
しかし、プログラマは気にせずに呼ぶことが出来る。二つは別々の名前空間にあり、重複しないからだ。
Cならば、append(Foo foo, Bar bar);とappend(Bar bar, Foo foo);を使っても同じ処理を書くことができる。
しかし名前空間が独立ではないから、もうひとつhoge用のappendを追加したいとき、困ってしまうだろう。
こうなると、hoge_appendとか、createWindowExとかやるしかない(w
オブジェクト指向なら、foo.append(bar);bar.append(foo);hoge.append(bar);hoge.append(foo);
を全て定義しても、衝突することが無い。オブジェクト指向は、
第一引数を特殊な名前空間として利用しているのだ。この特殊な第一引数、ピリオドの前の部分を、
まさにオブジェクトと呼ぶ。それを作るための定義がクラス(C語で言う、構造体や型の概念に近い)と呼ばれ、
実際にメモリ上に作られたものをインスタンスと呼ぶというわけだ。
foo.append(bar); // オブジェクト指向
>>58
結果的にはそうだよ。そうなる理由はね、名前空間の拡張があるからなのさ。
foo.append(bar);と、hoge.append(bar);は、別の関数を呼ぶかもしれない。同じかもしれない。
しかし、プログラマは気にせずに呼ぶことが出来る。二つは別々の名前空間にあり、重複しないからだ。
Cならば、append(Foo foo, Bar bar);とappend(Bar bar, Foo foo);を使っても同じ処理を書くことができる。
しかし名前空間が独立ではないから、もうひとつhoge用のappendを追加したいとき、困ってしまうだろう。
こうなると、hoge_appendとか、createWindowExとかやるしかない(w
オブジェクト指向なら、foo.append(bar);bar.append(foo);hoge.append(bar);hoge.append(foo);
を全て定義しても、衝突することが無い。オブジェクト指向は、
第一引数を特殊な名前空間として利用しているのだ。この特殊な第一引数、ピリオドの前の部分を、
まさにオブジェクトと呼ぶ。それを作るための定義がクラス(C語で言う、構造体や型の概念に近い)と呼ばれ、
実際にメモリ上に作られたものをインスタンスと呼ぶというわけだ。
61 ：デフォルトの名無しさん：03/06/21 07:14
このスレの冒頭の1の説明は糞だとおもう。
わかりづらいよ。
これならよくあるシューティングゲームや犬とか猫の話のがよっぽどわかりやすいよ。
わかりづらいよ。
これならよくあるシューティングゲームや犬とか猫の話のがよっぽどわかりやすいよ。
62 ：デフォルトの名無しさん：03/06/21 07:24
この拡張を利用することで、Hogeの、Hogeによる、Hogeのための関数
(おっと、オブジェクト指向ではクラス固有の関数をメソッドと呼ぶんだった。
ややこしいったらありゃしない。)を用意することができる。
Javaでは、hoge.append(bar);及びhoge.append(foo);として利用できるメソッドは、
以下のように書くことが出来る。
public class Hoge {
public void append(Foo foo) { /* 素敵なsomthing */ }
public void append(Bar bar) { /* 素敵なsomthing */ }
}
しかし、これでは関数の数が膨大になってプログラマが倒れてしまうだろう。
なにせ名前空間が拡張されたせいで、クラスごとにメソッドを書く必要が
あるのだ。すぐに200や2000のメソッドを書くことになりはしないだろうか。
いずれ横着者が現われて、バグ入りのメソッドをコピー&ペーストしはじめるのでは？
しかし安心して欲しい。こういうときのためにこそ、オブジェクト指向の提供する技術、
継承が利用できるのだ。
(おっと、オブジェクト指向ではクラス固有の関数をメソッドと呼ぶんだった。
ややこしいったらありゃしない。)を用意することができる。
Javaでは、hoge.append(bar);及びhoge.append(foo);として利用できるメソッドは、
以下のように書くことが出来る。
public class Hoge {
public void append(Foo foo) { /* 素敵なsomthing */ }
public void append(Bar bar) { /* 素敵なsomthing */ }
}
しかし、これでは関数の数が膨大になってプログラマが倒れてしまうだろう。
なにせ名前空間が拡張されたせいで、クラスごとにメソッドを書く必要が
あるのだ。すぐに200や2000のメソッドを書くことになりはしないだろうか。
いずれ横着者が現われて、バグ入りのメソッドをコピー&ペーストしはじめるのでは？
しかし安心して欲しい。こういうときのためにこそ、オブジェクト指向の提供する技術、
継承が利用できるのだ。
63 ：デフォルトの名無しさん：03/06/21 07:24
初めてC++のオブジェクト指向の本を読んで、
一体どんな高等な概念なんだろうと思ったけど、
自分が昔から考えてた概念そのままなんで拍子抜けした。
Cでプログラムしてた頃から、カプセル化したほうが管理しやすくて効率的だよなと思ってたんだけど。
どうしてみんな困惑してるのかわからん。
一体どんな高等な概念なんだろうと思ったけど、
自分が昔から考えてた概念そのままなんで拍子抜けした。
Cでプログラムしてた頃から、カプセル化したほうが管理しやすくて効率的だよなと思ってたんだけど。
どうしてみんな困惑してるのかわからん。
64 ：デフォルトの名無しさん：03/06/21 07:34
>>63
会社に入ってからわかったけど、ほとんどの人は設計が絶望的にヘタクソ。
会社に入ってからわかったけど、ほとんどの人は設計が絶望的にヘタクソ。
65 ：デフォルトの名無しさん：03/06/21 07:44
継承という技術が提供する概念は、非常に単純だ。
「見つからなかった場合、親のほうを探しに行く」ということだ。
さて恒例の仕様変更で、HogeとFooとBarのクラスにhelloworldメソッドを追加することになった。
しかも、全部同じ仕様なんだ。君は「いよいよコピペか？コピペなんだな？」と思うだろうが、それは違う。
こういうときには継承するのが一番だ。
public class HelloWorld {
public void helloworld() {
System.out.println("Hello, ObjectOriented!");
}
}
public class Hoge extends HelloWorld {}
public class Foo extends HelloWorld {}
public class Bar extends HelloWorld {}
これで、hoge.helloworld();のメソッド呼出しを行なうと、
自動的にHoge->HelloWorldとクラスの親方向にさかのぼっていき、
helloworldメソッドを探し出して実行してくれるようになる。コピペはいらないのだ。
もちろん、Hoge側でhelloworldを再定義することで、探しに行かないようにしたうえで
共通のhelloworldとは違う挙動にすることもできる。(これはメソッドのオーバーライドという。)
結局、継承は単なる手抜き手法であるとも言える。しかし、アプリケーション全体に影響を及ぼす
超重要な手抜き手法であるので、実際には今回のように安易に使うべきではない。
しかし、同じ動作をするメソッドを別々のクラスに書いているときには
設計がおかしいことがよくあるので、継承のことを思い出して欲しい。
「見つからなかった場合、親のほうを探しに行く」ということだ。
さて恒例の仕様変更で、HogeとFooとBarのクラスにhelloworldメソッドを追加することになった。
しかも、全部同じ仕様なんだ。君は「いよいよコピペか？コピペなんだな？」と思うだろうが、それは違う。
こういうときには継承するのが一番だ。
public class HelloWorld {
public void helloworld() {
System.out.println("Hello, ObjectOriented!");
}
}
public class Hoge extends HelloWorld {}
public class Foo extends HelloWorld {}
public class Bar extends HelloWorld {}
これで、hoge.helloworld();のメソッド呼出しを行なうと、
自動的にHoge->HelloWorldとクラスの親方向にさかのぼっていき、
helloworldメソッドを探し出して実行してくれるようになる。コピペはいらないのだ。
もちろん、Hoge側でhelloworldを再定義することで、探しに行かないようにしたうえで
共通のhelloworldとは違う挙動にすることもできる。(これはメソッドのオーバーライドという。)
結局、継承は単なる手抜き手法であるとも言える。しかし、アプリケーション全体に影響を及ぼす
超重要な手抜き手法であるので、実際には今回のように安易に使うべきではない。
しかし、同じ動作をするメソッドを別々のクラスに書いているときには
設計がおかしいことがよくあるので、継承のことを思い出して欲しい。
66 ：デフォルトの名無しさん：03/06/21 12:12
67 ：デフォルトの名無しさん：03/06/21 13:03
オブジェクト指向が理解できないってのは、プログラミングセンスが無いってことだよ。
68 ：デフォルトの名無しさん：03/06/21 13:26
オブジェクト指向の是非はともかく、
プログラミング技術として広く使われているのだから、
理解しなきゃ食ってけないわな。
プログラミング技術として広く使われているのだから、
理解しなきゃ食ってけないわな。
69 ：デフォルトの名無しさん：03/06/21 14:39
>>68
本末転倒なんだな、これが。
Ｃ言語の構造化プログラミングで試行錯誤した人が、オブジェクト指向という新しいパラダイムを勉強して、より良い設計・実装を身に付けていくのが本道。
それなのに今は必要だからと言って、構造化プログラミングもままならない人までも、いきなりオブジェクト指向しなくちゃならなくなる。
プログラムがシンプルだった時代を経ずに、いきなり複雑なライブラリを与えられてしまう新人さん達も、ある意味運が悪いといえる。
まぁ、がんがってくれとしかいえんわな。
本末転倒なんだな、これが。
Ｃ言語の構造化プログラミングで試行錯誤した人が、オブジェクト指向という新しいパラダイムを勉強して、より良い設計・実装を身に付けていくのが本道。
それなのに今は必要だからと言って、構造化プログラミングもままならない人までも、いきなりオブジェクト指向しなくちゃならなくなる。
プログラムがシンプルだった時代を経ずに、いきなり複雑なライブラリを与えられてしまう新人さん達も、ある意味運が悪いといえる。
まぁ、がんがってくれとしかいえんわな。
70 ：デフォルトの名無しさん：03/06/21 15:47
71 ：デフォルトの名無しさん：03/06/21 16:46
>>67
俺はオブジェクト指向をまだ理解してない（つーかC言語を
ちょうど始めたばっかり）から一般的な事しか言えないが。
外語大の学生に「何故英語が得意になったか？」とアンケートを
取ると「中学の時の先生が良かった」という答えが多かったそうだ。
学習者に勉強のおもしろさを気づかせる事も含め、教え方やテキスト
は非常に重要だと思う。俺は学習者の才能やセンスが必要なほどの勉強は
ごく一部だと考えてるよ。
例えば１冊に色々詰め込まなくてはいけなくなったからといって
「これでハローワールドが表示されましたね、さあ次はデータベースを
作ってみましょう」みたいな無茶な参考書は大嫌いだｗ
俺はオブジェクト指向をまだ理解してない（つーかC言語を
ちょうど始めたばっかり）から一般的な事しか言えないが。
外語大の学生に「何故英語が得意になったか？」とアンケートを
取ると「中学の時の先生が良かった」という答えが多かったそうだ。
学習者に勉強のおもしろさを気づかせる事も含め、教え方やテキスト
は非常に重要だと思う。俺は学習者の才能やセンスが必要なほどの勉強は
ごく一部だと考えてるよ。
例えば１冊に色々詰め込まなくてはいけなくなったからといって
「これでハローワールドが表示されましたね、さあ次はデータベースを
作ってみましょう」みたいな無茶な参考書は大嫌いだｗ
72 ：デフォルトの名無しさん：03/06/21 19:23
ははは
高校の数学の先生がそんなんだったなあ。
おかげで数学の成績がた落ち。
高校の数学の先生がそんなんだったなあ。
おかげで数学の成績がた落ち。
73 ：デフォルトの名無しさん：03/06/22 13:31
例えば
FlexGridとTextBoxを貼り付けたActiveXコントロールを作るよね
FlexGridのカーソル位置のあたいをTextBoxに表示するだけ。
そんな新しいコントロールを作った場合、
FlexGridとTextBoxを多重継承したっていうのか？
Javaでは多重継承できないって言うけど、こんなことも
できないんか？
FlexGridとTextBoxを貼り付けたActiveXコントロールを作るよね
FlexGridのカーソル位置のあたいをTextBoxに表示するだけ。
そんな新しいコントロールを作った場合、
FlexGridとTextBoxを多重継承したっていうのか？
Javaでは多重継承できないって言うけど、こんなことも
できないんか？
74 ：デフォルトの名無しさん：03/06/22 14:31
それは継承ではなく、オブジェクトコンポジションという。
75 ：デフォルトの名無しさん：03/06/22 15:52
>>55
>>★１と★２を見比べてくれ、まったく同じプログラムなのに
>>出力結果は違う。新しく自分でgen_A3()を作れば、さらに違う動作をさせることも出来る。
なんだか自慢気だが、それは駄目なところなんだって。
同じ記述をしたのに違う動作をするということは、そこの記述を
見ただけでは動作がわからない、ということ。
読む人にとっては困るだけ。
基本的に、カプセル化はデータ抽象を実現するためにある。
プログラムを読む人を戸惑わせるような使い方をするべきでない。
>>★１と★２を見比べてくれ、まったく同じプログラムなのに
>>出力結果は違う。新しく自分でgen_A3()を作れば、さらに違う動作をさせることも出来る。
なんだか自慢気だが、それは駄目なところなんだって。
同じ記述をしたのに違う動作をするということは、そこの記述を
見ただけでは動作がわからない、ということ。
読む人にとっては困るだけ。
基本的に、カプセル化はデータ抽象を実現するためにある。
プログラムを読む人を戸惑わせるような使い方をするべきでない。
76 ：デフォルトの名無しさん：03/06/22 16:16
動作は違っているだろうが、概念上同じ仕事をさせることができる
つーのがミソなわけだが。
つーのがミソなわけだが。
77 ：デフォルトの名無しさん：03/07/08 22:16
オブジェクト指向は創始されてからすでに３０年経ち、もはや古臭い感は
否めない。構造化→ＯＯＰ→に続くﾌﾟﾛｸﾞﾗﾐﾝｸﾞ手法第３の変革が必要だ。
今こそをそれを提唱しよう。その名は
78 ：デフォルトの名無しさん：03/07/08 22:41
ビッグオー
79 ：デフォルトの名無しさん：03/07/08 22:44
サイテイダワ
80 ：デフォルトの名無しさん：03/07/08 22:51
>>70
69では無いが、この間いっしょに仕事をした人間にトンデモないのがいたので、ちょっと
OOPから始めてできるつもりになっている奴のプログラムは、
とんでもないスパゲティープログラムを作る事がある、
そのスパゲティーぶりたるや、構造化プログラミング言語のスパゲッティーの比ではないよ。
goto 文の嵐は気張れば読めるがOOPのスパゲティーは破滅的に読めなくなる。
意味無く散乱したオブジェクトは洒落にならないです。
OOなら万能なんて絶対考えないほうがいい、むしろ危険度は高いと思ったほうがいい。
69では無いが、この間いっしょに仕事をした人間にトンデモないのがいたので、ちょっと
OOPから始めてできるつもりになっている奴のプログラムは、
とんでもないスパゲティープログラムを作る事がある、
そのスパゲティーぶりたるや、構造化プログラミング言語のスパゲッティーの比ではないよ。
goto 文の嵐は気張れば読めるがOOPのスパゲティーは破滅的に読めなくなる。
意味無く散乱したオブジェクトは洒落にならないです。
OOなら万能なんて絶対考えないほうがいい、むしろ危険度は高いと思ったほうがいい。
81 ：デフォルトの名無しさん：03/07/08 22:55
82 ：デフォルトの名無しさん：03/07/08 22:55
設計段階でレビューとかしないんだろうか？
設計をコードに落としやすいのも利点だと思うが
設計をコードに落としやすいのも利点だと思うが
83 ：デフォルトの名無しさん：03/07/08 22:59
>>65
そんな例で継承するのは馬鹿がすることですよ。
メソッドシグネチャを追加するくらいは我慢して、コンポジッションに
するのが基本です。
継承が本当の本当に必要なのは、多態処理を整理して記述したい時だけですお。
そんな例で継承するのは馬鹿がすることですよ。
メソッドシグネチャを追加するくらいは我慢して、コンポジッションに
するのが基本です。
継承が本当の本当に必要なのは、多態処理を整理して記述したい時だけですお。
たぶんVisitorパターンを知らないで、Visitorパターンなコードを読むと
「きったねーなぁ」とか思っちゃうと思う。
AbstractFactoryとかも。
「きったねーなぁ」とか思っちゃうと思う。
AbstractFactoryとかも。
85 ：デフォルトの名無しさん：03/07/08 23:15
>>81
最近増えているんですよ
オブジェクト指向言語は使えてもデザパタが理解できないで信じられないような物を作る奴が・・・・
構造化プログラミングができるなら、まぁ変なクセはあっても読めるんだけどね、
最初からOOPをしている奴の中には、見た瞬間に絶叫したくなるようなプログラムを書く人間がいるんですよ。
最近増えているんですよ
オブジェクト指向言語は使えてもデザパタが理解できないで信じられないような物を作る奴が・・・・
構造化プログラミングができるなら、まぁ変なクセはあっても読めるんだけどね、
最初からOOPをしている奴の中には、見た瞬間に絶叫したくなるようなプログラムを書く人間がいるんですよ。
>85
それは、「最初からOOPだから」変なコードを書いてるんじゃなくて
単に「経験が少ないから」変なコードになっちゃったんじゃないかなぁ。
とか思う。
それは、「最初からOOPだから」変なコードを書いてるんじゃなくて
単に「経験が少ないから」変なコードになっちゃったんじゃないかなぁ。
とか思う。
87 ：デフォルトの名無しさん：03/07/08 23:26
88 ：デフォルトの名無しさん：03/07/08 23:29
いきなりOOPとか言われても教えるほうも困るよな。
絶対main関数だけのプログラミングから始まるんだろ？
それってOOPか？
絶対main関数だけのプログラミングから始まるんだろ？
それってOOPか？
91 ：デフォルトの名無しさん：03/07/08 23:33
設計段階で、雑にでいいからクラス図書いて、そのとおりつくるところから
はじめれば、多少の試行錯誤は発生するにしても、あんまりトンデモな結果
にはならないとおもうけどな。
OOPなんて大げさに言うけど、実装レベルまで落とし込んで見れば、結局
のところ「分割した処理ロジックを、それぞれどこに書くか」ということ
でしかないような気がする今日この頃。最近の賢いIDEのおかげで、メソ
ッドの抽出、移動もクラスの分割、統合もすごいﾗｸﾁﾝにできるからねえ。
リファクタリング支援マンセー。
はじめれば、多少の試行錯誤は発生するにしても、あんまりトンデモな結果
にはならないとおもうけどな。
OOPなんて大げさに言うけど、実装レベルまで落とし込んで見れば、結局
のところ「分割した処理ロジックを、それぞれどこに書くか」ということ
でしかないような気がする今日この頃。最近の賢いIDEのおかげで、メソ
ッドの抽出、移動もクラスの分割、統合もすごいﾗｸﾁﾝにできるからねえ。
リファクタリング支援マンセー。
92 ：デフォルトの名無しさん：03/07/08 23:35
インターフェース境界の設定と
責任の所在の明確化
これが済めばあとは大体なすがままっちゅう感じかなあ
責任の所在の明確化
これが済めばあとは大体なすがままっちゅう感じかなあ
93 ：デフォルトの名無しさん：03/07/08 23:41
>>91
メソッドの抽出って、IDEが支援してくれるのですか？
例えば、いろんなトコから"そっくりなコード"を見つけてくれたりとかですか？
だったらすげーな。欲しい。名前教えて～くだされぇ
>>92
インタフェース協会って何ぞぇ？IEEEみたいの？
メソッドの抽出って、IDEが支援してくれるのですか？
例えば、いろんなトコから"そっくりなコード"を見つけてくれたりとかですか？
だったらすげーな。欲しい。名前教えて～くだされぇ
>>92
インタフェース協会って何ぞぇ？IEEEみたいの？
95 ：デフォルトの名無しさん：03/07/08 23:49
96 ：デフォルトの名無しさん：03/07/09 00:13
IDEは便利だけど弊害にもなると思うな。
ウィザードでclass宣言もメンバの雛型も自動生成されちゃうと、コードを倫理的に配置する能力が培われない。
OOPの話じゃないかもしれないけど、やっぱり手で全部書いてみる経験は大事だよ。
ウィザードでclass宣言もメンバの雛型も自動生成されちゃうと、コードを倫理的に配置する能力が培われない。
OOPの話じゃないかもしれないけど、やっぱり手で全部書いてみる経験は大事だよ。
97 ：デフォルトの名無しさん：03/07/09 23:55
あーみーどーにー蟲こーない
98 ：デフォルトの名無しさん：03/07/10 16:29
>>87
それはある。
以前どっかで公開されてたDirectXのラッパーライブラリのソースがまさに破滅的だった。
あっち行ってこっち行って、処理対象がthisではなくてパラメータだったりする。（Visitorに非ず）
俺は自分でOO信者だと思ってるけど、今まで非OOであれほどひどいものは見たこと無いからな・・・。
それはある。
以前どっかで公開されてたDirectXのラッパーライブラリのソースがまさに破滅的だった。
あっち行ってこっち行って、処理対象がthisではなくてパラメータだったりする。（Visitorに非ず）
俺は自分でOO信者だと思ってるけど、今まで非OOであれほどひどいものは見たこと無いからな・・・。
99 ：デフォルトの名無しさん：03/07/11 08:20
オブジェクト指向とコンポーネント指向の違いについて教えてください
100 ：デフォルトの名無しさん：03/07/11 08:22
コンポーネントは完結する。
オブジェクトはやりとりする。
オブジェクトはやりとりする。
101 ：デフォルトの名無しさん：03/07/11 10:14
コンポーネント指向は、オブジェクト指向の延長でしょう。
関連のあるデータと振る舞いをカプセル化したのが、
オブジェクト指向で、
関連のあるオブジェクトを1つにまとめて(コンポーネント化)
再利用していくのが、コンポーネント指向。
関連のあるデータと振る舞いをカプセル化したのが、
オブジェクト指向で、
関連のあるオブジェクトを1つにまとめて(コンポーネント化)
再利用していくのが、コンポーネント指向。
102 ：デフォルトの名無しさん：03/07/11 11:20
コンポーネント指向がオブジェクト指向の延長？むしろ逆じゃない？
構造体→抽象データ型→オブジェクト指向という流れの途中で、
「オブジェクト指向まで行かなくてもいいじゃん」と言って
抽象データ型から枝分かれしたのがコンポーネント指向だと思う。
時系列に並べて考えるなら延長と見れなくも無いけど、概念的には退化してる。
ま、退化したから悪いって訳ではなくて、「不必要に行き過ぎたから戻った」
ということではないかな。
構造体→抽象データ型→オブジェクト指向という流れの途中で、
「オブジェクト指向まで行かなくてもいいじゃん」と言って
抽象データ型から枝分かれしたのがコンポーネント指向だと思う。
時系列に並べて考えるなら延長と見れなくも無いけど、概念的には退化してる。
ま、退化したから悪いって訳ではなくて、「不必要に行き過ぎたから戻った」
ということではないかな。
103 ：デフォルトの名無しさん：03/07/11 14:16
104 ：デフォルトの名無しさん：03/07/11 21:15
コンポーネント指向とサービス指向の違いについて教えてください。
105 ：デフォルトの名無しさん：03/07/11 23:21
Property は OO 的じゃないって聞いたんですけど何ででしょうか？
106 ：デフォルトの名無しさん：03/07/12 01:11
簡単なウィンドウシステムとか良い練習になりませんか？
class CControl
class CWnd : public CControl
class CButton : public CControl
とか作って CWndでCControl(各種コントロール)のインスタンスを管理したりして
具体的なコントロールは、CControlから派生させると
継承, 仮想関数, カプセル化とか、ひと通り勉強出来ると思うのですが。
class CControl
class CWnd : public CControl
class CButton : public CControl
とか作って CWndでCControl(各種コントロール)のインスタンスを管理したりして
具体的なコントロールは、CControlから派生させると
継承, 仮想関数, カプセル化とか、ひと通り勉強出来ると思うのですが。
107 ：デフォルトの名無しさん：03/07/12 10:59
>>102
OOとOOPをごっちゃにしてないかい。
抽象データ型、継承、多態といったものは、OOPの性質。
OOの本質は、関連のあるデータや振る舞いをモジュールに集め、
モジュールの凝集度をage、モジュール間の結合度をsageることで、
再利用性を高め、変更に強くするということ。
コンポーネント指向もその延長であり、モジュールの粒度がより大きくなったもの。
OOとOOPをごっちゃにしてないかい。
抽象データ型、継承、多態といったものは、OOPの性質。
OOの本質は、関連のあるデータや振る舞いをモジュールに集め、
モジュールの凝集度をage、モジュール間の結合度をsageることで、
再利用性を高め、変更に強くするということ。
コンポーネント指向もその延長であり、モジュールの粒度がより大きくなったもの。
109 ：デフォルトの名無しさん：03/07/12 12:54
>>108
ファザードは、クライアントに対して、内部の複雑さをかくし、
シンプルなインターフェースを提供するものだから、
ちょっと違うと思うけど、
オブジェクトコンポジションは、コンポーネントを実装する
1つの手段。
ファザードは、クライアントに対して、内部の複雑さをかくし、
シンプルなインターフェースを提供するものだから、
ちょっと違うと思うけど、
オブジェクトコンポジションは、コンポーネントを実装する
1つの手段。
110 ：デフォルトの名無しさん：03/07/12 13:01
>>105
言語にもよるけど、カプセル化って意味で別に問題ないと思うけど。
言語にもよるけど、カプセル化って意味で別に問題ないと思うけど。
112 ：デフォルトの名無しさん：03/07/12 18:43
>>105
PureJava厨の戯言
PureJava厨の戯言
__∧＿∧_
|（ ＾＾ ）| ＜寝るぽ（＾＾）
|＼⌒⌒⌒＼
＼ |⌒⌒⌒~| 山崎渉
~￣￣￣￣
114 ：デフォルトの名無しさん：03/07/24 19:12
Delphi サイコー
（＾＾）
(⌒V⌒)
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
117 ：デフォルトの名無しさん：03/08/24 15:33
続かせないよ!
118 ：デフォルトの名無しさん：03/08/30 00:56
>>117
安心しろ続ける根性ある椰子はいないとおもわれ
安心しろ続ける根性ある椰子はいないとおもわれ
119 ：デフォルトの名無しさん：03/09/07 18:32
もっとオブジェクト指向のこと知りたい！勉強したい！
120 ：デフォルトの名無しさん ：03/09/07 20:22
スレの流れから逸脱するが
1の本ってソフトからでてるやつだろ？俺も意味わからんかった
りんごがどうとかフルーツがどうとか 銀行の例もくそ わかりづらい
まっ俺があほなだけだが。
スイッチをつかった例は具体的にイメージができたきがするわ
1の本ってソフトからでてるやつだろ？俺も意味わからんかった
りんごがどうとかフルーツがどうとか 銀行の例もくそ わかりづらい
まっ俺があほなだけだが。
スイッチをつかった例は具体的にイメージができたきがするわ
121 ：デフォルトの名無しさん：03/09/07 22:48
とりあえず、C++だけど、ダメダメな例。
http://www.jalix.org/projects/showimg/
A∋B,D,C な状態で、さらに B∋a,b,cとなっている、
このa,b,c が DやCの要素を直接操作するもんだから、も～。
わけわかめ。
http://www.jalix.org/projects/showimg/
A∋B,D,C な状態で、さらに B∋a,b,cとなっている、
このa,b,c が DやCの要素を直接操作するもんだから、も～。
わけわかめ。
122 ：デフォルトの名無しさん：03/09/08 10:01
オブジェクト指向を理解できたかどうかを確認する
問題＆解説キボン
問題＆解説キボン
123 ：デフォルトの名無しさん：03/09/08 18:20
イベントどんぶりについて
124 ：デフォルトの名無しさん：03/09/09 05:38
なんかこのｽﾚ読んだら、自分がオブジェクト指向を理解してないように思えてきた…。
鬱…。
鬱…。
125 ：デフォルトの名無しさん：03/09/09 06:24
つーかさ、物志向のやつって多くない？
オブジェクト=物でしか考えられないやつ
オブジェクトは別に物だけじゃない
オブジェクト=物でしか考えられないやつ
オブジェクトは別に物だけじゃない
126 ：デフォルトの名無しさん：03/09/09 07:33
オブジェクト=物ですが何か？
OOのテクニックの中で物以外もオブジェクトに見立てるようになってきただけでしょう。
OOのテクニックの中で物以外もオブジェクトに見立てるようになってきただけでしょう。
127 ：デフォルトの名無しさん：03/09/09 07:36
128 ：デフォルトの名無しさん：03/09/09 07:45
オブジェクト指向の本質は、
関連のあるデータや振る舞いを1つにまとめ、
機能の凝集度をあげ、機能間の結合度を下げること。
ものに見立てることじゃないよ。
関連のあるデータや振る舞いを1つにまとめ、
機能の凝集度をあげ、機能間の結合度を下げること。
ものに見立てることじゃないよ。
129 ：デフォルトの名無しさん：03/09/09 08:46
俺は>47と>69と同じこと思ってる。
また、最初の言語はCで、1年前に始めたんだけど、
構造化プログラミングとかだと、どうしても万能な関数を作ろうとするんだよな。
引数やらもかなーーーーり考えないといけないし。
んで、こんなんどうやったらめんどくならないかなーって、考え付いたことは、
１：構造体に関数をかけないか？
２：万能な関数を作ろうとしてしまうので、同名の関数でも引数の違いにより
違う処理をしたい。だがやりたいことは同じである。小さなカスタマイズ程度でおけ。グラやら登録情報等。
２は、引数にモード(mode)を持たせて、１ならこれ２ならこれと分けるようにしてたんだけど、後でわけわかめ。
で、先生に聞いたらさ。あー。オブジェクト指向そろそろ学ぶ時期かもな。
って言われたのさ。
このスレのいろんな発言見て、俺はこの先生につけてよかったと思えてる。
様々な新しい技術は、既存の技術の不具合(プログラムしにくい)
飛躍させたい。とか思って、考え出される物だよね？
いろーーんな人達の知恵が集まって出来たことだから、「使えない」「わからない」ってのは、
自分がどうプログラミングしているのか、わかってない人達なんじゃないかな
また、最初の言語はCで、1年前に始めたんだけど、
構造化プログラミングとかだと、どうしても万能な関数を作ろうとするんだよな。
引数やらもかなーーーーり考えないといけないし。
んで、こんなんどうやったらめんどくならないかなーって、考え付いたことは、
１：構造体に関数をかけないか？
２：万能な関数を作ろうとしてしまうので、同名の関数でも引数の違いにより
違う処理をしたい。だがやりたいことは同じである。小さなカスタマイズ程度でおけ。グラやら登録情報等。
２は、引数にモード(mode)を持たせて、１ならこれ２ならこれと分けるようにしてたんだけど、後でわけわかめ。
で、先生に聞いたらさ。あー。オブジェクト指向そろそろ学ぶ時期かもな。
って言われたのさ。
このスレのいろんな発言見て、俺はこの先生につけてよかったと思えてる。
様々な新しい技術は、既存の技術の不具合(プログラムしにくい)
飛躍させたい。とか思って、考え出される物だよね？
いろーーんな人達の知恵が集まって出来たことだから、「使えない」「わからない」ってのは、
自分がどうプログラミングしているのか、わかってない人達なんじゃないかな
130 ：デフォルトの名無しさん：03/09/09 10:56
>>129
違うよ。新しい技術は楽したいから生み出されるんだよ。
例えば、インタフェースを決めて馬鹿に作らせる。
作った物が散らばらない用に一箇所にまとめさせて、後でそれを丸
ごと入れ替えるんだよ。
インターフェースを一緒にしとけば、丸ごと入れ替えられるからね。
使えない奴を隔離するためにOOを使うんだよ。
違うよ。新しい技術は楽したいから生み出されるんだよ。
例えば、インタフェースを決めて馬鹿に作らせる。
作った物が散らばらない用に一箇所にまとめさせて、後でそれを丸
ごと入れ替えるんだよ。
インターフェースを一緒にしとけば、丸ごと入れ替えられるからね。
使えない奴を隔離するためにOOを使うんだよ。
131 ：デフォルトの名無しさん：03/09/09 11:53
DLLがいっぱいあるのはOOオブジェクト指向なんですか？
132 ：デフォルトの名無しさん：03/09/09 12:06
>>131 オーバレイ。
133 ：デフォルトの名無しさん：03/09/09 12:10
>>131
大場 怜
大場 怜
134 ：デフォルトの名無しさん：03/09/09 15:07
>>126
＞オブジェクト=物ですが何か？
＞OOのテクニックの中で物以外もオブジェクトに見立てるようになってきただけでしょう。
一行目と2行目は同じ人の考えですか？
言ってることがつじつまあわないんですが・・・
＞オブジェクト=物ですが何か？
＞OOのテクニックの中で物以外もオブジェクトに見立てるようになってきただけでしょう。
一行目と2行目は同じ人の考えですか？
言ってることがつじつまあわないんですが・・・
135 ：デフォルトの名無しさん：03/09/09 16:44
オブジェクト指向は最終的こうなる
object.write('いけてるOSとコマンド。あとゲームとかも出来たら。').run
object.write('いけてるOSとコマンド。あとゲームとかも出来たら。').run
136 ：デフォルトの名無しさん：03/09/09 21:16
＞言ってることがつじつまあわないんですが・・・
どこがどうつじつまが合わないんですか？
あなたの脳内の事なんて他人にはわかりませんよ。
どこがどうつじつまが合わないんですか？
あなたの脳内の事なんて他人にはわかりませんよ。
137 ：デフォルトの名無しさん：03/09/09 21:42
>>136
つじつまあわないその理由１
＞オブジェクト=物ですが何か？
「オブジェクト=物」と発言しているにもかかわらず
＞OOのテクニックの中で
「物以外もオブジェクトに見立てるようになってきただけでしょう。」
といっている。
どうせ言うなら1行目は、「オブジェクト＞=物」や「オブジェクト⊇物」と書くべき
つじつまあわないその理由２
さらに、この発言（>>126）は「オブジェクト=物ですが何か？」と書いている
この表現は>>125の意見に疑問を感じる時に発言する表現。
なのに2行目で言っていることは125が言っていることと同意である。
１行目で、疑問を抱きながら２行目で同意意見を言うのはつじつまあわない
つじつまあわないその理由１
＞オブジェクト=物ですが何か？
「オブジェクト=物」と発言しているにもかかわらず
＞OOのテクニックの中で
「物以外もオブジェクトに見立てるようになってきただけでしょう。」
といっている。
どうせ言うなら1行目は、「オブジェクト＞=物」や「オブジェクト⊇物」と書くべき
つじつまあわないその理由２
さらに、この発言（>>126）は「オブジェクト=物ですが何か？」と書いている
この表現は>>125の意見に疑問を感じる時に発言する表現。
なのに2行目で言っていることは125が言っていることと同意である。
１行目で、疑問を抱きながら２行目で同意意見を言うのはつじつまあわない
138 ：デフォルトの名無しさん：03/09/09 21:52
>>137
国語の授業をちゃんと受けてればそういう考えにならないと思うけど。
物以外もオブジェクトに見立てる っていうのは
物と、それ以外 （つまり、全ての物および機能）を
物と見立てる ということですよ。
まあそれはそれで、俺としてはその意見には異を唱えたいところだけど
それ以前の問題として議論に参加する資格のない知能障害>>137は
半島に帰れ。
国語の授業をちゃんと受けてればそういう考えにならないと思うけど。
物以外もオブジェクトに見立てる っていうのは
物と、それ以外 （つまり、全ての物および機能）を
物と見立てる ということですよ。
まあそれはそれで、俺としてはその意見には異を唱えたいところだけど
それ以前の問題として議論に参加する資格のない知能障害>>137は
半島に帰れ。
だから、そう言ってるんですが・・・125（俺）は・・・
なんか＞オブジェクト=物ですが何か？
といわれて125に反論しているみたいで嫌だ
なんか＞オブジェクト=物ですが何か？
といわれて125に反論しているみたいで嫌だ
>>138＞物と、それ以外 （つまり、全ての物および機能）を
俺の言ってることとは微妙に違う
機能でオブジェクトを見立てる方法と、物としてオブジェクトを見立てる方法
の2つのアプローチ（あるいは混在）があるとおれは言っている
俺の言ってることとは微妙に違う
機能でオブジェクトを見立てる方法と、物としてオブジェクトを見立てる方法
の2つのアプローチ（あるいは混在）があるとおれは言っている
142 ：デフォルトの名無しさん：03/09/09 22:41
畜生出遅れた！
おら、もう誰もいないのか？来いよ
おら、もう誰もいないのか？来いよ
143 ：デフォルトの名無しさん：03/09/10 00:22
まあ結論としてオブジェクトは物じゃないんだけどね
オブジェクトってのはアラン・ケイ博士の頭の中にある
SmallTalkの「オブジェクト」を説明するために作られた抽象的な概念そのもの。
物とか物体って言うのが近いかもしれないがオブジェクトはオブジェクトだよ。
美術館にあるわけわからん置物をオブジェって言うけどオブジェ＝置物って
言うかというとそうでもないだろ？
オブジェクトってのはアラン・ケイ博士の頭の中にある
SmallTalkの「オブジェクト」を説明するために作られた抽象的な概念そのもの。
物とか物体って言うのが近いかもしれないがオブジェクトはオブジェクトだよ。
美術館にあるわけわからん置物をオブジェって言うけどオブジェ＝置物って
言うかというとそうでもないだろ？
144 ：デフォルトの名無しさん：03/09/10 02:02
>>143
いや原義は オブジェクト==物 だろ？(英単語の日本語訳という意味ではない)
つまり 認識可能な物==物(オブジェクト) が原義。
最近は関数オブジェクトだのポリシーだのトレイツだの
原義のオブジェクトではない 概念 や 動作 までクラスとして定義するテクニックが流行っているだけで。
いや原義は オブジェクト==物 だろ？(英単語の日本語訳という意味ではない)
つまり 認識可能な物==物(オブジェクト) が原義。
最近は関数オブジェクトだのポリシーだのトレイツだの
原義のオブジェクトではない 概念 や 動作 までクラスとして定義するテクニックが流行っているだけで。
145 ：デフォルトの名無しさん：03/09/10 02:20
146 ：デフォルトの名無しさん：03/09/10 03:47
147 ：デフォルトの名無しさん：03/09/10 07:46
オブジェクトは、対象 or 物で良いと思うでつ。
データ構造をもとにモジュール化されているのが、
オブジェクト指向のスタートでつ。
データ構造をもとにモジュール化されているのが、
オブジェクト指向のスタートでつ。
148 ：デフォルトの名無しさん：03/09/11 02:15
>>143
オブジェクト自体は Simula-67 で提案されたものなので
それはちょっと違います。でも大筋では合っているかなとも。
ttp://marimpod.homeip.net/chomswiki/24
Simula-67 の段階ではオブジェクト指向という考え方は
まだなくて、単にユーザーが型を定義できる…程度に
とらえられていました。このオブジェクトが、自らが含む
メソッドを起動する様子をメッセージングというメタファ
に置き換えて独特の世界を作り上げたのが Smalltalk
とそこでのオブジェクト指向です。
他方で C++ は、C にクラスとテンプレートがあれば、
つまり Simula-67 のそれを若干整備すれば、Smalltalk ほど
極端なことをしなくともオブジェクトの特性を活用した
プログラミングは可能だとして、情報隠蔽や、継承、
動的結合などの要素を有する C++ のオブジェクト指向
というコンセンサスを得ました。
これだけなら問題はなかったのでしょうが、同じ
オブジェクト指向ということで、C++ でオブジェクト指向
するのに、Smalltalk のメタファを使った説明をしたり
する人が出てきて、混乱が生じてしまったのでしょう。
オブジェクト自体は Simula-67 で提案されたものなので
それはちょっと違います。でも大筋では合っているかなとも。
ttp://marimpod.homeip.net/chomswiki/24
Simula-67 の段階ではオブジェクト指向という考え方は
まだなくて、単にユーザーが型を定義できる…程度に
とらえられていました。このオブジェクトが、自らが含む
メソッドを起動する様子をメッセージングというメタファ
に置き換えて独特の世界を作り上げたのが Smalltalk
とそこでのオブジェクト指向です。
他方で C++ は、C にクラスとテンプレートがあれば、
つまり Simula-67 のそれを若干整備すれば、Smalltalk ほど
極端なことをしなくともオブジェクトの特性を活用した
プログラミングは可能だとして、情報隠蔽や、継承、
動的結合などの要素を有する C++ のオブジェクト指向
というコンセンサスを得ました。
これだけなら問題はなかったのでしょうが、同じ
オブジェクト指向ということで、C++ でオブジェクト指向
するのに、Smalltalk のメタファを使った説明をしたり
する人が出てきて、混乱が生じてしまったのでしょう。
149 ：デフォルトの名無しさん：03/09/11 16:31
>>148
C++はSmallTalkのオブジェクト指向をつまみ食いしてさらに
OS元来の機能を取り込んでしまってもはやオブジェクト指向だけでは
説明できないものをオブジェクトってよんでるんだね
OSを隠蔽するという点についてまったく逆の思想で作られてるが面白い
関数オブジェクトとかSmallTalkでは存在しないんだからオブジェクト指向的ではないと思う
ただ、そこらへんをActorモデルみたいな抽象的な概念で説明できたら
また別のなんちゃら指向ってのができるんじゃないのかな?
C++はSmallTalkのオブジェクト指向をつまみ食いしてさらに
OS元来の機能を取り込んでしまってもはやオブジェクト指向だけでは
説明できないものをオブジェクトってよんでるんだね
OSを隠蔽するという点についてまったく逆の思想で作られてるが面白い
関数オブジェクトとかSmallTalkでは存在しないんだからオブジェクト指向的ではないと思う
ただ、そこらへんをActorモデルみたいな抽象的な概念で説明できたら
また別のなんちゃら指向ってのができるんじゃないのかな?
150 ：デフォルトの名無しさん：03/09/11 16:34
r ‐､
| ○ | r‐‐､
_,;ﾄ - ｲ、 ∧l☆│∧ 良い子の諸君！
（⌒` ⌒・ ¨,､,,ﾄ.-ｲ/,､ l オブジェクト指向も所詮ただの「道具」だ。
|ヽ ~~⌒γ⌒） r'⌒ ｀!´ `⌒） そればかりに拘らずTPOに応じ臨機応変に使い
│ ヽー―'^ー-' （ ⌒γ⌒~~ /| 不適切な局面ではキッパリ捨てる勇気を持て！
│ 〉 |│ |｀ー^ｰ― r' |
│ /───| | |/ | l ﾄ､ |
| irｰ-､ ｰ ,} | / i
| / ｀X´ ヽ / 入
| ○ | r‐‐､
_,;ﾄ - ｲ、 ∧l☆│∧ 良い子の諸君！
（⌒` ⌒・ ¨,､,,ﾄ.-ｲ/,､ l オブジェクト指向も所詮ただの「道具」だ。
|ヽ ~~⌒γ⌒） r'⌒ ｀!´ `⌒） そればかりに拘らずTPOに応じ臨機応変に使い
│ ヽー―'^ー-' （ ⌒γ⌒~~ /| 不適切な局面ではキッパリ捨てる勇気を持て！
│ 〉 |│ |｀ー^ｰ― r' |
│ /───| | |/ | l ﾄ､ |
| irｰ-､ ｰ ,} | / i
| / ｀X´ ヽ / 入
151 ：デフォルトの名無しさん：03/09/11 22:15
偉そうに知ったかぶってるがSmallTalkなんていう言語はこの世にはないわけで、
君もSmalltalkerではないわけで、そんなの簡単にバレバレ。
C/C++はOS非依存だし(いいことばかりではない、そのせいでファイルシステムを扱う仕組みがない)
C++の仕様とMS謹製ライブラリの区別もつかないような君の脳内理論は
まともな人間なら誰もとりあわない。
単なる言語(実際には環境だが)のSmalltalkとオブジェクト指向というパラダイムそのものを
同一視してSmalltalkを神聖化しようとしている時点で思考回路が妖しすぎ。
まずはSmalltalkでもC++でもRUBYでもいいから何か一つでもまともに使えるようになってみれば？
君もSmalltalkerではないわけで、そんなの簡単にバレバレ。
C/C++はOS非依存だし(いいことばかりではない、そのせいでファイルシステムを扱う仕組みがない)
C++の仕様とMS謹製ライブラリの区別もつかないような君の脳内理論は
まともな人間なら誰もとりあわない。
単なる言語(実際には環境だが)のSmalltalkとオブジェクト指向というパラダイムそのものを
同一視してSmalltalkを神聖化しようとしている時点で思考回路が妖しすぎ。
まずはSmalltalkでもC++でもRUBYでもいいから何か一つでもまともに使えるようになってみれば？
152 ：デフォルトの名無しさん：03/09/12 02:09
>>151
まあまあ…。
たしかに 149 は、Smalltalk なんか未来永劫使わない、とか、
Smalltalker のつっこみなんかおそれないというのでも
ないなら、t は小文字で覚えておいたほうがよいかもね。
まあまあ…。
たしかに 149 は、Smalltalk なんか未来永劫使わない、とか、
Smalltalker のつっこみなんかおそれないというのでも
ないなら、t は小文字で覚えておいたほうがよいかもね。
153 ：デフォルトの名無しさん：03/09/13 05:16
メッセージを介したオブジェクトインスタンスの相互作用についての話が
あんまり出てこないやね。
単品で完結してるオブジェクトなんて面白くねぇ。
はふ～、インターネットは壮大なオブジェクト世界でええのぅ。
最も、ここの部分勘違いして、"すぱげっち"になってる
腐った例はいくつか出ているな(w
この腐ったれ共を考えるに、メッセージとオブジェクト、
まっとうなオブジェクト指向コーディングするために、
かなり重要な基礎概念ではなかろうか?
あんまり出てこないやね。
単品で完結してるオブジェクトなんて面白くねぇ。
はふ～、インターネットは壮大なオブジェクト世界でええのぅ。
最も、ここの部分勘違いして、"すぱげっち"になってる
腐った例はいくつか出ているな(w
この腐ったれ共を考えるに、メッセージとオブジェクト、
まっとうなオブジェクト指向コーディングするために、
かなり重要な基礎概念ではなかろうか?
154 ：デフォルトの名無しさん：03/09/13 13:17
>>153
私も、（こと Smalltalk の世界観においては）メッセージングは
オブジェクト指向にとってとても大事な要素だと思います。
正直、情報隠蔽だの、継承だの動的結合などは単なる枝葉で、
メッセージングメタファこそがオブジェクト指向という問題解決手法の
正体だとの認識でいます。
ただ、Smalltalk や Self 、ちょっと遅れをとるけど Objective-C と
いったメッセージ送信をそのまま式として表現できる言語ならともかく、、
C++ や Java 、Python や Ruby と言った世の“オブジェクト指向言語”で
オブジェクト指向を学ぶ際にこのメッセージ送信というメタファを持ち出すのは
かえって理解を阻害するのではないかなぁとの印象があります。
メッセージ送信をイメージしろと言われても、目の前にあるのは
引数のひとつが前に出た、一風変わった、しかしただの関数
呼び出し式なわけですから…。
もちろん、メッセージングをイメージしたプログラミングがAlgolライクな文法の
言語でできないということを言いたいのではありません。デザパタだって
C++ で立派に形作られています。ただ、こと初心者に限れば、メッセージングをイメージ
するためのトレーニングをこれらの言語で強要されると、（しかし、C++ を
学ぼうという人は必然的にそうした状況に追い込まれているわけですが）
結果として、オブジェクト指向（の説明）は難しいもの、ワケワカなもの
というイメージがつきまとってしまうようになるのかなと。
私も、（こと Smalltalk の世界観においては）メッセージングは
オブジェクト指向にとってとても大事な要素だと思います。
正直、情報隠蔽だの、継承だの動的結合などは単なる枝葉で、
メッセージングメタファこそがオブジェクト指向という問題解決手法の
正体だとの認識でいます。
ただ、Smalltalk や Self 、ちょっと遅れをとるけど Objective-C と
いったメッセージ送信をそのまま式として表現できる言語ならともかく、、
C++ や Java 、Python や Ruby と言った世の“オブジェクト指向言語”で
オブジェクト指向を学ぶ際にこのメッセージ送信というメタファを持ち出すのは
かえって理解を阻害するのではないかなぁとの印象があります。
メッセージ送信をイメージしろと言われても、目の前にあるのは
引数のひとつが前に出た、一風変わった、しかしただの関数
呼び出し式なわけですから…。
もちろん、メッセージングをイメージしたプログラミングがAlgolライクな文法の
言語でできないということを言いたいのではありません。デザパタだって
C++ で立派に形作られています。ただ、こと初心者に限れば、メッセージングをイメージ
するためのトレーニングをこれらの言語で強要されると、（しかし、C++ を
学ぼうという人は必然的にそうした状況に追い込まれているわけですが）
結果として、オブジェクト指向（の説明）は難しいもの、ワケワカなもの
というイメージがつきまとってしまうようになるのかなと。
155 ：デフォルトの名無しさん：03/09/13 13:20
いきなり、オブジェクトを“もの”だとかせずに、関数（手続き）を含んだ
データの一形態であること、その関数を起動するためにはオブジェクトを
名指しする必要がある（つまり、パラメータの一つは別格）というように、
まずオブジェクトに慣れ親しむ説明から入るよう心がければ、
C++ などにおけるオブジェクト指向入門に際した 1 の言うような違和感は
少しは軽減されるのではないでしょうか。
データの一形態であること、その関数を起動するためにはオブジェクトを
名指しする必要がある（つまり、パラメータの一つは別格）というように、
まずオブジェクトに慣れ親しむ説明から入るよう心がければ、
C++ などにおけるオブジェクト指向入門に際した 1 の言うような違和感は
少しは軽減されるのではないでしょうか。
156 ：デフォルトの名無しさん：03/09/13 17:23
最近C++学んで思ったこと。
オブジェクト指向の概念の説明だけに囚われていて、
コーディングの説明が疎かになってませんか？
オブジェクト指向の概念の説明だけに囚われていて、
コーディングの説明が疎かになってませんか？
157 ：デフォルトの名無しさん：03/09/13 17:44
158 ：デフォルトの名無しさん：03/09/13 18:07
非常に端的に言うと、
継承は class hoge: public baseclass{} とかコンストラクタは云々とか
継承は class hoge: public baseclass{} とかコンストラクタは云々とか
159 ：デフォルトの名無しさん：03/09/13 18:08
OOPLを人に教える立場の人って
まだまだ非OOPLから入って、OOPLにもまれてOOP, OOに感銘を受けたってタイプの人が多いだろうから
「まずはOOを理解してもらわなければ(自分のように)OOPらしくないプログラムを覚えてしまうだろう。」
って考えてしまうのは当然でしょうね。
僕は職場とかでは元々Cな人とかにC++について聞かれる事があるのですが、
やっぱり無意識のうちに目の前のハック方法より概念の説明に重点を置いてしまう事がよくあります。
まだまだ非OOPLから入って、OOPLにもまれてOOP, OOに感銘を受けたってタイプの人が多いだろうから
「まずはOOを理解してもらわなければ(自分のように)OOPらしくないプログラムを覚えてしまうだろう。」
って考えてしまうのは当然でしょうね。
僕は職場とかでは元々Cな人とかにC++について聞かれる事があるのですが、
やっぱり無意識のうちに目の前のハック方法より概念の説明に重点を置いてしまう事がよくあります。
161 ：デフォルトの名無しさん：03/09/13 18:51
>>1に同意。
本の場合、OOP側かOOA側に偏ってる事が多いと思う。
フルーツの分類に詳しくなってもなー。とか、多重継承の書き方は分かったけど、
どんな場面で使うのか分からん。とか。
で、複数の本買うと用語が違ってたりして、ますます意味不明に。
うぁぁぁん。
本の場合、OOP側かOOA側に偏ってる事が多いと思う。
フルーツの分類に詳しくなってもなー。とか、多重継承の書き方は分かったけど、
どんな場面で使うのか分からん。とか。
で、複数の本買うと用語が違ってたりして、ますます意味不明に。
うぁぁぁん。
162 ：デフォルトの名無しさん：03/09/14 00:08
>>160
メッセージから組み立てていく手法はどうだろう?
例えば、
電子メールで情報共有するのに、電子メールというメッセージを用いる。
Object"電子メールの送信" →(message:電子メール)→ Object"電子メールの受信"
送信するには、電子メールを入力してもらう必要がある。
Object"メール入力画面"→(message:電子メール)→Object"電子メールの送信"→...
情報の共有なんだから、メールを記憶しておくデータ・オブジェクトが必要。
共有する情報を表示するためのGUIも必要。
.....
てな具合に必要なものを集約していけば、
全体としてObject"メールソフト"の出来上がり。
オブジェクトの相互作用たるメッセージが先にあって、
それの流れに沿って行くと、オブジェクトが認識できるイメージ。
これだと概念の説明であっても、実際の処理フローに沿った、
使えるオブジェクトができあがる。プログラミング言語コード化
もさくっといける。
>>161
このObject"メールソフト"とObject"携帯電話"とを多重継承させたら、
Object"メール付き携帯電話"にならない?
メッセージから組み立てていく手法はどうだろう?
例えば、
電子メールで情報共有するのに、電子メールというメッセージを用いる。
Object"電子メールの送信" →(message:電子メール)→ Object"電子メールの受信"
送信するには、電子メールを入力してもらう必要がある。
Object"メール入力画面"→(message:電子メール)→Object"電子メールの送信"→...
情報の共有なんだから、メールを記憶しておくデータ・オブジェクトが必要。
共有する情報を表示するためのGUIも必要。
.....
てな具合に必要なものを集約していけば、
全体としてObject"メールソフト"の出来上がり。
オブジェクトの相互作用たるメッセージが先にあって、
それの流れに沿って行くと、オブジェクトが認識できるイメージ。
これだと概念の説明であっても、実際の処理フローに沿った、
使えるオブジェクトができあがる。プログラミング言語コード化
もさくっといける。
>>161
このObject"メールソフト"とObject"携帯電話"とを多重継承させたら、
Object"メール付き携帯電話"にならない?
163 ：デフォルトの名無しさん：03/09/14 00:38
C++だとメッセージなんかないから混乱の元。
164 ：デフォルトの名無しさん：03/09/14 02:14
>>163
メッセージやオブジェクトが言語、つまり、コード中に存在しなくちゃならない
って考え自体捨ててくれ。 その考え自体が混乱の元。
オブジェクト指向っつーのは、設計手法のひとつに過ぎないんだから。
世の中には、その全てをコード化しようとする向きもあるが、それは
実装が非効率になる。
まぁ、しかし、C++でもメッセージぐらい簡単に書けるぞ。
class Message;
class RecieveObject {
void RecieveMessage( Message * ); /* メッセージ寄越せ、ゴラァ!! */
}
class SendObject {
void SendMessage(){
RecieveObject->RecieveMessage( messageToSend );
}
void RecieveRequestSendMessage( Message *); /* メッセージ寄越せ、ゴラァ!! */
}
その他、CORBA系なんかのライブラリで高度なメッセージング
システムをサポートしてもらうのも、ひとつの手。
メッセージやオブジェクトが言語、つまり、コード中に存在しなくちゃならない
って考え自体捨ててくれ。 その考え自体が混乱の元。
オブジェクト指向っつーのは、設計手法のひとつに過ぎないんだから。
世の中には、その全てをコード化しようとする向きもあるが、それは
実装が非効率になる。
まぁ、しかし、C++でもメッセージぐらい簡単に書けるぞ。
class Message;
class RecieveObject {
void RecieveMessage( Message * ); /* メッセージ寄越せ、ゴラァ!! */
}
class SendObject {
void SendMessage(){
RecieveObject->RecieveMessage( messageToSend );
}
void RecieveRequestSendMessage( Message *); /* メッセージ寄越せ、ゴラァ!! */
}
その他、CORBA系なんかのライブラリで高度なメッセージング
システムをサポートしてもらうのも、ひとつの手。
165 ：デフォルトの名無しさん：03/09/14 03:33
166 ：デフォルトの名無しさん：03/09/14 04:18
>>164
そう。C++ の設計者であるストラウストラップも言うように C++ はけっして
オブジェクト指向プログラミング言語ではない（マルチパラダイム言語であるに
しても、少なくとも Smalltalk 的な実装は向かない）んですよね。だからオブジェクト
指向は設計の段階までにとどめておいて、コードに（オブジェクトはともかく）
メッセージを含まなければいけないといった考えかたは、まず捨ててかからないと
いけない、と。
コーディングまでオブジェクト指向でしたければ、効率を犠牲にするか言語を
変える必要があるはずです。
そう。C++ の設計者であるストラウストラップも言うように C++ はけっして
オブジェクト指向プログラミング言語ではない（マルチパラダイム言語であるに
しても、少なくとも Smalltalk 的な実装は向かない）んですよね。だからオブジェクト
指向は設計の段階までにとどめておいて、コードに（オブジェクトはともかく）
メッセージを含まなければいけないといった考えかたは、まず捨ててかからないと
いけない、と。
コーディングまでオブジェクト指向でしたければ、効率を犠牲にするか言語を
変える必要があるはずです。
167 ：デフォルトの名無しさん：03/09/14 08:29
>>165
別にいいんでないの?
Object"電子メール"の生成はVisitorパターンかね。
ま、コード化したら、メール“ソフト"なんてオブジェクトはどこにも
出てこないつもりなんで、そんな気にせんでください。
強いて言えば、ソースコードの総体がそうなるか。
別にいいんでないの?
Object"電子メール"の生成はVisitorパターンかね。
ま、コード化したら、メール“ソフト"なんてオブジェクトはどこにも
出てこないつもりなんで、そんな気にせんでください。
強いて言えば、ソースコードの総体がそうなるか。
168 ：デフォルトの名無しさん：03/09/14 18:24
だから、C++に限って言えば、初心者に教えるときには「メッセージ」なんて
言葉や概念は混乱の元になるから使うなって。
言葉や概念は混乱の元になるから使うなって。
169 ：デフォルトの名無しさん：03/09/14 20:18
データ構造、例えばstringを操作する時に、stringの内部を
直接操作することを禁止して、専用の関数だけで操作する、というのは
正統的なデータ抽象だけど、手続き指向の範囲でもこれは行われる。
一方、サブシステムは状態を持たない方が安全ではあるけど、
どうしても全体の構造にサブシステムが依存してしまって、
リファクタリングや再利用、小規模な拡張がやりにくくなる。
で、実際のほとんどのプログラムでは、サブシステムが何らかの
状態を持つようになっている。その状態は構造体に入れるのが一番自然。
この2つを連続したものとみなそう、というのがオブジェクト指向だと
思う。stringに文字を追加するのは、stringサーバへ文字を送信する
操作だと思ったり、buttonに表示する文字列を変えるのは、
ウィンドウのパラメータを変える操作だと思うわけ。
複数のオブジェクトを同時に操作する場合があったりして、
完全にこの考え方でなんでも統一できるわけじゃないけど、
これだけでも大半のケースは間に合ってしまう。
直接操作することを禁止して、専用の関数だけで操作する、というのは
正統的なデータ抽象だけど、手続き指向の範囲でもこれは行われる。
一方、サブシステムは状態を持たない方が安全ではあるけど、
どうしても全体の構造にサブシステムが依存してしまって、
リファクタリングや再利用、小規模な拡張がやりにくくなる。
で、実際のほとんどのプログラムでは、サブシステムが何らかの
状態を持つようになっている。その状態は構造体に入れるのが一番自然。
この2つを連続したものとみなそう、というのがオブジェクト指向だと
思う。stringに文字を追加するのは、stringサーバへ文字を送信する
操作だと思ったり、buttonに表示する文字列を変えるのは、
ウィンドウのパラメータを変える操作だと思うわけ。
複数のオブジェクトを同時に操作する場合があったりして、
完全にこの考え方でなんでも統一できるわけじゃないけど、
これだけでも大半のケースは間に合ってしまう。
170 ：デフォルトの名無しさん：03/09/14 20:21
C++ 入門者、初心者に向いたオブジェクト指向設計の例えと、そこから
実装へ持ってゆく作業過程の材材としてよいものはないかな。やはり
メモリリークしない文字列オブジェクトの実装とか？
実装へ持ってゆく作業過程の材材としてよいものはないかな。やはり
メモリリークしない文字列オブジェクトの実装とか？
171 ： ：03/09/14 20:23
>1
ロゴライターは十分わかり易いよ。
ロゴライターは十分わかり易いよ。
172 ：デフォルトの名無しさん：03/09/14 20:30
>>169
２段落目がちょっとよくわからん。かみ砕いたバージョンキボンヌ。
２段落目がちょっとよくわからん。かみ砕いたバージョンキボンヌ。
173 ：デフォルトの名無しさん：03/09/14 20:46
>>172
手続き指向では、アルゴリズムを抽象化した「関数」を
設計単位にするけど、関数は静的変数を使わない限り
状態を持たない(持たないのが良しとされる)から、
柔軟性が低い、ということ。
でも、関数型言語(よく知らんが)の方面では、関数は
関数であって、副作用も持つべきでないと言うんだよなあ。
関数がパラメータを持つのは構わないらしいけど。
手続き指向では、アルゴリズムを抽象化した「関数」を
設計単位にするけど、関数は静的変数を使わない限り
状態を持たない(持たないのが良しとされる)から、
柔軟性が低い、ということ。
でも、関数型言語(よく知らんが)の方面では、関数は
関数であって、副作用も持つべきでないと言うんだよなあ。
関数がパラメータを持つのは構わないらしいけど。
174 ：デフォルトの名無しさん：03/09/14 20:51
ネツメのJava言語ハンドブック、すごくOOの説明が上手だよ。
具体的で、無駄なく、的確で、分りやすく、低価格だから、お勧めするテスト。
具体的で、無駄なく、的確で、分りやすく、低価格だから、お勧めするテスト。
175 ：デフォルトの名無しさん：03/09/14 20:52
自分自身、混乱したことがあるの? 経験者?
メッセージなんて深く考えるなよ。
関数の引数とか、ネットワーク通信のやりとりとか、
ユーザの操作とか、ただのやりとりだ。
やりとり、データの受け渡し、入出力、通信、信号、情報の伝達。
メッセージなんて深く考えるなよ。
関数の引数とか、ネットワーク通信のやりとりとか、
ユーザの操作とか、ただのやりとりだ。
やりとり、データの受け渡し、入出力、通信、信号、情報の伝達。
あ、レス番付けるの忘れた
>>168 ね
>>168 ね
177 ：デフォルトの名無しさん：03/09/14 21:27
>>173
サブシステムは関数ね。補足サンクス。もしかして常識だった？ スマソ。
サブシステムは関数ね。補足サンクス。もしかして常識だった？ スマソ。
鉄の固まりはオブジェクトか否か。
語れ
語れ
179 ：デフォルトの名無しさん：03/09/14 22:16
>>178
むぅ。話が見えん…。“もの”なら無機物（無“機能”物）であってもオブジェクト
としてよいものなのか？といういたってシンプルな疑問か、それとも
それ自身を加工する道具を作れる唯一の金属である鉄とオブジェクトの
アナロジーを語ろうという主旨か。
むぅ。話が見えん…。“もの”なら無機物（無“機能”物）であってもオブジェクト
としてよいものなのか？といういたってシンプルな疑問か、それとも
それ自身を加工する道具を作れる唯一の金属である鉄とオブジェクトの
アナロジーを語ろうという主旨か。
180 ：デフォルトの名無しさん：03/09/14 22:55
181 ：デフォルトの名無しさん：03/09/14 23:15
182 ：デフォルトの名無しさん：03/09/14 23:35
183 ：デフォルトの名無しさん：03/09/14 23:43
( ﾟд)ﾋｿ(ﾟдﾟ)ﾋｿ(дﾟ )
「メッセージ」は Smalltalk 用語だから、少なくとも C++ においては、オブジェクト
指向設計時はともかく、実装方法の解説には使わない方がよいという話の流れ
が 181 には見えないらしい……。
「メッセージ」は Smalltalk 用語だから、少なくとも C++ においては、オブジェクト
指向設計時はともかく、実装方法の解説には使わない方がよいという話の流れ
が 181 には見えないらしい……。
184 ：デフォルトの名無しさん：03/09/14 23:54
>>174
気に入ったところを抜粋してもらえると助かる。
気に入ったところを抜粋してもらえると助かる。
185 ：デフォルトの名無しさん：03/09/15 00:01
>>183
そうそう。それに俺は設計時の話としてもメッセージなんて概念は
持ち出すべきじゃないと思ってる。
そうじゃないと、実装の説明のときに「で、さっきのメッセージはどうなるの？」
ってことになってしまう。
少なくともC++を念頭において教えるときには、単純にメソッド呼び出しとか
関数呼び出しでいいじゃない。
そうそう。それに俺は設計時の話としてもメッセージなんて概念は
持ち出すべきじゃないと思ってる。
そうじゃないと、実装の説明のときに「で、さっきのメッセージはどうなるの？」
ってことになってしまう。
少なくともC++を念頭において教えるときには、単純にメソッド呼び出しとか
関数呼び出しでいいじゃない。
186 ：デフォルトの名無しさん：03/09/15 00:08
まぁ、「メッセージパッシング」とかの概念をOOの初心者に教えようなんて奴は（ｒｙ
187 ：デフォルトの名無しさん：03/09/15 00:15
>>169
オブジェクト指向なら、
stringに文字を追加するのは、stringに追加する文字を添えたメッセージを送ることで、
buttonに表示するstringを差し替えるのは、buttonに差し替えるstringを添えてメッセージを送ること
じゃないの？ なぜサーバやウインドウが？？
まあそれはいいとして、こうした設計を C++ のクラス実装ではどう説明したらいいかって話だよね？
オブジェクト指向なら、
stringに文字を追加するのは、stringに追加する文字を添えたメッセージを送ることで、
buttonに表示するstringを差し替えるのは、buttonに差し替えるstringを添えてメッセージを送ること
じゃないの？ なぜサーバやウインドウが？？
まあそれはいいとして、こうした設計を C++ のクラス実装ではどう説明したらいいかって話だよね？
188 ：デフォルトの名無しさん：03/09/15 00:19
189 ：デフォルトの名無しさん：03/09/15 00:27
>>185
オブジェクト指向の前に、オブジェクトの話、一般論と C++ では
オブジェクトがどんな実装なのか、メンバー関数とは何で、どんな風
に呼び出すのかってな話はきちんとしておいたほうがよさげですね。
オブジェクト指向の前に、オブジェクトの話、一般論と C++ では
オブジェクトがどんな実装なのか、メンバー関数とは何で、どんな風
に呼び出すのかってな話はきちんとしておいたほうがよさげですね。
190 ：デフォルトの名無しさん：03/09/15 00:33
初心者には、OODの話なんかうっちゃって、OOPLを念頭において、
クラスとオブジェクト（インスタンス）の話から入るとよさげだと思うのだが。
クラスとオブジェクト（インスタンス）の話から入るとよさげだと思うのだが。
191 ：デフォルトの名無しさん：03/09/15 00:41
「メソッド」もSmalltalk用語だよね。
192 ：デフォルトの名無しさん：03/09/15 00:44
193 ：デフォルトの名無しさん：03/09/15 00:48
>>191
んなアホな。Smalltalk厨ってほんとウザイね。
んなアホな。Smalltalk厨ってほんとウザイね。
194 ：デフォルトの名無しさん：03/09/15 00:56
188 ｶﾞｲｲｺﾄｦｲｯﾀ!
小難しいことを述べてる前にコードにできる。これがOOPの真髄だ！
小難しいことを述べてる前にコードにできる。これがOOPの真髄だ！
195 ：デフォルトの名無しさん：03/09/15 01:05
>>193
そこまで浸透しているとはかえってオドロキ。
そこまで浸透しているとはかえってオドロキ。
196 ：デフォルトの名無しさん：03/09/15 01:47
Google
日本語のページからSmalltalk メソッドを検索しました。 約5,670件
日本語のページからJava メソッドを検索しました。 約138,000件
日本語のページからC++ メソッドを検索しました。 約42,600件
日本語のページからRuby メソッドを検索しました。 約62,900件
日本語のページからSmalltalk メソッドを検索しました。 約5,670件
日本語のページからJava メソッドを検索しました。 約138,000件
日本語のページからC++ メソッドを検索しました。 約42,600件
日本語のページからRuby メソッドを検索しました。 約62,900件
197 ：デフォルトの名無しさん：03/09/15 01:50
全言語のページからSmalltalk methodを検索しました。 約127,000件
全言語のページからJava methodを検索しました。 約3,050,000件
全言語のページからC++ methodを検索しました。 約1,360,000件
全言語のページからRuby methodを検索しました。 約326,000件
全言語のページからJava methodを検索しました。 約3,050,000件
全言語のページからC++ methodを検索しました。 約1,360,000件
全言語のページからRuby methodを検索しました。 約326,000件
198 ：デフォルトの名無しさん：03/09/15 02:35
なんつーか、Smalltalker氏んでねって感じ？
199 ：デフォルトの名無しさん：03/09/15 02:39
実はこのスレに Smalltalker はいないんだけどね。
200 ：デフォルトの名無しさん：03/09/15 03:21
201 ：デフォルトの名無しさん：03/09/15 03:51
202 ：デフォルトの名無しさん：03/09/15 07:17
真のSmalltalkerの漏れ様が登場しにくい？って感じ？
203 ：デフォルトの名無しさん：03/09/15 07:26
およそ、言語の歴史だの用語の起源だのをもちだすやつに
ろくなプログラマがいないことは、歴史が証明しておる。
ろくなプログラマがいないことは、歴史が証明しておる。
204 ：デフォルトの名無しさん：03/09/15 08:54
およそ、言語の歴史や用語の起源だのを無視するやつは
おしなべて無能なプログラマであることは、歴史が証明しておる。
おしなべて無能なプログラマであることは、歴史が証明しておる。
205 ：デフォルトの名無しさん：03/09/15 09:42
オブジェクト指向なんてわかっているプログラマなんて
1割もいないだろ？
1割もいないだろ？
206 ：デフォルトの名無しさん：03/09/15 09:47
>>173
関数が状態を持たないから柔軟性が低いって
どういうこと?
引数に状態を持つオブジェクトを渡すでも良いジャン。
ビジネスロジックを設計するときは、データ(状態)と振る舞いを
分けて設計すると考えやすいと思うけど。
関数が状態を持たないから柔軟性が低いって
どういうこと?
引数に状態を持つオブジェクトを渡すでも良いジャン。
ビジネスロジックを設計するときは、データ(状態)と振る舞いを
分けて設計すると考えやすいと思うけど。
207 ：デフォルトの名無しさん：03/09/15 09:47
自分が理解できないからといって他人も理解できないと思わないでください。
208 ：デフォルトの名無しさん：03/09/15 09:51
俺が研修上がりの新人さんにプログラムの基礎を教えたときのこと。
仕様だけ決めてあげて、まずは自由に作らせた。対象は超単機能クラス。
当然できてくるのは「とりあえず動く」設計の概念なんてないもの。
で、それからリファクタリングしながら説明する。
「ここを～～って概念のインターフェースにして切り出すと再利用性が高い」
とか言いながら。段階的に直してゆく。切り出しを促進するような仕様変更もしてやる。
で、切り出したクラスを使って別のプログラムを作らせた。再利用性の確認という意味で。
初心者さんに文章だけで教えるのって難しいと思ったからこの方法。
論点ずれてるかもしれないけど参考までに。
仕様だけ決めてあげて、まずは自由に作らせた。対象は超単機能クラス。
当然できてくるのは「とりあえず動く」設計の概念なんてないもの。
で、それからリファクタリングしながら説明する。
「ここを～～って概念のインターフェースにして切り出すと再利用性が高い」
とか言いながら。段階的に直してゆく。切り出しを促進するような仕様変更もしてやる。
で、切り出したクラスを使って別のプログラムを作らせた。再利用性の確認という意味で。
初心者さんに文章だけで教えるのって難しいと思ったからこの方法。
論点ずれてるかもしれないけど参考までに。
209 ：デフォルトの名無しさん：03/09/15 10:06
>>204
まあ、プログラマとして無能か有能かは分からないけど、自分の知りたい
ことを知るための文献を思いつかないとか、ルーツや現状に至る過程に
興味を持てない無頓着さというのは、プログラミング能力に何らか
の影響は与えるとは思う。しかし、Bjarne StroustrupがC++に、意識して
Smalltalkとは違った用語を選んだのは常識の範囲内では？
話を無理矢理戻すと、今回の件で分かるのはC++プログラマが
そうと気づかないほど、世の中がSmalltalkの世界観に汚染されて
いるということ。なるほどC++入門やCからの移行に適さない用語や
用例が多用されるわけだわな。
まあ、プログラマとして無能か有能かは分からないけど、自分の知りたい
ことを知るための文献を思いつかないとか、ルーツや現状に至る過程に
興味を持てない無頓着さというのは、プログラミング能力に何らか
の影響は与えるとは思う。しかし、Bjarne StroustrupがC++に、意識して
Smalltalkとは違った用語を選んだのは常識の範囲内では？
話を無理矢理戻すと、今回の件で分かるのはC++プログラマが
そうと気づかないほど、世の中がSmalltalkの世界観に汚染されて
いるということ。なるほどC++入門やCからの移行に適さない用語や
用例が多用されるわけだわな。
210 ：デフォルトの名無しさん：03/09/15 10:09
>>208
具体的にはどんなクラス？
具体的にはどんなクラス？
211 ：デフォルトの名無しさん：03/09/15 10:15
212 ：デフォルトの名無しさん：03/09/15 10:17
>>209
あんた、浮いてるよ。
あんた、浮いてるよ。
213 ：デフォルトの名無しさん：03/09/15 10:21
>>209
んじゃさ、AlgolやCLOS、Adaがこの世の中に及ぼしてる影響なんかを語っちゃってください。
んじゃさ、AlgolやCLOS、Adaがこの世の中に及ぼしてる影響なんかを語っちゃってください。
214 ：デフォルトの名無しさん：03/09/15 10:22
>>210
レスどうもありがとう。区切り文字列を与えて文字列を順番に取り出すクラス。
"a,aa,bd,dkr"で区切り文字列","なら、a aa bd dkrが順に取り出せるような。
で、区切り文字列が複数だったら、とか文字列じゃなくて文字だったらとか
というのに対応させてゆく（Strategyパターンになるのかな、こういうの）
という順序でした。
元々単機能のクラスを無理やり切り出している感もあったんだけど
概念を小さなクラスで学んでもらいたいと思ってこうしたよ。
これが果たして正解かどうかはわからないけれど、相手の子は
新しい発見をしてくれていたようだった。
レスどうもありがとう。区切り文字列を与えて文字列を順番に取り出すクラス。
"a,aa,bd,dkr"で区切り文字列","なら、a aa bd dkrが順に取り出せるような。
で、区切り文字列が複数だったら、とか文字列じゃなくて文字だったらとか
というのに対応させてゆく（Strategyパターンになるのかな、こういうの）
という順序でした。
元々単機能のクラスを無理やり切り出している感もあったんだけど
概念を小さなクラスで学んでもらいたいと思ってこうしたよ。
これが果たして正解かどうかはわからないけれど、相手の子は
新しい発見をしてくれていたようだった。
215 ：デフォルトの名無しさん：03/09/15 10:26
216 ：デフォルトの名無しさん：03/09/15 10:28
217 ：デフォルトの名無しさん：03/09/15 10:37
メッセージ＝メソッド＝メンバー関数 とうことを誰かが教えてくれないと
初学者がそこでつまづくことがありそうだ。
初学者がそこでつまづくことがありそうだ。
218 ：デフォルトの名無しさん：03/09/15 10:57
>>215
知らないんなら語らないでくだちゃい。
知らないんなら語らないでくだちゃい。
219 ：デフォルトの名無しさん：03/09/15 11:00
>>216
>Smalltalkの世界観なんて誰も気にしてないと思われ。
俺もそう思う。Smalltalkを持ち出す奴はXeroxのAltoを持ち出す奴に似てるな。
Smalltalkこそが真のOOPLである、Smalltalkは崇高なのだ、みたいなにおいがして嫌い。
>Smalltalkの世界観なんて誰も気にしてないと思われ。
俺もそう思う。Smalltalkを持ち出す奴はXeroxのAltoを持ち出す奴に似てるな。
Smalltalkこそが真のOOPLである、Smalltalkは崇高なのだ、みたいなにおいがして嫌い。
220 ：デフォルトの名無しさん：03/09/15 11:04
UserDatabse::AddUser(User aUser)
の、aUserみたいのを「ひそみにならう」っていうんだよな。
の、aUserみたいのを「ひそみにならう」っていうんだよな。
221 ：デフォルトの名無しさん：03/09/15 11:17
SqueakはOOの初心者におすすめなわけだが・・・
222 ：デフォルトの名無しさん：03/09/15 11:19
食わず嫌いってのもあるから。
223 ：デフォルトの名無しさん：03/09/15 11:43
ここはやはりオブジェクト指向ですごいソフトをつくってもらわないと
224 ：デフォルトの名無しさん：03/09/15 11:48
>>219
Smalltalkを持ち出す奴 → 実際は環境を起動したことすらない。
Altoを持ち出す奴 → そのGUIベースOSがSmalltalk環境そのものだと知らない。
だけどおまえはその両方だな。
Smalltalkを持ち出す奴 → 実際は環境を起動したことすらない。
Altoを持ち出す奴 → そのGUIベースOSがSmalltalk環境そのものだと知らない。
だけどおまえはその両方だな。
225 ：デフォルトの名無しさん：03/09/15 11:57
226 ：デフォルトの名無しさん：03/09/15 14:17
>>214
関数クラス？
関数クラス？
227 ：デフォルトの名無しさん：03/09/15 15:41
>>206
> 関数が状態を持たないから柔軟性が低いって
> どういうこと?
> 引数に状態を持つオブジェクトを渡すでも良いジャン。
その「状態を持つオブジェクト」を複数の関数で共有し始めたら、
そりゃオブジェクト指向だ。
共有までしなくても、アンチ以外の人はそれを関数オブジェクトと言う。
> 関数が状態を持たないから柔軟性が低いって
> どういうこと?
> 引数に状態を持つオブジェクトを渡すでも良いジャン。
その「状態を持つオブジェクト」を複数の関数で共有し始めたら、
そりゃオブジェクト指向だ。
共有までしなくても、アンチ以外の人はそれを関数オブジェクトと言う。
228 ：Smalltalker：03/09/15 16:12
おまえら能書きたれる前にSmalltalkやってみそ。
229 ：デフォルトの名無しさん：03/09/15 16:20
オブジェクト指向 != クラス指向
230 ：デフォルトの名無しさん：03/09/15 16:27
そもそもお前ら初心者に教える機会なんてないだろ？
231 ：デフォルトの名無しさん：03/09/15 17:32
>>230
少なくとも聞かれることはあるよ。
少なくとも聞かれることはあるよ。
232 ：デフォルトの名無しさん：03/09/15 18:24
ある程度センスのある人じゃない限り最初からピンとくるような概念ではないような気する。
自分の場合はセンスない側に分類されるから、OOPっていうのはおおざっぱに
機能追加などをしたときにプログラムに修正や追加をする部分を抑えられる事とか
アクセス制限をかけることが保守性や安全性につながってるなっていう有り難味の部分を感じ取れれば
まずはいいんじゃないだろうか。
でもよく言われるより直感に近いとかいうのはどうかと思う。
いざオブジェクト指向的に設計してみろといわれると、よく模範的に使われる例に似たものでもないかぎり
どう手をつけていいのがわからなくなってしまう。手続き型的な考え方のほうがヒューリスティックにできるような
気がするし、まだ直感的と言えるのではないかと思う。
オブジェクト指向的思考を身につけるいい方法ってなにかあります？
今はとりあえずデザインパターンを勉強しようかなと思ってます。
自分の場合はセンスない側に分類されるから、OOPっていうのはおおざっぱに
機能追加などをしたときにプログラムに修正や追加をする部分を抑えられる事とか
アクセス制限をかけることが保守性や安全性につながってるなっていう有り難味の部分を感じ取れれば
まずはいいんじゃないだろうか。
でもよく言われるより直感に近いとかいうのはどうかと思う。
いざオブジェクト指向的に設計してみろといわれると、よく模範的に使われる例に似たものでもないかぎり
どう手をつけていいのがわからなくなってしまう。手続き型的な考え方のほうがヒューリスティックにできるような
気がするし、まだ直感的と言えるのではないかと思う。
オブジェクト指向的思考を身につけるいい方法ってなにかあります？
今はとりあえずデザインパターンを勉強しようかなと思ってます。
233 ：デフォルトの名無しさん：03/09/15 18:40
漏れはOOな言語やライプラリを使ってプログラミングするのが一番手っ取り早いと思うよ。
234 ：デフォルトの名無しさん：03/09/15 18:41
>>232
OOとデザパタは関係ない
OOとデザパタは関係ない
235 ：デフォルトの名無しさん：03/09/15 18:47
236 ：デフォルトの名無しさん：03/09/15 19:15
>>234
オブジェクト指向設計の再利用できるパターンがデザパタじゃないの？
オブジェクト指向設計の再利用できるパターンがデザパタじゃないの？
237 ：デフォルトの名無しさん：03/09/15 19:18
C++は現実なのかなぁ?
C++のオブジェクト指向は機能の一つだろうし。
変数に型があって、レイトバインディングがデフォルトじゃないOO言語は嫌い。
C++のオブジェクト指向は機能の一つだろうし。
変数に型があって、レイトバインディングがデフォルトじゃないOO言語は嫌い。
238 ：デフォルトの名無しさん：03/09/15 19:20
239 ：デフォルトの名無しさん：03/09/15 19:23
>>238
そうなんだ。勉強してきます。
そうなんだ。勉強してきます。
240 ：デフォルトの名無しさん：03/09/15 19:25
>>237
C++はCの互換性と速度を求めたからああいう形になったんじゃん
C++はCの互換性と速度を求めたからああいう形になったんじゃん
241 ：デフォルトの名無しさん：03/09/15 19:27
>>240
うん、だから、C++はオブジェクト指向言語というより、オブジェクト指向「機能付き」言語なんでは?
うん、だから、C++はオブジェクト指向言語というより、オブジェクト指向「機能付き」言語なんでは?
242 ：デフォルトの名無しさん：03/09/15 20:18
そういうのはハイブリッド言語というのだ。
243 ：デフォルトの名無しさん：03/09/15 20:19
244 ：デフォルトの名無しさん：03/09/15 20:42
>>178
分子とかうざったういこと考えないと普段の感覚では鉄の塊も鉄であるから鉄の塊とはせずに鉄クラスにサイズと重さのプロパティを持たせるべきであると思いました。
分子とかうざったういこと考えないと普段の感覚では鉄の塊も鉄であるから鉄の塊とはせずに鉄クラスにサイズと重さのプロパティを持たせるべきであると思いました。
245 ：デフォルトの名無しさん：03/09/15 21:05
C++は抽象データ型をCに追加した言語でしょ？
246 ：デフォルトの名無しさん：03/09/15 21:14
>>229
本当はね。でも世の中はクラス指向で動いている。
Smalltalkerでもイコールだと思っている人は多いよ。
ttp://www.ogis-ri.co.jp/otc/hiroba/technical/Classification/C4_1.html
ちなみにアラン・ケイやアデル・ゴールドバーグはそうは思っていない。
ダン・インガルスは中庸かな。
本当はね。でも世の中はクラス指向で動いている。
Smalltalkerでもイコールだと思っている人は多いよ。
ttp://www.ogis-ri.co.jp/otc/hiroba/technical/Classification/C4_1.html
ちなみにアラン・ケイやアデル・ゴールドバーグはそうは思っていない。
ダン・インガルスは中庸かな。
247 ：デフォルトの名無しさん：03/09/15 21:29
248 ：デフォルトの名無しさん：03/09/15 21:30
指導的立場にある人やエンドユーザーの考える「オブジェクト指向」はメッセージパッシングで、
プログラマの頼るべき「オブジェクト指向」はクラス志向になるんじゃないの？
エンドユーザーは既存のクラスで事足りるけど、プログラマはクラス設計しないとおまんま食い上げだし。
プログラマの頼るべき「オブジェクト指向」はクラス志向になるんじゃないの？
エンドユーザーは既存のクラスで事足りるけど、プログラマはクラス設計しないとおまんま食い上げだし。
>>246
クラス指向以外には、テンプレート指向くらいしか知らないんだけど、他に知ってますか?
クラス指向以外には、テンプレート指向くらいしか知らないんだけど、他に知ってますか?
250 ：デフォルトの名無しさん：03/09/15 21:33
>>238
GoFのデザインパターンはその限りじゃないけどな。
GoFのデザインパターンはその限りじゃないけどな。
251 ：デフォルトの名無しさん：03/09/15 21:39
ほんとOO厨ってうざいね。
いくら雑学があっても設計・実装できなきゃクソなのにね。
いくら雑学があっても設計・実装できなきゃクソなのにね。
252 ：デフォルトの名無しさん：03/09/15 21:45
設計・実装なんてできてあたりまえだろ。
自分で使うのと、ひとに教えるのとでは大きな開きがある。
実装レベルで苦しんでるようじゃ理解できないだろうがね。
自分で使うのと、ひとに教えるのとでは大きな開きがある。
実装レベルで苦しんでるようじゃ理解できないだろうがね。
253 ：デフォルトの名無しさん：03/09/15 22:07
>>238 >>250
デザインパターンに限らず、OOは考え方や設計手法だからどんな言語でもある程度応用は利く。
OOPLに求められるのは、そうやって組み立てたものをストレスなく実装できるか、
それをサポートする言語機能を備えているか、とういうこと。
な～んて話はそれこそ何回となく繰り返されている。それこそパターン。
デザインパターンに限らず、OOは考え方や設計手法だからどんな言語でもある程度応用は利く。
OOPLに求められるのは、そうやって組み立てたものをストレスなく実装できるか、
それをサポートする言語機能を備えているか、とういうこと。
な～んて話はそれこそ何回となく繰り返されている。それこそパターン。
254 ：デフォルトの名無しさん：03/09/15 22:50
>>247
そんなやつらはないだろ…。ケント・ベックだってSmalltalkerだ。
ブーチはAda、メイヤーはEiffelだから調べるまでもなく
「メッセージパッシングなんて（あいまいなもの）くそ食らえ」だろ(笑)。
ケント・ベックはダン・インガルスと同じで中庸かな。
「そう、計算処理をメッセージとメソッドに分け、レシーバのクラスに応じて
実行時にメソッドに束縛（bind）するというやり方は、通常の
プロシージャ・コールとそれほど違いがないように思えるかもしれません。
しかし、このちょっとした変更が大きな違いを生み出すのです。」
そんなやつらはないだろ…。ケント・ベックだってSmalltalkerだ。
ブーチはAda、メイヤーはEiffelだから調べるまでもなく
「メッセージパッシングなんて（あいまいなもの）くそ食らえ」だろ(笑)。
ケント・ベックはダン・インガルスと同じで中庸かな。
「そう、計算処理をメッセージとメソッドに分け、レシーバのクラスに応じて
実行時にメソッドに束縛（bind）するというやり方は、通常の
プロシージャ・コールとそれほど違いがないように思えるかもしれません。
しかし、このちょっとした変更が大きな違いを生み出すのです。」
FFゲットだぜ！
256 ：デフォルトの名無しさん：03/09/15 23:31
>>254
BoochはAdaで、MayerはEiffel？寝言は寝て言え。
BoochはAdaで、MayerはEiffel？寝言は寝て言え。
257 ：デフォルトの名無しさん：03/09/15 23:34
258 ：デフォルトの名無しさん：03/09/15 23:47
>>257の見解もききたーい！
260 ：デフォルトの名無しさん：03/09/15 23:50
・・・？なんで人の使ってる言語がそんなに気になるの？
261 ：デフォルトの名無しさん：03/09/15 23:57
262 ：Smalltalker：03/09/16 00:06
おまえら能書きたれる前にSmalltalkやってみそ。
263 ：駆け出しSmalltalker：03/09/16 00:08
>>262
メタプログラミングを適用すべき局面について語ってみてくれ
メタプログラミングを適用すべき局面について語ってみてくれ
264 ：デフォルトの名無しさん：03/09/16 00:14
>>256
Kent Beckへのコメントは？
Kent Beckへのコメントは？
265 ：駆け出しSmalltalker：03/09/16 00:16
>>262
メタプログラミングの発展系とも言えるアスペクト指向について語ってみてくれ
メタプログラミングの発展系とも言えるアスペクト指向について語ってみてくれ
266 ：デフォルトの名無しさん：03/09/16 00:17
267 ：デフォルトの名無しさん：03/09/16 00:23
Smalltalk厨はいろいろ知ってるからSmalltalk“も”知っているだけさ。
C++だけしか知らないのにオブジェクト指向を語ることはできないだろ？
C++だけしか知らないのにオブジェクト指向を語ることはできないだろ？
268 ：駆け出しSmalltalker：03/09/16 00:25
ここにSmalltalkerが言るって聞いて来たんですけど…
ガセネタ捕まされたのでしょうか？
ガセネタ捕まされたのでしょうか？
269 ：デフォルトの名無しさん：03/09/16 01:15
いくらオブジェクト指向ができても、人が見たりプレイして楽しめるものを造れないとあんまり凄くないと思う。
270 ：デフォルトの名無しさん：03/09/16 01:49
Smalltalkやっとるのね、Smalltalkやってるやつが悪いんじゃないが
ここのSmalltalkerはなんか鼻にかけてる感じがしてムカつくね
ここのSmalltalkerはなんか鼻にかけてる感じがしてムカつくね
271 ：デフォルトの名無しさん：03/09/16 03:05
俺はそうは思わんぞ。
知らんできたこともいくつかあったし。
C++厨が妙な対抗心燃やして自爆してるのが無様なだけ。
知らんできたこともいくつかあったし。
C++厨が妙な対抗心燃やして自爆してるのが無様なだけ。
272 ：デフォルトの名無しさん：03/09/16 03:25
正直smalltalkってずっと昔に消滅して今ではどっかの大学の研究室の片隅で一部の学生の教育に使っているものかと思ってた。
273 ：デフォルトの名無しさん：03/09/16 03:42
漏れもStarとともに消滅したものとばかり。
274 ：デフォルトの名無しさん：03/09/16 03:55
なんで、C++とSmalltalkの話ばっかり?
ここはC++な人間のたまり場なのか…
ここはC++な人間のたまり場なのか…
275 ：デフォルトの名無しさん：03/09/16 04:07
Selfなんかどう? プロトタイプベースのOOPL。
276 ：デフォルトの名無しさん：03/09/16 07:46
>>227
関数オブジェクトというのはよくわからんが。
オブジェクト指向(クラス指向?)は、
クラスに振る舞いが所属しているから、
難しくなるんじゃないかな。
データと振る舞いを分離して、振る舞いはどっからでも呼べるように
なっていると誰にでもわかりやすい。
関数オブジェクトというのはよくわからんが。
オブジェクト指向(クラス指向?)は、
クラスに振る舞いが所属しているから、
難しくなるんじゃないかな。
データと振る舞いを分離して、振る舞いはどっからでも呼べるように
なっていると誰にでもわかりやすい。
277 ：デフォルトの名無しさん：03/09/16 08:34
なんでSmalltalkerと話しているのはC++使いだと思うんだろう？
Java使いやEffel、Ruby使いかもしれないのに。
少なくとも漏れはJava使いだけど、「メソッド」云々のときに
「Smalltalkの概念もここまで広がったか」みたいな書き込み見て
カチンときたよ。
Java使いやEffel、Ruby使いかもしれないのに。
少なくとも漏れはJava使いだけど、「メソッド」云々のときに
「Smalltalkの概念もここまで広がったか」みたいな書き込み見て
カチンときたよ。
278 ：デフォルトの名無しさん：03/09/16 08:35
279 ：デフォルトの名無しさん：03/09/16 09:15
>>276
一生手続き指向やってろ。
一生手続き指向やってろ。
280 ：デフォルトの名無しさん：03/09/16 09:34
281 ：デフォルトの名無しさん：03/09/16 09:51
282 ：デフォルトの名無しさん：03/09/16 10:48
>>278
ちがうよ。Smalltalkでは古典的にメッセージングメタファがその世界観に取り込まれていた[1]
あるいは、今さらながらに強調する向きもある[2]にもかかわらず、そのSmalltalk
“でも”という意味だ、と思う(藁
[1] ttp://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html
[2] ttp://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017025.html
ちがうよ。Smalltalkでは古典的にメッセージングメタファがその世界観に取り込まれていた[1]
あるいは、今さらながらに強調する向きもある[2]にもかかわらず、そのSmalltalk
“でも”という意味だ、と思う(藁
[1] ttp://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html
[2] ttp://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017025.html
283 ：デフォルトの名無しさん：03/09/16 10:54
>>277
C++で「メソッド」が設計者の意に反して使われるようになったのはJava誕生より前。
Javaで「メソッド」という用語が定められたのはSmalltalkの強い影響下にあったから。
どこにカチンとこなあかん理由があるのかが謎。
C++で「メソッド」が設計者の意に反して使われるようになったのはJava誕生より前。
Javaで「メソッド」という用語が定められたのはSmalltalkの強い影響下にあったから。
どこにカチンとこなあかん理由があるのかが謎。
284 ：デフォルトの名無しさん：03/09/16 11:45
データの局所性を高めたり隠蔽するってさ、
一データ群を取り扱う関数群を一つのソースにまとめて、データへのアクセスは
専用のI/O関数を介してやり取りするのと違いはある？
Cでもこういうのを徹底しとけばいいんでしょ？
一データ群を取り扱う関数群を一つのソースにまとめて、データへのアクセスは
専用のI/O関数を介してやり取りするのと違いはある？
Cでもこういうのを徹底しとけばいいんでしょ？
285 ：デフォルトの名無しさん：03/09/16 11:53
>>284
それはオブジェクト指向設計ができてるってことだから。
ただ、Cはそれを実装する手段を言語が提供していないだけ。
だから、無理にCでやらずにC++でやればいいと。
（環境が許すならだけどね）
それはオブジェクト指向設計ができてるってことだから。
ただ、Cはそれを実装する手段を言語が提供していないだけ。
だから、無理にCでやらずにC++でやればいいと。
（環境が許すならだけどね）
287 ：デフォルトの名無しさん：03/09/16 17:30
interefaceってEiffelからきた概念じゃないの？
288 ：デフォルトの名無しさん：03/09/16 19:46
このスレの趣旨は
如何にわかりやすくオブジェクト指向を説明するか
でOK？
如何にわかりやすくオブジェクト指向を説明するか
でOK？
289 ：デフォルトの名無しさん：03/09/16 20:05
>>288
いいと思う。けど、>>1 がC++に言及しているからこれをどこまで配慮するかが問題。
C++におけるオブジェクト指向に限らなくてもよいとしても、オブジェクト、OO（OOD）、OOP、
対象になるOOPLのコンセンサスは必要だろう。まだ、OO（OOD）とはってところで
もめているかんじがする。
いいと思う。けど、>>1 がC++に言及しているからこれをどこまで配慮するかが問題。
C++におけるオブジェクト指向に限らなくてもよいとしても、オブジェクト、OO（OOD）、OOP、
対象になるOOPLのコンセンサスは必要だろう。まだ、OO（OOD）とはってところで
もめているかんじがする。
290 ：デフォルトの名無しさん：03/09/16 21:02
単なるプロシージャ・コールをメッセージとメソッドに分けるとどんなメリットがあるの？
291 ：デフォルトの名無しさん：03/09/16 21:07
＞それはオブジェクト指向設計ができてるってことだから。
そうかなあ（ｗ
そうかなあ（ｗ
292 ：デフォルトの名無しさん：03/09/16 21:44
>>291
それは「データの局所性を高めたり隠蔽する」だけじゃだめってこと？
それは「データの局所性を高めたり隠蔽する」だけじゃだめってこと？
293 ：デフォルトの名無しさん：03/09/16 22:23
>>281
インターフェースや多重継承が何の関係が。
インターフェースや多重継承が何の関係が。
294 ：デフォルトの名無しさん：03/09/16 22:26
>>290
メッセージとメソッドは同じとちゃうん。
メッセージとメソッドは同じとちゃうん。
295 ：デフォルトの名無しさん：03/09/16 22:32
>>292
「データの局所性を高めたり隠蔽する」ことによってモジュールの強度を高く、
他モジュールとの結合度を低くすることが品質を高めるのに有効。
てのは古くから言われてたことで、ｃではスコープを使ってそれを実現できるし。
オブジェクト指向とか言われてるものがその延長線上「にも」あるのは確かとしても
それがそのまま「オブジェクト指向設計が・・」というのは釈然としないな。
何かをシミュレートするのに、その属性と振る舞いを内部に隠蔽できた方が便利だから
その手法が取り入れられているんだろうけども、それなら、何かをシミュレートするための、
属性と振る舞いが内部に隠蔽されて、公開された方法でしか操作することのできないモジュールを、
いかにシミュレートする対象に忠実に再現できているかがオブジェクト指向を用いた設計のキモ
であるような気がしないでもない。
だからこそ「コントロールパネルのシミュレータ」であるＧＵＩのように、シミュレートする対象を
直感的に再現しやすいようなものの構築に早くから応用されて本領を発揮してきたんだと思うし。
まあ、そんなことを言いながら俺自身はオブジェクトとインスタンスの違いもわからない厨であるわけだが（大笑
「データの局所性を高めたり隠蔽する」ことによってモジュールの強度を高く、
他モジュールとの結合度を低くすることが品質を高めるのに有効。
てのは古くから言われてたことで、ｃではスコープを使ってそれを実現できるし。
オブジェクト指向とか言われてるものがその延長線上「にも」あるのは確かとしても
それがそのまま「オブジェクト指向設計が・・」というのは釈然としないな。
何かをシミュレートするのに、その属性と振る舞いを内部に隠蔽できた方が便利だから
その手法が取り入れられているんだろうけども、それなら、何かをシミュレートするための、
属性と振る舞いが内部に隠蔽されて、公開された方法でしか操作することのできないモジュールを、
いかにシミュレートする対象に忠実に再現できているかがオブジェクト指向を用いた設計のキモ
であるような気がしないでもない。
だからこそ「コントロールパネルのシミュレータ」であるＧＵＩのように、シミュレートする対象を
直感的に再現しやすいようなものの構築に早くから応用されて本領を発揮してきたんだと思うし。
まあ、そんなことを言いながら俺自身はオブジェクトとインスタンスの違いもわからない厨であるわけだが（大笑
ウォーシミュレーションとか作ろうと思ったら大変だね。
９０式戦車とかコブラとか設計して、どかどか大量生産しないといけないし。
おまけにリアルさを求めると両軍の戦車がリアルタイムで並列動作しちゃってさ。
ばんばんメッセージ撃ち合うの。もう見てらんない。
９０式戦車とかコブラとか設計して、どかどか大量生産しないといけないし。
おまけにリアルさを求めると両軍の戦車がリアルタイムで並列動作しちゃってさ。
ばんばんメッセージ撃ち合うの。もう見てらんない。
297 ：デフォルトの名無しさん：03/09/16 23:11
>>289
別にC++でもJavaでも、ましてやSmalltalkでもいいけど、
それぞれが何かのOOPLを前提として初心者にどう教えれば
いいかを議論すればいいのでは？
だって、OOPLなんてまったく考慮せずに「初心者にOOを教える」
なんて状況はまず無いでしょ。
普通目的は「言語Xをどううまく使うか」でしょ。
別にC++でもJavaでも、ましてやSmalltalkでもいいけど、
それぞれが何かのOOPLを前提として初心者にどう教えれば
いいかを議論すればいいのでは？
だって、OOPLなんてまったく考慮せずに「初心者にOOを教える」
なんて状況はまず無いでしょ。
普通目的は「言語Xをどううまく使うか」でしょ。
298 ：デフォルトの名無しさん：03/09/16 23:38
>>295
「オブジェクト」という処理がついてまわるデータ型を実装時に使えるということを前提に
「データの局所性を高めたり隠蔽する」というCでは古くから使われていたのと同種の
設計手法の呼び名を変えたのが（クラス指向の）「オブジェクト指向（設計）」
なのではないでしょうか？ 違いますかね。
インスタンスは、属するクラスの存在を前提とした（クラスベースの）オブジェクトの呼び名です。
「オブジェクト」という処理がついてまわるデータ型を実装時に使えるということを前提に
「データの局所性を高めたり隠蔽する」というCでは古くから使われていたのと同種の
設計手法の呼び名を変えたのが（クラス指向の）「オブジェクト指向（設計）」
なのではないでしょうか？ 違いますかね。
インスタンスは、属するクラスの存在を前提とした（クラスベースの）オブジェクトの呼び名です。
299 ：デフォルトの名無しさん：03/09/16 23:44
>>297
UML
UML
>>299
え？どのOOPLも使ったこと無い奴にUML教えるの？
え？どのOOPLも使ったこと無い奴にUML教えるの？
301 ：デフォルトの名無しさん：03/09/17 00:09
302 ：デフォルトの名無しさん：03/09/17 00:10
>>300
オブジェクト指向設計技術者養成とか(藁
オブジェクト指向設計技術者養成とか(藁
304 ：デフォルトの名無しさん：03/09/17 00:29
305 ：デフォルトの名無しさん：03/09/17 00:33
>>290
単なるプロシージャ・コールをメッセージと格付けすることで、
対応するメソッドに期待される処理内容を明示的にする責務を負わせる。
これにより、メソッドの実装を知らなくとも、あるいは具体的に実装を
ひとつに定めなくとも、コード（もしくは擬似コード）を読み下す/書き下ろすことができる、
というような効果が期待できる。
Smalltalkでコメントが減らせるのはこうした考え方が徹底されているため。
タイプ数を極力減らそうとするC、その流れを汲むC++では馴染まない考え方かも。
単なるプロシージャ・コールをメッセージと格付けすることで、
対応するメソッドに期待される処理内容を明示的にする責務を負わせる。
これにより、メソッドの実装を知らなくとも、あるいは具体的に実装を
ひとつに定めなくとも、コード（もしくは擬似コード）を読み下す/書き下ろすことができる、
というような効果が期待できる。
Smalltalkでコメントが減らせるのはこうした考え方が徹底されているため。
タイプ数を極力減らそうとするC、その流れを汲むC++では馴染まない考え方かも。
306 ：デフォルトの名無しさん：03/09/17 05:45
プロシージャ呼び出しから予想される機能と実際の処理内容が重なるのは
そのプロシージャが上手く機能分割されており、かつ機能に即したプロシージャ名を
規約に従って定めることが徹底しているからで、タイピング量とは（あまり）関係がない。
別にｃでもfortranでも馴染まないということはない。
実装に先立って機能分割とその機能の呼び出し名を予め定めることができれば
規約の徹底に役立つかもしれない。
そしてその規約が万人に理解しやすいものになるかどうかは、表現するモノが
いかに万人の常識に沿って作られているかによる。つまり常識を再現できているか。
直感的に分かりやすい規約ならば規約そのものを知らなくても、コードを見て
なんとなく理解できる可能性がある。
記述方法が関数呼び出しなのはベースとなった言語との親和性にすぎない。
ただ、その関数からリターンされるまでブロックされるということを期待させやすい。
そのプロシージャが上手く機能分割されており、かつ機能に即したプロシージャ名を
規約に従って定めることが徹底しているからで、タイピング量とは（あまり）関係がない。
別にｃでもfortranでも馴染まないということはない。
実装に先立って機能分割とその機能の呼び出し名を予め定めることができれば
規約の徹底に役立つかもしれない。
そしてその規約が万人に理解しやすいものになるかどうかは、表現するモノが
いかに万人の常識に沿って作られているかによる。つまり常識を再現できているか。
直感的に分かりやすい規約ならば規約そのものを知らなくても、コードを見て
なんとなく理解できる可能性がある。
記述方法が関数呼び出しなのはベースとなった言語との親和性にすぎない。
ただ、その関数からリターンされるまでブロックされるということを期待させやすい。
307 ：デフォルトの名無しさん：03/09/17 07:24
>>305-306
こういう奴が初心者に教えると、ろくなこと無いってのの見本のような発言だな（藁
こういう奴が初心者に教えると、ろくなこと無いってのの見本のような発言だな（藁
308 ：デフォルトの名無しさん：03/09/17 07:45
309 ：デフォルトの名無しさん：03/09/17 13:27
やわらかく言ってみるテスト。
単なる関数呼び出しをあえて「メッセージ」と呼んで区別するのは、
1. 言語によっては関数呼び出しの前に、型に合わせた適切な関数を選ぶ別の内部作業が入るから、その違いをユーザーに意識させるため。
2. 実際の処理内容を連想するのに役立つ“余計な”情報を関数名に含ませることを推奨するため。
3. Smalltalk、Objective-C など、ほんとにメッセージ送信式でコードを記述する言語があるため。
このどれにも興味がなければ「メッセージ」とわざわざ言い換えなくてもいい。
単なる関数呼び出しをあえて「メッセージ」と呼んで区別するのは、
1. 言語によっては関数呼び出しの前に、型に合わせた適切な関数を選ぶ別の内部作業が入るから、その違いをユーザーに意識させるため。
2. 実際の処理内容を連想するのに役立つ“余計な”情報を関数名に含ませることを推奨するため。
3. Smalltalk、Objective-C など、ほんとにメッセージ送信式でコードを記述する言語があるため。
このどれにも興味がなければ「メッセージ」とわざわざ言い換えなくてもいい。
310 ：デフォルトの名無しさん：03/09/17 13:35
311 ：デフォルトの名無しさん：03/09/17 13:47
単なる関数呼び出しとメッセージとごちゃ混ぜにしてる人が多すぎ。
まったく素人は困るな
まったく素人は困るな
312 ：デフォルトの名無しさん：03/09/17 14:32
>>311
ちっ、ちがうのか？ つきつめれば単なる関数呼び出しだと思うが…。
ちっ、ちがうのか？ つきつめれば単なる関数呼び出しだと思うが…。
313 ：デフォルトの名無しさん：03/09/17 14:43
314 ：デフォルトの名無しさん：03/09/17 15:14
>>305
コメントは減らせるが関数名はどんどん長くなる罠。
model:collectionOrSelector:okaySelector:cancelSelector:addSelector:deleteSelector:gotoSelector:menuSelector:changeSelector:valueMorphSelector:keyMorphSelector:objectToStringSelector:releaseSelector:balloonTextSelector:
なんて関数名はそれこそ可読性の観点でいかがなものかと。ま、これは極端だけど、
subclass:instanceVariableNames:classVariableNames:poolDictionaries:category:
なんてのもざらだし。
コメントは減らせるが関数名はどんどん長くなる罠。
model:collectionOrSelector:okaySelector:cancelSelector:addSelector:deleteSelector:gotoSelector:menuSelector:changeSelector:valueMorphSelector:keyMorphSelector:objectToStringSelector:releaseSelector:balloonTextSelector:
なんて関数名はそれこそ可読性の観点でいかがなものかと。ま、これは極端だけど、
subclass:instanceVariableNames:classVariableNames:poolDictionaries:category:
なんてのもざらだし。
315 ：デフォルトの名無しさん：03/09/17 17:34
呪文みたいですな
316 ：デフォルトの名無しさん：03/09/17 18:30
そんなのは掟破りのSqueakだからだろと思ってVisualWorksで調べてみたら、
やっぱり結構長い名前のメッセージセレクタがありました。==>184文字
| symbols keywordSelectors longestSelector |
symbols := ByteSymbol allInstances.
keywordSelectors := symbols select: [:symbol | symbol size > 2 and: [symbol last == $:]].
longestSelector := (keywordSelectors asSortedCollection: [:a :b | a size > b size]) first.
^ longestSelector size
やっぱり結構長い名前のメッセージセレクタがありました。==>184文字
| symbols keywordSelectors longestSelector |
symbols := ByteSymbol allInstances.
keywordSelectors := symbols select: [:symbol | symbol size > 2 and: [symbol last == $:]].
longestSelector := (keywordSelectors asSortedCollection: [:a :b | a size > b size]) first.
^ longestSelector size
317 ：デフォルトの名無しさん：03/09/17 20:38
処理を理解している状態においてもそんなに長い名前が書かれてたら鬱にならないか？
ま、思想は分かるんだけどさ。
ま、思想は分かるんだけどさ。
318 ：デフォルトの名無しさん：03/09/17 22:03
>>317
調べてみると、クラスライブラリの全メソッドのソースを読んだとき 80 文字以上のメッセージ
セレクタに出会う頻度は約 240 個にひとつと少ない…いや、意外と多いような気も
せんでもないですが(^_^;)。
まあ、100 文字を越えるものとなると、800 個にひとつ 近くまで落ちるので、
鬱になるほどは頻繁ではない、はずです。計算上は…(笑)。
| allMethods longSelectors sendors |
allMethods := CompiledMethod allInstances.
sendors := OrderedCollection new.
longSelectors := Symbol allInstances select: [ :symbol | symbol size > 80].
longSelectors do: [ :longSelector | sendors addAll: (Smalltalk allCallsOn: longSelector)].
^ allMethods size / sendors asSet size asFloat
調べてみると、クラスライブラリの全メソッドのソースを読んだとき 80 文字以上のメッセージ
セレクタに出会う頻度は約 240 個にひとつと少ない…いや、意外と多いような気も
せんでもないですが(^_^;)。
まあ、100 文字を越えるものとなると、800 個にひとつ 近くまで落ちるので、
鬱になるほどは頻繁ではない、はずです。計算上は…(笑)。
| allMethods longSelectors sendors |
allMethods := CompiledMethod allInstances.
sendors := OrderedCollection new.
longSelectors := Symbol allInstances select: [ :symbol | symbol size > 80].
longSelectors do: [ :longSelector | sendors addAll: (Smalltalk allCallsOn: longSelector)].
^ allMethods size / sendors asSet size asFloat
319 ：デフォルトの名無しさん：03/09/17 22:08
全部漢字で名づけた方が短いんじゃないか？
320 ：デフォルトの名無しさん：03/09/17 22:44
>>318
誤：sendors → 正：senders
誤：sendors → 正：senders
321 ：デフォルトの名無しさん：03/09/17 22:57
322 ：デフォルトの名無しさん：03/09/17 23:39
>単なる関数呼び出しをあえて「メッセージ」と呼んで区別するのは、
漏れはLispがわざわざ"consセル"と呼ぶのと同しだと思っていたのだが
漏れはLispがわざわざ"consセル"と呼ぶのと同しだと思っていたのだが
323 ：デフォルトの名無しさん：03/09/18 00:35
実際に呼び出される関数が動的に定まる時点で「単なる関数呼び出し」と言い切るのは
躊躇われるのだけれども、じゃあそれが真のメッセージなのかとすごまれても困ってしまうし
どうせ誤解されるなら「単なる関数呼び出し」だと思われた方がはるかに無難なように思う。
「クラスなんて単に関数の書ける構造体じゃーん」という言葉もあながち的外れではないし。
まあ、オブジェクトに対する操作をどういう名前で呼ぼうが大した問題でない事は確かだが。
躊躇われるのだけれども、じゃあそれが真のメッセージなのかとすごまれても困ってしまうし
どうせ誤解されるなら「単なる関数呼び出し」だと思われた方がはるかに無難なように思う。
「クラスなんて単に関数の書ける構造体じゃーん」という言葉もあながち的外れではないし。
まあ、オブジェクトに対する操作をどういう名前で呼ぼうが大した問題でない事は確かだが。
324 ：デフォルトの名無しさん：03/09/18 00:47
325 ：デフォルトの名無しさん：03/09/18 01:04
メソッドはメソッドであって、メンバ関数はメンバ関数だと思うがｗ
326 ：デフォルトの名無しさん：03/09/18 01:41
つうか、難解に説明する人って、記述・表現の正確性にこだわりすぎって思う。
「ものを教える」って、「分かった、理解できた」という楽しい体験を与えて、学習への
モチベーションと最低限の語彙・知識を持たせるためのものだと思うんだけど。
自分で学習して、自分なりに知識を構築していく中で、教えられた表現が実は
簡略化・擬似化されたものだったと気づいて修正していける能力を身に付けさせる、
って思想・観点で書かれた技術ドキュメントって、ものすごく少ない。
「ものを教える」って、「分かった、理解できた」という楽しい体験を与えて、学習への
モチベーションと最低限の語彙・知識を持たせるためのものだと思うんだけど。
自分で学習して、自分なりに知識を構築していく中で、教えられた表現が実は
簡略化・擬似化されたものだったと気づいて修正していける能力を身に付けさせる、
って思想・観点で書かれた技術ドキュメントって、ものすごく少ない。
327 ：デフォルトの名無しさん：03/09/18 02:05
読み取り精度はあくまでも文法解析という意味において・・・
その人独特の言い回しと言うか、著者のいいたい事を読み取る精度と
自分自身の理解力とは少し違う気もする。
つまり、眠気をさそう説明というのは問題じゃなかろうかと。
読み手の我儘と言われればそれまでだが。
その人独特の言い回しと言うか、著者のいいたい事を読み取る精度と
自分自身の理解力とは少し違う気もする。
つまり、眠気をさそう説明というのは問題じゃなかろうかと。
読み手の我儘と言われればそれまでだが。
328 ：デフォルトの名無しさん：03/09/18 02:26
329 ：デフォルトの名無しさん：03/09/18 05:07
我儘っつーか、
作ったプログラムが誤動作を起こすのは、コンピュータに対するプログラマの意思通達ミス。
作ったプログラムがコンパイルエラーを起こすのは、コンピュータが認識する以前のプログラマの入力ミス。
こう考えると我儘なのはどっちかと考えさせられないか？
もちろん人とコンピュータを同列にして比較できないが。
作ったプログラムが誤動作を起こすのは、コンピュータに対するプログラマの意思通達ミス。
作ったプログラムがコンパイルエラーを起こすのは、コンピュータが認識する以前のプログラマの入力ミス。
こう考えると我儘なのはどっちかと考えさせられないか？
もちろん人とコンピュータを同列にして比較できないが。
330 ：デフォルトの名無しさん：03/09/18 08:23
331 ：デフォルトの名無しさん：03/09/18 10:03
>>330
アセンブラさえあればｃなんか要らないって言ってた人を思い出したよ。
アセンブラさえあればｃなんか要らないって言ってた人を思い出したよ。
332 ：デフォルトの名無しさん：03/09/18 10:20
Javaさえあれば、他の全ての言語はいらないって言ってた人を思いだしたよ。
333 ：デフォルトの名無しさん：03/09/18 10:24
足なんて飾りです、お偉いさんにはそれがわからないんです。っていった人は生きてるのかな？
334 ：デフォルトの名無しさん：03/09/18 10:30
>>332
Ｃ＋＋、ＣＯＢＯＬ、ＬＩＳＰとその一族 は少なくとも必要だよな。
Ｃ＋＋、ＣＯＢＯＬ、ＬＩＳＰとその一族 は少なくとも必要だよな。
335 ：デフォルトの名無しさん：03/09/18 10:39
>>333
いや、あの人はまだ生まれてもいないだろ…。
いや、あの人はまだ生まれてもいないだろ…。
336 ：デフォルトの名無しさん：03/09/18 10:44
OO厨の典型的なセリフその1
メッセージとかメソッドとかメンバ関数とかいろんな呼び方してるけどさ「結
局単なる関数」だろ？言語によって呼び方が違うだけじゃん。単なる関数呼び
出しをわざわざメッセージ送信とか言う奴って要するにアフォだろ？ あのな、
Smalltalkなんてきょうび流行んねーんだよ。ボケが。 得意げな顔して何が、
メッセージ送信、だ。 お前、メッセージ送信って言いたいだけちゃうんかと。
メッセージとかメソッドとかメンバ関数とかいろんな呼び方してるけどさ「結
局単なる関数」だろ？言語によって呼び方が違うだけじゃん。単なる関数呼び
出しをわざわざメッセージ送信とか言う奴って要するにアフォだろ？ あのな、
Smalltalkなんてきょうび流行んねーんだよ。ボケが。 得意げな顔して何が、
メッセージ送信、だ。 お前、メッセージ送信って言いたいだけちゃうんかと。
337 ：デフォルトの名無しさん：03/09/18 10:44
338 ：デフォルトの名無しさん：03/09/18 10:51
ｏｏの説明って擬人化したほうがわかりやすいよね。
役割分担をする、そしてその人に依頼をする。
それをメッセージが同だこうだいうから・・・。
役割分担をする、そしてその人に依頼をする。
それをメッセージが同だこうだいうから・・・。
339 ：デフォルトの名無しさん：03/09/18 10:55
マルチプルインスタンスって言ってる時点でタコだね。マルチプルじゃないインスタンスってあるのかよ。
340 ：デフォルトの名無しさん：03/09/18 10:59
分かりやすいことが正確な理解につながるとは必ずしも限らない
341 ：デフォルトの名無しさん：03/09/18 11:02
342 ：デフォルトの名無しさん：03/09/18 11:16
>>337
感想というか、自分なりに真面目に物を考えたことは誉めてあげていいと思う。
ただ本を読んで覚えこもうとするよりはマシ。
でも、思うて学ばざればって感じする。歴史的な経緯をもっと知ると考えがかわるだろう。
あれでわかりやすいかどうかは・・・どうだろう？
感想というか、自分なりに真面目に物を考えたことは誉めてあげていいと思う。
ただ本を読んで覚えこもうとするよりはマシ。
でも、思うて学ばざればって感じする。歴史的な経緯をもっと知ると考えがかわるだろう。
あれでわかりやすいかどうかは・・・どうだろう？
343 ：デフォルトの名無しさん：03/09/18 11:34
っつーかあんな姿勢でも本が書けてそこそこ売れてるっていうんだから
世の中なんか間違ってる・・・
世の中なんか間違ってる・・・
344 ：デフォルトの名無しさん：03/09/18 11:55
OO厨の典型的なセリフその2
メッセージ送信とか言ってobj.message(x)とか書いてるけど、これって結局
objを引数にしたmessage(obj, x)っていう関数呼び出しと変わらねーだろ。単
なる「字面の問題」だし「気持ちの問題」だね。構文の書き方なんて結局その
言語の作り手が勝手に決められるし、あとは単に慣れの問題。obj.message(x)っ
て書いたほうがオブジェクト指向っ「ぽく」なるっていうんなら別にいいけど、
何かそれってバカっぽいよね。っていうかオブジェクト指向が分かっちゃって
る俺から言わせればこんなことを問題にすること自体オブジェクト指向を分かっ
てない証拠なのね。だって単なる「字面の問題」だし「気持ちの問題」だから。
オブジェクト指向の本質とな何にも関係ないわけ。悪いけど君、勉強が足りな
いと思う。
メッセージ送信とか言ってobj.message(x)とか書いてるけど、これって結局
objを引数にしたmessage(obj, x)っていう関数呼び出しと変わらねーだろ。単
なる「字面の問題」だし「気持ちの問題」だね。構文の書き方なんて結局その
言語の作り手が勝手に決められるし、あとは単に慣れの問題。obj.message(x)っ
て書いたほうがオブジェクト指向っ「ぽく」なるっていうんなら別にいいけど、
何かそれってバカっぽいよね。っていうかオブジェクト指向が分かっちゃって
る俺から言わせればこんなことを問題にすること自体オブジェクト指向を分かっ
てない証拠なのね。だって単なる「字面の問題」だし「気持ちの問題」だから。
オブジェクト指向の本質とな何にも関係ないわけ。悪いけど君、勉強が足りな
いと思う。
345 ：デフォルトの名無しさん：03/09/18 12:04
＞単に慣れの問題
つまるところこれなんだろうな。
つまるところこれなんだろうな。
346 ：デフォルトの名無しさん：03/09/18 12:10
>>345
あなたも厨ということで
あなたも厨ということで
347 ：デフォルトの名無しさん：03/09/18 12:45
他人が買うだけならどうだっていいじゃん。
348 ：デフォルトの名無しさん：03/09/18 17:44
C++ JAVA Objective-Cのメッセージ送信の比較
http://homepage.mac.com/mkino2/oop/messaging.html
http://homepage.mac.com/mkino2/oop/messaging.html
349 ：デフォルトの名無しさん：03/09/18 19:50
>>338
世の中のほとんどすべての事柄は擬人化すると分かりやすくなるんだよ。
でも同時にそれは危険なことでもあると言う人が昔からたくさんいる。
>>340の中の人もそういうことが言いたいんだと思う。
世の中のほとんどすべての事柄は擬人化すると分かりやすくなるんだよ。
でも同時にそれは危険なことでもあると言う人が昔からたくさんいる。
>>340の中の人もそういうことが言いたいんだと思う。
350 ：デフォルトの名無しさん：03/09/18 20:01
誰か結城御大の出動要請をする勇者はいないか？
351 ：デフォルトの名無しさん：03/09/18 20:30
ヤバイ。オブジェクト指向ヤバイ。まじでヤバイよ、マジヤバイ。
オブジェクト指向ヤバイ。
まず覚える事が多い。もう多いなんてもんじゃない。超多い。
多いとかっても
「ペーパーバック500ページぶんくらい？」
とか、もう、そういうレベルじゃない。
何しろ未定義。スゲェ！なんか単位とか無いの。何ページとか何時間とかを超越してる。未定義だし超多い。
しかも拡張してるらしい。ヤバイよ、拡張だよ。
だって普通はC言語とか拡張しないじゃん。だって関数呼び出しの仕様がだんだん増えてったら困るじゃん。コールバックが超デリゲーションとか困るっしょ。
名前空間が増えて、言語が出始めたときはusingがいらなかったのに、三年したらusing namespace stdとか泣くっしょ。
だからC言語とか拡張しない。話のわかるヤツだ。
けどオブジェクト指向はヤバイ。そんなの気にしない。拡張しまくり。最も最初に考案されたsmalltalkとか勉強してもよくわかんないくらい多い。ヤバすぎ。
未定義っていたけど、もしかしたら定義できるかもしんない。でも定義できるって事にすると
「じゃあ、オブジェクト指向の理解の基準ってナニよ？」
って事になるし、それは誰もわからない。ヤバイ。誰にも分からないなんて凄すぎる。
あと超乱立。約50言語。1言語でいうと10フレームワーク。ヤバイ。多すぎ。全部覚える暇もなく死ぬ。怖い。
それに超動的。超malloc。それに超言い換え。メソッドとか平気で出てくる。メソッドて。スポーツ選手でも言わねぇよ、最近。
なんつってもオブジェクト指向は型変換が凄い。ベースクラスとか平気だし。
うちらなんて型変換とかたかだか引き数の整合とるだけで上手く扱えないから統一したり、キャストしてみたり、関数使ったりするのに、
オブジェクト指向は全然平気。型変換を言語機能で扱ってる。凄い。ヤバイ。
とにかく貴様ら、オブジェクト指向のヤバさをもっと知るべきだと思います。
そんなヤバイオブジェクト指向に出て行った前橋とか超偉い。もっとがんばれ。超がんばれ
オブジェクト指向ヤバイ。
まず覚える事が多い。もう多いなんてもんじゃない。超多い。
多いとかっても
「ペーパーバック500ページぶんくらい？」
とか、もう、そういうレベルじゃない。
何しろ未定義。スゲェ！なんか単位とか無いの。何ページとか何時間とかを超越してる。未定義だし超多い。
しかも拡張してるらしい。ヤバイよ、拡張だよ。
だって普通はC言語とか拡張しないじゃん。だって関数呼び出しの仕様がだんだん増えてったら困るじゃん。コールバックが超デリゲーションとか困るっしょ。
名前空間が増えて、言語が出始めたときはusingがいらなかったのに、三年したらusing namespace stdとか泣くっしょ。
だからC言語とか拡張しない。話のわかるヤツだ。
けどオブジェクト指向はヤバイ。そんなの気にしない。拡張しまくり。最も最初に考案されたsmalltalkとか勉強してもよくわかんないくらい多い。ヤバすぎ。
未定義っていたけど、もしかしたら定義できるかもしんない。でも定義できるって事にすると
「じゃあ、オブジェクト指向の理解の基準ってナニよ？」
って事になるし、それは誰もわからない。ヤバイ。誰にも分からないなんて凄すぎる。
あと超乱立。約50言語。1言語でいうと10フレームワーク。ヤバイ。多すぎ。全部覚える暇もなく死ぬ。怖い。
それに超動的。超malloc。それに超言い換え。メソッドとか平気で出てくる。メソッドて。スポーツ選手でも言わねぇよ、最近。
なんつってもオブジェクト指向は型変換が凄い。ベースクラスとか平気だし。
うちらなんて型変換とかたかだか引き数の整合とるだけで上手く扱えないから統一したり、キャストしてみたり、関数使ったりするのに、
オブジェクト指向は全然平気。型変換を言語機能で扱ってる。凄い。ヤバイ。
とにかく貴様ら、オブジェクト指向のヤバさをもっと知るべきだと思います。
そんなヤバイオブジェクト指向に出て行った前橋とか超偉い。もっとがんばれ。超がんばれ
352 ：デフォルトの名無しさん：03/09/18 22:57
353 ：デフォルトの名無しさん：03/09/18 23:05
354 ：デフォルトの名無しさん：03/09/18 23:19
>>353
私もそう思うよ。もちろん。
なんたって分かりやすくするための技術というか方法なんだから。
それで余計に分かりにくくなったとしたら、どこかで何かが間違っているんだよ。
上の方で出てるメッセージ送信がどうのって話しはあんまり気にしなくてもいいと思う。
それなりにおもしろいけど。
私もそう思うよ。もちろん。
なんたって分かりやすくするための技術というか方法なんだから。
それで余計に分かりにくくなったとしたら、どこかで何かが間違っているんだよ。
上の方で出てるメッセージ送信がどうのって話しはあんまり気にしなくてもいいと思う。
それなりにおもしろいけど。
355 ：デフォルトの名無しさん：03/09/19 00:23
356 ：デフォルトの名無しさん：03/09/19 00:36
>>355
一応言っておくと、哺乳類や車は擬人化じゃないからな
一応言っておくと、哺乳類や車は擬人化じゃないからな
357 ：デフォルトの名無しさん：03/09/19 07:21
>>355
擬人化するんじゃなくてアプリケーションで表現したいものに擬すればいいんじゃないかな。
大抵のソフトウェアは何らかの管理する対象を持ってるんだから。
帳簿を 決算すると 決算書ができる。
ホテルに 予約を入れると 部屋が予約済みになる。
計測器の 現在値を読むと 最新の計測値を知ることができる。
生産ラインの ゾーンを見ると 現在のトラッキングの状態がわかる。
オセロ盤に 駒を置くと はさまれた石はひっくりかえる。
ラスボスに 弾が当たると ラスボスが死ぬ（かもしれない）
魔法使いに 攻撃を加えると ＨＰが減る（かもしれない）
送信待ちメールボックスに メールを投函すると あて先の受信メールボックス届く
ファイルを クローズすると そのファイルはクローズする。
取り扱う対象とソフトウェアの内部で独立しているモジュールが（ある程度）一致していれば
他人にも自分にも（ソフトウェアの内部構造を）説明しやすいし理解されやすい。
擬人化するんじゃなくてアプリケーションで表現したいものに擬すればいいんじゃないかな。
大抵のソフトウェアは何らかの管理する対象を持ってるんだから。
帳簿を 決算すると 決算書ができる。
ホテルに 予約を入れると 部屋が予約済みになる。
計測器の 現在値を読むと 最新の計測値を知ることができる。
生産ラインの ゾーンを見ると 現在のトラッキングの状態がわかる。
オセロ盤に 駒を置くと はさまれた石はひっくりかえる。
ラスボスに 弾が当たると ラスボスが死ぬ（かもしれない）
魔法使いに 攻撃を加えると ＨＰが減る（かもしれない）
送信待ちメールボックスに メールを投函すると あて先の受信メールボックス届く
ファイルを クローズすると そのファイルはクローズする。
取り扱う対象とソフトウェアの内部で独立しているモジュールが（ある程度）一致していれば
他人にも自分にも（ソフトウェアの内部構造を）説明しやすいし理解されやすい。
358 ：デフォルトの名無しさん：03/09/19 07:35
そして、帳簿とかホテルの部屋とか一口でいっても、実際にはいろいろあるし、
そのいろいろ、を個別に表現する際に「共通の部分を抜き出して共有する」より
「違っている部分だけを付け加える」方が、より分かりやすい（かもしれない）
分かりやすくするために違っている部分を付け加えてバリエーションを増やしているので
子、孫、曾孫、とつぎはぎを重ねることで、もし分かりにくくなるとしたら本末転倒。
でも十分に構想を練ってスマートに表現できればコードの再利用にも役立つかもしれない。
ちょうど、従来のモジュール分割をうまくやれば汎用的で再利用しやすいモジュールが
出来るかもしれないように。
だから（帳簿やホテルの部屋とかのように）何を一口で表現するのかが表現する際に
重要となりそう。
りんごとオレンジを果物だと一口で表現するとしたら、果物であることが特別な意味を持つような場合に
有効かもしれないが、そうでない場合には一口で表す意味などない。
うまく表現することが大切なのであって正確に表現することとはちょっと違うように思う。
そのいろいろ、を個別に表現する際に「共通の部分を抜き出して共有する」より
「違っている部分だけを付け加える」方が、より分かりやすい（かもしれない）
分かりやすくするために違っている部分を付け加えてバリエーションを増やしているので
子、孫、曾孫、とつぎはぎを重ねることで、もし分かりにくくなるとしたら本末転倒。
でも十分に構想を練ってスマートに表現できればコードの再利用にも役立つかもしれない。
ちょうど、従来のモジュール分割をうまくやれば汎用的で再利用しやすいモジュールが
出来るかもしれないように。
だから（帳簿やホテルの部屋とかのように）何を一口で表現するのかが表現する際に
重要となりそう。
りんごとオレンジを果物だと一口で表現するとしたら、果物であることが特別な意味を持つような場合に
有効かもしれないが、そうでない場合には一口で表す意味などない。
うまく表現することが大切なのであって正確に表現することとはちょっと違うように思う。
359 ：デフォルトの名無しさん：03/09/19 07:49
360 ：デフォルトの名無しさん：03/09/19 08:09
各オブジェクトが並列に動作していないのは、その言語を作った人がそれで不都合がない
と割り切った結果なのだと思う。なんでもかんでも並列に動作されてしまうより
そちらのほうがずいぶんとましな話だ。（取り扱う分野にもよるのかな？）
オブジェクトに対する操作をメッセージなんて言ってしまうのは
多分「オブジェクトに対する操作」と書くのが面倒くさいからじゃないだろうか。
書いてる方は常にオブジェクトに対する操作だと意識していると思うから。
もしそれを忘れて単なる関数呼び出しだと捕らえると（別にそれでもいいけど）
「オブジェクトのメンバ変数をメソッドを通して間接的にアクセスするのは
直接アクセスするのと同じことで隠蔽の意味がない」とか言ってしまうかもしれない。
オブジェクトの属性を操作によって変更できるとしたら、それは（クラスの）設計者が
その操作を公開することが必要だと判断したからで、その判断を放棄して常にそのような
操作を用意しているとしたら迂闊と言えるだろうけども、それでもその属性を表現する
メンバ変数自体を公開してしまうよりはずっと懸命な判断だと思う。
オブジェクトへの操作に対してそのオブジェクトがいかに振舞うかは、当のオブジェクトが
判断するのが自然なことだろうから、アクセス用のメソッドが呼び出されたとしても
実際にどう処理されるかはオブジェクト（の振る舞いを決定するクラス、メソッド）
次第だという余地を残すことができる。
別のメンバ変数の状態に応じて変更を許可、拒否したり、変更された時刻や回数を記録したり、
上下限値を超える設定に対して補正をかけたり、そのメンバ変数自体を無くしてしまったり
する余地を残すことができる。
と割り切った結果なのだと思う。なんでもかんでも並列に動作されてしまうより
そちらのほうがずいぶんとましな話だ。（取り扱う分野にもよるのかな？）
オブジェクトに対する操作をメッセージなんて言ってしまうのは
多分「オブジェクトに対する操作」と書くのが面倒くさいからじゃないだろうか。
書いてる方は常にオブジェクトに対する操作だと意識していると思うから。
もしそれを忘れて単なる関数呼び出しだと捕らえると（別にそれでもいいけど）
「オブジェクトのメンバ変数をメソッドを通して間接的にアクセスするのは
直接アクセスするのと同じことで隠蔽の意味がない」とか言ってしまうかもしれない。
オブジェクトの属性を操作によって変更できるとしたら、それは（クラスの）設計者が
その操作を公開することが必要だと判断したからで、その判断を放棄して常にそのような
操作を用意しているとしたら迂闊と言えるだろうけども、それでもその属性を表現する
メンバ変数自体を公開してしまうよりはずっと懸命な判断だと思う。
オブジェクトへの操作に対してそのオブジェクトがいかに振舞うかは、当のオブジェクトが
判断するのが自然なことだろうから、アクセス用のメソッドが呼び出されたとしても
実際にどう処理されるかはオブジェクト（の振る舞いを決定するクラス、メソッド）
次第だという余地を残すことができる。
別のメンバ変数の状態に応じて変更を許可、拒否したり、変更された時刻や回数を記録したり、
上下限値を超える設定に対して補正をかけたり、そのメンバ変数自体を無くしてしまったり
する余地を残すことができる。
361 ：デフォルトの名無しさん：03/09/19 08:55
擬人化＝両さんが部長に難しいことを説明してもらうときの紙芝居（４０巻近辺？）
362 ：デフォルトの名無しさん：03/09/19 13:19
>>357-358
この文章を見ると、「分かりやすく説明しよう」っていう気持ちが伝わってくるよ。
例えにしても、単語の一つ一つにしても、出来るだけ平易なものをっていう意図が
ちゃんと分かるし、実際平易なのがすごい。この人のOO本出たら買うよｗ
正直言うと、初見のときは、後半部分ではOOにおける継承のメリットや
オブジェクトモデリングの重要性を説いてるのだということを把握するのに
ちょっと時間が掛かったんだけど、「何度か読めば理解できる」って思えたから、
読み直す時も負担に感じなかったし、実際読み直したら理解できた（と思う）。
>>360
「オブジェクトの並列な動作」で早くも挫折……
この文章を見ると、「分かりやすく説明しよう」っていう気持ちが伝わってくるよ。
例えにしても、単語の一つ一つにしても、出来るだけ平易なものをっていう意図が
ちゃんと分かるし、実際平易なのがすごい。この人のOO本出たら買うよｗ
正直言うと、初見のときは、後半部分ではOOにおける継承のメリットや
オブジェクトモデリングの重要性を説いてるのだということを把握するのに
ちょっと時間が掛かったんだけど、「何度か読めば理解できる」って思えたから、
読み直す時も負担に感じなかったし、実際読み直したら理解できた（と思う）。
>>360
「オブジェクトの並列な動作」で早くも挫折……
363 ：デフォルトの名無しさん：03/09/19 18:51
364 ：デフォルトの名無しさん：03/09/19 18:58
>malloc()相当の機能で動的に確保しますよね。だからGCが重要になる。
ちゃんと解放してればGCはいらんわけだが。
ちゃんと解放してればGCはいらんわけだが。
365 ：デフォルトの名無しさん：03/09/19 19:12
GCはオブジェクト指向には必須
366 ：デフォルトの名無しさん：03/09/19 19:22
>>365
(ﾟДﾟ)<
(ﾟДﾟ)<
367 ：デフォルトの名無しさん：03/09/19 20:45
★最新アダルト情報はこちらです★
http://click.dtiserv2.com/Click2/1-98-7254
http://click.dtiserv2.com/Click2/1-98-7254
368 ：デフォルトの名無しさん：03/09/19 21:08
>>330
大嘘は書いてないにしても不正確で偏った文章だな。
タイトル「継承・多態・たとえ話の理解できない脳足りんの為のカプセル化入門」にしたほうがいいんじゃないのか。
おかげで掲示板も言葉尻を捉えたしょうもないネタばっかだし。
肝心の筆者がターゲットにしている読み手の反応はなんかあったのかね。
大嘘は書いてないにしても不正確で偏った文章だな。
タイトル「継承・多態・たとえ話の理解できない脳足りんの為のカプセル化入門」にしたほうがいいんじゃないのか。
おかげで掲示板も言葉尻を捉えたしょうもないネタばっかだし。
肝心の筆者がターゲットにしている読み手の反応はなんかあったのかね。
369 ：デフォルトの名無しさん：03/09/19 21:26
GCなんて飾りです、前橋さんにはそれが分からんのです。
370 ：デフォルトの名無しさん：03/09/19 21:48
通りすがりの>>369よりは前橋さんの方が信じられるな。
371 ：デフォルトの名無しさん：03/09/19 22:10
>>368
> 不正確で偏った文章だな。
> たとえ話の理解できない脳足りん
よほど「脳足りん」な方々に失望させられたんでしょうね……
かく言う私も前橋さんの思いは実体験としてよくわかる人間ですが、
とはいえオセロが出た時点で失望を覚えたのも事実だったり。
理由は>>337ね。あとこの文章を見てる限り、OOに対する理解は
未だ途上にあるんじゃないかというように見えるので、>>342にも
賛同できたり。
>>343みたいに、ああいう姿勢で書いたものに読み手がつくこと自体に
失望する向きもあるかとは思いますが、でもそのレベルの人たちに
「モノを教える技術」も大切だと思うよ。厨房に手取り足取りを嫌ったり
面倒がったりする気持ちも分かるけどね。
> 不正確で偏った文章だな。
> たとえ話の理解できない脳足りん
よほど「脳足りん」な方々に失望させられたんでしょうね……
かく言う私も前橋さんの思いは実体験としてよくわかる人間ですが、
とはいえオセロが出た時点で失望を覚えたのも事実だったり。
理由は>>337ね。あとこの文章を見てる限り、OOに対する理解は
未だ途上にあるんじゃないかというように見えるので、>>342にも
賛同できたり。
>>343みたいに、ああいう姿勢で書いたものに読み手がつくこと自体に
失望する向きもあるかとは思いますが、でもそのレベルの人たちに
「モノを教える技術」も大切だと思うよ。厨房に手取り足取りを嫌ったり
面倒がったりする気持ちも分かるけどね。
372 ：デフォルトの名無しさん：03/09/19 22:48
あのサイトのメインの読者がどういう層なのかわからんが、C→C++とかJavaってパターン以外の
OOPの世界観があるっつー事が閉じた世界の人の目に触れるような事になればOKだろうなぁ。
とりあえず煽る態度はやばやばだとおもーが（藁
にしても俺様世界観だよなぁ。前橋って人は。雑記とか見てたら粉末君を思い出してしもたよ（藁
OOPの世界観があるっつー事が閉じた世界の人の目に触れるような事になればOKだろうなぁ。
とりあえず煽る態度はやばやばだとおもーが（藁
にしても俺様世界観だよなぁ。前橋って人は。雑記とか見てたら粉末君を思い出してしもたよ（藁
373 ：デフォルトの名無しさん：03/09/19 23:09
おいおい、ずいぶんインパクト大きかったらしいな。
374 ：デフォルトの名無しさん：03/09/19 23:13
>>372
注目されてるから読んでみるべーと思ったら、いきなり
> 私は、オブジェクト指向の「本質」と呼ぶべきものは、カプセル化でも継承でも
> ポリモルフィズムでもなく、「マルチプルインスタンス」にあると思っています。
> ところがぎっちょんそういう説明をしている本やWebページはほとんどない。
> 「マルチプルインスタンス オブジェクト指向」でGoogleしてもヒットは0件 (2003/9/16現在)、
> 「マルチインスタンス」ではRDBMSのインスタンスを指すらしい。でも、C++ FAQ
> には 以下の記述があります。
とあって、もう読む気ゼロ。
注目されてるから読んでみるべーと思ったら、いきなり
> 私は、オブジェクト指向の「本質」と呼ぶべきものは、カプセル化でも継承でも
> ポリモルフィズムでもなく、「マルチプルインスタンス」にあると思っています。
> ところがぎっちょんそういう説明をしている本やWebページはほとんどない。
> 「マルチプルインスタンス オブジェクト指向」でGoogleしてもヒットは0件 (2003/9/16現在)、
> 「マルチインスタンス」ではRDBMSのインスタンスを指すらしい。でも、C++ FAQ
> には 以下の記述があります。
とあって、もう読む気ゼロ。
375 ：デフォルトの名無しさん：03/09/19 23:19
好みもあるけど、この手のカタカナ多用文書ってきらいだな。
適切な約を付けるか、英語のままにしてほしい。
カタカナ表音って、読みつらくてしょうがない。
適切な約を付けるか、英語のままにしてほしい。
カタカナ表音って、読みつらくてしょうがない。
376 ：デフォルトの名無しさん：03/09/19 23:27
これだからC上がりってイヤなんだよな。
377 ：デフォルトの名無しさん：03/09/19 23:27
何がオブジェクト指向か、を説明するのに、オブジェクト指向以外でも
使う概念(カプセル化とか何とか)を前面に持って来たら、そりゃ混乱もする
だろう。ちゃんとオブジェクト指向独自の部分を切り出せよ。
使う概念(カプセル化とか何とか)を前面に持って来たら、そりゃ混乱もする
だろう。ちゃんとオブジェクト指向独自の部分を切り出せよ。
378 ：デフォルトの名無しさん：03/09/19 23:35
お前はマルチプルインスタンス言いたいだけちゃうんかと・・・
379 ：デフォルトの名無しさん：03/09/19 23:37
380 ：デフォルトの名無しさん：03/09/19 23:57
マルティプルインスタンスが生産性向上に役立つって説明は間違ってないと思うけどな。
「役に立つOOPLの機能」という意味でそこに注目するのは正しい切り口だと思う。
「役に立つOOPLの機能」という意味でそこに注目するのは正しい切り口だと思う。
381 ：デフォルトの名無しさん：03/09/19 23:58
モウティポウインステァンス
思わずageちゃいました。ごめんなさい。
383 ：デフォルトの名無しさん：03/09/20 00:03
実のところマルチプルインスタンスなんてオブジェクト指向とは無関係に昔から行われてきたことですし、
オブジェクト指向で継承やポリモルフィズムよりも先に覚えなければならないことではありません。
私は、オブジェクト指向の「本質」と呼ぶべきものは、マルチプルインスタンスではなく、「カプセル化・継承・ポリモルフィズム」にあると思っています。
オブジェクト指向で継承やポリモルフィズムよりも先に覚えなければならないことではありません。
私は、オブジェクト指向の「本質」と呼ぶべきものは、マルチプルインスタンスではなく、「カプセル化・継承・ポリモルフィズム」にあると思っています。
実のところカプセル化・継承・ポリモルフィズムなんてオブジェクト指向とは無関係に昔から行われてきたことですし、
オブジェクト指向で思考方法よりも先に覚えなければならないことではありません。
私は、オブジェクト指向の「本質」と呼ぶべきものは、カプセル化・継承・ポリモルフィズムではなく、「思考方法」にあると思っています。
オブジェクト指向で思考方法よりも先に覚えなければならないことではありません。
私は、オブジェクト指向の「本質」と呼ぶべきものは、カプセル化・継承・ポリモルフィズムではなく、「思考方法」にあると思っています。
385 ：デフォルトの名無しさん：03/09/20 00:15
実のところオブジェクト指向プログラミングなんてオブジェクト指向プログラミング言語とは無関係に昔から行われてきたことですし、
オブジェクト指向で新たに言語を覚えなければならないということはありません。
私は、オブジェクト指向の「本質」と呼ぶべきものは、プログラミング言語のサポートではなく、「CでOOP」にあると思っています。
オブジェクト指向で新たに言語を覚えなければならないということはありません。
私は、オブジェクト指向の「本質」と呼ぶべきものは、プログラミング言語のサポートではなく、「CでOOP」にあると思っています。
386 ：デフォルトの名無しさん：03/09/20 00:20
藻前らふざけすぎ
>>385
最後の行がなければある意味正しかったですね。
最後の行がなければある意味正しかったですね。
388 ：デフォルトの名無しさん：03/09/20 00:28
マルティプルインスタンスってなんだ？
オブジェクトの動的ロードって事か？
オブジェクトの動的ロードって事か？
>>388
monostateの対義語かな。
monostateの対義語かな。
390 ：デフォルトの名無しさん：03/09/20 00:37
391 ：デフォルトの名無しさん：03/09/20 01:05
392 ：デフォルトの名無しさん：03/09/20 01:09
前橋を叩いてるのは憂鬱本信者か。
憂鬱本の出版時期までOOを知らなかった不勉強者の集まりだと思えば当然の行為だな。
憂鬱本の出版時期までOOを知らなかった不勉強者の集まりだと思えば当然の行為だな。
393 ：デフォルトの名無しさん：03/09/20 01:29
でもあれだよなぁ。ここもあすこのおかげでこんだけ盛り上がるわけだし（藁
影響力あったって事か？
どっちにしても分析設計からOOPできてないと駄目駄目って事でOK？
影響力あったって事か？
どっちにしても分析設計からOOPできてないと駄目駄目って事でOK？
394 ：デフォルトの名無しさん：03/09/20 01:30
>>393
Pは必要ないだろ
Pは必要ないだろ
395 ：デフォルトの名無しさん：03/09/20 01:35
オブジェクト歯垢
396 ：デフォルトの名無しさん：03/09/20 01:38
しかしOOPの根源的三要素は10年以上前から常識だと思ってたんだがな。
Turbo Pascalユーザーズガイド第？章「オブジェクト指向プログラミング」は実に分かりやすかった。
Turbo Pascalユーザーズガイド第？章「オブジェクト指向プログラミング」は実に分かりやすかった。
397 ：デフォルトの名無しさん：03/09/20 01:41
クラスやら継承やら動的結合のような実装方法より前に、機能主導ではなくてデータ主導の考え方
だよって教えるべきではないかとも思う。
だよって教えるべきではないかとも思う。
398 ：デフォルトの名無しさん：03/09/20 03:02
>>397
またバカが参入
またバカが参入
399 ：デフォルトの名無しさん：03/09/20 03:50
それはデータ指向アプローチ(到着時には死亡していた)では？
400 ：デフォルトの名無しさん：03/09/20 04:50
401 ：デフォルトの名無しさん：03/09/20 08:55
関数を呼び出して。。。
Ｃ言語を分かりにくいものにしている最大の要因として、「関数」という言葉が挙げられます。
関数という言葉を聞くと、まるで引き渡した数値をもとに計算された結果を得ることが
できるように思えますが、実際はそうではありません。実は、まったく同じパラメータを渡しても
異なる値が戻される場合があるのです！
これはなぜかというと、Ｃ言語で関数と呼ばれているものが戻り値として返すのはパラメータを元に
計算された結果ではなく、関数の内部で実行された手続きの処理ステータスだからなのです。
つまり、Ｃ言語における関数とは値を求めるためのものではなく、関数の「副作用」としての
手続きを実行させるための手段として用いられるものだと考えられます。
Ｃ言語で関数と呼ばれているのは、実のところ単なるサブルーチンコールにすぎないのです（！！）
こんなものに「関数」なんてまぎらわしい名前をつけていることが、Ｃ言語の学習を妨げているのだと思います。
Ｃ言語を分かりにくいものにしている最大の要因として、「関数」という言葉が挙げられます。
関数という言葉を聞くと、まるで引き渡した数値をもとに計算された結果を得ることが
できるように思えますが、実際はそうではありません。実は、まったく同じパラメータを渡しても
異なる値が戻される場合があるのです！
これはなぜかというと、Ｃ言語で関数と呼ばれているものが戻り値として返すのはパラメータを元に
計算された結果ではなく、関数の内部で実行された手続きの処理ステータスだからなのです。
つまり、Ｃ言語における関数とは値を求めるためのものではなく、関数の「副作用」としての
手続きを実行させるための手段として用いられるものだと考えられます。
Ｃ言語で関数と呼ばれているのは、実のところ単なるサブルーチンコールにすぎないのです（！！）
こんなものに「関数」なんてまぎらわしい名前をつけていることが、Ｃ言語の学習を妨げているのだと思います。
402 ：デフォルトの名無しさん：03/09/20 08:56
関数で生産性は上がるか。。。
よく使用される手続きをサブルーチン化することでコードの再利用性が高まるという意見もよく聞きます。
しかし、わたしはこの意見にも懐疑的です。一度書いたコードを再利用したいなら、コピペすればよいのでは？
と、多少実戦を経験したプログラマなら思うことでしょう。実際サブルーチンコールなどというものが
普及するずっと以前から「サンプルソース」という形で再利用可能なコードが提供されいたわけです。
ただ、私はサブルーチンコールに意味がないとは考えません。メモリの節約になるからです。
よく使用される手続きをサブルーチン化することでコードの再利用性が高まるという意見もよく聞きます。
しかし、わたしはこの意見にも懐疑的です。一度書いたコードを再利用したいなら、コピペすればよいのでは？
と、多少実戦を経験したプログラマなら思うことでしょう。実際サブルーチンコールなどというものが
普及するずっと以前から「サンプルソース」という形で再利用可能なコードが提供されいたわけです。
ただ、私はサブルーチンコールに意味がないとは考えません。メモリの節約になるからです。
403 ：デフォルトの名無しさん：03/09/20 08:57
構造体ってナニ？。。。
さて、Ｃ言語では複数の変数をひとまとめにしてあつかうために構造体と呼ばれるものを使います。
rec.seqno = 1;
rec.datanum = 3;
rec.data[0] = 100;
rec.data[1] = 101;
書き方としてはこんなところでしょうか。構造体が使えなければ次のようになるでしょう。
rec_seqno = 1;
rec_datanum = 3;
rec_data[0] = 100;
rec_data[1] = 101;
こんなの見た目が変わっただけじゃないか！
全くそのとおり。宣言のコピペの手間を除けば構造体といってもその程度のものです。
さて、Ｃ言語では複数の変数をひとまとめにしてあつかうために構造体と呼ばれるものを使います。
rec.seqno = 1;
rec.datanum = 3;
rec.data[0] = 100;
rec.data[1] = 101;
書き方としてはこんなところでしょうか。構造体が使えなければ次のようになるでしょう。
rec_seqno = 1;
rec_datanum = 3;
rec_data[0] = 100;
rec_data[1] = 101;
こんなの見た目が変わっただけじゃないか！
全くそのとおり。宣言のコピペの手間を除けば構造体といってもその程度のものです。
404 ：デフォルトの名無しさん：03/09/20 08:59
おさらい
・サブルーチンのことを「関数」といわれて納得できる人は性格に難がある。
・サブルーチンライブラリで再利用性が高まるといっている連中の多くはコピペとの違いを説明できない。
・「モジュール化が大切」なんていっている入門書は信じるな。
・変数名にプレフィックス、ポストフィックスをつければローカル変数は不要。
・どうしてもメモリが足りなくてサブルーチンを使用した場合、それは「関数」と名前を変えるがどうってことはない。大丈夫だ。
・サブルーチンのことを「関数」といわれて納得できる人は性格に難がある。
・サブルーチンライブラリで再利用性が高まるといっている連中の多くはコピペとの違いを説明できない。
・「モジュール化が大切」なんていっている入門書は信じるな。
・変数名にプレフィックス、ポストフィックスをつければローカル変数は不要。
・どうしてもメモリが足りなくてサブルーチンを使用した場合、それは「関数」と名前を変えるがどうってことはない。大丈夫だ。
405 ：デフォルトの名無しさん：03/09/20 09:01
406 ：デフォルトの名無しさん：03/09/20 09:03
407 ：デフォルトの名無しさん：03/09/20 09:45
OOの設計ってstatic変数によるモジュール化と大筋は同じで、
その種のモジュール化とOOの最大の違いがマルチプルインスタンス
だから、マルチプルインスタンスは最後の一歩であって、
その前のモジュール化を見落としたら本末転倒というしか無い。
singletonなんて言い出したらモジュール化と完全に一緒じゃん。
その種のモジュール化とOOの最大の違いがマルチプルインスタンス
だから、マルチプルインスタンスは最後の一歩であって、
その前のモジュール化を見落としたら本末転倒というしか無い。
singletonなんて言い出したらモジュール化と完全に一緒じゃん。
408 ：デフォルトの名無しさん：03/09/20 10:00
なんか、ものすごいのがやってきてるな。
まだ夏休みだっけ？
まだ夏休みだっけ？
409 ：デフォルトの名無しさん：03/09/20 10:24
410 ：デフォルトの名無しさん：03/09/20 10:30
411 ：デフォルトの名無しさん：03/09/20 10:31
>>397
OOもデータにスポットを当てた手法なんだけどね。
機能とデータどちらかに偏るのではなく、
どっちもバランス良く分析しなければならない。
客のRFPをもとにどのような機能をこのシステムが持たなければ
いかないのかを分析するのは、もちろん機能中心だ。
それと同時に、画面、帳票などの情報をもとにER分析を行う。
これはもちろんデータ中心だ。
OOもデータにスポットを当てた手法なんだけどね。
機能とデータどちらかに偏るのではなく、
どっちもバランス良く分析しなければならない。
客のRFPをもとにどのような機能をこのシステムが持たなければ
いかないのかを分析するのは、もちろん機能中心だ。
それと同時に、画面、帳票などの情報をもとにER分析を行う。
これはもちろんデータ中心だ。
412 ：デフォルトの名無しさん：03/09/20 10:32
413 ：デフォルトの名無しさん：03/09/20 10:43
>>409
関数を思いつくままに作っていくとその関数をテストする作業が膨大になってしまいます。
逆にコピー&ペーストをした場合、テストの項目はそのコードが属する関数唯一つだけで一切増えません。
コピー＆ペーストは近年急激に膨張し続けているソフトウェアの規模に対する直接的な回答であるといえるでしょう。
関数を思いつくままに作っていくとその関数をテストする作業が膨大になってしまいます。
逆にコピー&ペーストをした場合、テストの項目はそのコードが属する関数唯一つだけで一切増えません。
コピー＆ペーストは近年急激に膨張し続けているソフトウェアの規模に対する直接的な回答であるといえるでしょう。
414 ：デフォルトの名無しさん：03/09/20 11:08
>>399
英語にしないとわかりにくいダジャレだな
英語にしないとわかりにくいダジャレだな
415 ：デフォルトの名無しさん：03/09/20 11:12
416 ：デフォルトの名無しさん：03/09/20 11:12
>414
なるほど、そういうシャレだったのか。
なるほど、そういうシャレだったのか。
417 ：デフォルトの名無しさん：03/09/20 12:35
まだ駆け出しだが、プログラム作ってて、ここは継承でやれるんだろうけど、
継承するべきか、あるいは既存のクラスそのものを改造したほうが潔いかと
判断に悩むことがある。
貧乏性なもんで、継承しちゃうと、メモリの消費量とか、ファイルサイズが
大きくなるんじゃないかと気になるし。
継承するべきか、あるいは既存のクラスそのものを改造したほうが潔いかと
判断に悩むことがある。
貧乏性なもんで、継承しちゃうと、メモリの消費量とか、ファイルサイズが
大きくなるんじゃないかと気になるし。
418 ：デフォルトの名無しさん：03/09/20 13:50
そもそもどういったときにオブジェクト指向独自の機能を使うのか解りにくい
と思うのはコーディング経験が浅いからでしょうか？
と思うのはコーディング経験が浅いからでしょうか？
419 ：デフォルトの名無しさん：03/09/20 14:03
実験コードたくさん書いて、たくさんテストすりゃいいじゃん。
決して無駄な時間じゃないでしょ。
決して無駄な時間じゃないでしょ。
420 ：デフォルトの名無しさん：03/09/20 16:03
421 ：デフォルトの名無しさん：03/09/20 16:12
経験は大切だ。だがそれだけに頼ってはならない。
422 ：デフォルトの名無しさん：03/09/20 17:33
確かにコード書くのも大事だけど、間違った事を繰り返してるだけだとトンデモくんになっちゃうよなぁ。
423 ：デフォルトの名無しさん：03/09/20 18:49
業務でコードを書いてると、
とにかく機能を実装することに目が入って
設計を疎かにすることも多いな。
オレはリファクタリングという言葉を拡大解釈して
一度書いたコードを時折見直すように心掛けてる。
そうしないとダメなコーディングをずっと続けて、
リファクタリングの時間を取るよりも余計に時間を食う羽目になるからね。
とにかく機能を実装することに目が入って
設計を疎かにすることも多いな。
オレはリファクタリングという言葉を拡大解釈して
一度書いたコードを時折見直すように心掛けてる。
そうしないとダメなコーディングをずっと続けて、
リファクタリングの時間を取るよりも余計に時間を食う羽目になるからね。
424 ：デフォルトの名無しさん：03/09/20 21:52
>>418
それはコーディング経験が浅いんでなく、オブジェクト指向の勉強が足りてないからだと思う・・・。
自分自身の取るに足らない経験から言うと、Javaをやると自然と身に付くと思うよ。
その後でC++行く方が良い感じ、と思った。少なくとも自分は。
それはコーディング経験が浅いんでなく、オブジェクト指向の勉強が足りてないからだと思う・・・。
自分自身の取るに足らない経験から言うと、Javaをやると自然と身に付くと思うよ。
その後でC++行く方が良い感じ、と思った。少なくとも自分は。
425 ：デフォルトの名無しさん：03/09/20 22:00
リファクタリングなんて不要です。
一度かいたコードを見直し修正するなんて馬鹿げています。
動いているんだからそれでいいじゃないですか？下手に手を入れたら、動かなくなります。
そもそもソースなんて機械語を生成するため記号の羅列にすぎません。
文芸作品ではないです。可読せいや一貫性などを考慮する必要はありません。動けばいいのです。
コードの保守？保守するのはどうせ私ではありません。
保守は他の人間にやらせるのがもっとも現実的な答えです。
一度かいたコードを見直し修正するなんて馬鹿げています。
動いているんだからそれでいいじゃないですか？下手に手を入れたら、動かなくなります。
そもそもソースなんて機械語を生成するため記号の羅列にすぎません。
文芸作品ではないです。可読せいや一貫性などを考慮する必要はありません。動けばいいのです。
コードの保守？保守するのはどうせ私ではありません。
保守は他の人間にやらせるのがもっとも現実的な答えです。
426 ：デフォルトの名無しさん：03/09/20 22:12
>>425
> 動いているんだからそれでいいじゃないですか？下手に手を入れたら、動かなくなります。
そりゃーそうだ、君の作ったげーじつ的なソースはドミノのような仕組が入ってるからね。
リファクタリングには向かない。
作り直すに限る。
> コードの保守？保守するのはどうせ私ではありません。
> 保守は他の人間にやらせるのがもっとも現実的な答えです。
因果応報という言葉をちみに送ろう。
自分が世界最強のDQNだと思ってるうちはまだ若い。
世界は広いのです。あなたより強烈な奴の作ったソースが何時の日かあなたの前に立ちはだかります。
> 動いているんだからそれでいいじゃないですか？下手に手を入れたら、動かなくなります。
そりゃーそうだ、君の作ったげーじつ的なソースはドミノのような仕組が入ってるからね。
リファクタリングには向かない。
作り直すに限る。
> コードの保守？保守するのはどうせ私ではありません。
> 保守は他の人間にやらせるのがもっとも現実的な答えです。
因果応報という言葉をちみに送ろう。
自分が世界最強のDQNだと思ってるうちはまだ若い。
世界は広いのです。あなたより強烈な奴の作ったソースが何時の日かあなたの前に立ちはだかります。
427 ：デフォルトの名無しさん：03/09/20 22:43
あそこの掲示板もかなり話が逸れだしてるよな。
アレはアレで別の意味で参考になるが。
関数をメッセージって呼ぼうとする姿勢は実装云々の話じゃないよな。
そこら辺がちっとも出てこないのがなんだかもぉ。
あとイロイロ盛り上がってる割には「じゃあ人にどうやって教えようか」って
肝心の話がほとんど出てないし。
>>426
ネタにマジレスか（ry
アレはアレで別の意味で参考になるが。
関数をメッセージって呼ぼうとする姿勢は実装云々の話じゃないよな。
そこら辺がちっとも出てこないのがなんだかもぉ。
あとイロイロ盛り上がってる割には「じゃあ人にどうやって教えようか」って
肝心の話がほとんど出てないし。
>>426
ネタにマジレスか（ry
428 ：デフォルトの名無しさん：03/09/21 00:13
モリポーフィズムって響きがいいね。
∧＿∧
（ ´∀｀） ＜ もりぽ
∧＿∧
（ ´∀｀） ＜ もりぽ
429 ：デフォルトの名無しさん：03/09/21 00:15
>>427
頼む。(ry の意味を教えてくれ。
頼む。(ry の意味を教えてくれ。
430 ：デフォルトの名無しさん：03/09/21 00:26
（ryやアホアンチは自作自演Java厨のキーワード
431 ：デフォルトの名無しさん：03/09/21 01:10
まじめに頼む。
433 ：デフォルトの名無しさん：03/09/21 02:12
>>432
2chにまじめなんて求める奴は..(略
2chにまじめなんて求める奴は..(略
434 ：デフォルトの名無しさん：03/09/21 02:16
ハードウェアの動作をオブジェクト指向でプログラムすると
自然と分かるよ。てゆーか、ハードウェア記述言語は少し参考になる。
自然と分かるよ。てゆーか、ハードウェア記述言語は少し参考になる。
435 ：デフォルトの名無しさん：03/09/21 03:28
省略→略→ryaku→ry
436 ：デフォルトの名無しさん：03/09/21 03:36
関係ない話なんだけどね。完全に横槍なんだけどね。
習作でList<T>のクラス作ってたんですよ。
着々と実装していって、クラスがほぼ完成してきた頃っいったら、
もう把握するのも嫌な位に着々とゆであがったスパゲッティなわけですよ。
で、もうちょっとで完成だ！って時に、
関数単位のテストを結構やってたにもかかわらず、deleteでこけるわけですよ。
deleteをオーバーライドしたかいも無く、これに泣いて約3日何も進展無しですよ。
どうしようもなくて、決起して作り直したんですよ。
思い立ったからには、実装中の不満も解消しようとしてはじめたわけなんですよ。
それがなんと、1日で完成した上に機能の実装もほぼ終わり、しかもdeleteも通ったんですよ！！
もー、ビックリするほどユートピアってこう言うことだったのか！！と思う位ですよ。
何がいいたいかと言うとね。
構造体が無いとこう言うことがおきまくるし、読み直しをしないと整合性がもてないのですよ。
ぅうううううううううううーーーーーーーーーーぃいゃっほぉーーーーーーーーーい！！
あーっひゃっひゃっひゃ。（以下略。
習作でList<T>のクラス作ってたんですよ。
着々と実装していって、クラスがほぼ完成してきた頃っいったら、
もう把握するのも嫌な位に着々とゆであがったスパゲッティなわけですよ。
で、もうちょっとで完成だ！って時に、
関数単位のテストを結構やってたにもかかわらず、deleteでこけるわけですよ。
deleteをオーバーライドしたかいも無く、これに泣いて約3日何も進展無しですよ。
どうしようもなくて、決起して作り直したんですよ。
思い立ったからには、実装中の不満も解消しようとしてはじめたわけなんですよ。
それがなんと、1日で完成した上に機能の実装もほぼ終わり、しかもdeleteも通ったんですよ！！
もー、ビックリするほどユートピアってこう言うことだったのか！！と思う位ですよ。
何がいいたいかと言うとね。
構造体が無いとこう言うことがおきまくるし、読み直しをしないと整合性がもてないのですよ。
ぅうううううううううううーーーーーーーーーーぃいゃっほぉーーーーーーーーーい！！
あーっひゃっひゃっひゃ。（以下略。
>>435
おー(涙)。これで寝れます。
おー(涙)。これで寝れます。
438 ：デフォルトの名無しさん：03/09/21 05:11
マルチプルインスタンス君の説明は多態で適切なメソッドが選ばれるという
OOの重要な性質の説明以前で終わっているから、あんな結論なんだろう。
正直、「逝ってよしの1」って前橋君だったんだろ？
オセロもでてくるし。
OOの重要な性質の説明以前で終わっているから、あんな結論なんだろう。
正直、「逝ってよしの1」って前橋君だったんだろ？
オセロもでてくるし。
439 ：デフォルトの名無しさん：03/09/21 05:21
はじめてあずまんが大王見たけど
大阪 ってただの致傷だよな
大阪 ってただの致傷だよな
440 ：デフォルトの名無しさん：03/09/21 05:50
441 ：デフォルトの名無しさん：03/09/21 06:54
>>439
志村！スレタイ、スレタイ！
志村！スレタイ、スレタイ！
442 ：デフォルトの名無しさん：03/09/21 08:50
洗脳するなら、経験者より未経験者、大人より子供、秀才より馬鹿ってのはあるね。
ただ、安易に受け入れることによって、本質を見抜けないって副作用があるかな。
ただ、安易に受け入れることによって、本質を見抜けないって副作用があるかな。
443 ：デフォルトの名無しさん：03/09/21 09:08
>>440
業務フロー的なものとオブジェクト指向は結びつかないと思われ。
業務フロー的なものとオブジェクト指向は結びつかないと思われ。
444 ：デフォルトの名無しさん：03/09/21 09:25
>>439を見るに、OOとあずまんがの集合は重なると言う結論で。
445 ：デフォルトの名無しさん：03/09/21 09:27
446 ：デフォルトの名無しさん：03/09/21 10:03
メッセージ受信者も英語のメッセージ専用とか日本語のメッセージ専用とか決めとく方が
全世界の言語を操れる人を雇うよりコストが低いのです。
偉い人にはそれがわからんのです。
全世界の言語を操れる人を雇うよりコストが低いのです。
偉い人にはそれがわからんのです。
447 ：デフォルトの名無しさん：03/09/21 11:00
言語としてメソッドのオーバーロードをサポートしてなくて
受け渡された情報の一部を使って決定した下請けに回している場合とかでも
やっぱりメッセージといってかまわないと思うが、とか。
>446
日本語を使う送信者もスワヒリ語を操る送信者も、受信者が誰で何人いるかなんて気にしなくていいしね。
受け渡された情報の一部を使って決定した下請けに回している場合とかでも
やっぱりメッセージといってかまわないと思うが、とか。
>446
日本語を使う送信者もスワヒリ語を操る送信者も、受信者が誰で何人いるかなんて気にしなくていいしね。
448 ：デフォルトの名無しさん：03/09/21 11:16
なんかココに居る連中、エラソウなコメントしてるヤツ多いな。
そんなにアゲアシしたけりゃOOについてわかり易い説明してみろ。
あ、俺は高橋君じゃないぞ。
そんなにアゲアシしたけりゃOOについてわかり易い説明してみろ。
あ、俺は高橋君じゃないぞ。
449 ：デフォルトの名無しさん：03/09/21 11:38
> そんなにアゲアシしたけりゃ
と
> OOについてわかり易い説明してみろ。
はどうつながるのか？
と
> OOについてわかり易い説明してみろ。
はどうつながるのか？
450 ：デフォルトの名無しさん：03/09/21 12:39
もまいらはオブジェクト指向と実務で使えるオブジェクト指向を勘違いしておる。
451 ：デフォルトの名無しさん：03/09/21 13:04
というかどうやったらOOP入門で挫折できるんだろう。
そんなに難しいか？
そんなに難しいか？
452 ：デフォルトの名無しさん：03/09/21 13:09
453 ：デフォルトの名無しさん：03/09/21 13:13
454 ：デフォルトの名無しさん：03/09/21 13:18
>>453
いやー、魔法の杖ってほしくなるじゃん。
データからのアプローチとオブジェクトで分析のすり合わせを最近ためしてるんだけど、
なかなかいいように思えて、結局やっぱり、なんていうか。ｗ
経験値なんだろうけどね。
実際にハードがあるもの（組み込みとか装置系）はオブジェクトに当てはめ安いと思う。
業務って結構抽象的なものをオブジェクトにするかどうするかで悩む。
いやー、魔法の杖ってほしくなるじゃん。
データからのアプローチとオブジェクトで分析のすり合わせを最近ためしてるんだけど、
なかなかいいように思えて、結局やっぱり、なんていうか。ｗ
経験値なんだろうけどね。
実際にハードがあるもの（組み込みとか装置系）はオブジェクトに当てはめ安いと思う。
業務って結構抽象的なものをオブジェクトにするかどうするかで悩む。
455 ：デフォルトの名無しさん：03/09/21 13:27
>>454
> 実際にハードがあるもの（組み込みとか装置系）はオブジェクトに当てはめ安いと思う。
ハードというか、データ中心だとオブジェクトを見つけやすいね。GUI を使う場合の
ウィンドウやメニューバー、フレームワークとしての Document-View, あとは CAD
なんかを作るときのモデル・モーションなどなど。
GoF のデザパタを見ると、挙動やアルゴリズムをオブジェクトに落とし込むスキームとして
State, Strategy なんかが示されてるけど、これはうまく使えるようになるまで、やや時間が
かかる。うまくハマれば強力だけど。
> 実際にハードがあるもの（組み込みとか装置系）はオブジェクトに当てはめ安いと思う。
ハードというか、データ中心だとオブジェクトを見つけやすいね。GUI を使う場合の
ウィンドウやメニューバー、フレームワークとしての Document-View, あとは CAD
なんかを作るときのモデル・モーションなどなど。
GoF のデザパタを見ると、挙動やアルゴリズムをオブジェクトに落とし込むスキームとして
State, Strategy なんかが示されてるけど、これはうまく使えるようになるまで、やや時間が
かかる。うまくハマれば強力だけど。
456 ：デフォルトの名無しさん：03/09/21 13:36
>>455
データ中心でも、やっぱり業務が噛むとなんともいえないときがある。
昔のDBを引き継いだりもあるし。その設計が屑だったらさらに鬱。
分析パターンも読んだけど、まだしっくりきていない。
例にある程度の業務だったらパッケージ買えば済む程度のやつばかりだし。ｗ
まあ、その中から如何にモデル化して単純にしていくかがテクなんだろうけどね。
データ中心でも、やっぱり業務が噛むとなんともいえないときがある。
昔のDBを引き継いだりもあるし。その設計が屑だったらさらに鬱。
分析パターンも読んだけど、まだしっくりきていない。
例にある程度の業務だったらパッケージ買えば済む程度のやつばかりだし。ｗ
まあ、その中から如何にモデル化して単純にしていくかがテクなんだろうけどね。
457 ：デフォルトの名無しさん：03/09/21 13:47
458 ：デフォルトの名無しさん：03/09/21 14:57
>>454
業務のデータはER分析。
業務の振る舞いはとりあえず手続きとして分析。
無理してOOするのではなく、
あきらかにOOが使えそうな部分にだけ、
OOを適用する。
最初からOOしようとするから、疲れちゃうんじゃないかな。
業務のデータはER分析。
業務の振る舞いはとりあえず手続きとして分析。
無理してOOするのではなく、
あきらかにOOが使えそうな部分にだけ、
OOを適用する。
最初からOOしようとするから、疲れちゃうんじゃないかな。
459 ：デフォルトの名無しさん：03/09/21 15:02
460 ：デフォルトの名無しさん：03/09/21 15:16
>>448
OOとは、関連のあるデータと振る舞いを１つにまとめ、
再利用性、メンテナンス性を高めようとすることだ。
OOのプログラミング的な要素として、
カプセル化、継承、多態性などがある。
カプセル化は、内部の実装を隠すことによって、
内部的な変更が外部に対して影響を与えないようにする。
これが、メンテナンス性の向上につながる。
継承は、既にある機能を利用して、足りない部分だけを
差分で実装することで、再利用性を高める。
多態性は、説明が難しいね。(ｗ
OOとは、関連のあるデータと振る舞いを１つにまとめ、
再利用性、メンテナンス性を高めようとすることだ。
OOのプログラミング的な要素として、
カプセル化、継承、多態性などがある。
カプセル化は、内部の実装を隠すことによって、
内部的な変更が外部に対して影響を与えないようにする。
これが、メンテナンス性の向上につながる。
継承は、既にある機能を利用して、足りない部分だけを
差分で実装することで、再利用性を高める。
多態性は、説明が難しいね。(ｗ
461 ：デフォルトの名無しさん：03/09/21 15:59
多態とは同じメッセージに対して異なるメソッドが選択されること。
前橋君にはそれがわからんのです。
前橋君にはそれがわからんのです。
462 ：デフォルトの名無しさん：03/09/21 16:18
463 ：デフォルトの名無しさん：03/09/21 16:21
蹴っ飛ばしたときにわんと鳴くかにゃあと鳴くかは、そいつ次第ってことだろ。
「わんと鳴く」とか「にゃあと鳴く」ていう実際の処理と「蹴っ飛ばす」て操作を分けて
メッセージとメソッド、操作と振る舞い、関数呼び出しと実際の関数の処理内容、
が別物だと考えるって教えずに、ただの関数呼び出しなんですよ、安心してください
って言っちゃうと
「わんと鳴く関数の呼び出し」やら「にゃあと鳴く関数の呼び出し」やらやっちゃうんじゃないかね。
「わんと鳴く」とか「にゃあと鳴く」ていう実際の処理と「蹴っ飛ばす」て操作を分けて
メッセージとメソッド、操作と振る舞い、関数呼び出しと実際の関数の処理内容、
が別物だと考えるって教えずに、ただの関数呼び出しなんですよ、安心してください
って言っちゃうと
「わんと鳴く関数の呼び出し」やら「にゃあと鳴く関数の呼び出し」やらやっちゃうんじゃないかね。
464 ：デフォルトの名無しさん：03/09/21 16:24
465 ：デフォルトの名無しさん：03/09/21 16:34
>>461
多態性は、同じメッセージに対して、実行時に
実際に呼び出されるメソッドが決定されることだと
思うけど、もうちょっとわかりやすく説明できないだろうか。
初心者には、ちょっと難しい。
例を挙げるしかないのかな。
多態性は、同じメッセージに対して、実行時に
実際に呼び出されるメソッドが決定されることだと
思うけど、もうちょっとわかりやすく説明できないだろうか。
初心者には、ちょっと難しい。
例を挙げるしかないのかな。
466 ：デフォルトの名無しさん：03/09/21 16:48
ゲームってさ
かなりオブジェクト指向だと思われるんですけどね。
あー
エロゲみたいな奴じゃなくて
アクションゲームとか
シューティング（弾幕（*ﾟ∀ﾟ）=3ﾊｧﾊｧ ）とか
かなりオブジェクト指向だと思われるんですけどね。
あー
エロゲみたいな奴じゃなくて
アクションゲームとか
シューティング（弾幕（*ﾟ∀ﾟ）=3ﾊｧﾊｧ ）とか
467 ：デフォルトの名無しさん：03/09/21 16:49
OOは、どんな言語でもなんとなくできるだろ。
指向なんだから
http://dictionary.goo.ne.jp/search.php?MT=%BB%D8%B8%FE&kind=&mode=0&jn.x=38&jn.y=9
指向なんだから
http://dictionary.goo.ne.jp/search.php?MT=%BB%D8%B8%FE&kind=&mode=0&jn.x=38&jn.y=9
468 ：デフォルトの名無しさん：03/09/21 16:53
exなんとかC++でも言ってたけど
オブジェクト指向を10人に尋ねると
15個ぐらい答えが返ってくると。
C++は、OO言語じゃない。
マルチパラダイム言語だと。
オブジェクト指向を10人に尋ねると
15個ぐらい答えが返ってくると。
C++は、OO言語じゃない。
マルチパラダイム言語だと。
469 ：デフォルトの名無しさん：03/09/21 16:56
ザクⅠ
↓
ザクⅡ→シャア専用ザク
↓
ザクⅢ
↓
ザクⅡ→シャア専用ザク
↓
ザクⅢ
470 ：デフォルトの名無しさん：03/09/21 17:05
>>466 信長とか、恋愛シミュレーションのパラメータ管理とか、まさにそうだよ。シミュレーションだから。
471 ：デフォルトの名無しさん：03/09/21 17:05
MS
＋－+－－＋－－－－－－－＋
↓ ↓ ↓
AE製MS ジオニック製MS ツイマッド製MS
↓ ↓ ↓
ガンダム ザク ドム
↓
ザクⅡ
疲れた
＋－+－－＋－－－－－－－＋
↓ ↓ ↓
AE製MS ジオニック製MS ツイマッド製MS
↓ ↓ ↓
ガンダム ザク ドム
↓
ザクⅡ
疲れた
472 ：デフォルトの名無しさん：03/09/21 17:07
473 ：デフォルトの名無しさん：03/09/21 17:09
474 ：デフォルトの名無しさん：03/09/21 17:23
>>472 お前、女口説いたことあるか？ デートに誘って、振る舞いが同じだったことあるか？
475 ：デフォルトの名無しさん：03/09/21 17:28
>>474
パラメータ管理と出たからな。
マネージャクラスのことかと思ったよ。
キャラクタのことさしてるとは、思わなかったよ。
ごめんな。
おじさん、シミュレーションゲーム退屈だから、あんまやってないねん。
パラメータ管理と出たからな。
マネージャクラスのことかと思ったよ。
キャラクタのことさしてるとは、思わなかったよ。
ごめんな。
おじさん、シミュレーションゲーム退屈だから、あんまやってないねん。
476 ：デフォルトの名無しさん：03/09/21 17:30
477 ：デフォルトの名無しさん：03/09/21 17:32
複数のオブジェクトが絡むと
難しいな。
難しいな。
478 ：デフォルトの名無しさん：03/09/21 17:42
479 ：デフォルトの名無しさん：03/09/21 18:00
いいかげんnon virtualなメソッドは廃止して欲しいよ。
デフォルトnon virtualなんて論外だ。
override可能・不可能を指定できればそれでよし。
デフォルトnon virtualなんて論外だ。
override可能・不可能を指定できればそれでよし。
480 ：デフォルトの名無しさん：03/09/21 19:20
90年代初期のOOは、
全部virtual指向でした。
結果：
破綻するから駄目だー
ってことになったから
駄目って聞いた。
全部virtual指向でした。
結果：
破綻するから駄目だー
ってことになったから
駄目って聞いた。
481 ：デフォルトの名無しさん：03/09/21 19:34
なんですって？
482 ：デフォルトの名無しさん：03/09/21 23:57
483 ：デフォルトの名無しさん：03/09/22 01:16
484 ：デフォルトの名無しさん：03/09/22 04:44
大体、バーちゃるじゃなかったらポリモフができないじゃん。
485 ：デフォルトの名無しさん：03/09/22 04:59
javaのインターフェイスっての、便利だよ
486 ：デフォルトの名無しさん：03/09/22 07:13
>>484
Javaがでふぉでバーチャルなのが気に入らないんだ炉。
finalがでふぉで、オーバーライドさせたいメソッドだけ、
finalをはずす、あるいはvirtual指定させるの邦画、
安全なきもするが、今となってはどうでも良いな。
Javaがでふぉでバーチャルなのが気に入らないんだ炉。
finalがでふぉで、オーバーライドさせたいメソッドだけ、
finalをはずす、あるいはvirtual指定させるの邦画、
安全なきもするが、今となってはどうでも良いな。
487 ：デフォルトの名無しさん：03/09/22 07:20
>>483=486
内容には期待してないが、せめて日本語しゃべってくれ
内容には期待してないが、せめて日本語しゃべってくれ
488 ：デフォルトの名無しさん：03/09/22 07:42
どっちでもいいじゃねえか。馬鹿か。
489 ：デフォルトの名無しさん：03/09/22 13:21
>>461
いや。それは分かっているけど、最初に知っておかなければならない
ことではない、というスタンスで進めたいのだと。多態性を考えなければ、
そしてメソッドを必ず用意するなら、メッセージ送信は単なる関数
呼び出しと変わらない、と考えて差し支えない。したがって、メソッド
を関数、メッセージを単なる関数呼び出しと言って何が悪い、と。
それに対して、多態性は最初に教えるべきことだと信じている人たちは
暴言だと反発しているだけ。論じるべきは多態性を最初に教えるべきか
否かで、メッセージ云々では平行線たどるのは当然かな。さらに
関係ない(?)「kit」の前橋君を擁護する発言がことを複雑にしている。
いや。それは分かっているけど、最初に知っておかなければならない
ことではない、というスタンスで進めたいのだと。多態性を考えなければ、
そしてメソッドを必ず用意するなら、メッセージ送信は単なる関数
呼び出しと変わらない、と考えて差し支えない。したがって、メソッド
を関数、メッセージを単なる関数呼び出しと言って何が悪い、と。
それに対して、多態性は最初に教えるべきことだと信じている人たちは
暴言だと反発しているだけ。論じるべきは多態性を最初に教えるべきか
否かで、メッセージ云々では平行線たどるのは当然かな。さらに
関係ない(?)「kit」の前橋君を擁護する発言がことを複雑にしている。
490 ：デフォルトの名無しさん：03/09/22 13:43
多態性こそがOOプログラミングの最も重要な概念だと思うがどうよ？
「関数呼び出し」を抽象化し、「メッセージ」と「メソッド」に分けたことこそが、
OOPの本質じゃないの？？
「関数呼び出し」を抽象化し、「メッセージ」と「メソッド」に分けたことこそが、
OOPの本質じゃないの？？
491 ：デフォルトの名無しさん：03/09/22 13:56
ついでに言うと
「メソッドを関数、メッセージを単なる関数呼び出し」
というのは当たらないと思う。
「メソッド」とはその名の通り、それぞれのオブジェクト（クラス）の持っている
固有の手続きのこと。
「メッセージ」とはその名の通り、それぞれのオブジェクトが反応すべきシグナルの
ことだと思う。
これらの概念が、手続き指向におけるただの関数呼び出しとして実装されていたとしても、
それは単にその言語の実装がそうなっているだけ。
「メソッドを関数、メッセージを単なる関数呼び出し」
というのは当たらないと思う。
「メソッド」とはその名の通り、それぞれのオブジェクト（クラス）の持っている
固有の手続きのこと。
「メッセージ」とはその名の通り、それぞれのオブジェクトが反応すべきシグナルの
ことだと思う。
これらの概念が、手続き指向におけるただの関数呼び出しとして実装されていたとしても、
それは単にその言語の実装がそうなっているだけ。
492 ：デフォルトの名無しさん：03/09/22 13:57
すいません、どうも分からないのですが、
>>163-164はWindowsプログラムで言う、
ウィンドウプロシージャみたいものなのでしょうか
つまりC++以外だと、極端な話、全てのメッセージを
一つのメソッドで振り分ける様な感じなのでしょうか？違うかな…。
>>163-164はWindowsプログラムで言う、
ウィンドウプロシージャみたいものなのでしょうか
つまりC++以外だと、極端な話、全てのメッセージを
一つのメソッドで振り分ける様な感じなのでしょうか？違うかな…。
493 ：デフォルトの名無しさん：03/09/22 13:58
>>489
>最初に知っておかなければならないことではない、
OOのお勉強でクラス、カプセル化を覚えて多態を知らない期間ってほんの一瞬だと思うんだけどな。
彼はなぜゆえに多態、継承に対してあんなに構える必要があるんだろう？
OOに挫折した人に何でもかんでも無理やりCの概念で教えるのが正しいとは思えないよ。
正直あんな駄文書くんならCの構造化プログラミングをきっちり解説したサイト作った方が100倍有益だよ。
むしろそっちの方がCからOOP(L)への移行しやすいと思うよ。
>最初に知っておかなければならないことではない、
OOのお勉強でクラス、カプセル化を覚えて多態を知らない期間ってほんの一瞬だと思うんだけどな。
彼はなぜゆえに多態、継承に対してあんなに構える必要があるんだろう？
OOに挫折した人に何でもかんでも無理やりCの概念で教えるのが正しいとは思えないよ。
正直あんな駄文書くんならCの構造化プログラミングをきっちり解説したサイト作った方が100倍有益だよ。
むしろそっちの方がCからOOP(L)への移行しやすいと思うよ。
494 ：デフォルトの名無しさん：03/09/22 14:05
C++のfoo.bar()という形式でも、概念的にはbarは立派なメッセージ
だと思うが。
ここでの問題は、メッセージを実行時に動的に扱うこと（セレクタとか）と、
OOPの基本概念としてのメッセージが混同されていることと、
C++の形式が関数呼び出しにしか見えないために、「メッセージ」の概念に
慣れることのできない人との噛み合ない議論のように思う。
だと思うが。
ここでの問題は、メッセージを実行時に動的に扱うこと（セレクタとか）と、
OOPの基本概念としてのメッセージが混同されていることと、
C++の形式が関数呼び出しにしか見えないために、「メッセージ」の概念に
慣れることのできない人との噛み合ない議論のように思う。
495 ：デフォルトの名無しさん：03/09/22 14:18
BASICやFORTRANにどっぷり浸かったら C に移行するのは茨の道
C にどっぷり浸かったら C++ に移行するのは茨の道
じゃあ浸からない程度にやろうか？
なんて考えると何も身につかない。
C++でもJavaでもC#でもいいけどさ、自分のやりたい言語からはじめろよ。
ALGOLの系譜で今から覚える価値あるのはVM系のJavaとC#(と D 言語？)、
静的プログラミングのC++、
きれいなOOのObjective Cの３流派だけだろ。
組み込み系でもなければ C とかもうすっこんでろって感じ？
C にどっぷり浸かったら C++ に移行するのは茨の道
じゃあ浸からない程度にやろうか？
なんて考えると何も身につかない。
C++でもJavaでもC#でもいいけどさ、自分のやりたい言語からはじめろよ。
ALGOLの系譜で今から覚える価値あるのはVM系のJavaとC#(と D 言語？)、
静的プログラミングのC++、
きれいなOOのObjective Cの３流派だけだろ。
組み込み系でもなければ C とかもうすっこんでろって感じ？
496 ：デフォルトの名無しさん：03/09/22 15:01
>>495
「きれいなOOのObjective C」の「きれいなOO」部分は
「ALGOLの系譜」ではないとおもわれ。ｗ
ALGOL系にこだわらずに悪いこといわんからLISPとSMALLTALKは
最低やっておけYO。SMALLTALKなんか今じゃロハで処理系が
手に入るんだから…。
「きれいなOOのObjective C」の「きれいなOO」部分は
「ALGOLの系譜」ではないとおもわれ。ｗ
ALGOL系にこだわらずに悪いこといわんからLISPとSMALLTALKは
最低やっておけYO。SMALLTALKなんか今じゃロハで処理系が
手に入るんだから…。
497 ：デフォルトの名無しさん：03/09/22 15:30
>>496
漏れもLisp系とSmalltalk位やっとけに賛成。
てか考え方が全然違うからなんじゃこれ？！って最初はびびるのだが、なんとなく分かってくると
C++とかの書き方すら変わってくるんだよな。
ちょいとした時間を見つけられればどちらも処理系どころかチュートリアルもダータなのがあるから
～厨と言われない柔軟な考えを身に付ける素地はできるぞ。
漏れもLisp系とSmalltalk位やっとけに賛成。
てか考え方が全然違うからなんじゃこれ？！って最初はびびるのだが、なんとなく分かってくると
C++とかの書き方すら変わってくるんだよな。
ちょいとした時間を見つけられればどちらも処理系どころかチュートリアルもダータなのがあるから
～厨と言われない柔軟な考えを身に付ける素地はできるぞ。
498 ：デフォルトの名無しさん：03/09/22 15:35
>>494
> メッセージを実行時に動的に扱うこと（セレクタとか）と、
> OOPの基本概念としてのメッセージが混同されていることと、
「OOPの基本概念」のメッセージを言語仕様に体現化したのが「セレクタ」や
「メッセージ」だ。
Algol系文法の多くのOOPLはそれをちょっと変わった関数呼び出しで
仕組みだけ流用できることを思い付いただけ。混同しとんのはお前じゃヴォケ。
> C++の形式が関数呼び出しにしか見えないために
だからC++には「メッセージ」なんて概念は最初からないんだってば。
それはSmalltalkの広めた別の世界観だから、Objective-CとSelfと
Smalltalkくらいの限られた言語にしか適用できないんだって。それを知ってて
敢えて「メッセージ」という言葉を使うなら、分かりやすい置き換えは使う側の
当然の責務。でなきゃ、実質的にも表面的にも関数呼び出しでいいんだよ。
ttp://www.research.att.com/~bs/bs_faq.html#learn-Smalltalk
ttp://www.research.att.com/~bs/bs_faq.html#from-Smalltalk
> メッセージを実行時に動的に扱うこと（セレクタとか）と、
> OOPの基本概念としてのメッセージが混同されていることと、
「OOPの基本概念」のメッセージを言語仕様に体現化したのが「セレクタ」や
「メッセージ」だ。
Algol系文法の多くのOOPLはそれをちょっと変わった関数呼び出しで
仕組みだけ流用できることを思い付いただけ。混同しとんのはお前じゃヴォケ。
> C++の形式が関数呼び出しにしか見えないために
だからC++には「メッセージ」なんて概念は最初からないんだってば。
それはSmalltalkの広めた別の世界観だから、Objective-CとSelfと
Smalltalkくらいの限られた言語にしか適用できないんだって。それを知ってて
敢えて「メッセージ」という言葉を使うなら、分かりやすい置き換えは使う側の
当然の責務。でなきゃ、実質的にも表面的にも関数呼び出しでいいんだよ。
ttp://www.research.att.com/~bs/bs_faq.html#learn-Smalltalk
ttp://www.research.att.com/~bs/bs_faq.html#from-Smalltalk
499 ：デフォルトの名無しさん：03/09/22 15:44
>>497
>C++とかの書き方すら変わってくるんだよな。
例えばどんな感じで？Smalltalkは知らないけどLispにはなんも影響受けなかったよ。
正直実用的なコード書いたことないからかもしれないけど。
自分的にはC#覚えてたらDelphiのクラスのスタイルがなんとなく変わってきてしまった・・・
>C++とかの書き方すら変わってくるんだよな。
例えばどんな感じで？Smalltalkは知らないけどLispにはなんも影響受けなかったよ。
正直実用的なコード書いたことないからかもしれないけど。
自分的にはC#覚えてたらDelphiのクラスのスタイルがなんとなく変わってきてしまった・・・
500 ：デフォルトの名無しさん：03/09/22 15:46
>>498
>C++ got its Object-Oriented concepts from Smalltalk?
>No. C++ got the key notions of classes, derived classes, virtual functions
>(in other words, the notions of encapsulation,
>inheritance and polymorphism) from Simula just like Smalltalk did.
>In terms of family relationships, C++ and Smalltalk are siblings
この文章のどこにC++に「メッセージ」概念がない、と書いてある？
OOコンセプトを(Smalltalkと同様に)Simulaから受け継いだ「兄弟」だ、
と逝っているだけだよね？
君の逝っている「ちょっと変わった関数呼び出し 」はVirtual Function Tableによる
「メッセージ」を「メソッド」に変換する技法の事でしかなく、OOプログラミングにおける
「メッセージ」と「メソッド」の概念が存在していることに変わりはない。
>C++ got its Object-Oriented concepts from Smalltalk?
>No. C++ got the key notions of classes, derived classes, virtual functions
>(in other words, the notions of encapsulation,
>inheritance and polymorphism) from Simula just like Smalltalk did.
>In terms of family relationships, C++ and Smalltalk are siblings
この文章のどこにC++に「メッセージ」概念がない、と書いてある？
OOコンセプトを(Smalltalkと同様に)Simulaから受け継いだ「兄弟」だ、
と逝っているだけだよね？
君の逝っている「ちょっと変わった関数呼び出し 」はVirtual Function Tableによる
「メッセージ」を「メソッド」に変換する技法の事でしかなく、OOプログラミングにおける
「メッセージ」と「メソッド」の概念が存在していることに変わりはない。
501 ：デフォルトの名無しさん：03/09/22 15:48
結局、「メッセージ」と「メソッド」を意識できない人間が、
「実質的にも表面的にも関数呼び出しでいいんだよ。 」と、
逝っているだけ、ということでファイナルアンサー？
「実質的にも表面的にも関数呼び出しでいいんだよ。 」と、
逝っているだけ、ということでファイナルアンサー？
502 ：デフォルトの名無しさん：03/09/22 16:03
私の主張をもう一度書くと、多態とは
「同一のメッセージに対してそれぞれのオブジェクトが異なるメソッドを選択すること」
だから、C++のような呼び出しスキーム
にあっても、「メッセージ」概念は存在しているんだよ。
C++とSmalltalkの違いは、「メッセージ」から「メソッド」への変換（メソッドディスパッチ）のポリシーが異なっていること。
Smalltalkは、いわゆるMethod Lookupで、実行時に動的に「メッセージ」と「メソッド」の結合を行う。
一方、C++のnon-virtualな手続きは、コンパイル時にオブジェクトとメソッドへの結合を済ませている。
（だから最終的には単なる関数呼び出しになる。）
C++のvirtualな手続きやJavaはコンパイル時に「メッセージ」をVirtual Function Tableに対するオフセット値にまで解決する。
（SmalltalkのMethod Lookupよりも高速だが柔軟性に乏しい。）
つまり、言語によって「メッセージ」から「メソッド」への変換方針が異なるが、そこで実現しているのは、いずれも、
「同一のメッセージに対してそれぞれのオブジェクトが異なるメソッドを選択すること」
なんだよ。
「同一のメッセージに対してそれぞれのオブジェクトが異なるメソッドを選択すること」
だから、C++のような呼び出しスキーム
にあっても、「メッセージ」概念は存在しているんだよ。
C++とSmalltalkの違いは、「メッセージ」から「メソッド」への変換（メソッドディスパッチ）のポリシーが異なっていること。
Smalltalkは、いわゆるMethod Lookupで、実行時に動的に「メッセージ」と「メソッド」の結合を行う。
一方、C++のnon-virtualな手続きは、コンパイル時にオブジェクトとメソッドへの結合を済ませている。
（だから最終的には単なる関数呼び出しになる。）
C++のvirtualな手続きやJavaはコンパイル時に「メッセージ」をVirtual Function Tableに対するオフセット値にまで解決する。
（SmalltalkのMethod Lookupよりも高速だが柔軟性に乏しい。）
つまり、言語によって「メッセージ」から「メソッド」への変換方針が異なるが、そこで実現しているのは、いずれも、
「同一のメッセージに対してそれぞれのオブジェクトが異なるメソッドを選択すること」
なんだよ。
503 ：デフォルトの名無しさん：03/09/22 16:04
>>500
だからSimulaにもC++にもメッセージなんて概念はないんだって。
もっと言ったら、SimulaにはOOって考え方すらない。
あるのはオブジェクト（ユーザー定義可能な型）とそれを使った
プログラミングだけだ。
SimulaとC++の初期の文献でmessageって言葉を使っているところを
提示できたら謝ってやるよ。
C++FAQの引用はSmalltalkの世界観を（参考にするぶんにはいいが）
鵜呑みにはするなって話だ。ヴォケ。
だからSimulaにもC++にもメッセージなんて概念はないんだって。
もっと言ったら、SimulaにはOOって考え方すらない。
あるのはオブジェクト（ユーザー定義可能な型）とそれを使った
プログラミングだけだ。
SimulaとC++の初期の文献でmessageって言葉を使っているところを
提示できたら謝ってやるよ。
C++FAQの引用はSmalltalkの世界観を（参考にするぶんにはいいが）
鵜呑みにはするなって話だ。ヴォケ。
504 ：デフォルトの名無しさん：03/09/22 16:12
>>503
Smalltalkの世界観とC++の世界観が違うのは同意だが、
その二つの言語にまたがるOOP概念を統一的に説明するなら、
「メッセージ」と「メソッド」の区別（つまり多態性の理解）は必須だろ？
Smalltalkの世界観とC++の世界観が違うのは同意だが、
その二つの言語にまたがるOOP概念を統一的に説明するなら、
「メッセージ」と「メソッド」の区別（つまり多態性の理解）は必須だろ？
505 ：デフォルトの名無しさん：03/09/22 16:17
>>504
> 「メッセージ」と「メソッド」の区別（つまり多態性の理解）は必須だろ？
わからんやっちゃなぁ…。多態性は多態性で説明しろって。そこに
「メッセージ」なんてワケワカな世界観を持ち込むなって話だYO。
漏れに言わせれば「メソッド」＝「振る舞い」なんて単語もダウトだ。
> 「メッセージ」と「メソッド」の区別（つまり多態性の理解）は必須だろ？
わからんやっちゃなぁ…。多態性は多態性で説明しろって。そこに
「メッセージ」なんてワケワカな世界観を持ち込むなって話だYO。
漏れに言わせれば「メソッド」＝「振る舞い」なんて単語もダウトだ。
506 ：デフォルトの名無しさん：03/09/22 16:18
本人でつか？
507 ：デフォルトの名無しさん：03/09/22 16:21
508 ：デフォルトの名無しさん：03/09/22 16:50
>>507
だぁかぁらぁ…、
「(見た目)同一の関数呼び出しに対して、ユーザーが定義した型にあわせた関数実装がコールされる」
って機構を説明するのに、どうして「メッセージ」だの「振る舞い」だのって
メタファがいちいち必要かって話。脳みそ、働いてる？
だぁかぁらぁ…、
「(見た目)同一の関数呼び出しに対して、ユーザーが定義した型にあわせた関数実装がコールされる」
って機構を説明するのに、どうして「メッセージ」だの「振る舞い」だのって
メタファがいちいち必要かって話。脳みそ、働いてる？
509 ：デフォルトの名無しさん：03/09/22 16:59
510 ：デフォルトの名無しさん：03/09/22 17:01
>>508
>(見た目)同一の関数
つまりメッセージ。
>ユーザーが定義した型にあわせた関数実装
つまりメソッド。
メタファが必要なのはそれがわりとOOPに固有の概念だから。
他人に説明する時に毎回「ユーザーが定義した型にあわせた関数実装」というのがメンドイので、
「メソッド」と呼ぶように、「(見た目)同一の関数（に見えるもの）」を
「メッセージ」と呼ぶだけのことでしょう。
なにが難しいのさ？
>(見た目)同一の関数
つまりメッセージ。
>ユーザーが定義した型にあわせた関数実装
つまりメソッド。
メタファが必要なのはそれがわりとOOPに固有の概念だから。
他人に説明する時に毎回「ユーザーが定義した型にあわせた関数実装」というのがメンドイので、
「メソッド」と呼ぶように、「(見た目)同一の関数（に見えるもの）」を
「メッセージ」と呼ぶだけのことでしょう。
なにが難しいのさ？
511 ：デフォルトの名無しさん：03/09/22 17:06
前橋君が「メッセージ」じゃなくて「関数呼び出し」という
「自分が今まで理解してきた概念を流用して」OOPを理解したがるのは、
『「ポインタ」ってなんだよ、ただのアドレスだろ？』といってるのと
同じこと。
「自分が今まで理解してきた概念を流用して」OOPを理解したがるのは、
『「ポインタ」ってなんだよ、ただのアドレスだろ？』といってるのと
同じこと。
512 ：デフォルトの名無しさん：03/09/22 17:09
おもしろいから、つづけれ
513 ：デフォルトの名無しさん：03/09/22 17:12
>>511
まさにその件でmatzに著作を迷教科書呼ばわりされて必死に弁解してたよ(藁
まさにその件でmatzに著作を迷教科書呼ばわりされて必死に弁解してたよ(藁
514 ：デフォルトの名無しさん：03/09/22 17:20
>>510
なんか弱っちいな。ｗ じゃ、百万歩ゆずって、その
「メッセージ」だの「振る舞い」だのが「わりとOOPに固有の概念」
として認識されるようになったのはいつからさ。漏れに言わせれば、
それが1や前橋君の対象読者やC++（におけるOO）の不幸の始まりだ罠。
なんか弱っちいな。ｗ じゃ、百万歩ゆずって、その
「メッセージ」だの「振る舞い」だのが「わりとOOPに固有の概念」
として認識されるようになったのはいつからさ。漏れに言わせれば、
それが1や前橋君の対象読者やC++（におけるOO）の不幸の始まりだ罠。
515 ：デフォルトの名無しさん：03/09/22 17:26
>>513
そのやりとりの場所おしえれ。黄泉鯛。
そのやりとりの場所おしえれ。黄泉鯛。
516 ：デフォルトの名無しさん：03/09/22 17:29
>>514
あのね、君の>>508の
「(見た目)同一の関数呼び出しに対して、ユーザーが定義した型にあわせた関数実装がコールされる」
は、私の
「同一のメッセージに対してそれぞれのオブジェクトが異なるメソッドを選択すること」
のメタファを使わない言い換えにすぎないってことを、>>510で指摘しているわけよ。
他人の認識なんか全く関係ないわけ。話題をそらすなよ。
「自分が今まで理解してきた概念を流用して」しか概念が理解できない、と言い張ることが、
他人の目にはとても愚かに見えていることが判る？？
あのね、君の>>508の
「(見た目)同一の関数呼び出しに対して、ユーザーが定義した型にあわせた関数実装がコールされる」
は、私の
「同一のメッセージに対してそれぞれのオブジェクトが異なるメソッドを選択すること」
のメタファを使わない言い換えにすぎないってことを、>>510で指摘しているわけよ。
他人の認識なんか全く関係ないわけ。話題をそらすなよ。
「自分が今まで理解してきた概念を流用して」しか概念が理解できない、と言い張ることが、
他人の目にはとても愚かに見えていることが判る？？
517 ：デフォルトの名無しさん：03/09/22 17:37
518 ：デフォルトの名無しさん：03/09/22 17:40
>>517
どこが盲目的なメタファの乱用なのか指摘してみろ。
C的な「関数呼び出し」を「メッセージ」と「メソッド」概念に分割し結果、
C++とJavaとSmalltalkの多態を統一的に説明してやったじゃないか。
どこが盲目的なメタファの乱用なのか指摘してみろ。
C的な「関数呼び出し」を「メッセージ」と「メソッド」概念に分割し結果、
C++とJavaとSmalltalkの多態を統一的に説明してやったじゃないか。
519 ：デフォルトの名無しさん：03/09/22 17:53
結局前橋君は「メッセージ」や「メソッド」という既に共通理解の得られた概念を、
「関数呼び出し」のオレ様定義（自分勝手な概念拡張）で言い換えて理解しているに
過ぎない。そしてオレ様定義ではない「関数呼び出し」で言い換えが可能なのは、
C++のnon-virtualな手続きなどの特殊な一部に過ぎない。
だからvirtual手続きやJava、Smalltalkのメソッド呼び出しの説明としては不十分で
当然。理解できなくて「別世界」と思っていて当然。
でもこれは結局OOPを理解していないってことだよね。
「関数呼び出し」のオレ様定義（自分勝手な概念拡張）で言い換えて理解しているに
過ぎない。そしてオレ様定義ではない「関数呼び出し」で言い換えが可能なのは、
C++のnon-virtualな手続きなどの特殊な一部に過ぎない。
だからvirtual手続きやJava、Smalltalkのメソッド呼び出しの説明としては不十分で
当然。理解できなくて「別世界」と思っていて当然。
でもこれは結局OOPを理解していないってことだよね。
520 ：デフォルトの名無しさん：03/09/22 18:01
>>518
・出典を提示できない→意図したとおりの適正なメタファ適用か怪しい。
・Stroustrupは(漏れの知る限り）メッセージなんてメタファは使っていない。
・メッセージなんか輪下欄というC++ユーザーは確かに存在する。
・メッセージなんか白んでも、C++でOOPはできる。
誤解しているみたいだから言っておくと、
Javaでメソッドを、SmalltalkやObjective-Cでメッセージを
使って説明するのはいっこうに釜ワンよ。だって、鼻からそういうものがあって
それをそう呼ぶと定義しているんだもん。否定しようがないじゃん。ｗ
・出典を提示できない→意図したとおりの適正なメタファ適用か怪しい。
・Stroustrupは(漏れの知る限り）メッセージなんてメタファは使っていない。
・メッセージなんか輪下欄というC++ユーザーは確かに存在する。
・メッセージなんか白んでも、C++でOOPはできる。
誤解しているみたいだから言っておくと、
Javaでメソッドを、SmalltalkやObjective-Cでメッセージを
使って説明するのはいっこうに釜ワンよ。だって、鼻からそういうものがあって
それをそう呼ぶと定義しているんだもん。否定しようがないじゃん。ｗ
521 ：デフォルトの名無しさん：03/09/22 18:08
>>520
C++の説明ではなくてオブジェクト指向の概念の説明として
「関数呼び出し」説は不適切といっているんだよ。
Stroustrupがどう説明するかは関係ない。
C++はCのプログラマが違和感ないようにシンタックスが構築されているだけだよ。
そして多態の説明に「メッセージ」概念を持ち込むのは上で何度も主張しているように
自然なんだよ。
C++の説明ではなくてオブジェクト指向の概念の説明として
「関数呼び出し」説は不適切といっているんだよ。
Stroustrupがどう説明するかは関係ない。
C++はCのプログラマが違和感ないようにシンタックスが構築されているだけだよ。
そして多態の説明に「メッセージ」概念を持ち込むのは上で何度も主張しているように
自然なんだよ。
522 ：デフォルトの名無しさん：03/09/22 18:18
>>520
> ・メッセージなんか輪下欄というC++ユーザーは確かに存在する。
> ・メッセージなんか白んでも、C++でOOPはできる。
念のため補足。ここでの「メッセージ」＝多態性じゃないぞ
あくまで「メッセージってメタファ」だぞ。
って遅かったか。ｗ
>>521
じゃあ「関数呼び出し」のほうがすっきりするStroustrupの頭にある
C++のOOPはOOじゃないのか？ ｗ
シンタックスの話をすれば、C++のシンタックスを取り入れたJavaにも
メッセージのメタファはしっくりこんとと思うぞ。
用語として定められちゃったメソッドならともかく。
> ・メッセージなんか輪下欄というC++ユーザーは確かに存在する。
> ・メッセージなんか白んでも、C++でOOPはできる。
念のため補足。ここでの「メッセージ」＝多態性じゃないぞ
あくまで「メッセージってメタファ」だぞ。
って遅かったか。ｗ
>>521
じゃあ「関数呼び出し」のほうがすっきりするStroustrupの頭にある
C++のOOPはOOじゃないのか？ ｗ
シンタックスの話をすれば、C++のシンタックスを取り入れたJavaにも
メッセージのメタファはしっくりこんとと思うぞ。
用語として定められちゃったメソッドならともかく。
523 ：デフォルトの名無しさん：03/09/22 18:29
>>522
見た目「関数呼び出し」のほうがすっきりする」（ように見える）ように作ってあるんだよ。
C++は。
もうなんども書いてバカらしくなるのだけれども、私の主張は、そんなC++であっても、
「メッセージ」と「メソッド」という概念は有効なんだ、ってこと。
しっくりしないどころか、その方がOOPの説明としては適切だと言っているの。
むしろ、C++の落とし穴はまさに、「ただの関数呼び出し」にしか見えない、って
ところだと思う。
見た目「関数呼び出し」のほうがすっきりする」（ように見える）ように作ってあるんだよ。
C++は。
もうなんども書いてバカらしくなるのだけれども、私の主張は、そんなC++であっても、
「メッセージ」と「メソッド」という概念は有効なんだ、ってこと。
しっくりしないどころか、その方がOOPの説明としては適切だと言っているの。
むしろ、C++の落とし穴はまさに、「ただの関数呼び出し」にしか見えない、って
ところだと思う。
524 ：デフォルトの名無しさん：03/09/22 18:37
をぃをぃ。メタファ大事さあまりに、ついに歴史までつくっちゃったよ。ｗ
> 見た目「関数呼び出し」のほうがすっきりする」（ように見える）ように作ってある
メッセージメタファ厨の盲信ぶり、ここに極まれり、だな。やれやれ…。
> 見た目「関数呼び出し」のほうがすっきりする」（ように見える）ように作ってある
メッセージメタファ厨の盲信ぶり、ここに極まれり、だな。やれやれ…。
525 ：デフォルトの名無しさん：03/09/22 18:38
publicな変数は無視ですか？
526 ：デフォルトの名無しさん：03/09/22 18:57
スレの流れとあんま関係ないけどさ、publicな変数書いた奴は公然猥褻罪適用しようぜ。
527 ：デフォルトの名無しさん：03/09/22 19:16
>>515
ポインタとアドレスじゃなく参照とポインタだった。
http://member.nifty.ne.jp/maebashi/seiha/hosoku001.html#reference_vs_pointer
リンク先のリンク先では
Javaではポインタと参照を文法的に厳密に区別する必要がないし
Javaにポインタがないと馬鹿にされるのが悔しいからあえて混同しましょう。といううんこ議論が展開されてる。
この人JavaとCの知識のみで常識やら用語やらを語ってるからおかしくなるんだよな。
ポインタとアドレスじゃなく参照とポインタだった。
http://member.nifty.ne.jp/maebashi/seiha/hosoku001.html#reference_vs_pointer
リンク先のリンク先では
Javaではポインタと参照を文法的に厳密に区別する必要がないし
Javaにポインタがないと馬鹿にされるのが悔しいからあえて混同しましょう。といううんこ議論が展開されてる。
この人JavaとCの知識のみで常識やら用語やらを語ってるからおかしくなるんだよな。
528 ：デフォルトの名無しさん：03/09/22 19:23
オレは前橋ファンだが、
確かにポインタ云々の議論は無益な議論だよ。
「自衛隊は軍隊ではない！」
っていうような無益な用語論争だよ。
確かにポインタ云々の議論は無益な議論だよ。
「自衛隊は軍隊ではない！」
っていうような無益な用語論争だよ。
529 ：デフォルトの名無しさん：03/09/22 19:31
まとめるとこんな感じ？
「汝ら、我、平和をもたらしに来たと思うなかれ。
むしろ災いなり。今ここに一家五人あらば、
三人は二人に、二人は三人に別れて争わん。
父は息子に、息子は父に、母は娘に、娘は母に」
【ルカの福音書第１２章５１節～５３節】
「汝ら、我、平和をもたらしに来たと思うなかれ。
むしろ災いなり。今ここに一家五人あらば、
三人は二人に、二人は三人に別れて争わん。
父は息子に、息子は父に、母は娘に、娘は母に」
【ルカの福音書第１２章５１節～５３節】
530 ：デフォルトの名無しさん：03/09/22 19:44
>>527
だんけ。いや、さんくす。これからじっくりよんでたのしみます。
だんけ。いや、さんくす。これからじっくりよんでたのしみます。
532 ：デフォルトの名無しさん：03/09/22 20:35
533 ：デフォルトの名無しさん：03/09/22 20:37
＞こんな人が本を書いてるんですね。
びっくりするだろ？ おれもびっくりしたｗ
びっくりするだろ？ おれもびっくりしたｗ
534 ：デフォルトの名無しさん：03/09/22 20:56
>>528
「自衛隊は軍隊ではない！」は「自衛隊は事実上軍隊と同じ」で
「参照はポインタではない！」は「参照は事実上ポインタと同じ」でいいですか？
ポインタと参照の議論って各々が全然違うところに立って議論してるから
まとまるものもまとまらないと思うんだよね。
～言語のポインタという機能と参照という機能は別物である！とか
プログラミング全般においてポインタと参照は同じ目的である！とか
そういう違う次元の話がごちゃまぜで語られててもうぐちゃぐちゃ。
「自衛隊は軍隊ではない！」は「自衛隊は事実上軍隊と同じ」で
「参照はポインタではない！」は「参照は事実上ポインタと同じ」でいいですか？
ポインタと参照の議論って各々が全然違うところに立って議論してるから
まとまるものもまとまらないと思うんだよね。
～言語のポインタという機能と参照という機能は別物である！とか
プログラミング全般においてポインタと参照は同じ目的である！とか
そういう違う次元の話がごちゃまぜで語られててもうぐちゃぐちゃ。
535 ：デフォルトの名無しさん：03/09/22 21:02
>「参照は事実上ポインタと同じ」でいいですか？
実害はないが正直厨房臭いよ。
まぁ続きはJavaスレかJavaHouseでやってくれ。
実害はないが正直厨房臭いよ。
まぁ続きはJavaスレかJavaHouseでやってくれ。
536 ：デフォルトの名無しさん：03/09/22 21:39
何かまだ関数呼び出しをメッセージとか言ってるアフォがいるみたいなんだけ
どさぁ、そろそろその低能っぷりを晒すのもいい加減にして欲しい。マジで。
もう一回だけ言っとくと、C++に「メッセージ」なんて概念はないわけ。何で
ないのかっていうとStroustrupがメッセージなんて言葉使ってないから。それ
だけ。逆に言えばStroustrupが使ってたらメッセージという概念が発生するわ
け。ま、文献にあたることや出所を明示することは基本だから覚えといて。
どさぁ、そろそろその低能っぷりを晒すのもいい加減にして欲しい。マジで。
もう一回だけ言っとくと、C++に「メッセージ」なんて概念はないわけ。何で
ないのかっていうとStroustrupがメッセージなんて言葉使ってないから。それ
だけ。逆に言えばStroustrupが使ってたらメッセージという概念が発生するわ
け。ま、文献にあたることや出所を明示することは基本だから覚えといて。
537 ：デフォルトの名無しさん：03/09/22 21:43
何かまだ自衛隊を軍隊とか言ってるアフォがいるみたいなんだけ
どさぁ、そろそろその低能っぷりを晒すのもいい加減にして欲しい。マジで。
もう一回だけ言っとくと、日本に「軍隊」なんて概念はないわけ。何で
ないのかっていうと日本政府が軍隊なんて言葉使ってないから。それ
だけ。逆に言えば日本政府が使ってたら軍隊という概念が発生するわ
け。ま、文献にあたることや出所を明示することは基本だから覚えといて。
どさぁ、そろそろその低能っぷりを晒すのもいい加減にして欲しい。マジで。
もう一回だけ言っとくと、日本に「軍隊」なんて概念はないわけ。何で
ないのかっていうと日本政府が軍隊なんて言葉使ってないから。それ
だけ。逆に言えば日本政府が使ってたら軍隊という概念が発生するわ
け。ま、文献にあたることや出所を明示することは基本だから覚えといて。
538 ：デフォルトの名無しさん：03/09/22 21:44
>>537
ネタにマジレスというやつですか？
ネタにマジレスというやつですか？
539 ：デフォルトの名無しさん：03/09/22 21:58
まぁ続きは自衛隊スレか国会でやってくれ。
俺としたことが画竜点睛ってやつだな
まぁ続きは自衛隊板か国会でやってくれ。
まぁ続きは自衛隊板か国会でやってくれ。
541 ：デフォルトの名無しさん：03/09/22 22:07
C++は明らかにスレ違いだろ。身の程をわきまえろ。
542 ：デフォルトの名無しさん：03/09/22 22:08
Smalltalk厨ってほんとうざいね。
OOの中心はSmalltalkである、ってか？（ｗ
OOの中心はSmalltalkである、ってか？（ｗ
543 ：デフォルトの名無しさん：03/09/22 22:09
自衛隊の方がスレ違いだがな
544 ：デフォルトの名無しさん：03/09/22 22:22
C++は明らかにスレ違いだろ。OOだけの言語じゃないからな。
545 ：デフォルトの名無しさん：03/09/22 22:29
>>536
C++でも単なる関数呼び出しではないことを>>502で言っているつもりなんだけどね。
メソッドディスパッチの技法のような実装寄りの話をした上で、こういったOOPの
性質を統一的に説明する上で「メッセージ」概念は有用だといっているんだよ。
「関数呼び出し」に見えるから、「関数」なんだ、とかの低いレベルにしがみついているなら
勝手にどうぞ。
C++でも単なる関数呼び出しではないことを>>502で言っているつもりなんだけどね。
メソッドディスパッチの技法のような実装寄りの話をした上で、こういったOOPの
性質を統一的に説明する上で「メッセージ」概念は有用だといっているんだよ。
「関数呼び出し」に見えるから、「関数」なんだ、とかの低いレベルにしがみついているなら
勝手にどうぞ。
546 ：デフォルトの名無しさん：03/09/22 22:30
>>545
ネタにマジレスというやつですか？(再)
ネタにマジレスというやつですか？(再)
547 ：デフォルトの名無しさん：03/09/22 22:32
548 ：デフォルトの名無しさん：03/09/22 22:33
549 ：デフォルトの名無しさん：03/09/22 22:33
>>547
嘲笑の意味が分からないのだが。
嘲笑の意味が分からないのだが。
550 ：デフォルトの名無しさん：03/09/22 22:52
551 ：デフォルトの名無しさん：03/09/22 22:55
0点
552 ：デフォルトの名無しさん：03/09/22 22:56
初出は知らないが、「メッセージ」「メソッド」でググって
一番上にきたページのリンクを貼ってやるよ。ほらよ。
http://kaiunix.cs.shinshu-u.ac.jp/Lesson/SoftEng/2003/text/node72.html
一番上にきたページのリンクを貼ってやるよ。ほらよ。
http://kaiunix.cs.shinshu-u.ac.jp/Lesson/SoftEng/2003/text/node72.html
553 ：デフォルトの名無しさん：03/09/22 22:57
「メディアはメッセージである」
マーシャル・マクルーハン
マーシャル・マクルーハン
555 ：デフォルトの名無しさん：03/09/22 23:00
>>553
マッサージ屋は（・∀・）ｶｴﾚ!!
マッサージ屋は（・∀・）ｶｴﾚ!!
556 ：デフォルトの名無しさん：03/09/22 23:01
いや、「メタファー」はほかの人なのかな。
とにかく、「メッセージという概念」というものがよくわからないので、
話が紛糾してるのではないかなーと思ったわけで。
とにかく、「メッセージという概念」というものがよくわからないので、
話が紛糾してるのではないかなーと思ったわけで。
558 ：デフォルトの名無しさん：03/09/22 23:04
>>557
紛糾してると思うのは気のせいでしょう
紛糾してると思うのは気のせいでしょう
メタファーは俺ですがなにか？
上記ページの言っている内容は、俺の主張している内容と全く同じですが？
上記ページの言っている内容は、俺の主張している内容と全く同じですが？
560 ：デフォルトの名無しさん：03/09/22 23:06
>>559
青筋立てて主張するほどのことでもないと思います
青筋立てて主張するほどのことでもないと思います
561 ：550：03/09/22 23:06
562 ：デフォルトの名無しさん：03/09/22 23:07
OOP童貞諸君まずはrubyを覚えたまえ。
563 ：デフォルトの名無しさん：03/09/22 23:08
>>550
で、あなたはメッセージに対してどう思うわけ？
で、あなたはメッセージに対してどう思うわけ？
>>560
そのとおりだね。
>>561
Smalltalk由来の用語でOOPを説明してはいけないと？
しかし実際の用語がどうであれ、OOにおいてメッセージやメソッドに相当する概念が
現れてくるのは自明なのでは？
そのとおりだね。
>>561
Smalltalk由来の用語でOOPを説明してはいけないと？
しかし実際の用語がどうであれ、OOにおいてメッセージやメソッドに相当する概念が
現れてくるのは自明なのでは？
566 ：デフォルトの名無しさん：03/09/22 23:12
>>541
はぁ？1を嫁！
はぁ？1を嫁！
>>564
>Smalltalk由来の用語でOOPを説明してはいけないと？
いえ、そんなこと言ってません。
>しかし実際の用語がどうであれ、OOにおいてメッセージやメソッドに相当する概念が
>現れてくるのは自明なのでは？
私もそう思いますが、「メッセージ」というのがSmalltalkで言うそれなのか、
それともまったく違った概念（というかSmalltalkとは違う出自の概念）なのかが
気になっただけです。
>Smalltalk由来の用語でOOPを説明してはいけないと？
いえ、そんなこと言ってません。
>しかし実際の用語がどうであれ、OOにおいてメッセージやメソッドに相当する概念が
>現れてくるのは自明なのでは？
私もそう思いますが、「メッセージ」というのがSmalltalkで言うそれなのか、
それともまったく違った概念（というかSmalltalkとは違う出自の概念）なのかが
気になっただけです。
568 ：デフォルトの名無しさん：03/09/22 23:15
569 ：デフォルトの名無しさん：03/09/22 23:16
まったく休みの合間のつまらん日によくもまあこんなくだらん議論を。
双方、とりあえずねろ。
双方、とりあえずねろ。
570 ：デフォルトの名無しさん：03/09/22 23:18
571 ：デフォルトの名無しさん：03/09/22 23:21
前橋君って前橋和弥のことか？
>>567
言っていることがよく分からないが、私の言うメッセージは
http://kaiunix.cs.shinshu-u.ac.jp/Lesson/SoftEng/2003/text/node72.html
で、出てくるメッセージと同じで、Smalltalkにおいても同じだと思うけど。
ただし、Smalltalkではメッセージはセレクタと引数の組み合わせで表されるので、
「セレクタ」こそがメッセージだ、と考える人がいるかもしれない。
でも私はその立場には組しない。
わたしはSmalltalk中心厨じゃないので。
言っていることがよく分からないが、私の言うメッセージは
http://kaiunix.cs.shinshu-u.ac.jp/Lesson/SoftEng/2003/text/node72.html
で、出てくるメッセージと同じで、Smalltalkにおいても同じだと思うけど。
ただし、Smalltalkではメッセージはセレクタと引数の組み合わせで表されるので、
「セレクタ」こそがメッセージだ、と考える人がいるかもしれない。
でも私はその立場には組しない。
わたしはSmalltalk中心厨じゃないので。
573 ：デフォルトの名無しさん：03/09/22 23:26
C++ってオブジェクト指向言語じゃないって製作者自身が言ってなかたっけ?
574 ：デフォルトの名無しさん：03/09/22 23:28
>>330にアホが大量に釣られとるな。
575 ：デフォルトの名無しさん：03/09/22 23:30
>>574
見物は楽しいですか？
見物は楽しいですか？
576 ：デフォルトの名無しさん：03/09/22 23:33
ああ、やっぱり前橋和弥のことか。
こいつってねっからのC厨じゃん。
著書みたらおもしろいぞ。
ポインタの本はすっげー面白かったけど
オブジェクト指向についてはずぶの素人だと思うぞ
C++で開発なんかできないとかほざいてたし
こいつってねっからのC厨じゃん。
著書みたらおもしろいぞ。
ポインタの本はすっげー面白かったけど
オブジェクト指向についてはずぶの素人だと思うぞ
C++で開発なんかできないとかほざいてたし
戦場スレで粘着し続けた「逝って良しの1」はたぶん前橋和弥。
578 ：デフォルトの名無しさん：03/09/22 23:36
違いますって。
579 ：デフォルトの名無しさん：03/09/22 23:38
>>578
お前誰？
お前誰？
580 ：デフォルトの名無しさん：03/09/22 23:38
上の発言は私です。名前入れ忘れ。
582 ：デフォルトの名無しさん：03/09/23 00:37
なんだか、C++の実装とOODの考え方の間で議論しているように思えます。
583 ：デフォルトの名無しさん：03/09/23 00:47
584 ：デフォルトの名無しさん：03/09/23 00:53
前橋氏も結城氏も見てるんだよね。
両氏のファンのオレは嬉しいよ。マジで。
両氏のファンのオレは嬉しいよ。マジで。
585 ：デフォルトの名無しさん：03/09/23 01:02
馬鹿かおまえは。
前橋も結城も関係無いよ。
でも、結城結構指示されてんだね以外。
なんでや。
前橋も結城も関係無いよ。
でも、結城結構指示されてんだね以外。
なんでや。
586 ：デフォルトの名無しさん：03/09/23 01:08
>>573
oop*も*できる、とストラウストラップは言っているんだ。
oop*も*できる、とストラウストラップは言っているんだ。
587 ：デフォルトの名無しさん：03/09/23 01:30
>>521
> Stroustrupがどう説明するかは関係ない。
馬脚をあらわしとる。
そういうキミが信じている「情報隠蔽」「継承」「多様性」は
StroustrupがSimulaを参考にC++のOOを通じて体系づけたものだ。
その三要素を説明するのにメッセージなんてSmalltalk臭のメタファを
使うのは天につばするようなものだ！
> Stroustrupがどう説明するかは関係ない。
馬脚をあらわしとる。
そういうキミが信じている「情報隠蔽」「継承」「多様性」は
StroustrupがSimulaを参考にC++のOOを通じて体系づけたものだ。
その三要素を説明するのにメッセージなんてSmalltalk臭のメタファを
使うのは天につばするようなものだ！
588 ：デフォルトの名無しさん：03/09/23 01:38
589 ：デフォルトの名無しさん：03/09/23 01:40
590 ：デフォルトの名無しさん：03/09/23 01:57
>>589
宗教くさくなると氏の印象貶めるだけだからやめとけ。
宗教くさくなると氏の印象貶めるだけだからやめとけ。
591 ：デフォルトの名無しさん：03/09/23 02:06
今の今になって前橋氏のサイトを見てきた訳ですが、
あれはゴリゴリの手続き型プログラマがいかにOOLを咀嚼するかがテーマな訳で、
そして咀嚼するのはあくまでOOLな訳でOOPではないところが味噌な訳で、
あれを見ていると痛々しくなる訳で、しかし、同時にあれを読んで勇気づけられる
プログラマも世の中にはゴマンと居る訳で、噫と思ったりする訳です。
あれはゴリゴリの手続き型プログラマがいかにOOLを咀嚼するかがテーマな訳で、
そして咀嚼するのはあくまでOOLな訳でOOPではないところが味噌な訳で、
あれを見ていると痛々しくなる訳で、しかし、同時にあれを読んで勇気づけられる
プログラマも世の中にはゴマンと居る訳で、噫と思ったりする訳です。
592 ：デフォルトの名無しさん：03/09/23 02:08
593 ：デフォルトの名無しさん：03/09/23 02:16
ＯＯＬ ＝ オブジェクト指向言語
ＯＯＰ ＝ オブジェクト指向プログラミング
噫 ＝ ちくび
ＯＯＰ ＝ オブジェクト指向プログラミング
噫 ＝ ちくび
594 ：デフォルトの名無しさん：03/09/23 02:21
前橋君のマルチインスタンス云々の話を当然と思ってる人と理解できない人のかみ合わない会話の例
http://pc2.2ch.net/test/read.cgi/tech/1058787619/62-66
http://pc2.2ch.net/test/read.cgi/tech/1058787619/62-66
595 ：デフォルトの名無しさん：03/09/23 02:21
596 ：デフォルトの名無しさん：03/09/23 02:22
俺はここまで馬鹿じゃない、と勇気づけられる奴だろ。
補足しておきますと、Cでもstatic云々という所がマルチインスタンスを理解できてない人の素朴な疑問の部分です。
間にへんなのが挟まってたので打ち間違えました。最後まで読まないとわからないですね。
http://pc2.2ch.net/test/read.cgi/tech/1058787619/62-68
http://pc2.2ch.net/test/read.cgi/tech/1058787619/62-68
599 ：デフォルトの名無しさん：03/09/23 03:27
>>489
＞最初に知っておかなければならないことではない
1.アクセサ作るくらいなら、メンバ変数の public 化のほうがまし。
2.共通部分をサブルーチン化すれば継承は要らない。
3.メッセージ送信なんて、ただの関数呼び出し。
いったい何を最初に教えるの？
カプセル化？ 継承？ 多態？
つか、教えようという試み自体に無理が無いか？
＞最初に知っておかなければならないことではない
1.アクセサ作るくらいなら、メンバ変数の public 化のほうがまし。
2.共通部分をサブルーチン化すれば継承は要らない。
3.メッセージ送信なんて、ただの関数呼び出し。
いったい何を最初に教えるの？
カプセル化？ 継承？ 多態？
つか、教えようという試み自体に無理が無いか？
600 ：デフォルトの名無しさん：03/09/23 07:50
>>587
馬鹿はいっぺん死んでこい。
>No. C++ got the key notions of classes, derived classes, virtual functions
>(in other words, the notions of encapsulation,
>inheritance and polymorphism) from Simula just like Smalltalk did.
上の文章で括弧でくくられた部分は実際はSmalltalkの体系化した概念だが、
Stroustrupは同じ概念を別の単語で言い換えているに過ぎない。
馬鹿はいっぺん死んでこい。
>No. C++ got the key notions of classes, derived classes, virtual functions
>(in other words, the notions of encapsulation,
>inheritance and polymorphism) from Simula just like Smalltalk did.
上の文章で括弧でくくられた部分は実際はSmalltalkの体系化した概念だが、
Stroustrupは同じ概念を別の単語で言い換えているに過ぎない。
601 ：デフォルトの名無しさん：03/09/23 08:04
602 ：デフォルトの名無しさん：03/09/23 09:06
>>601
別に否定なんかされないと思うけど。ひょっとして言語の仕様に関する知識？
別に否定なんかされないと思うけど。ひょっとして言語の仕様に関する知識？
603 ：デフォルトの名無しさん：03/09/23 09:15
>>600
C++誕生以前のSmalltalkのどの論文にそんな体系づけ書いてあった？
C++誕生以前のSmalltalkのどの論文にそんな体系づけ書いてあった？
604 ：デフォルトの名無しさん：03/09/23 09:17
おいおい、a.add(b)のaddがメッセージであるって初心者に教えて、
いったい何のメリットがあるんだ？
馬鹿も休み休み言えよ。
いったい何のメリットがあるんだ？
馬鹿も休み休み言えよ。
605 ：デフォルトの名無しさん：03/09/23 09:26
606 ：デフォルトの名無しさん：03/09/23 09:28
メッセージなんかじゃないし、メッセージとは何かなんて知る必要もないのだと教えて
いったい何のメリットがあるのでしょう。
オブジェクト指向とやらとはどんなものなのか勉強してみようという相手に
勉強なんかする必要はない、と言って何か解決するのでしょうか？
馬鹿はずっと休んでいてください。
いったい何のメリットがあるのでしょう。
オブジェクト指向とやらとはどんなものなのか勉強してみようという相手に
勉強なんかする必要はない、と言って何か解決するのでしょうか？
馬鹿はずっと休んでいてください。
607 ：デフォルトの名無しさん：03/09/23 09:31
OOの一般的な概念を教えるときはメッセージを使い
C++の文法教える段階では使わないでいいだろ。なにお前らごねてんだよ。
C++の文法教える段階では使わないでいいだろ。なにお前らごねてんだよ。
608 ：デフォルトの名無しさん：03/09/23 09:32
609 ：デフォルトの名無しさん：03/09/23 09:34
610 ：デフォルトの名無しさん：03/09/23 09:36
おや、どうやら今までの関数呼び出しとはちょっと違うみたいだぞ？と思えるねｗ
611 ：デフォルトの名無しさん：03/09/23 09:39
>>610
おや、都合が悪くなると「実装」の話をもちだすんですか？（ｗ
おや、都合が悪くなると「実装」の話をもちだすんですか？（ｗ
612 ：デフォルトの名無しさん：03/09/23 09:41
>>607
一般的な概念を一通り説明し終えたら、それを実際の文法に当てはめてみるのもいいかもね。
一般的な概念を一通り説明し終えたら、それを実際の文法に当てはめてみるのもいいかもね。
613 ：デフォルトの名無しさん：03/09/23 09:42
>>611
おや、「実装」の話だったんですか？（ｗ
おや、「実装」の話だったんですか？（ｗ
614 ：デフォルトの名無しさん：03/09/23 09:43
SmalltalkerとC++房ってほんとになか悪いな(ｗ
カプセル化、継承、多態性がどっから始まったかは
どうでも良いです。
呼び出す側がメッセージで、実際に選択されるのがメソッド。
これもOKで、メタファどうのこうのはどうでも良いです。
メッセージとメソッドの違いは、多態性の説明で良く分かると
これもOK。
カプセル化、継承、多態性がどっから始まったかは
どうでも良いです。
呼び出す側がメッセージで、実際に選択されるのがメソッド。
これもOKで、メタファどうのこうのはどうでも良いです。
メッセージとメソッドの違いは、多態性の説明で良く分かると
これもOK。
615 ：デフォルトの名無しさん：03/09/23 09:44
>>613
自分で「関数呼び出し」なんて言語実装上の問題を持ち出しておきながら、
> おや、「実装」の話だったんですか？（ｗ
とは、思考能力ゼロだな、お前（ｗ
関数呼び出しが言語実装上の問題じゃないというなら、一体全体何の話を
お前はしようとしてるのだ？
自分で「関数呼び出し」なんて言語実装上の問題を持ち出しておきながら、
> おや、「実装」の話だったんですか？（ｗ
とは、思考能力ゼロだな、お前（ｗ
関数呼び出しが言語実装上の問題じゃないというなら、一体全体何の話を
お前はしようとしてるのだ？
616 ：デフォルトの名無しさん：03/09/23 09:45
Smalltalk厨と言わないあたり、>>614はC++嫌いのSmalltalk厨だろう。
617 ：デフォルトの名無しさん：03/09/23 09:47
>>615
・・・ a.add(b) の add の話だよ。
・・・ a.add(b) の add の話だよ。
618 ：デフォルトの名無しさん：03/09/23 09:47
>>617
見苦しい
見苦しい
619 ：デフォルトの名無しさん：03/09/23 09:47
620 ：デフォルトの名無しさん：03/09/23 09:49
>>617
あほか、a.add(b)が今までそいつが使ってきたであろうadd(a, b)とは
違うことは一目瞭然じゃないか。そのaddが「メッセージ」であると
教えることに何のメリットがあるのだ、と聞いてるんだよ。
あほか、a.add(b)が今までそいつが使ってきたであろうadd(a, b)とは
違うことは一目瞭然じゃないか。そのaddが「メッセージ」であると
教えることに何のメリットがあるのだ、と聞いてるんだよ。
621 ：デフォルトの名無しさん：03/09/23 09:50
>>620
同意
同意
622 ：デフォルトの名無しさん：03/09/23 09:54
まったく、天気のいい休日に、実に下らんことを議論して。
双方、とりあえず休んで散歩してこい。
まず冷静になれ。
もう少し考えてRESしろ。一言レスは無駄にスレを伸ばすだけ。
双方、とりあえず休んで散歩してこい。
まず冷静になれ。
もう少し考えてRESしろ。一言レスは無駄にスレを伸ばすだけ。
623 ：デフォルトの名無しさん：03/09/23 09:56
>>622
中国地方は雨だそうだ。
中国地方は雨だそうだ。
624 ：デフォルトの名無しさん：03/09/23 09:58
Smalltalk厨など存在しない。
Java厨が、Smalltalk厨を騙ってるだけ。
(そんなにJava厨ってのは、恥ずかしいことなんだろうか？)
Java厨が、Smalltalk厨を騙ってるだけ。
(そんなにJava厨ってのは、恥ずかしいことなんだろうか？)
625 ：デフォルトの名無しさん：03/09/23 09:59
>>619
多態性の説明では必要だと思われ。
そんな難しい概念じゃないでしょう。
まさか、多態性の説明では、仮想メソッドのテーブルを
子から親へたどって、一致するメソッドを探すんだというつもりじゃ(ｗ
勝負age
多態性の説明では必要だと思われ。
そんな難しい概念じゃないでしょう。
まさか、多態性の説明では、仮想メソッドのテーブルを
子から親へたどって、一致するメソッドを探すんだというつもりじゃ(ｗ
勝負age
626 ：デフォルトの名無しさん：03/09/23 10:00
無視sage
627 ：デフォルトの名無しさん：03/09/23 10:00
628 ：デフォルトの名無しさん：03/09/23 10:02
>>625
どうして多態性の説明に、メッセージが必要なんだよ。
メッセージは多態のトリガーにしか過ぎず、それを「メソッド」
と言っても何の問題も無い。
それに「メッセージ」難しい概念だといってるわけじゃない。
教える相手が持っていない新しい「用語」をことさら持ち出す
必要は無いと言ってるんだ。。
>まさか、多態性の説明では、仮想メソッドのテーブルを
>子から親へたどって、一致するメソッドを探すんだというつもりじゃ(ｗ
だから、言語実装の話を持ち出すんじゃない。
どうして多態性の説明に、メッセージが必要なんだよ。
メッセージは多態のトリガーにしか過ぎず、それを「メソッド」
と言っても何の問題も無い。
それに「メッセージ」難しい概念だといってるわけじゃない。
教える相手が持っていない新しい「用語」をことさら持ち出す
必要は無いと言ってるんだ。。
>まさか、多態性の説明では、仮想メソッドのテーブルを
>子から親へたどって、一致するメソッドを探すんだというつもりじゃ(ｗ
だから、言語実装の話を持ち出すんじゃない。
629 ：デフォルトの名無しさん：03/09/23 10:04
630 ：デフォルトの名無しさん：03/09/23 10:05
見た目が変われば一目瞭然だと思う・・・
631 ：デフォルトの名無しさん：03/09/23 10:06
そんなに難しい話じゃないんだよ。
OO厨の頭の中には、メッセージじゃなきゃダメなんだという、
深くて暗い固定概念がこびりついてるんだよ。
ただそれだけなんだよ。
OO厨の頭の中には、メッセージじゃなきゃダメなんだという、
深くて暗い固定概念がこびりついてるんだよ。
ただそれだけなんだよ。
632 ：デフォルトの名無しさん：03/09/23 10:07
普通の人間じゃなかったのか～。いや、そうなんじゃないかとはうすうす思ってはいたんだ。
ところで、違いってナニ？
ところで、違いってナニ？
633 ：デフォルトの名無しさん：03/09/23 10:09
634 ：デフォルトの名無しさん：03/09/23 10:10
>>628
メソッドがトリガーなら、実際の処理は何と呼んだほうがいいの？
メソッドがトリガーなら、実際の処理は何と呼んだほうがいいの？
635 ：デフォルトの名無しさん：03/09/23 10:12
636 ：デフォルトの名無しさん：03/09/23 10:12
637 ：デフォルトの名無しさん：03/09/23 10:13
>>634
すまん、「メソッド呼び出し」と「メソッド」の間違い。
すまん、「メソッド呼び出し」と「メソッド」の間違い。
638 ：デフォルトの名無しさん：03/09/23 10:15
>>635
説明する気もないが、とにかく役に立つと「思う」だけだよ。
そんなものなくても理解できた、便利とは思わない、という向きには不要だが、
他人の話を理解したり他人に話を伝えるときにも有用だと「思う」ね。
説明する気もないが、とにかく役に立つと「思う」だけだよ。
そんなものなくても理解できた、便利とは思わない、という向きには不要だが、
他人の話を理解したり他人に話を伝えるときにも有用だと「思う」ね。
639 ：デフォルトの名無しさん：03/09/23 10:16
>>636
>いったいどういう違いなのかを理解するために有用かもしれないね。
あふぉか。その違いを説明するときに「メッセージ」という概念はいらんと言ってるんだ。
もしそこで持ち出すメリットがあるというなら、それは何なのだと聞いてるんだよ。
>いったいどういう違いなのかを理解するために有用かもしれないね。
あふぉか。その違いを説明するときに「メッセージ」という概念はいらんと言ってるんだ。
もしそこで持ち出すメリットがあるというなら、それは何なのだと聞いてるんだよ。
640 ：デフォルトの名無しさん：03/09/23 10:18
>>637
それだと「メソッド呼び出し」と「メソッド」の関係を
従来の「関数呼び出し」と「関数」の関係と全く同じものだと考えてしまうかも。
メソッドなんて関数と同じだ、ゴルア！とか怒鳴られたらヤだなあ・・・。
それだと「メソッド呼び出し」と「メソッド」の関係を
従来の「関数呼び出し」と「関数」の関係と全く同じものだと考えてしまうかも。
メソッドなんて関数と同じだ、ゴルア！とか怒鳴られたらヤだなあ・・・。
641 ：デフォルトの名無しさん：03/09/23 10:18
>>628
わかりやすく説明できるなら、メッセージという用語にはこだわらないよ。
それじゃ、多態の説明はどうなる?
あるオブジェクトのメソッドを呼び出すと、実行時に
実際割り当てられているオブジェクトのメソッドが呼び出されます。
このように、実行時にどのオブジェクトを割り当てるかで、
さまざまな振る舞いをさせることができることを多態といいます。
か。
わかりやすく説明できるなら、メッセージという用語にはこだわらないよ。
それじゃ、多態の説明はどうなる?
あるオブジェクトのメソッドを呼び出すと、実行時に
実際割り当てられているオブジェクトのメソッドが呼び出されます。
このように、実行時にどのオブジェクトを割り当てるかで、
さまざまな振る舞いをさせることができることを多態といいます。
か。
642 ：デフォルトの名無しさん：03/09/23 10:18
643 ：デフォルトの名無しさん：03/09/23 10:20
>>639
そう思うなら説明してみせなってば。別に笑わないから。
そう思うなら説明してみせなってば。別に笑わないから。
644 ：デフォルトの名無しさん：03/09/23 10:21
ここは健忘症の方々が永遠にループし続けるスレですか？
645 ：デフォルトの名無しさん：03/09/23 10:21
>>642
そうそう。不要、ゆえに、不要。不毛だねえ。
そうそう。不要、ゆえに、不要。不毛だねえ。
646 ：デフォルトの名無しさん：03/09/23 10:23
647 ：デフォルトの名無しさん：03/09/23 10:24
>>644
そうそう。こんなことやってるから、こいつらなら勝てる、とか、釣れる、とか思われるのかも。不毛だねえ。
そうそう。こんなことやってるから、こいつらなら勝てる、とか、釣れる、とか思われるのかも。不毛だねえ。
648 ：デフォルトの名無しさん：03/09/23 10:24
649 ：デフォルトの名無しさん：03/09/23 10:24
>>646 ok
650 ：デフォルトの名無しさん：03/09/23 10:27
>>650
いや、一応思ってるよ。おれ本人だから。
いや、一応思ってるよ。おれ本人だから。
652 ：デフォルトの名無しさん：03/09/23 10:34
涼しいねぇ。そろそろ毛布だねぇ。
653 ：デフォルトの名無しさん：03/09/23 10:38
a.add(b) -> メソッド
add(a, b) -> 関数
の違いって、メソッドは暗黙の引数thisが渡されるだけで、
多態を考えなければあんましかわんないきがするんだけど。
add(a, b) -> 関数
の違いって、メソッドは暗黙の引数thisが渡されるだけで、
多態を考えなければあんましかわんないきがするんだけど。
654 ：デフォルトの名無しさん：03/09/23 10:39
>>653
多態も考えなきゃ駄目だよ。
多態も考えなきゃ駄目だよ。
655 ：デフォルトの名無しさん：03/09/23 10:42
656 ：デフォルトの名無しさん：03/09/23 10:49
>>654
オブジェクト指向は多態を使いこなせて意味がある。
多態を使わない局面では、手続き指向とさして変わりはない。
ということで良いでつか。
をれ的には、多態が必要な場合は、OOを使う。
そうでないなら手続き型で十分。
という使い分けなら、わかりやすくて良いのだが。
オブジェクト指向は多態を使いこなせて意味がある。
多態を使わない局面では、手続き指向とさして変わりはない。
ということで良いでつか。
をれ的には、多態が必要な場合は、OOを使う。
そうでないなら手続き型で十分。
という使い分けなら、わかりやすくて良いのだが。
657 ：デフォルトの名無しさん：03/09/23 10:55
658 ：デフォルトの名無しさん：03/09/23 10:55
多態は「使いこなす」ようなものじゃないと思うけどね。
すごく便利な機能だから使わなわなければ損だ、と思うような人と、
「使いこなす」（のが難しい）と思っている人の認識じゃ天と地だわな。
すごく便利な機能だから使わなわなければ損だ、と思うような人と、
「使いこなす」（のが難しい）と思っている人の認識じゃ天と地だわな。
659 ：デフォルトの名無しさん：03/09/23 10:55
>多態を使わない局面では、手続き指向とさして変わりはない。
「オブジェクト指向プログラミングは今までなされたどの試みよりも
データ抽象化・カプセル化・構造化されています。」
なんて文章があったし単なるシンタックスシュガーとしても普通に有用だよ。
別に多態の有無で脳内モードを切り替える必要は全然ないと思うが。
「オブジェクト指向プログラミングは今までなされたどの試みよりも
データ抽象化・カプセル化・構造化されています。」
なんて文章があったし単なるシンタックスシュガーとしても普通に有用だよ。
別に多態の有無で脳内モードを切り替える必要は全然ないと思うが。
660 ：デフォルトの名無しさん：03/09/23 10:56
誰か656に釣られてやれよ。
うわ! 突然書き込みが増えた。
662 ：デフォルトの名無しさん：03/09/23 10:57
＞別に多態の有無で脳内モードを切り替える必要は全然ないと思うが。
そうだよ、ねえ・・・。
そうだよ、ねえ・・・。
663 ：デフォルトの名無しさん：03/09/23 11:07
664 ：デフォルトの名無しさん：03/09/23 11:10
はい、ここで継承不要論↓
665 ：デフォルトの名無しさん：03/09/23 11:12
>>663
クラスライブラリ・フレームワーク使ってるだけってOOPとは言えないだろ。
クラスライブラリ・フレームワーク使ってるだけってOOPとは言えないだろ。
666 ：デフォルトの名無しさん：03/09/23 11:17
多態云々と大げさに言いだすようじゃ、まだまだなんだと思うぞ。
派生と差分プログラムでは、多態は当たり前に存在するんだから。
派生と差分プログラムでは、多態は当たり前に存在するんだから。
667 ：デフォルトの名無しさん：03/09/23 11:17
>>664
不要というか、継承の取り扱いに慎重になるのは自然な感覚なんじゃないかな。
不要というか、継承の取り扱いに慎重になるのは自然な感覚なんじゃないかな。
668 ：デフォルトの名無しさん：03/09/23 11:18
>>664
継承があるお陰で結構楽できていいぞ
継承があるお陰で結構楽できていいぞ
669 ：デフォルトの名無しさん：03/09/23 11:20
悲観的なのと楽観的なのが
670 ：デフォルトの名無しさん：03/09/23 11:21
>>659
シンタックスシュガーってのは不明だが。
世の中、OOが難しいと思っているやつはいっぱいいるわけだ。
そういうやつらに、
「ふだんは、手続き型で十分。多態が必要になったらOOも使いましょう。」
くらいの話で開発が進められたら楽でいいとおもうわけよ。
「今回の開発は、OOでいきます」
なんていったら、みんな不安でいっぱいになっちゃうから。
シンタックスシュガーってのは不明だが。
世の中、OOが難しいと思っているやつはいっぱいいるわけだ。
そういうやつらに、
「ふだんは、手続き型で十分。多態が必要になったらOOも使いましょう。」
くらいの話で開発が進められたら楽でいいとおもうわけよ。
「今回の開発は、OOでいきます」
なんていったら、みんな不安でいっぱいになっちゃうから。
671 ：デフォルトの名無しさん：03/09/23 11:24
基本クラスを継承させたものを多態で使い分けれるってのは便利。
継承要らんってのはVB厨の戯言だろ
継承要らんってのはVB厨の戯言だろ
672 ：デフォルトの名無しさん：03/09/23 11:27
>>665
をれは、OOにはこだわらなくって、
単に楽して開発したいわけよ。
できるだけ、開発メンバーに負担かけたくないから、
OOは振りかざしたくない。
ても、OOの良いところはおいしく使いたいと。
をれは、OOにはこだわらなくって、
単に楽して開発したいわけよ。
できるだけ、開発メンバーに負担かけたくないから、
OOは振りかざしたくない。
ても、OOの良いところはおいしく使いたいと。
673 ：デフォルトの名無しさん：03/09/23 11:27
>>671
継承の弊害をしっとるけ？
継承の弊害をしっとるけ？
674 ：デフォルトの名無しさん：03/09/23 11:28
675 ：デフォルトの名無しさん：03/09/23 11:30
676 ：デフォルトの名無しさん：03/09/23 11:31
確かに実装継承は有害だと思う。
そればっかりやってる奴のクラス構成は目も当てられん。
そればっかりやってる奴のクラス構成は目も当てられん。
677 ：デフォルトの名無しさん：03/09/23 11:32
OOは多態があるから「便利」なんじゃなくて、
継承や差分プログラムにおいて、多態は必然なんだよ。
継承や差分プログラムにおいて、多態は必然なんだよ。
678 ：デフォルトの名無しさん：03/09/23 11:32
>>675
多態のほうが、real worldをメタファとして説明しやすいと思うのだが。
多態のほうが、real worldをメタファとして説明しやすいと思うのだが。
679 ：デフォルトの名無しさん：03/09/23 11:34
>>677
多態に継承は必須ではないのだが？
多態に継承は必須ではないのだが？
680 ：デフォルトの名無しさん：03/09/23 11:34
681 ：デフォルトの名無しさん：03/09/23 11:35
基本的にOOを構造化言語の概念だけで説明しようと思ってるのが間違ってるん
だよ。全部CにmappingしてCではこうなる、とか。言語の構造化をアセンブラ
で説明しようとするのと同じことだ。構造化言語の分岐やループを結局gotoだ
ろ、という風に。
だよ。全部CにmappingしてCではこうなる、とか。言語の構造化をアセンブラ
で説明しようとするのと同じことだ。構造化言語の分岐やループを結局gotoだ
ろ、という風に。
682 ：デフォルトの名無しさん：03/09/23 11:38
デザパタみたいに、多態を使いこなしてみたいなのの弊害なのかな？
継承と差分プログラミング、ベースクラスでの操作の必要性が理解出来れば、
すでに多態は、当たり前のようにそこにあると思うんだけど。
継承と差分プログラミング、ベースクラスでの操作の必要性が理解出来れば、
すでに多態は、当たり前のようにそこにあると思うんだけど。
683 ：デフォルトの名無しさん：03/09/23 11:39
>>680
自分の感性==万人の感性と思い込んでる奴がいることに警鐘を鳴らしたまでだ。
自分の感性==万人の感性と思い込んでる奴がいることに警鐘を鳴らしたまでだ。
684 ：デフォルトの名無しさん：03/09/23 11:41
こういうスレで「不毛」は禁句。
685 ：デフォルトの名無しさん：03/09/23 11:41
>>682
言いたいことがよくわからんが「多態がわからないオマエは馬鹿」とでも言いたいのか？
言いたいことがよくわからんが「多態がわからないオマエは馬鹿」とでも言いたいのか？
686 ：デフォルトの名無しさん：03/09/23 11:42
>>685
その通り
その通り
687 ：デフォルトの名無しさん：03/09/23 11:42
688 ：デフォルトの名無しさん：03/09/23 11:44
>>675
自分が壁だったからといって、他人も同レベルだとは考えないこと。
自分が壁だったからといって、他人も同レベルだとは考えないこと。
689 ：デフォルトの名無しさん：03/09/23 11:44
690 ：デフォルトの名無しさん：03/09/23 11:44
691 ：デフォルトの名無しさん：03/09/23 11:45
基本三要素って何ですか？
692 ：デフォルトの名無しさん：03/09/23 11:46
カキコ・コンパイル・実行
693 ：デフォルトの名無しさん：03/09/23 11:46
>>691
自由、平和、独立 の三つだよ。
自由、平和、独立 の三つだよ。
694 ：デフォルトの名無しさん：03/09/23 11:46
カプセル化、継承、多態性のことでないの？
695 ：デフォルトの名無しさん：03/09/23 11:46
持たず、作らず、持ち込ませず
696 ：デフォルトの名無しさん：03/09/23 11:47
俺は多態こそがOOの神髄だと思うんだがなぁ。。。
697 ：デフォルトの名無しさん：03/09/23 11:49
友情・努力・成長だっけ？
698 ：デフォルトの名無しさん：03/09/23 11:49
オブジェクト指向は戦場では必要なしというのがよくわかりました・・・
699 ：デフォルトの名無しさん：03/09/23 11:50
700 ：デフォルトの名無しさん：03/09/23 11:50
>>697
面白くないんだけど
面白くないんだけど
701 ：デフォルトの名無しさん：03/09/23 11:50
702 ：デフォルトの名無しさん：03/09/23 11:50
>>700
お前のレスがな
お前のレスがな
703 ：デフォルトの名無しさん：03/09/23 11:51
>>698
戦場で必要なのは体力と精神力だよ。
戦場で必要なのは体力と精神力だよ。
704 ：デフォルトの名無しさん：03/09/23 11:51
705 ：デフォルトの名無しさん：03/09/23 11:51
706 ：デフォルトの名無しさん：03/09/23 11:53
ﾃﾞｻﾞﾊﾟﾀ厨うざ。
それが自慰だとなぜ気付かない。
それが自慰だとなぜ気付かない。
707 ：デフォルトの名無しさん：03/09/23 11:53
>>698
早く次のスレ立てろよ。
早く次のスレ立てろよ。
708 ：デフォルトの名無しさん：03/09/23 11:57
709 ：デフォルトの名無しさん：03/09/23 11:58
>>708
ひどいね、これ。
ひどいね、これ。
710 ：デフォルトの名無しさん：03/09/23 11:59
>>709
どこが？
どこが？
711 ：デフォルトの名無しさん：03/09/23 12:00
色彩が
712 ：デフォルトの名無しさん：03/09/23 12:00
>>710
自分で判断しろよ。まんどくせ。
自分で判断しろよ。まんどくせ。
713 ：デフォルトの名無しさん：03/09/23 12:02
>>708
なんでいまさら１０年前に書かれたものを引っ張り出すんだろう？
なんでいまさら１０年前に書かれたものを引っ張り出すんだろう？
714 ：デフォルトの名無しさん：03/09/23 12:02
>>711
同意。あのロゴとか。
同意。あのロゴとか。
715 ：デフォルトの名無しさん：03/09/23 12:03
> オブジェクト指向とは、モノのあり方に着目して、現実の世界をモデル化することである！
だそうです。
だそうです。
716 ：デフォルトの名無しさん：03/09/23 12:03
>>715
常識だな
常識だな
717 ：デフォルトの名無しさん：03/09/23 12:04
あー、10年前のものか。それじゃしかたないかもね。
718 ：デフォルトの名無しさん：03/09/23 12:06
オブジェクト指向プログラミングといえばSmalltalkでもRubyでもJavaでもなくDelphiです。
http://www.google.co.jp/search?hl=ja&ie=UTF-8&oe=UTF-8&c2coff=1&q=%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0&lr=
http://www.google.co.jp/search?hl=ja&ie=UTF-8&oe=UTF-8&c2coff=1&q=%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0&lr=
719 ：デフォルトの名無しさん：03/09/23 12:06
720 ：デフォルトの名無しさん：03/09/23 12:08
>>719
アイコンがいかん
アイコンがいかん
721 ：デフォルトの名無しさん：03/09/23 12:08
１０年前のオーバーロードって、あれでよかったの？
722 ：デフォルトの名無しさん：03/09/23 12:08
>>719
ふつうでしょ。何を期待しているのやら。
ふつうでしょ。何を期待しているのやら。
723 ：デフォルトの名無しさん：03/09/23 12:08
>>704
昔は、教育もいろいろやったんだけどね。
プロジェクトのはじめに、デザパタやリファクタリングの
勉強会開いたり、本買ってあげて、就業中でも
かまわないから読んでおくようにいったり。
結局みんながやってくれたのは、JUnitでテストをきちんと
書くことだけだったYO
多分俺が悪いだけだね。
逝ってきます。
昔は、教育もいろいろやったんだけどね。
プロジェクトのはじめに、デザパタやリファクタリングの
勉強会開いたり、本買ってあげて、就業中でも
かまわないから読んでおくようにいったり。
結局みんながやってくれたのは、JUnitでテストをきちんと
書くことだけだったYO
多分俺が悪いだけだね。
逝ってきます。
724 ：デフォルトの名無しさん：03/09/23 12:09
>>719
オナニー
オナニー
725 ：デフォルトの名無しさん：03/09/23 12:10
>>723
そうだと思う。君自身よく理解していないからだろう。
そうだと思う。君自身よく理解していないからだろう。
726 ：デフォルトの名無しさん：03/09/23 12:10
>>721
間違い。
間違い。
727 ：デフォルトの名無しさん：03/09/23 12:13
728 ：デフォルトの名無しさん：03/09/23 12:15
>>727
うーん、オブジェクト指向じゃない注文方法も聞きたいな（ｗ
うーん、オブジェクト指向じゃない注文方法も聞きたいな（ｗ
729 ：デフォルトの名無しさん：03/09/23 12:15
>>727
憂オブにも似たようなこと書いてあったような気がする。
憂オブにも似たようなこと書いてあったような気がする。
730 ：デフォルトの名無しさん：03/09/23 12:15
731 ：デフォルトの名無しさん：03/09/23 12:16
>>728
オブジェクト指向じゃないやり方は「材料買ってきて自分で作る」
オブジェクト指向じゃないやり方は「材料買ってきて自分で作る」
732 ：デフォルトの名無しさん：03/09/23 12:17
このスレは、今3人がリロードしているようだ（俺も含めて）（藁
733 ：デフォルトの名無しさん：03/09/23 12:17
非オブジェクト指向==車輪の再開発ってこと？
734 ：デフォルトの名無しさん：03/09/23 12:17
735 ：デフォルトの名無しさん：03/09/23 12:18
どっちかっていうと材料を個別に買ってきてそれを一つ一つ手渡して作ってもらうって漢字。
736 ：デフォルトの名無しさん：03/09/23 12:19
手続き指向=注文の多い料理店
737 ：デフォルトの名無しさん：03/09/23 12:19
>>733 違う。「材料買ってきて～」は手続き型言語のメタファ。
738 ：デフォルトの名無しさん：03/09/23 12:20
ハンバーガー屋クラスからマックとモスを派生させて、全国各地にインスタンスを生成させるとか。
739 ：デフォルトの名無しさん：03/09/23 12:20
740 ：デフォルトの名無しさん：03/09/23 12:21
>>739
買って読め。
買って読め。
741 ：デフォルトの名無しさん：03/09/23 12:23
742 ：デフォルトの名無しさん：03/09/23 12:25
743 ：デフォルトの名無しさん：03/09/23 12:26
744 ：デフォルトの名無しさん：03/09/23 12:27
>>743
読み方は「ウプ」じゃなかったのか・・・
読み方は「ウプ」じゃなかったのか・・・
745 ：デフォルトの名無しさん：03/09/23 12:29
ここまで記述量が少ないと技術用語辞典を買ってきてよんでも同じ、
ていうか、何がやりたいの？
ていうか、何がやりたいの？
746 ：デフォルトの名無しさん：03/09/23 12:30
>>745
オブジェクト指向プログラミング
オブジェクト指向プログラミング
747 ：デフォルトの名無しさん：03/09/23 12:32
>>746
何でもいいから java の入門書買ってきて、例題を打ち込んでいじってみたら？
何でもいいから java の入門書買ってきて、例題を打ち込んでいじってみたら？
748 ：デフォルトの名無しさん：03/09/23 12:33
つーか、藻前ら、加護ちゃんが激太りでホラー状態になってるぞ！
749 ：デフォルトの名無しさん：03/09/23 12:35
>>748
な、なんだってー
な、なんだってー
750 ：デフォルトの名無しさん：03/09/23 12:39
751 ：デフォルトの名無しさん：03/09/23 12:39
>>734に同意
OO：喫茶店で「ランチください」
手続き型：喫茶店で「ステーキ定食ライス大盛り焼き加減はミディアムレア、サラダはイタリアンドレッシングでコーヒーはアメリカンを食後に」
OOの利点はこのメッセージは他の喫茶店でも
まったく同じように使えること。
手続き型的なメッセージは他の喫茶店では使えないかもしれない。
752 ：デフォルトの名無しさん：03/09/23 12:47
753 ：デフォルトの名無しさん：03/09/23 12:49
754 ：デフォルトの名無しさん：03/09/23 12:49
>>751
その例えは間違っている。手続き型は店員に頼まない。
その例えは間違っている。手続き型は店員に頼まない。
755 ：デフォルトの名無しさん：03/09/23 12:49
>>752
継承してオーバーライドするんだろ。そのまんまじゃん。
継承してオーバーライドするんだろ。そのまんまじゃん。
756 ：デフォルトの名無しさん：03/09/23 12:50
757 ：デフォルトの名無しさん：03/09/23 12:53
758 ：デフォルトの名無しさん：03/09/23 12:55
オブジェクト指向:中華料理屋
非オブジェクト指向:喫茶店
非オブジェクト指向:喫茶店
759 ：デフォルトの名無しさん：03/09/23 13:03
ここまでいくとエージェント指向のほうが適任だぞ
760 ：デフォルトの名無しさん：03/09/23 13:05
>>752
「ランチください」って言うと、そういうのを出してくれるような
店か店員に対してメッセージを出す。
（あらかじめ店を選ぶか店員に指示をだしておく必要はあるかもしれない）
>>754
そんなことないんじゃない？
「店員に頼む関数」を呼び出すことはあると思われ
例えばCのFILE,fopen,fread,fwrite,fcloseみたいな一連のファミリーは
手続き型だけど、隠蔽されたFILEオブジェクトにメッセージを投げるイメージじゃん？
多態はしてくれないからOO的ではない
（UNIXがファイルという抽象概念を作ってくれたから、
実は多態できるけど、それはプログラム側の話ではない）
「ランチください」って言うと、そういうのを出してくれるような
店か店員に対してメッセージを出す。
（あらかじめ店を選ぶか店員に指示をだしておく必要はあるかもしれない）
>>754
そんなことないんじゃない？
「店員に頼む関数」を呼び出すことはあると思われ
例えばCのFILE,fopen,fread,fwrite,fcloseみたいな一連のファミリーは
手続き型だけど、隠蔽されたFILEオブジェクトにメッセージを投げるイメージじゃん？
多態はしてくれないからOO的ではない
（UNIXがファイルという抽象概念を作ってくれたから、
実は多態できるけど、それはプログラム側の話ではない）
761 ：デフォルトの名無しさん：03/09/23 13:05
>>758
ますますわからんたとえ。
ますますわからんたとえ。
762 ：デフォルトの名無しさん：03/09/23 13:10
既存の店員から派生した自分の注文を実行する店員を、
事前に自分で用意しておくんだろ。
だから変なたとえはやめろと。
事前に自分で用意しておくんだろ。
だから変なたとえはやめろと。
763 ：デフォルトの名無しさん：03/09/23 13:12
764 ：デフォルトの名無しさん：03/09/23 13:13
「こんな喫茶店はいやだ!!」スレこれにて終了と。
765 ：デフォルトの名無しさん：03/09/23 13:14
>>762
注文ごとに店員が違うのか？
注文ごとに店員が違うのか？
766 ：デフォルトの名無しさん：03/09/23 13:16
767 ：デフォルトの名無しさん：03/09/23 13:20
要はいまどき喫茶店なんて経営しても人件費ばかりかかって儲からない、
という事だな。
という事だな。
768 ：デフォルトの名無しさん：03/09/23 13:20
>>765
前日に店員のクローンを作っておいて（派生）、家につれて帰り教育し（カスタマイズ）、
食いに行くときは、食いに行くやつ１人１人が、店員１人を連れて行くんだろう。
そもそも注文にたとえるのがアホって事だな。
前日に店員のクローンを作っておいて（派生）、家につれて帰り教育し（カスタマイズ）、
食いに行くときは、食いに行くやつ１人１人が、店員１人を連れて行くんだろう。
そもそも注文にたとえるのがアホって事だな。
769 ：デフォルトの名無しさん：03/09/23 13:21
770 ：デフォルトの名無しさん：03/09/23 13:22
771 ：デフォルトの名無しさん：03/09/23 13:24
772 ：デフォルトの名無しさん：03/09/23 13:25
エージェント店員に抽象レシピオブジェクトを継承したステーキ定食を渡す。
細かい注文がある場合はステーキ定食にあらかじめミディアムレアメッセージや
大盛りメッセージを出してから渡す。
細かい注文がある場合はステーキ定食にあらかじめミディアムレアメッセージや
大盛りメッセージを出してから渡す。
773 ：デフォルトの名無しさん：03/09/23 13:25
774 ：デフォルトの名無しさん：03/09/23 13:27
775 ：デフォルトの名無しさん：03/09/23 13:28
776 ：デフォルトの名無しさん：03/09/23 13:29
食い逃げメソッドも必要だな。
777 ：デフォルトの名無しさん：03/09/23 13:29
店員 <-- ランチを 注文する
店員 <-- ステーキ定食を 注文する
店員 <-- ステーキ定食ライス大盛りを 注文する
...
店員 <-- ステーキ定食を 注文する
店員 <-- ステーキ定食ライス大盛りを 注文する
...
778 ：デフォルトの名無しさん：03/09/23 13:31
結論 馬鹿な例えは混乱するだけ
779 ：デフォルトの名無しさん：03/09/23 13:31
>>772
細かい注文はプロパティだろ
細かい注文はプロパティだろ
780 ：デフォルトの名無しさん：03/09/23 13:31
781 ：デフォルトの名無しさん：03/09/23 13:32
混乱してるのは768だけのようだが
782 ：デフォルトの名無しさん：03/09/23 13:32
要は、店員を抽象クラスにしておいて注文取りメソッドを定義、喫茶店ではウェイトレス、クラブではママを派生して注文取りメソッドをオーバーライドすればいいだけ。その中で誘惑しようが何しようが自由。
エスパーな店員クラスなら客クラスをフレンドにして直接考食べたい料理が定義されてる部分にアクセスしてもいい。
店が店員を所持し、客が入ってくるイベントで客を引数に店員の注文メソッドを呼び出す。
そのメソッドの戻り値で客が怒って帰ったとか注文を取ることに成功したとか判断する。
また、店員クラスは注文書クラスを所持しており、そこに客からの注文をＡＤＤしていくことになる。
店はそれをゲットしてコックに渡して料理を作らせる。
エスパーな店員クラスなら客クラスをフレンドにして直接考食べたい料理が定義されてる部分にアクセスしてもいい。
店が店員を所持し、客が入ってくるイベントで客を引数に店員の注文メソッドを呼び出す。
そのメソッドの戻り値で客が怒って帰ったとか注文を取ることに成功したとか判断する。
また、店員クラスは注文書クラスを所持しており、そこに客からの注文をＡＤＤしていくことになる。
店はそれをゲットしてコックに渡して料理を作らせる。
783 ：デフォルトの名無しさん：03/09/23 13:32
C++のa->add(b)って表記おかしいよね！
a<-add(b)のがわかりやすいじゃん！
a<-add(b)のがわかりやすいじゃん！
784 ：デフォルトの名無しさん：03/09/23 13:32
非常に有意義な議論ですので、喫茶店経営スレにコピペを貼ってきます。
785 ：デフォルトの名無しさん：03/09/23 13:33
>>783
aが-add(b)より小さい
aが-add(b)より小さい
786 ：デフォルトの名無しさん：03/09/23 13:33
787 ：デフォルトの名無しさん：03/09/23 13:33
>>777
ランチを継承したステーキ定食オブジェクトのプロパティをライス大盛りにしてから渡せ
ランチを継承したステーキ定食オブジェクトのプロパティをライス大盛りにしてから渡せ
788 ：デフォルトの名無しさん：03/09/23 13:34
>>751のたとえが変なだけ。
789 ：デフォルトの名無しさん：03/09/23 13:35
もともとは、どうやってピザを作るかの話なのに、どうやってピザを頼むかに話が変わっとる
790 ：デフォルトの名無しさん：03/09/23 13:35
>>789
違う。どうやってピザを食べる(手に入れる)か。
違う。どうやってピザを食べる(手に入れる)か。
791 ：デフォルトの名無しさん：03/09/23 13:36
>>782
こんなオナニーが有意義だと勘違いしてるようじゃ・・・
こんなオナニーが有意義だと勘違いしてるようじゃ・・・
792 ：デフォルトの名無しさん：03/09/23 13:37
>>786
自分でレシピを作って渡すなら、普段は「店」の中に隠蔽されている汎用の「料理人」の
インスタンスを自分で用意して、直接それを渡せばいい。
それをラップしたいから「店」への注文にたとえてるんでしょ。「ランチ」なんだから。
自分でレシピを作って渡すなら、普段は「店」の中に隠蔽されている汎用の「料理人」の
インスタンスを自分で用意して、直接それを渡せばいい。
それをラップしたいから「店」への注文にたとえてるんでしょ。「ランチ」なんだから。
793 ：デフォルトの名無しさん：03/09/23 13:37
保守age
794 ：デフォルトの名無しさん：03/09/23 13:38
>>791
たとえた本人だけは悦に入ってるけどね
たとえた本人だけは悦に入ってるけどね
795 ：デフォルトの名無しさん：03/09/23 13:38
違わないって。手に入れる手段の話なんかしてないし、問題じゃない。
796 ：デフォルトの名無しさん：03/09/23 13:39
797 ：デフォルトの名無しさん：03/09/23 13:40
もともとは餃子を一から作る（手続き指向的）のが大変なので、
「餃子」インスタンスを「中華料理屋」に作ってもらう、
というたとえなんじゃないの？
デフォルトの餃子インスタンスなら注文するだけで作ってくれるわけで。
それとカスタマイズの余地の多いランチオブジェクトに問題をすり変えたんだよ。
>>751は。
「餃子」インスタンスを「中華料理屋」に作ってもらう、
というたとえなんじゃないの？
デフォルトの餃子インスタンスなら注文するだけで作ってくれるわけで。
それとカスタマイズの余地の多いランチオブジェクトに問題をすり変えたんだよ。
>>751は。
798 ：デフォルトの名無しさん：03/09/23 13:40
なんだここは？ＯＯの面白さを理解できない厨ばかりか？正直ショックだ。
799 ：デフォルトの名無しさん：03/09/23 13:41
正直、ここ２～３日はつまらん。
議論のための議論をしてるようで。
議論のための議論をしてるようで。
800 ：デフォルトの名無しさん：03/09/23 13:41
>>796
もちろん見てる。
もちろん見てる。
801 ：デフォルトの名無しさん：03/09/23 13:42
802 ：デフォルトの名無しさん：03/09/23 13:43
>>797
すり替えたんじゃなくて、さらに一歩すすめたように見えるけど。
すり替えたんじゃなくて、さらに一歩すすめたように見えるけど。
803 ：デフォルトの名無しさん：03/09/23 13:43
804 ：デフォルトの名無しさん：03/09/23 13:43
効率の良い方法を模索する暇があったら、今できる方法でさっさと制作に取りかかれ。
805 ：デフォルトの名無しさん：03/09/23 13:44
ま、>>782がアフォってことで。「要は」なんていう奴にろくな奴がいないのの証明になったね。
806 ：デフォルトの名無しさん：03/09/23 13:45
>>801
事実だからしょうがない。
まあ、ある意味コンプレックスっやつなのかな。
ある程度ＯＯをやれば、手続きは合理的でないことはすぐにわかるのに。
まあ、慣れてしまったものをいまさら変えろというのが無理があるのかな。
でも手続きからがんばってＯＯに入れた人間は尊敬したいね。
事実だからしょうがない。
まあ、ある意味コンプレックスっやつなのかな。
ある程度ＯＯをやれば、手続きは合理的でないことはすぐにわかるのに。
まあ、慣れてしまったものをいまさら変えろというのが無理があるのかな。
でも手続きからがんばってＯＯに入れた人間は尊敬したいね。
807 ：デフォルトの名無しさん：03/09/23 13:45
>>803 何を？
808 ：デフォルトの名無しさん：03/09/23 13:46
つかウェイトレスとかがいる時点でオブジェクト指向ではなくて
エージェント指向にまで行ってるわけだ。
オブジェクト指向だと場所の概念がないから
わざわざウェイトレスを介してコックに注文を渡すことを説明できない。
エージェント指向にまで行ってるわけだ。
オブジェクト指向だと場所の概念がないから
わざわざウェイトレスを介してコックに注文を渡すことを説明できない。
809 ：デフォルトの名無しさん：03/09/23 13:47
カスタマイズしたいならバイキングに逝ってデコレートしろ。
810 ：デフォルトの名無しさん：03/09/23 13:47
>>805
具体的にいえよ。どこがどうアフォなのか。まあ次のセリフは予想できるけど。この手の輩はワンパターンだからな。
具体的にいえよ。どこがどうアフォなのか。まあ次のセリフは予想できるけど。この手の輩はワンパターンだからな。
811 ：デフォルトの名無しさん：03/09/23 13:48
バイキングじゃデコレートできませんが
812 ：デフォルトの名無しさん：03/09/23 13:48
>>810
釣れたw
釣れたw
813 ：デフォルトの名無しさん：03/09/23 13:48
所詮ＯＯ自体、選択肢のひとつでしかない事を知れ。
814 ：デフォルトの名無しさん：03/09/23 13:49
815 ：デフォルトの名無しさん：03/09/23 13:49
>>812
うわっ 寒・・・
うわっ 寒・・・
816 ：デフォルトの名無しさん：03/09/23 13:49
817 ：デフォルトの名無しさん：03/09/23 13:49
プログラミングの話を、何でも現実世界にたとえるのは無理がある。
という結論でよろしいか？
という結論でよろしいか？
818 ：デフォルトの名無しさん：03/09/23 13:50
>>808
それはちょっと。
それはちょっと。
819 ：デフォルトの名無しさん：03/09/23 13:50
>>816
それはオブジェクト指向でない
それはオブジェクト指向でない
820 ：デフォルトの名無しさん：03/09/23 13:50
821 ：デフォルトの名無しさん：03/09/23 13:51
>>810
だから「要」になってない発言を「要は」で切り出すアフォだって言ってるんだが
だから「要」になってない発言を「要は」で切り出すアフォだって言ってるんだが
822 ：デフォルトの名無しさん：03/09/23 13:51
>>817
現実の世界をソフトウェアで例えるために日夜苦労している人もいるよ。
現実の世界をソフトウェアで例えるために日夜苦労している人もいるよ。
823 ：デフォルトの名無しさん：03/09/23 13:52
824 ：デフォルトの名無しさん：03/09/23 13:52
825 ：デフォルトの名無しさん：03/09/23 13:53
826 ：デフォルトの名無しさん：03/09/23 13:53
>>823
どんな場合でも適用できるからOOはすばらしい。
どんな場合でも適用できるからOOはすばらしい。
827 ：デフォルトの名無しさん：03/09/23 13:54
憂プロまんせー
828 ：デフォルトの名無しさん：03/09/23 13:54
>>826
馬鹿かアホかと。
馬鹿かアホかと。
829 ：デフォルトの名無しさん：03/09/23 13:54
どれが釣りなんだか。
830 ：デフォルトの名無しさん：03/09/23 13:55
>>824
明らかにネタページじゃないか。
明らかにネタページじゃないか。
831 ：デフォルトの名無しさん：03/09/23 13:55
832 ：デフォルトの名無しさん：03/09/23 13:55
デコレータパターンって、ゴハン＋牛肉＝牛丼、ゴハン＋ルー＝カレーとかいうものじゃないよ。
833 ：デフォルトの名無しさん：03/09/23 13:55
834 ：デフォルトの名無しさん：03/09/23 13:55
>>803
ウェイトレスに注文メッセージのパラメータとしてメニューオブジェクトを渡すんだろうが!
ウェイトレスに注文メッセージのパラメータとしてメニューオブジェクトを渡すんだろうが!
835 ：デフォルトの名無しさん：03/09/23 13:56
>>834
ウェイトレスの服装は？
ウェイトレスの服装は？
836 ：デフォルトの名無しさん：03/09/23 13:57
>>330
明らかにネタページじゃないか。
明らかにネタページじゃないか。
837 ：デフォルトの名無しさん：03/09/23 13:57
話は違うがJavaって、オブジェクト指向言語としての純度は決して高くない
と思うんだが、それにしちゃあJava信者ってオブジェクト指向にこだわり
たがる人が多い。Java信者の信仰の源ってどこにあるの？
と思うんだが、それにしちゃあJava信者ってオブジェクト指向にこだわり
たがる人が多い。Java信者の信仰の源ってどこにあるの？
838 ：デフォルトの名無しさん：03/09/23 13:58
839 ：デフォルトの名無しさん：03/09/23 13:58
レストランの店員ってエージェント指向じゃん
店の使者なんだから
店の使者なんだから
840 ：デフォルトの名無しさん：03/09/23 13:58
>>837
現存する言語の中では一番高いと思うが
現存する言語の中では一番高いと思うが
841 ：デフォルトの名無しさん：03/09/23 13:58
>>837 Javaは純粋なOOPL
842 ：デフォルトの名無しさん：03/09/23 13:58
釣りということで自分が他人より上になった気がするのか？
お前の人生は誰のための人生だ？
ちっぽけすぎて煽る気にもらん。
お前の人生は誰のための人生だ？
ちっぽけすぎて煽る気にもらん。
843 ：デフォルトの名無しさん：03/09/23 13:59
844 ：デフォルトの名無しさん：03/09/23 13:59
>>842
釣おち？
釣おち？
845 ：デフォルトの名無しさん：03/09/23 14:00
846 ：デフォルトの名無しさん：03/09/23 14:00
> 食いに行くときは、食いに行くやつ１人１人が、店員１人を連れて行くんだろう。
晒しsage
晒しsage
847 ：デフォルトの名無しさん：03/09/23 14:00
Javaはポインタがないから糞だな。
848 ：デフォルトの名無しさん：03/09/23 14:00
>>819
なぜオブジェクト指向じゃないかということをきちんと説明しないとこの手の輩にはわからないよ
なぜオブジェクト指向じゃないかということをきちんと説明しないとこの手の輩にはわからないよ
849 ：デフォルトの名無しさん：03/09/23 14:00
>>838
現存する釣りの中では一番高いと思うが
現存する釣りの中では一番高いと思うが
850 ：デフォルトの名無しさん：03/09/23 14:00
851 ：デフォルトの名無しさん：03/09/23 14:00
>>837
JavaはC++流の妥協的（型制限が強い）オブジェクト指向の完成系
JavaはC++流の妥協的（型制限が強い）オブジェクト指向の完成系
852 ：デフォルトの名無しさん：03/09/23 14:01
そろそろかってに勝利宣言していい？
853 ：デフォルトの名無しさん：03/09/23 14:01
そもそもJava信者なんかいません。妄想でしょう
854 ：デフォルトの名無しさん：03/09/23 14:01
GoFでも結城でもいいが、デザパタ本読んで出直せ＞＞８４５
855 ：デフォルトの名無しさん：03/09/23 14:02
さてと、、、そろそろ実況板にいってベイスターズを応援してくるか。
856 ：デフォルトの名無しさん：03/09/23 14:02
857 ：デフォルトの名無しさん：03/09/23 14:02
Smalltalkの勝利！
Smalltalker以外氏ね！
Smalltalker以外氏ね！
858 ：デフォルトの名無しさん：03/09/23 14:03
>>845
なぜデザパタ本を読んで出直さなければならないかということをきちんと説明しないとこの手の輩にはわからないよ
なぜデザパタ本を読んで出直さなければならないかということをきちんと説明しないとこの手の輩にはわからないよ
859 ：デフォルトの名無しさん：03/09/23 14:03
ＯＯをデザパタといってるのは痛いな。
860 ：デフォルトの名無しさん：03/09/23 14:04
>>858
なぜその手の輩にはわからないかということをきちんと説明しないとこの手の輩にはわからないよ
なぜその手の輩にはわからないかということをきちんと説明しないとこの手の輩にはわからないよ
861 ：デフォルトの名無しさん：03/09/23 14:04
デザインパターンはオブジェクトの具体的な使い方をパターンとして示すものであり
必ずしもオブジェクト指向的ではない。
必ずしもオブジェクト指向的ではない。
862 ：デフォルトの名無しさん：03/09/23 14:04
>>813
そうだよ。
OOPLは手続き型言語に比べて表現力が高いっていうだけ。
手続き型言語で表現しようとすると面倒だが
OOPLだとさくっと表現できる概念がある（例えば多態）
そんでその応用範囲が広いからOOが流行るわけで。
そうだよ。
OOPLは手続き型言語に比べて表現力が高いっていうだけ。
手続き型言語で表現しようとすると面倒だが
OOPLだとさくっと表現できる概念がある（例えば多態）
そんでその応用範囲が広いからOOが流行るわけで。
863 ：デフォルトの名無しさん：03/09/23 14:04
864 ：デフォルトの名無しさん：03/09/23 14:04
>>859
デザパタくらいは理解しようね(笑)
デザパタくらいは理解しようね(笑)
865 ：デフォルトの名無しさん：03/09/23 14:05
Java信者デザパタ会派
866 ：デフォルトの名無しさん：03/09/23 14:05
>>846
> > 食いに行くときは、食いに行くやつ１人１人が、店員１人を連れて行くんだろう。
>
> 晒しsage
それは、「いかに現実世界で旨く例えられるか」を競っている、
無意味な行為を繰り返すバカに、どんな馬鹿なことをしているかという
例として書いた物なんだが。
やはりバカに行間を読めというのはむりだったか(w
> > 食いに行くときは、食いに行くやつ１人１人が、店員１人を連れて行くんだろう。
>
> 晒しsage
それは、「いかに現実世界で旨く例えられるか」を競っている、
無意味な行為を繰り返すバカに、どんな馬鹿なことをしているかという
例として書いた物なんだが。
やはりバカに行間を読めというのはむりだったか(w
867 ：デフォルトの名無しさん：03/09/23 14:05
シゲ死ね団
868 ：デフォルトの名無しさん：03/09/23 14:06
Rubyが最も純度の高いOOPLかな
869 ：デフォルトの名無しさん：03/09/23 14:06
＞GoFでも結城でも
今から読むとしたら、どちらがいいでしょうかね。
今から読むとしたら、どちらがいいでしょうかね。
870 ：デフォルトの名無しさん：03/09/23 14:06
>>869
GoF
GoF
871 ：デフォルトの名無しさん：03/09/23 14:06
結城たんと始めるGolF
872 ：デフォルトの名無しさん：03/09/23 14:07
873 ：デフォルトの名無しさん：03/09/23 14:07
C++をやる予定ならGoF、それ以外の言語なら結城
874 ：デフォルトの名無しさん：03/09/23 14:07
875 ：デフォルトの名無しさん：03/09/23 14:07
876 ：デフォルトの名無しさん：03/09/23 14:08
>>875
あなたはデザインパターンを理解してますか？
あなたはデザインパターンを理解してますか？
877 ：デフォルトの名無しさん：03/09/23 14:08
>>870-871 迷いますね。
878 ：デフォルトの名無しさん：03/09/23 14:09
つーか、デザパタって２３個しかないと思ってる奴がいるみたいね（藁
879 ：デフォルトの名無しさん：03/09/23 14:09
>>873
わかりました、あなたを信じます。
わかりました、あなたを信じます。
880 ：デフォルトの名無しさん：03/09/23 14:09
23とはまた中途半端な。
881 ：デフォルトの名無しさん：03/09/23 14:09
882 ：デフォルトの名無しさん：03/09/23 14:09
憂プロ読み返してみたが前橋の逝ってる「例えが混乱させてる」とかってのを
汲んであるし、前橋より100倍考えて書いてあると思うんだが。
前橋的には憂プロは駄目だったのかな。
たしかにアレで全員がわかるとは思わないけど全員がわかるように教えるのを
そもそも書籍に求めるのが無理な話だし。
5年前の書籍としては結構良い方だと思うんだが。
汲んであるし、前橋より100倍考えて書いてあると思うんだが。
前橋的には憂プロは駄目だったのかな。
たしかにアレで全員がわかるとは思わないけど全員がわかるように教えるのを
そもそも書籍に求めるのが無理な話だし。
5年前の書籍としては結構良い方だと思うんだが。
883 ：デフォルトの名無しさん：03/09/23 14:10
884 ：デフォルトの名無しさん：03/09/23 14:10
885 ：デフォルトの名無しさん：03/09/23 14:10
886 ：デフォルトの名無しさん：03/09/23 14:11
>>882
前橋はもういいよ。
前橋はもういいよ。
887 ：デフォルトの名無しさん：03/09/23 14:11
>>886
もういいのか？
もういいのか？
888 ：デフォルトの名無しさん：03/09/23 14:11
前橋ってたしかＣ言語ポインタ完全の著者だよね。
889 ：デフォルトの名無しさん：03/09/23 14:12
そりゃ現代のプログラマのたしなみとして、デザパタくらい理解しておくべき
だろうけど、「このシステムでいかにしてデザパタを適用すべきか、うーん、
うーん」って悩んでいる奴がいたらアホかと言いたくなる。デザパタ使わなく
ても動くんだったら、それはそれで別にいいだろと。
だろうけど、「このシステムでいかにしてデザパタを適用すべきか、うーん、
うーん」って悩んでいる奴がいたらアホかと言いたくなる。デザパタ使わなく
ても動くんだったら、それはそれで別にいいだろと。
890 ：デフォルトの名無しさん：03/09/23 14:12
なんで前橋などという小物を何度も取り上げるんだろうね？
どうでもいいじゃん、そんなやつ。
どうでもいいじゃん、そんなやつ。
891 ：デフォルトの名無しさん：03/09/23 14:12
>>888
それ、おもしろいの？
それ、おもしろいの？
892 ：デフォルトの名無しさん：03/09/23 14:12
麻奈たんもデザパタ本書いてくれないかな。
893 ：デフォルトの名無しさん：03/09/23 14:14
デザインパターンなど自分の頭の中で自動的に生成できる。ただし俺だけね。俺だからできる。
894 ：デフォルトの名無しさん：03/09/23 14:14
>>891
ネタとして読んでおくべき
ネタとして読んでおくべき
895 ：デフォルトの名無しさん：03/09/23 14:15
手際の良い人にはOOPなんかいらん
896 ：デフォルトの名無しさん：03/09/23 14:15
>>894
ネタならもういいです。あんまり笑えないし。
ネタならもういいです。あんまり笑えないし。
897 ：デフォルトの名無しさん：03/09/23 14:16
898 ：デフォルトの名無しさん：03/09/23 14:16
899 ：デフォルトの名無しさん：03/09/23 14:16
>>896
心が荒んでいるの？
心が荒んでいるの？
900 ：デフォルトの名無しさん：03/09/23 14:17
901 ：デフォルトの名無しさん：03/09/23 14:18
>>897よな。
902 ：デフォルトの名無しさん：03/09/23 14:18
903 ：デフォルトの名無しさん：03/09/23 14:19
>>902
まあ初心者がポインタをつかむためのステップアップ本だな
まあ初心者がポインタをつかむためのステップアップ本だな
904 ：デフォルトの名無しさん：03/09/23 14:19
ポインタはオブジェクト指向の敵だ。
905 ：デフォルトの名無しさん：03/09/23 14:19
>>880
中途半端？なんで？
中途半端？なんで？
906 ：デフォルトの名無しさん：03/09/23 14:20
907 ：デフォルトの名無しさん：03/09/23 14:20
>>882
憂プロってなんで信者みたいなのがいるんだろな
憂プロってなんで信者みたいなのがいるんだろな
908 ：デフォルトの名無しさん：03/09/23 14:20
909 ：デフォルトの名無しさん：03/09/23 14:21
もはや全員が壮大なスレ違い
おれもなー
おれもなー
910 ：デフォルトの名無しさん：03/09/23 14:21
911 ：デフォルトの名無しさん：03/09/23 14:21
>>907
信者に見えるのは気のせいです
信者に見えるのは気のせいです
912 ：デフォルトの名無しさん：03/09/23 14:23
>>910
漢数字で書けよって煽り？
漢数字で書けよって煽り？
913 ：デフォルトの名無しさん：03/09/23 14:24
914 ：デフォルトの名無しさん：03/09/23 14:25
なんで、にじゅうさんが中途半端なんだ？
915 ：デフォルトの名無しさん：03/09/23 14:26
素数だから
916 ：デフォルトの名無しさん：03/09/23 14:26
917 ：デフォルトの名無しさん：03/09/23 14:27
さて、そろそろオレはランチを食ってくるか．．．
918 ：デフォルトの名無しさん：03/09/23 14:28
┌──────────── 千葉大会 ─────────────┐
│〃〃〃〃〃〃〃┌───────┴───────┐〃〃〃〃〃〃〃│
│〃〃〃┌───┴───┐〃〃〃〃〃〃〃┌───┴───┐〃〃〃│
│〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃│
│┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐│
├┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┤
│東│銚│拓│二│学│安│佐│千│流│流│市│八│成│千│銚│我│
│海│子│大│松│館│房│倉│葉│山│通│立│千│東│葉│子│孫│
│大│西│紅│沼│浦│ │ │商│東│経│柏│代│ │経│商｜子｜
│浦│ │陵│南│安│ │ │大│ │大│ │松│ │大│ │ │
│安│ │ │ │ │ │ │付│ │柏│ │陰│ │付 │ │ │
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
│〃〃〃〃〃〃〃┌───────┴───────┐〃〃〃〃〃〃〃│
│〃〃〃┌───┴───┐〃〃〃〃〃〃〃┌───┴───┐〃〃〃│
│〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃│
│┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐│
├┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┤
│東│銚│拓│二│学│安│佐│千│流│流│市│八│成│千│銚│我│
│海│子│大│松│館│房│倉│葉│山│通│立│千│東│葉│子│孫│
│大│西│紅│沼│浦│ │ │商│東│経│柏│代│ │経│商｜子｜
│浦│ │陵│南│安│ │ │大│ │大│ │松│ │大│ │ │
│安│ │ │ │ │ │ │付│ │柏│ │陰│ │付 │ │ │
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
919 ：デフォルトの名無しさん：03/09/23 14:28
わけわからん。
「デザパタって二十三個しかないと思っている奴がいるみたいね」
「二十三って素数だから中途半端だね」
？？？
「デザパタって二十三個しかないと思っている奴がいるみたいね」
「二十三って素数だから中途半端だね」
？？？
920 ：デフォルトの名無しさん：03/09/23 14:28
やはり今晩は豚煮ラーメンと豚煮おにぎりにしよう。
921 ：デフォルトの名無しさん：03/09/23 14:28
2^n じゃないから
922 ：デフォルトの名無しさん：03/09/23 14:29
┌──────────── 千葉大会 ─────────────┐
│〃〃〃〃〃〃〃┌───────┴───────┐〃〃〃〃〃〃〃│
│〃〃〃┌───┴───┐〃〃〃〃〃〃〃┌───┴───┐〃〃〃│
│〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃│
│┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐│
├┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┤
│東│銚│拓│二│学│安│佐│千│流│流│市│八│成│千│銚│我│
│海│子│大│松│館│房│倉│葉│山│通│立│千│東│葉│子│孫│
│大│西│紅│沼│浦│ │ │商│東│経│柏│代│ │経│商｜子｜
│浦│ │陵│南│安│ │ │大│ │大│ │松│ │大│ │ │
│安│ │ │ │ │ │ │付│ │柏│ │陰│ │付│ │ │
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
│〃〃〃〃〃〃〃┌───────┴───────┐〃〃〃〃〃〃〃│
│〃〃〃┌───┴───┐〃〃〃〃〃〃〃┌───┴───┐〃〃〃│
│〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃│
│┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐│
├┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┤
│東│銚│拓│二│学│安│佐│千│流│流│市│八│成│千│銚│我│
│海│子│大│松│館│房│倉│葉│山│通│立│千│東│葉│子│孫│
│大│西│紅│沼│浦│ │ │商│東│経│柏│代│ │経│商｜子｜
│浦│ │陵│南│安│ │ │大│ │大│ │松│ │大│ │ │
│安│ │ │ │ │ │ │付│ │柏│ │陰│ │付│ │ │
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
923 ：デフォルトの名無しさん：03/09/23 14:29
1と自身以外では割り切れないから
924 ：デフォルトの名無しさん：03/09/23 14:29
925 ：テスト：03/09/23 14:30
┌──────────── 秋季千葉大会 ─────────────┐
│〃〃〃〃〃〃〃┌───────┴───────┐〃〃〃〃〃〃〃│
│〃〃〃┌───┴───┐〃〃〃〃〃〃〃┌───┴───┐〃〃〃│
│〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃│
│┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐│
├┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┤
│東│銚│拓│二│学│安│佐│千│流│流│市│八│成│千│銚│我│
│海│子│大│松│館│房│倉│葉│山│通│立│千│東│葉│子│孫│
│大│西│紅│沼│浦│ │ │商│東│経│柏│代│ │経│商｜子｜
│浦│ │陵│南│安│ │ │大│ │大│ │松│ │大│ │ │
│安│ │ │ │ │ │ │付│ │柏│ │陰│ │付│ │ │
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
│〃〃〃〃〃〃〃┌───────┴───────┐〃〃〃〃〃〃〃│
│〃〃〃┌───┴───┐〃〃〃〃〃〃〃┌───┴───┐〃〃〃│
│〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃│
│┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐│
├┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┤
│東│銚│拓│二│学│安│佐│千│流│流│市│八│成│千│銚│我│
│海│子│大│松│館│房│倉│葉│山│通│立│千│東│葉│子│孫│
│大│西│紅│沼│浦│ │ │商│東│経│柏│代│ │経│商｜子｜
│浦│ │陵│南│安│ │ │大│ │大│ │松│ │大│ │ │
│安│ │ │ │ │ │ │付│ │柏│ │陰│ │付│ │ │
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
926 ：デフォルトの名無しさん：03/09/23 14:30
あーごめん。なぜか「23個"くらい"しか」と読んでいた。
927 ：デフォルトの名無しさん：03/09/23 14:30
>>880 GoF本に23個のデザインパターンが紹介されているから、それが全てだって
思ってる奴がいるって話だろ（マジレス）
思ってる奴がいるって話だろ（マジレス）
928 ：テスト：03/09/23 14:30
┌──────────── 秋季千葉大会 ───────────┐
│〃〃〃〃〃〃〃┌───────┴───────┐〃〃〃〃〃〃〃│
│〃〃〃┌───┴───┐〃〃〃〃〃〃〃┌───┴───┐〃〃〃│
│〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃│
│┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐│
├┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┤
│東│銚│拓│二│学│安│佐│千│流│流│市│八│成│千│銚│我│
│海│子│大│松│館│房│倉│葉│山│通│立│千│東│葉│子│孫│
│大│西│紅│沼│浦│ │ │商│東│経│柏│代│ │経│商｜子｜
│浦│ │陵│南│安│ │ │大│ │大│ │松│ │大│ │ │
│安│ │ │ │ │ │ │付│ │柏│ │陰│ │付│ │ │
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
│〃〃〃〃〃〃〃┌───────┴───────┐〃〃〃〃〃〃〃│
│〃〃〃┌───┴───┐〃〃〃〃〃〃〃┌───┴───┐〃〃〃│
│〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃〃〃┌─┴─┐〃│
│┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐〃┌┴┐│
├┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┤
│東│銚│拓│二│学│安│佐│千│流│流│市│八│成│千│銚│我│
│海│子│大│松│館│房│倉│葉│山│通│立│千│東│葉│子│孫│
│大│西│紅│沼│浦│ │ │商│東│経│柏│代│ │経│商｜子｜
│浦│ │陵│南│安│ │ │大│ │大│ │松│ │大│ │ │
│安│ │ │ │ │ │ │付│ │柏│ │陰│ │付│ │ │
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
929 ：デフォルトの名無しさん：03/09/23 14:30
>>927
俺の読み間違いだった。ｽﾏｿ
俺の読み間違いだった。ｽﾏｿ
930 ：デフォルトの名無しさん：03/09/23 14:31
次スレいるか？
931 ：デフォルトの名無しさん：03/09/23 14:32
つまり８８０はGoFに16個あるいは、32個載ってると思ってたというオチですな。
932 ：デフォルトの名無しさん：03/09/23 14:32
>>915
１と自身以外では割り切れないということが何故半端なのか、むしろ自身以外で割り切れるほうが半端じゃないのかということをきちんと説明しないとこの手の輩にはわからないよ
１と自身以外では割り切れないということが何故半端なのか、むしろ自身以外で割り切れるほうが半端じゃないのかということをきちんと説明しないとこの手の輩にはわからないよ
933 ：デフォルトの名無しさん：03/09/23 14:33
934 ：デフォルトの名無しさん：03/09/23 14:33
もう、マジなのか天然なのかネタなのかわからなくなってきたね！
じゃなくて「二、三個くらいしかない」
936 ：デフォルトの名無しさん：03/09/23 14:35
素数だからってより基数の因数の倍数じゃないからだろ。
937 ：デフォルトの名無しさん：03/09/23 14:35
ま、「23」と見てGoFだと思わなかった>>880の負けですな。
938 ：デフォルトの名無しさん：03/09/23 14:36
プルグラマって数学音痴って本当だったんだね！
939 ：デフォルトの名無しさん：03/09/23 14:36
>>937
読んだことないから
読んだことないから
940 ：デフォルトの名無しさん：03/09/23 14:37
>>824
結城浩は2ちゃんねらー？
結城浩は2ちゃんねらー？
941 ：デフォルトの名無しさん：03/09/23 14:39
>>930
いらん。っていうかいりません。お願いですから立てないで下さい。
いらん。っていうかいりません。お願いですから立てないで下さい。
結城さんが2ちゃんねらーなのは有名だと思っていたが・・・。
943 ：デフォルトの名無しさん：03/09/23 14:40
944 ：デフォルトの名無しさん：03/09/23 14:41
>>942
期待通りのレスありがと。
期待通りのレスありがと。
945 ：デフォルトの名無しさん：03/09/23 14:43
>>943
もぉたてたよ
もぉたてたよ
946 ：デフォルトの名無しさん：03/09/23 14:45
947 ：デフォルトの名無しさん：03/09/23 15:12
-------------------
ここまで読み飛ばした
-------------------
ここまで読み飛ばした
-------------------
948 ：デフォルトの名無しさん：03/09/23 15:25
ネタはマ板でよろぴく。
949 ：デフォルトの名無しさん：03/09/23 15:28
(⌒Y⌒Y⌒)
／＼＿＿／
/ ／ ＼
/ ／ ⌒ ⌒ ＼
（⌒ / (･) (･) ｜
（ (6 つ ｜ ／￣￣￣
（ ｜ ＿＿＿ ｜ ＜ かあさん、
＼ ＼＿/ / ＼この味どうかしら？
＼＿＿＿_／ ＼＿＿＿＿
／＼＿＿／
/ ／ ＼
/ ／ ⌒ ⌒ ＼
（⌒ / (･) (･) ｜
（ (6 つ ｜ ／￣￣￣
（ ｜ ＿＿＿ ｜ ＜ かあさん、
＼ ＼＿/ / ＼この味どうかしら？
＼＿＿＿_／ ＼＿＿＿＿
950 ：デフォルトの名無しさん：03/09/23 15:33
こーひーうんまい
951 ：デフォルトの名無しさん：03/09/23 17:28
終了
952 ：デフォルトの名無しさん：03/09/23 17:33
953 ：デフォルトの名無しさん：03/09/23 18:01
なんだ、結局このスレも次のスレも前橋とかいう奴が建てたのか
954 ：デフォルトの名無しさん：03/09/23 18:39
>>837
熱狂的なJava信者はだいたいアンチC++
熱狂的なJava信者はだいたいアンチC++
955 ：デフォルトの名無しさん：03/09/23 18:41
おまいら、まだオブジェクト指向とか言ってんの？！
いいかげん卒業しろよ。能無しが。
956 ：デフォルトの名無しさん：03/09/23 20:00
>>954
んなこたーない。
本当のJava使いにはC++にもSmalltalkにもObjectiveCにもリスペクトがある。
最近VBやらCOBOLから移ってきた低層馬鹿Javaらーが
Javaさえちゃんと理解できてないのに理解したつもりになって、
理解できないC++を叩いてるだけ。
んなこたーない。
本当のJava使いにはC++にもSmalltalkにもObjectiveCにもリスペクトがある。
最近VBやらCOBOLから移ってきた低層馬鹿Javaらーが
Javaさえちゃんと理解できてないのに理解したつもりになって、
理解できないC++を叩いてるだけ。
957 ：デフォルトの名無しさん：03/09/23 22:15
リスペクトがあるリスペクトがあるリスペクトがあるリスペクトがあるリスペクトがある
リスペクトがあるリスペクトがあるリスペクトがあるリスペクトがあるリスペクトがある
リスペクトがあるリスペクトがあるリスペクトがあるリスペクトがあるリスペクトがある
リスペクトがあるリスペクトがあるリスペクトがあるリスペクトがあるリスペクトがある
リスペクトがあるリスペクトがあるリスペクトがあるリスペクトがあるリスペクトがある
リスペクトがあるリスペクトがあるリスペクトがあるリスペクトがあるリスペクトがある
リスペクトがあるリスペクトがあるリスペクトがあるリスペクトがあるリスペクトがある
リスペクトがあるリスペクトがあるリスペクトがあるリスペクトがあるリスペクトがある
リスペクトがあるリスペクトがあるリスペクトがあるリスペクトがあるリスペクトがある
リスペクトがあるリスペクトがあるリスペクトがあるリスペクトがあるリスペクトがある
リスペクトがあるリスペクトがあるリスペクトがあるリスペクトがあるリスペクトがある
958 ：デフォルトの名無しさん：03/09/23 22:34
頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い
頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い
頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い
頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い
頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い
頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い
頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い
頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い
頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い
頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い
頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い頭痛が痛い
959 ：デフォルトの名無しさん：03/09/23 23:07
>>955は、理解できていない。
960 ：デフォルトの名無しさん：03/09/23 23:11
>>897
朝起きたら、
まずwinnyで何が落ちてるか調べるパターン
会社のソースカツ丼は、
ケチャップなので、おばちゃんに
ケチャップかけないで、自分で、食卓にある普通のソースかけるから。
と言うパターン
帰ってきて、
すぐに寝たいと思った時は、すぐ寝て、
朝風呂に入るパターン
朝起きたら、
まずwinnyで何が落ちてるか調べるパターン
会社のソースカツ丼は、
ケチャップなので、おばちゃんに
ケチャップかけないで、自分で、食卓にある普通のソースかけるから。
と言うパターン
帰ってきて、
すぐに寝たいと思った時は、すぐ寝て、
朝風呂に入るパターン
961 ：デフォルトの名無しさん：03/09/23 23:14
カレーにソースかけて食べるパターン
962 ：デフォルトの名無しさん：03/09/23 23:15
いつものことですが
無駄に２ちゃんねるで時間をつぶしてしまっているパターン
無駄に２ちゃんねるで時間をつぶしてしまっているパターン
963 ：デフォルトの名無しさん：03/09/23 23:15
１０００まで、パターンでよろしくのパターン
964 ：デフォルトの名無しさん：03/09/23 23:16
やべっ
ここ、ム板だった。
マ板でやるべきだったと後悔するパターン
ここ、ム板だった。
マ板でやるべきだったと後悔するパターン
965 ：デフォルトの名無しさん：03/09/23 23:21
カップ焼きソバに
お湯とソースを一緒に入れてしまったパターン
お湯とソースを一緒に入れてしまったパターン
966 ：デフォルトの名無しさん：03/09/23 23:23
勢いないぞパターン
967 ：デフォルトの名無しさん：03/09/23 23:24
実は、俺しか居ないパターン
968 ：デフォルトの名無しさん：03/09/23 23:55
o
969 ：これがパターンだっ！：03/09/23 23:59
・名称:デジタル乞食
・概要:朝起きたら、まずwinnyで何が落ちてるか調べる
・利点:いろいろなものが手に入る
・欠点:明日タイーホされてもおかしくない諸刃の剣
・名称:小さな親切大きなお世話
・概要:会社のソースカツ丼は、ケチャップなので、おばちゃんにケチャップかけないで、自分で、食卓にある普通のソースかけるから。と言う
・利点:お好みのフレイバーが楽しめる
・欠点:おばちゃんによっては問答無用でラーメンに天ぷらをつっこんで「サービスよ！」とのたまうツワモノもいる。
・名称:早起きはチャンリンシャンの得
・概要:帰ってきて、すぐに寝たいと思った時は、すぐ寝て、朝風呂に入る
・利点:朝から気分よく出かけられる。
・欠点:寝坊すると汗まみれで行かねばならず最悪
・概要:朝起きたら、まずwinnyで何が落ちてるか調べる
・利点:いろいろなものが手に入る
・欠点:明日タイーホされてもおかしくない諸刃の剣
・名称:小さな親切大きなお世話
・概要:会社のソースカツ丼は、ケチャップなので、おばちゃんにケチャップかけないで、自分で、食卓にある普通のソースかけるから。と言う
・利点:お好みのフレイバーが楽しめる
・欠点:おばちゃんによっては問答無用でラーメンに天ぷらをつっこんで「サービスよ！」とのたまうツワモノもいる。
・名称:早起きはチャンリンシャンの得
・概要:帰ってきて、すぐに寝たいと思った時は、すぐ寝て、朝風呂に入る
・利点:朝から気分よく出かけられる。
・欠点:寝坊すると汗まみれで行かねばならず最悪
970 ：デフォルトの名無しさん：03/09/24 00:05
#include <stdio.h>
int main(void)
{
puts("hello, world");
return 0;
}
int main(void)
{
puts("hello, world");
return 0;
}
971 ：デフォルトの名無しさん：03/09/24 00:36
スレが終わる前に一つだけ教えてくれ。
オブジェクト指向がわかった、ってどういう状態なんだ?
オブジェクト指向がわかった、ってどういう状態なんだ?
972 ：デフォルトの名無しさん：03/09/24 00:46
悟りの状態かな。
数学がわかった。
漢字がわかった。
料理がわかった。
運動がわかった。みたいな。
言葉にはできないある種の神秘的な状態。
敢えて言葉にすれば「そこにあるエッセンス」がわかったとでも言うのか。
数学がわかった。
漢字がわかった。
料理がわかった。
運動がわかった。みたいな。
言葉にはできないある種の神秘的な状態。
敢えて言葉にすれば「そこにあるエッセンス」がわかったとでも言うのか。
973 ：デフォルトの名無しさん：03/09/24 00:48
自転車に乗れない人に「なぜ乗れるのか？」と聞かれても
それを答えるのは難しい。
それを答えるのは難しい。
974 ：デフォルトの名無しさん：03/09/24 00:50
水面を歩けない人に「なぜ歩けるのか？」と聞かれても
それに答えるのは難しい。
ちなみに、足が沈むより前に次の足を出すからなのだが。
それに答えるのは難しい。
ちなみに、足が沈むより前に次の足を出すからなのだが。
975 ：デフォルトの名無しさん：03/09/24 00:53
だからある程度の期間はモヤモヤが残るような事はあってもしかたないんよ。
潜在意識の中にそれらがずっと蓄積されていって、ある時それらが結びついて
表層意識まで浮上してきた時、「あっ！そか。」って。そういう状態。
潜在意識の中にそれらがずっと蓄積されていって、ある時それらが結びついて
表層意識まで浮上してきた時、「あっ！そか。」って。そういう状態。
976 ：デフォルトの名無しさん：03/09/24 00:55
>>974
バシリスク。
バシリスク。
977 ：デフォルトの名無しさん：03/09/24 01:07
978 ：デフォルトの名無しさん：03/09/24 01:08
たとえば、語学留学で海外で生活してて
3ヶ月目に急に話が聞き取れるようになるらしい。
確かにオブジェクト指向が分かった、っていう感じもあるけど
そこまで極端なブレイクスルーがあるか？
3ヶ月目に急に話が聞き取れるようになるらしい。
確かにオブジェクト指向が分かった、っていう感じもあるけど
そこまで極端なブレイクスルーがあるか？
979 ：デフォルトの名無しさん：03/09/24 01:10
道端を歩いていて、
そこに見えるモノの関連性を
全てクラス図で脳内に描けるとか。。。。
そんな奴いないかｗ
そこに見えるモノの関連性を
全てクラス図で脳内に描けるとか。。。。
そんな奴いないかｗ
980 ：デフォルトの名無しさん：03/09/24 01:13
俺は世界が全て0と1だけで構成されていたのをついこの間確信したよ。
981 ：デフォルトの名無しさん：03/09/24 01:15
俺は急激なのあったけど。
GoFのパターンを一個ずつ勉強してた時かな。
キターって叫びたかった。
こういう時どうするのか、何故こうなってるのか、そういうのが
突然サックリ理解できるようになった。
勘が働くようになったとでも言うのか？
GoFのパターンを一個ずつ勉強してた時かな。
キターって叫びたかった。
こういう時どうするのか、何故こうなってるのか、そういうのが
突然サックリ理解できるようになった。
勘が働くようになったとでも言うのか？
982 ：デフォルトの名無しさん：03/09/24 01:17
スレが終わる前に２つだけ教えてくれ。
次スレを立てたのは本当に前橋君なのか?
そして結城先生は本当にこんな糞スレ読んでるか？
次スレを立てたのは本当に前橋君なのか?
そして結城先生は本当にこんな糞スレ読んでるか？
983 ：デフォルトの名無しさん：03/09/24 01:21
クラス間の構成を考える時は客観視、クラスの実装を考える時は
主観的に考えるんだ。
主観的に考えるんだ。
984 ：デフォルトの名無しさん：03/09/24 01:23
>982
結城先生は2chに目を通してはいると思うけど。。
特に、「どうやって説明するか」ということには興味があるだろうし。
スレを立てたのは前橋氏ではないでしょｗ
結城先生は2chに目を通してはいると思うけど。。
特に、「どうやって説明するか」ということには興味があるだろうし。
スレを立てたのは前橋氏ではないでしょｗ
985 ：デフォルトの名無しさん：03/09/24 01:24
あんまり進んでないので再度アナウンスさせていただきます。
次スレです。このスレの哀れな次スレです。
どうぞ、皆様よろしくお願いします。
オブジェクト指向の説明について 2ループ目
http://pc2.2ch.net/test/read.cgi/tech/1064295567/l50
次スレです。このスレの哀れな次スレです。
どうぞ、皆様よろしくお願いします。
オブジェクト指向の説明について 2ループ目
http://pc2.2ch.net/test/read.cgi/tech/1064295567/l50
986 ：デフォルトの名無しさん：03/09/24 01:25
おれは自分の中にある神がおれ自身なんだってついこの間悟ったよ。
俺はOOPな言語でクラス設計をしてコードを書くことはそこそこできるつもりだが、
オブジェクト指向そのものがわかっているかどうかは怪しい。
別に今までブレークスルーもなかった。
ちょっと感心したところは、関連が継承される所と、
多態でswitch-case相当をクラス設計に持ち込める所くらいだ。
なので、ちょっとどんな感じなのかを聞いてみたかった。
>>976
また一つ勉強になったよ。役には立ちそうに無いが。
オブジェクト指向そのものがわかっているかどうかは怪しい。
別に今までブレークスルーもなかった。
ちょっと感心したところは、関連が継承される所と、
多態でswitch-case相当をクラス設計に持ち込める所くらいだ。
なので、ちょっとどんな感じなのかを聞いてみたかった。
>>976
また一つ勉強になったよ。役には立ちそうに無いが。
988 ：デフォルトの名無しさん：03/09/24 01:37
こうしてまた一つ、トリビアが生まれた。
989 ：デフォルトの名無しさん：03/09/24 01:45
何がトリビア？バジリスクが水面を走れる理由？
990 ：デフォルトの名無しさん：03/09/24 01:58
じゃ、1000取り合戦いってみる？
991 ：デフォルトの名無しさん：03/09/24 02:38
ねぇおにいちゃん。
一緒に1000取り合戦、しよ♪
一緒に1000取り合戦、しよ♪
992 ：デフォルトの名無しさん：03/09/24 02:43
1000を取る為のデザインパターンは、何が必要ですか？
993 ：デフォルトの名無しさん：03/09/24 03:02
複数の本を読んで混乱するもう一つの要因が分かった。
みんな(著者によって)オブジェクト指向の捕らえ方(見方)が違うからなんだね。
ああ、エウレカと叫ぶ日は来るのかなぁ。
みんな(著者によって)オブジェクト指向の捕らえ方(見方)が違うからなんだね。
ああ、エウレカと叫ぶ日は来るのかなぁ。
994 ：デフォルトの名無しさん：03/09/24 03:19
一つの傾向として本を読む時に情報を丸のみする事を「本から学ぶ」って
タイプより「本を材料に考える」ってタイプの方が理解が早い。
前者は複数の本を読むと混乱する。後者は複数の本を読むと自分なりに
統合と差分を取ろうとする。
ま、なんでもそうだが。
タイプより「本を材料に考える」ってタイプの方が理解が早い。
前者は複数の本を読むと混乱する。後者は複数の本を読むと自分なりに
統合と差分を取ろうとする。
ま、なんでもそうだが。
995 ：デフォルトの名無しさん：03/09/24 05:26
なぜみんな1000を取ろうとしない？
996 ：デフォルトの名無しさん：03/09/24 05:34
996
997 ：デフォルトの名無しさん：03/09/24 07:20
997
998 ：デフォルトの名無しさん：03/09/24 07:21
998
999
1000 ：デフォルトの名無しさん：03/09/24 07:22
では、いただきます。
1000
1000
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。