5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

オブジェクト指向の説明について

1 :デフォルトの名無しさん:03/05/19 20:39
自分も最初その概念がわかるまで少し時間がかかったと思う。
しかし振り返って見ると説明の仕方が悪いとしか思えない。
誰が最初に言い出したのか知らないが、プログラミングの実態からかけ離れた概念の事ばかり説明する。
新しい概念を学ぶ、教える際に最も効果的なのは、身近な具体例を見ることである。
これを取り違えたのか、プログラミングの概念を説明するのに、魚とかりんごとかロボットとか名詞動詞とか、そんな事ばかり書いてある。
大方の入門者はそんな事よりももっとコンピュータの振る舞いに近い例を求めているはずだ。
こういうのを見るたびに思うことは、このような日常生活の例を出してプログラミングの概念を説明するのは、説明するものの自己満足なのではないか?ということ。
CをベースにしてC++に移行(今は少なくなったのかもしれないが)しようとする人間にとってこういう妙な概念化は非常にまどろっこしい、時には馬鹿にされている感じさえ受ける。
続く

2 :デフォルトの名無しさん:03/05/19 20:40
続かせないよ!

3 :デフォルトの名無しさん:03/05/19 20:44
>>1

単に読んだものが君のレベルにあわなかった
だけ。あうものをさがしなさい。

4 :デフォルトの名無しさん:03/05/19 20:45

いや、興味深いテーマだ。続けてくれ〜。

5 :デフォルトの名無しさん:03/05/19 20:46
自分が思いついた説明をすると、

デスクトップにあるアイコンが良い例だと思う。
アイコンはオブジェクトのインスタンスである。
メモ帳のアイコンはテキストという内容を含んでおり、動作は右クリックすると確認操作できる。
デスクトップで右クリックすると、ある程度のオブジェクトの雛形、ショートカット、フォルダー、テキストファイルなど、が用意されている。
これに名前をつけて新規作成するのがオブジェクトのインスタンス化に他ならない。

オブジェクト指向以前の操作では、例えばWORDのファイルを開こうとしたときには、WORDを立ち上げ(関数、手続き)そこからファイルを指示選択するという操作だったのが、
オブジェクト指向、アイコンの操作ではそのWORDファイルをクリックすると、自動的にWORDが立ち上がる。
これがよく巷の説明にある、オブジェクト自身が己の振る舞いを知っているということだ。
エクセルファイルはエクセルをたちあげるし、右クリックから別のメソッドを選ぶこともできる。

こういうのをイルカは泳ぐが、車は走るとか書かれるとハア?ってなっちゃうと思うんだけどね。

6 :デフォルトの名無しさん:03/05/19 20:48
>>3
レベルの高い教師ほど、初心者にわかりやすい説明をする。
難しい哲学書ほど、大して内容はない。

7 :デフォルトの名無しさん:03/05/19 20:51
既存スレでどうぞ。

【OO?】オブジェクトオリエンテッド総合【非OO?】
http://pc2.2ch.net/test/read.cgi/tech/1041658161/

8 :1,5,6:03/05/19 20:53
実際にコーディングして思うことは、
どれくらいの人間がその入門書に書いてある、りんごとかフルーツの継承とかそういう卑近な例を頭に思い浮かべながらやってんだろう?
ということ。
確かに大規模なプロジェクトでモデリングする際はそういうアーティスティックな例みたいなものがパワーを発揮するのかもしれないけど、
普通は、そんな日常生活の動詞みたいな事を思い浮かべながらクラスの設計とかしない。
というかそんな人いる?

9 :デフォルトの名無しさん:03/05/19 20:55
>>7
まあ自治厨も2ちゃんのメソッドというかイベントみたいなもんだな。

10 ::03/05/19 21:03
継承というのもアイコンを見ればわかりやすい、自分が見る限りすべてのアイコンにはプロパティがある。
これはすべての親で継承されていると思う。あと切り取り、コピー、削除、ショートカットの作成、開く、アイコンによっていろいろ継承の仕方が異なる。

11 :デフォルトの名無しさん:03/05/19 21:04
>>9
既存スレの検索をしてなさそうなスレに対して、
誘導を一回書く以外はしないけどね。


12 :デフォルトの名無しさん:03/05/19 21:10
このスレ立て人に禿同。
なんにしろ比喩的な概念や理論というのは、結果や成果の後にくっつけてくる物なんだから
それが分かりやすい説明だと思えるのは実際にそれを実践した事がある人だけであって
何の実践も無いビギナーの人には地に足の付かない分かりにくいものだと俺も思うよ。


13 :動画直リン:03/05/19 21:11
http://homepage.mac.com/hitomi18/

14 :デフォルトの名無しさん:03/05/19 21:11
>>11
でも、まあ、NETとかC#とか全部のスレに対して仕事をしているんだから、たいそうなメソッドだよな。
9割方のスレにそのイベント発生してるんじゃないのか?

15 :デフォルトの名無しさん:03/05/19 21:13
>>1 世の中にはさ、デスクトップの事象とそれのプログラミング上の
メタファーが完全に一致するフレームワークは既に存在するけど、
それでプログラミングの理解が進むかといったら、そういうわけではない
ってのが俺の経験。OS/2のWPSとかね。

16 :1:03/05/19 21:14
そうだと思うよ。
抽象的な理論まで昇華させるのは、その概念に十分慣れてからで良い。
そもそも、君の言うとおり、OOの創始者もそんなイルカとかロボットの動詞名詞とかから始めたわけがない、と俺は思っている。
それを入門と謳うものが初心者にありがたそうに、その昇華した後の概念を説明する。

17 :1:03/05/19 21:15
上は>>12に対してのレスね。



18 :デフォルトの名無しさん:03/05/19 21:18
じぶんはMFC使うようになってはじめてOOが多少理解できた。
(ここでスーパークラスにキャストすればいいとか)

やっぱり実際にクラスライブラリに触れてみるのがいいんじゃない?




19 :デフォルトの名無しさん:03/05/19 21:18
そうとう噛み砕いたあげく 「イルカとかロボットの動詞名詞」 になったわけで。
OMT や OOSE 読んで OO がすぐわかるなら、イルカでも分かるだろう。

20 :1:03/05/19 21:19
>>18
その際に、まず動詞と名詞を抽出するとか、りんごの例は理解の助けになったかい?

21 :1:03/05/19 21:23
CとC++の例で比較しながら、どんどんやっていけばいいと思う。具体的に。
それを第一章みたいなのが全部抽象的な概念で、わかったつもりになったか、よくわからないまま、第2章に進むというのがパターン。
たいがいの入門書とかWEB上の入門ページ見ればわかると思うけどね。

22 :デフォルトの名無しさん:03/05/19 21:29
独習C++で勉強してるんだけどクラスの説明でフルーツがでてきたな。

23 :1:03/05/19 21:31
>>22
でどうよ?

24 :デフォルトの名無しさん:03/05/19 21:36
>>23
どうこう言えるレベルまでまだ進んでいないから何ともいえない。

25 :18:03/05/19 21:45
そういや全然役に立たなかったね(藁

CFrame > CDialog が継承だとか OnPaint()をオーバーライドするとか
言われたほうがよほどわかりやすいとおもう。

26 :デフォルトの名無しさん:03/05/20 12:59
[クラスの継承]

class ギコ猫  
      ∧∧ ・逝ってよし
〜′ ̄ ̄( ゚Д゚) ・ゴルァ
 UU ̄ ̄ U U

 ↓

class フサギコ
  ,,,,,,,,,,,,,,,∧,,∧ ・逝ってよし
〜′,,,,,,,,,,ミ,,゚Д゚彡・ゴルァ
 UU"""" U U   ・フサフサだぞ


27 :デフォルトの名無しさん:03/05/20 23:47
>>26
ドラクエの転職みたいなもん?

28 :デフォルトの名無しさん:03/05/21 10:00
フサギコはギコ猫のサブクラスだから、
フサギコクラスを作るときに「フサフサだぞ」メソッドを記述すれば、
ギコ猫から継承したメソッド「逝ってよし」「ゴルァ」が存在し、
フサギコ特有のメソッド「フサフサだぞ」が存在するクラスになる。

で、よろしいんだろうか。

29 :sage:03/05/22 11:13
,

30 :デフォルトの名無しさん:03/05/22 14:10
俺はイルカとかロボットで十分分かりやすかったけど
分からない人も多いんだねぇ

31 :デフォルトの名無しさん:03/05/22 14:11
>>1は説明のしかたを疑う前に自分の頭を疑ったほうが良いよ

32 :デフォルトの名無しさん:03/05/22 14:17
>>9
2chのスレが立ってから終わるまでを
オブジェクト指向風に考えると面白いな

33 :デフォルトの名無しさん:03/05/22 16:05
>>30
わからないのはこのスレの1だけだから安心しれ
わかりにくいと思ったら思ったやつがもっとわかりやすい説明をしてそれが広まるだろ。
そうなってないのはすでに十分わかりやすいからだ。

34 :デフォルトの名無しさん:03/05/22 22:53
とっかかりの説明として、
関数呼び出しに、主語が要る、じゃダメ?

35 ::03/05/22 23:04
>>30,>>33

俺はあの説明でもわかったぜ!と自慢するスレでも、あの説明でわからないのは馬鹿!と見下すスレでもない。
正直、お前らがすんなり、あのりんごの説明でわかったとは俺は信じないし、仮にわかったとしても別のベースというかとっかかりを使ったに決まっている。自分でそれ気がついていないだけ。


36 :デフォルトの名無しさん:03/05/22 23:12
>仮にわかったとしても別のベースというかとっかかりを使ったに決まっている

なんつーか。例えばどんな 「別のベースというかとっかかり」 があるの?
それを議論すべきじゃないのかな。

37 ::03/05/22 23:14
>>31もだ。
本質を理解してこのスレに書き込んでいるのか?

ああいう一連の例は、概念を具体化して説明しているのではなくて、むしろいたずらに抽象化している。
プログラミングの経験が十分にあり、ある種の感のようなものが働く人間はイルカが泳ぐと書かれていても、何を言わんとしているのか脳内で別の具体化が自動的にできるので問題がないんだろうね、きっと。
しかし、その他の人間にとっては、けしてわかり易い具体例ではない。

俺はわかったよ。というレスではなくて、反論があるならこの論旨にそってして欲しいね。
そうでないなら、へえ、それは良かったねとしか言えないな。

38 :デフォルトの名無しさん:03/05/22 23:22
>>1はイメージをつかむ能力が低いんだよ

39 ::03/05/22 23:26
いいか?「1」のことじゃなくて、「初心者に対する説明の仕方」に関する話題なんだよ。
さんざんもう書いているのにわからないかい?
>>38は日本語読解能力が低いね。

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
現実世界での具体化が、プログラミングでの抽象化につながってしまってる点が問題なんじゃない?

犬もイルカも哺乳類、と言うだけじゃそりゃおちこぼれも出てくるだろうさ。
だからそれの隣に配列もリストもコンテナ、ってゆー例を書いて、現実世界での具体的な例とプログラミングでの具体的な例を対比させれば良いんで無いか?

44 :山崎渉:03/05/28 12:51
     ∧_∧
ピュ.ー (  ^^ ) <これからも僕を応援して下さいね(^^)。
  =〔~∪ ̄ ̄〕
  = ◎――◎                      山崎渉

45 :デフォルトの名無しさん:03/05/31 02:13
============終了============

46 :デフォルトの名無しさん:03/06/20 01:23
名スレの予感

47 :デフォルトの名無しさん:03/06/20 04:51
うーむ。結局、オブジェクト指向の嬉しさを知るためには、
そうではないコードの害を知ることが大切な気がする。
なんとなくは理解できても、じゃあ、なんでそんなことしなければならないの?
ってのまでは理解しがたいし。
初等者がプログラムの勉強で使う程度のプログラムなら
手続き的に書くのが一番早くて、すんなりはまる場合が多いしね。

たくさんコード書いていたら、自然とオブジェクト指向なコードを作ろうとしていたし。
それはC言語のような手続き言語でも同様に。

余事象を感じなきゃ、抽象化の概念とか分かり辛いよね。

48 :デフォルトの名無しさん:03/06/20 09:06
りんごの例は理解を助けるものではない。
その意味が分かったときこそ理解できたという目印。

49 :デフォルトの名無しさん:03/06/20 12:34
まずは「ifやswitchは、多いと無様」という観念を育てるべき。

50 :_:03/06/20 12:35
http://homepage.mac.com/hiroyuki44/

51 :デフォルトの名無しさん:03/06/20 13:13
何故、ifやswitchが多いと無様 なんだろうね。
おっしゃっているのは、
 ポリモルフィズムを使った処理の切り分けの方が、
 いちいち型をチェックするif文やswitch文よりも、
 コードの局所性が高く、メンテや拡張が容易だ
ってな文脈だと思うけど。

それは結局実利ベースの価値判断であって、
スマート/無様 などという曖昧な美的判断を
信仰させる必要がほんとにあるのかな?

そりゃ、たしかに美的判断の方が、直感的でわかり易いけど、
んなもんに全面的に頼ったら論理的誤りを排除しにくいし、
価値が逆転する局面では、迷信を信じ込むイタイ人、
になっちゃうんじゃないのかな?

52 :書き直し:03/06/20 13:21
一体全体何故、ifやswitchが多いと無様 なんだろうね。
おっしゃっているのは、
「ポリモルフィズムを使った処理の切り分けの方が、
 いちいち型をチェックするif文やswitch文よりも、
 コードの局所性が高く、メンテや拡張が容易だ」
ってな文脈だろうと勝手に思うけど。

ポリモルフィズムの件は、実利ベースの価値判断であって、
スマート/無様 などという曖昧な美的判断/信仰とは違うと思うよ。

そりゃ、説明が厄介な事は、全て美的判断で説明しちまえれば楽だろーけど、
んなもんに頼っちまったら、論理的誤りを排除できなくなるし、
価値が逆転するよな局面では、「無様な」馬脚を現す結果になるよ。



53 :デフォルトの名無しさん:03/06/20 13:25
俺は簡単なアセンブラしかやったことがないから
オブジェクト指向についてはよくわからない。

とりあえず、ここで>>1の書いた文章読んでもオブジェクト指向に
ついて全然理解が進んでいない。
>>1は既に解っている人に向かって同意を求める為に書いた文だから、
初心者向きで無いのは当然だと思う。
もし元気があったら、初心者にも解るよう書いてくれないか?
2CHでは図が入らないからどこかのHPでもいい。
何の説明も無しに「オブジェクト」「インスタンス」「メソッド」
などという用語が出ないような本当の初心者向きの説明。
それが解りやすければ>>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 ); // ★1
a = gen_A2( 20 );
a.func( &a ); // ★2
{
A b = a;
b.func( &b ); // ★3
}
return 0;
}

★1と★2を見比べてくれ、まったく同じプログラムなのに出力結果は違う。新しく自分でgen_A3()を作れば、さらに違う動作をさせることも出来る。
★3も見てほしい、bにaを代入して関数を呼ぶと、★2と同じ結果が得られるんだ。もしデータと手続きを二元・三元管理していたら、手間が増えちゃって大変さ。

データと手続きをまとめた型Aをクラスといい、実際にその情報が格納されているaやbをインスタンス(実体)といい、データを処理するための手続きであるfuncをメソッド(手段)、aを初期化するために使ったgen_A1のような手続きをコンストラクタ(建築家)と呼んでる。
★1と★2のように、呼び出すコンストラクタによって振る舞いが代わることを利用して継承(すでにある機能を利用しつつさらに拡張したり異なった処理をすること)を行うんだ。場所が無いから継承については誰かに譲るよ。

56 :デフォルトの名無しさん:03/06/20 14:57
それじゃダメだろ。実装のテクニカルしかないじゃん。
機能のカプセル化とか、インタフェースとか、そういうことを理解しなくちゃオブジェクト指向とはいえない。

57 :デフォルトの名無しさん:03/06/20 15:12
>>56
一レスでそこまで出来ないよ

58 :デフォルトの名無しさん:03/06/21 01:35
>>55
ちょっと、そのソースを簡単に実行できる環境を探し中w
今C勉強始めたばかりだけどC++のソースって大分違う。
ttp://homepage1.nifty.com/kentake/ のC++版みたいな
やつないですかね。

>>55で、とりあえず解ったこと。
「データと、そのデータを処理する手続きを一緒くたにして管理すると
なんか凄いメリットがあるらしいぞ」w

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語で言う、構造体や型の概念に近い)と呼ばれ、
実際にメモリ上に作られたものをインスタンスと呼ぶというわけだ。

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のメソッドを書くことになりはしないだろうか。
いずれ横着者が現われて、バグ入りのメソッドをコピー&ペーストしはじめるのでは?
しかし安心して欲しい。こういうときのためにこそ、オブジェクト指向の提供する技術、
継承が利用できるのだ。


63 :デフォルトの名無しさん:03/06/21 07:24
初めて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とは違う挙動にすることもできる。(これはメソッドのオーバーライドという。)

結局、継承は単なる手抜き手法であるとも言える。しかし、アプリケーション全体に影響を及ぼす
超重要な手抜き手法であるので、実際には今回のように安易に使うべきではない。
しかし、同じ動作をするメソッドを別々のクラスに書いているときには
設計がおかしいことがよくあるので、継承のことを思い出して欲しい。

66 :デフォルトの名無しさん:03/06/21 12:12
>>63
俺だってそうだよ。
このスレは、困惑する人がいることに対する問題提起だろ。

ただまぁ、結局はオブジェクト指向を学ぶ以前に何をやってきたかが一番大きいと思うがな。

67 :デフォルトの名無しさん:03/06/21 13:03
オブジェクト指向が理解できないってのは、プログラミングセンスが無いってことだよ。

68 :デフォルトの名無しさん:03/06/21 13:26
オブジェクト指向の是非はともかく、
プログラミング技術として広く使われているのだから、
理解しなきゃ食ってけないわな。

69 :デフォルトの名無しさん:03/06/21 14:39
>>68
本末転倒なんだな、これが。

C言語の構造化プログラミングで試行錯誤した人が、オブジェクト指向という新しいパラダイムを勉強して、より良い設計・実装を身に付けていくのが本道。
それなのに今は必要だからと言って、構造化プログラミングもままならない人までも、いきなりオブジェクト指向しなくちゃならなくなる。
プログラムがシンプルだった時代を経ずに、いきなり複雑なライブラリを与えられてしまう新人さん達も、ある意味運が悪いといえる。
まぁ、がんがってくれとしかいえんわな。

70 :デフォルトの名無しさん:03/06/21 15:47
>>69
非OOを知らない人はOOを当たり前に吸収するからそれほど不幸でも無いよ
非OOからOOに乗り移れない人たちよりは幸せ

71 :デフォルトの名無しさん:03/06/21 16:46
>>67
俺はオブジェクト指向をまだ理解してない(つーかC言語を
ちょうど始めたばっかり)から一般的な事しか言えないが。

外語大の学生に「何故英語が得意になったか?」とアンケートを
取ると「中学の時の先生が良かった」という答えが多かったそうだ。
学習者に勉強のおもしろさを気づかせる事も含め、教え方やテキスト
は非常に重要だと思う。俺は学習者の才能やセンスが必要なほどの勉強は
ごく一部だと考えてるよ。
例えば1冊に色々詰め込まなくてはいけなくなったからといって
「これでハローワールドが表示されましたね、さあ次はデータベースを
作ってみましょう」みたいな無茶な参考書は大嫌いだw

72 :デフォルトの名無しさん:03/06/21 19:23
ははは
高校の数学の先生がそんなんだったなあ。
おかげで数学の成績がた落ち。

73 :デフォルトの名無しさん:03/06/22 13:31
例えば
FlexGridとTextBoxを貼り付けたActiveXコントロールを作るよね
FlexGridのカーソル位置のあたいをTextBoxに表示するだけ。
そんな新しいコントロールを作った場合、
FlexGridとTextBoxを多重継承したっていうのか?
Javaでは多重継承できないって言うけど、こんなことも
できないんか?


74 :デフォルトの名無しさん:03/06/22 14:31
それは継承ではなく、オブジェクトコンポジションという。

75 :デフォルトの名無しさん:03/06/22 15:52
>>55
>>★1と★2を見比べてくれ、まったく同じプログラムなのに
>>出力結果は違う。新しく自分でgen_A3()を作れば、さらに違う動作をさせることも出来る。

なんだか自慢気だが、それは駄目なところなんだって。

同じ記述をしたのに違う動作をするということは、そこの記述を
見ただけでは動作がわからない、ということ。
読む人にとっては困るだけ。

基本的に、カプセル化はデータ抽象を実現するためにある。
プログラムを読む人を戸惑わせるような使い方をするべきでない。


76 :デフォルトの名無しさん:03/06/22 16:16
動作は違っているだろうが、概念上同じ仕事をさせることができる
つーのがミソなわけだが。

77 :デフォルトの名無しさん:03/07/08 22:16

オブジェクト指向は創始されてからすでに30年経ち、もはや古臭い感は
否めない。構造化→OOP→に続くプログラミング手法第3の変革が必要だ。
今こそをそれを提唱しよう。その名は


78 :デフォルトの名無しさん:03/07/08 22:41
ビッグオー

79 :デフォルトの名無しさん:03/07/08 22:44
サイテイダワ

80 :デフォルトの名無しさん:03/07/08 22:51
>>70
69では無いが、この間いっしょに仕事をした人間にトンデモないのがいたので、ちょっと
OOPから始めてできるつもりになっている奴のプログラムは、
とんでもないスパゲティープログラムを作る事がある、
そのスパゲティーぶりたるや、構造化プログラミング言語のスパゲッティーの比ではないよ。
goto 文の嵐は気張れば読めるがOOPのスパゲティーは破滅的に読めなくなる。
意味無く散乱したオブジェクトは洒落にならないです。
OOなら万能なんて絶対考えないほうがいい、むしろ危険度は高いと思ったほうがいい。

81 :デフォルトの名無しさん:03/07/08 22:55
>>80
そのトンデモ構造がどんな構造なのか、正直興味あるな。
というか、具体的にどうなっていたのかがわからんので説得力ないよ。

82 :デフォルトの名無しさん:03/07/08 22:55
設計段階でレビューとかしないんだろうか?
設計をコードに落としやすいのも利点だと思うが

83 :デフォルトの名無しさん:03/07/08 22:59
>>65
そんな例で継承するのは馬鹿がすることですよ。
メソッドシグネチャを追加するくらいは我慢して、コンポジッションに
するのが基本です。

継承が本当の本当に必要なのは、多態処理を整理して記述したい時だけですお。


84 :r:03/07/08 23:12
たぶんVisitorパターンを知らないで、Visitorパターンなコードを読むと
「きったねーなぁ」とか思っちゃうと思う。
AbstractFactoryとかも。

85 :デフォルトの名無しさん:03/07/08 23:15
>>81
最近増えているんですよ
オブジェクト指向言語は使えてもデザパタが理解できないで信じられないような物を作る奴が・・・・
構造化プログラミングができるなら、まぁ変なクセはあっても読めるんだけどね、
最初からOOPをしている奴の中には、見た瞬間に絶叫したくなるようなプログラムを書く人間がいるんですよ。

86 :r:03/07/08 23:23
>85
それは、「最初からOOPだから」変なコードを書いてるんじゃなくて
単に「経験が少ないから」変なコードになっちゃったんじゃないかなぁ。
とか思う。


87 :デフォルトの名無しさん:03/07/08 23:26
>>86
まぁ経験が足りないといえば、その通りで以上終了なんですが、
破滅的になる度合いがね・・・・
OOPの方が激しいことは確か。

88 :デフォルトの名無しさん:03/07/08 23:29
いきなりOOPとか言われても教えるほうも困るよな。
絶対main関数だけのプログラミングから始まるんだろ?
それってOOPか?

89 :r:03/07/08 23:31
>>87
そうなんだー。でも、この板の「辞めようと思ったソース」スレでも
オブジェクト指向を駆使した感じのコードは見たことないからなぁ。あんまりピンとこない。

90 :r:03/07/08 23:32
>>88
エントリポイントがどこにあろうが、
それはOOPだと思うけど。

91 :デフォルトの名無しさん:03/07/08 23:33
設計段階で、雑にでいいからクラス図書いて、そのとおりつくるところから
はじめれば、多少の試行錯誤は発生するにしても、あんまりトンデモな結果
にはならないとおもうけどな。

OOPなんて大げさに言うけど、実装レベルまで落とし込んで見れば、結局
のところ「分割した処理ロジックを、それぞれどこに書くか」ということ
でしかないような気がする今日この頃。最近の賢いIDEのおかげで、メソ
ッドの抽出、移動もクラスの分割、統合もすごいラクチンにできるからねえ。
リファクタリング支援マンセー。

92 :デフォルトの名無しさん:03/07/08 23:35
インターフェース境界の設定と
責任の所在の明確化

これが済めばあとは大体なすがままっちゅう感じかなあ

93 :デフォルトの名無しさん:03/07/08 23:41
>>91
俺もそう思う。
だからあんまり>>80みたいな事にはなりにくいと思うんだが・・・

いきなり設計もせず「作れ」とか言ってるのかな

94 :r:03/07/08 23:41
>>91
メソッドの抽出って、IDEが支援してくれるのですか?
例えば、いろんなトコから"そっくりなコード"を見つけてくれたりとかですか?
だったらすげーな。欲しい。名前教えて〜くだされぇ

>>92
インタフェース協会って何ぞぇ?IEEEみたいの?



95 :デフォルトの名無しさん:03/07/08 23:49
>>91
そういう人が設計するならいいが「デザインパターンの単純そうな質問」の734みたいな事になると大変だけどな。


96 :デフォルトの名無しさん:03/07/09 00:13
IDEは便利だけど弊害にもなると思うな。
ウィザードでclass宣言もメンバの雛型も自動生成されちゃうと、コードを倫理的に配置する能力が培われない。
OOPの話じゃないかもしれないけど、やっぱり手で全部書いてみる経験は大事だよ。

97 :デフォルトの名無しさん:03/07/09 23:55
あーみーどーにー蟲こーない

98 :デフォルトの名無しさん:03/07/10 16:29
>>87
それはある。
以前どっかで公開されてたDirectXのラッパーライブラリのソースがまさに破滅的だった。
あっち行ってこっち行って、処理対象がthisではなくてパラメータだったりする。(Visitorに非ず)
俺は自分でOO信者だと思ってるけど、今まで非OOであれほどひどいものは見たこと無いからな・・・。

99 :デフォルトの名無しさん:03/07/11 08:20
オブジェクト指向とコンポーネント指向の違いについて教えてください

100 :デフォルトの名無しさん:03/07/11 08:22
コンポーネントは完結する。
オブジェクトはやりとりする。

101 :デフォルトの名無しさん:03/07/11 10:14
コンポーネント指向は、オブジェクト指向の延長でしょう。

関連のあるデータと振る舞いをカプセル化したのが、
オブジェクト指向で、
関連のあるオブジェクトを1つにまとめて(コンポーネント化)
再利用していくのが、コンポーネント指向。

102 :デフォルトの名無しさん:03/07/11 11:20
コンポーネント指向がオブジェクト指向の延長?むしろ逆じゃない?
構造体→抽象データ型→オブジェクト指向という流れの途中で、
「オブジェクト指向まで行かなくてもいいじゃん」と言って
抽象データ型から枝分かれしたのがコンポーネント指向だと思う。

時系列に並べて考えるなら延長と見れなくも無いけど、概念的には退化してる。
ま、退化したから悪いって訳ではなくて、「不必要に行き過ぎたから戻った」
ということではないかな。

103 :デフォルトの名無しさん:03/07/11 14:16
楼駆屡韻多亞腑栄棲ってどうよ?

http://www.seshop.com/detail.asp?pid=4115&mode=spec

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から派生させると
継承, 仮想関数, カプセル化とか、ひと通り勉強出来ると思うのですが。

107 :デフォルトの名無しさん:03/07/12 10:59
>>102
OOとOOPをごっちゃにしてないかい。
抽象データ型、継承、多態といったものは、OOPの性質。

OOの本質は、関連のあるデータや振る舞いをモジュールに集め、
モジュールの凝集度をage、モジュール間の結合度をsageることで、
再利用性を高め、変更に強くするということ。

コンポーネント指向もその延長であり、モジュールの粒度がより大きくなったもの。

108 :102:03/07/12 11:24
>>107
むむむ、そういうことなら俺のコンポーネント指向の理解が足りないのかも。
コンポーネント指向指向におけるコンポーネントとは
ファサードまたはオブジェクトコンポジションと同義ってことでOK?

109 :デフォルトの名無しさん:03/07/12 12:54
>>108
ファザードは、クライアントに対して、内部の複雑さをかくし、
シンプルなインターフェースを提供するものだから、
ちょっと違うと思うけど、
オブジェクトコンポジションは、コンポーネントを実装する
1つの手段。

110 :デフォルトの名無しさん:03/07/12 13:01
>>105
言語にもよるけど、カプセル化って意味で別に問題ないと思うけど。

111 :あぼーん:03/07/12 13:09
http://homepage.mac.com/hiroyuki44/jaz09.html

112 :デフォルトの名無しさん:03/07/12 18:43
>>105
PureJava厨の戯言

113 :山崎 渉:03/07/15 09:54

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

114 :デフォルトの名無しさん:03/07/24 19:12
Delphi サイコー

115 :山崎 渉:03/08/02 02:22
(^^)

116 :山崎 渉:03/08/15 16:37
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

36 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)