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

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

貴様ら!オブジェクト指向を教えろ!!

1 :Java太郎:03/03/15 11:48
理解してるんだったら、教えやがれ!!

2 :デフォルトの名無しさん:03/03/15 11:50
勉強しろよ
低脳

3 :デフォルトの名無しさん:03/03/15 11:53
お尻の穴が少し広がった

4 :3:03/03/15 11:54
誤爆スマソ

5 :デフォルトの名無しさん:03/03/15 11:55
そろそろコタツのしまいどきですね

6 :デフォルトの名無しさん:03/03/15 11:57
T>>1=class(T2chaneller)
public
property Hikikomori defaut True;
procedure CreateKusoThread;
procedure Jisakujien;
end;

7 :デフォルトの名無しさん:03/03/15 11:59
つくしの子が恥ずかしげに顔を出す頃なんだなぁ

8 :デフォルトの名無しさん:03/03/15 12:07
VB太郎の間違いじゃないの?


9 :デフォルトの名無しさん:03/03/15 12:39
キャベツ太郎

10 :デフォルトの名無しさん:03/03/15 12:47
>>3
どの板の誤爆か大体予想つくw

11 :デフォルトの名無しさん:03/03/15 12:48
>>1
Javaができるなら自分でクラス作りながら勉強しろ
コンパイルエラーがお前にオブジェクト指向を教えてくれるぞ

12 :Java太郎:03/03/15 13:23
オレはコンパイルエラーが大嫌いだ!!
オレが間違っているのではない!マシンが悪いのだ!!!

13 :デフォルトの名無しさん:03/03/15 13:25
なんかの罰ゲームですか?

14 :デフォルトの名無しさん:03/03/15 13:31
>>11
クラス!=オブジェクト指向
いくらクラスを作ってもオブジェクト指向は理解できない

15 :デフォルトの名無しさん:03/03/15 13:31
                          'i、
                           ゙l、
                   .-,,,      .′      _
                     ゙゙''  .,r・'''''''''┐   ゙゙゙″
                        .,i´゚ ∀ ゚ .゙l コンパイルエラー
                        .ヒ     ,ィ°
                         .゚!,,, ゙,i´    `゚'-、
                         .°        .`
                   .,ノ         ゙i、
                   ′         .°
                                  ./¨゙゙ヽ コンパイキタイー
                 .,-‐''''''r,コンパイラー      l  ゚∀゚ ヽ、
                .,i´゚∀゚  ト            .|  .,,,,  .゙'ー、,
                .゙l  .,,,,,` ゙l           .」° .:゙゙°    `'‐,
                ,} ゙゙゙゙  .ヽ          |′      .|ヽ,  ゙'-、
          ._,,,,,,.--'″     ,.:'r,         .| ,,,      | .゙゙''ー-,,,'i、
          ”'''-、__        .,.゚'L       '・'゛.|     .|     ″
                ̄ ̄!     .:'i\,\        .|      ゙l
                 |      ゙'l,`i、 `i、      .}  .=@  |、
                 ..}       .〔 .゙'-,\     .,l゙ .,i´゙l,  |
                 .|    j_  ゙|   .゙''7    .l゙ ,/  :゚i、 .l゙
                 .|    | ゙'i、 .゙l        l/    ヽ.l゙
                .,r"   ,i´  ゙'-,」        °     .”
                ―---┘

16 :デフォルトの名無しさん:03/03/15 13:38
>>15
激しく同意


17 :Java太郎:03/03/15 13:41
オブジェクト=インスタンスってのがわからねぇぜ!!

18 :デフォルトの名無しさん:03/03/15 13:44
>>12
そんなこといってる奴には、
いつまでたっても、オブジェクト指向どころか
プログラミングを極めることができない。

19 :デフォルトの名無しさん:03/03/15 13:47
>>18
極める?バカじゃないの?
そんなことできるはず無いじゃん
居るんだよね〜少しプログラミングできるからって、「極めた」って言う奴が。
そういう発言は慎め!

20 :19:03/03/15 13:49
>>18
お前のせいで名前を入れ忘れたじゃねぇか!!
チッ・・・お前が居ると調子狂うぜ、まったくよw

21 :デフォルトの名無しさん:03/03/15 13:52
>>19-20
いいからよく本を読んで勉強しろ
がんがれ


22 :デフォルトの名無しさん:03/03/15 13:53
スライムから、バブルスライムやメタルスライムを派生させる。
これで継承は完璧。

インターフェースを定義して、魔法と剣の攻撃を同じような関数に
インプリメントする。
これでメッセージパッシングは完璧。

ゲームの途中のデータを保存して中断できるようにする。
これでシリアライゼーションは完璧。

できあがったら、RPGコンテストで賞金をもらえ。

23 :Java太郎:03/03/15 13:54
>>21
お前、いい奴だな・・・
オレの一番の下僕にしてやるぞ♪

24 :Java太郎:03/03/15 13:57
>>22
継承の例えは誉めてやる
メッセージパッシングはまぁまぁだな
シリアライゼーションなんて知らねぇよ!!
オレが知らないって事は、存在しないんだよ!!
このウソツキめ!!

25 :デフォルトの名無しさん:03/03/15 13:58
>>22
さらにいうならデータの保存はMementoパターンだろ

26 :デフォルトの名無しさん:03/03/15 13:59
個人スレたてんなボケ

27 :デフォルトの名無しさん:03/03/15 13:59
>>24
java.io.Serializableを調べよ

28 :Java太郎:03/03/15 14:01
>>25
そ、そうだ!!それだ・・・
(なんだよそれ・・・((((;゚Д゚)))ガクガクブルブル)

29 :Java太郎:03/03/15 14:02
>>27
はい!先輩!!

30 :デフォルトの名無しさん :03/03/15 14:03
個人スレたてんなボケ

31 :Java太郎 ◆adhRKFl5jU :03/03/15 14:04
ごめんなさいもうしません削除依頼出してきます
このスレは終了しますた。
-----------------------------------------------



32 :デフォルトの名無しさん:03/03/15 14:04
昨日のperl馬鹿か?

33 :Java太郎:03/03/15 14:04
>>31
偽者キタ━━━━━━\(T▽T)/━━━━━━ !!!!!
それだけ、オレが人気者って証拠だな♪

34 :Katjusha extender:03/03/15 14:06
倉庫に落ちました。。。

35 :デフォルトの名無しさん:03/03/15 14:10


このスレの存在がオブジェクト指向ではない。




36 :Java太郎 ◆DMVtSSFzcg :03/03/15 14:18
甚だ不本意だが、トリップつけてやるぜ!!
人気を奪われちゃー金を手に入れれねぇからな!!

37 :デフォルトの名無しさん:03/03/15 14:37
極論、オブジェクト指向っていうのは、特別な理論じゃなくて、開発しやすいからごく自然に使われてるってだけ。普通にプログラミングすればオブジェクト指向にたどりつくと思うんだよね。

38 :デフォルトの名無しさん:03/03/15 14:39
はぁ?

          ,,―‐.                  r-、    _,--,、
     ,―-、 .| ./''i、│  r-,,,,,,,,,,,,,,,,,,,,,,,,―ー.    ゙l, `"゙゙゙゙゙ ̄^   \
    /   \ ヽ,゙'゙_,/   .゙l、         `i、   \ _,,―ー'''/  .,r'"     
.,,,、.,,i´ .,/^'i、 `'i、``     `--‐'''''''''''''''"'''''''''''゙     `゛   .丿  .,       
{ ""  ,/`  ヽ、 `'i、                        丿  .,/`     
.ヽ、 丿    \  .\                      ,/′ 、ヽ,,、      
  ゙'ー'"      ゙'i、  ‘i、.r-、      __,,,,,,,,--、     / .,/\ `'-,、   
           ヽ  .]゙l `゙゙゙゙"゙゙゙゙ ̄ ̄     `'i、  ,/ .,,/   .ヽ  \
            ゙ヽ_/ .ヽ_.,,,,--―――――ー-ノ_,/゙,,/′     ゙l   ,"
                 `             ゙‐''"`        ゙'ー'"


39 :Java太郎 ◆DMVtSSFzcg :03/03/15 14:49
>>37
そういう事なのか!?!?
あとほんの少しだけ、勉強してやる。
兄貴!待ってろよ

40 :Java太郎 ◆dcpChnLpNk :03/03/15 15:04
>>36>>39
かってに騙るなボケ。トリップまでつけて厚かましいんだよ、もう来るな。

41 :デフォルトの名無しさん:03/03/15 15:08
// 手続き型
function("hoge");
// オブジェクト指向
class instance i = new class();
i.method("hoge");

こんな構文より、重要なのは設計のほう。
名詞を拾ってクラス化していかないと、オブジェクト指向にはならない。
これは慣れて覚えるしかない。

//おまえに馴染の深いサンプルでも読んで
//オブジェクト指向を理解しろ。
Humen javaTaro = new Humen(parents);
if (javaTaro.madeThreadLikeExcrement()) {
 i.say("逝って良し".javaTaro);
}


42 :デフォルトの名無しさん:03/03/15 15:12
>>28
GoFデザインパターンの一種
オブジェクトの状態を一時的に保存するデザインパターン
保存するときに、Serializableを使ってファイルに保存してしまえばさらに便利。
初心者に優しい結城浩のデザインパターン本でも読むことをお勧めする。

オブジェクト指向を使いこなすならデザインパターンも知らなくては。

43 :Java太郎 ◆DMVtSSFzcg :03/03/15 15:17
はぁ・・・なんだか色々難しいぜ!!(ウソ)
しょうがない、殺るか!

44 :Java太郎 ◆DMVtSSFzcg :03/03/15 15:19
>>42
Java言語プログラミングレッスンの下を読みはじめたよ
ふぅ・・・だるくてやる気が出ないのが本音(ウソ)

45 :デフォルトの名無しさん:03/03/15 15:22
ある男がらくだと共に砂漠を旅していました。
しかし思った以上に長く続く砂漠に、若い男の性欲は耐える事が出来ませんでした。
そこで男は思い付きました。
「そうだ!らくだとやろう!」
男はらくだの後ろへまわると早速自分のものを入れようとしました。
しかしその時らくだはトトッと数歩前へ。それに男が近づき再びチャレンジ。
しかしらくだはまたもやトトッと数歩前へ。その後、何度も試したけど同じ事の繰り返し。
男は行為をあきらめ、再びらくだと旅を続けました。
そしてしばらく歩いていると、なんと前方にきれいな女性が倒れているではありませんか!
男は女性に言いました。
男:「大丈夫ですか?」
女:「あ…あの、のどが乾いて死にそうなんです…」
男はここぞとばかりに言いました。
男:「じゃあ、水をあげたらなんでも言う事をきいてくれますか?」
女:「はい…言う通りにします……」
男は水をあげた。
女:「ああ、ありがとうございました。おかげで助かりました」
男:「よし。言う事をきいてもらうぞ」
女:「…はい……」
男:「じゃあ、らくだ押さえといて」




46 :Java太郎 ◆DMVtSSFzcg :03/03/15 15:26
>>45
(一応、反応するか・・・( ´Д`))
スゴイ!涙が出ちゃう話だね・・・
最近、涙もろくてw
ハハもう年かな?

47 :デフォルトの名無しさん:03/03/15 15:27
>>1の妹の亞里亞です。
このたびは兄やがこんなスレッドを立ててしまってごめんなさい・・・。
兄や、最近亞里亞のところに来てくれないの・・・。くすんくすん。
じいやに聞いたらね、兄やはどこか遠い世界に逝ってしまったって急に怒るの。
そんなときのじいやはとっても怖いんです。
兄や、どうして亞里亞をひとりぼっちにするの・・・?くすん。

兄や・・・早く帰ってきてください・・・くすん。
亞里亞、兄やのお馬さんじゃないと楽しくないの。
じいやにまた怒られるかもしれないけど、兄やとまたお馬さんごっこしたいな。


48 :デフォルトの名無しさん:03/03/15 15:27
プログラムって何回も何回も似たような単純作業をすることが多いから、
抽象的な概念を導入することで作業を一般化して、
同じ作業を繰り返す手間を省こうって話なんだよなあ。
ある程度、普通にプログラムを書いていれば、
モジュール化をしてゆくようになるし、
いろんなプログラムからモジュールを使えば、
モジュール強度なんかも気になってくる。
で、言語レベルでそのサポートをしてくれるのが
オブジェクト指向の言語だから、
単に便利だから使ってるってだけ。
その便利さが分からないってことは、
知識と経験が足りないって可能性は高いかも。

49 :デフォルトの名無しさん:03/03/15 15:28
>>1の妹の花穂ですっ★
お兄ちゃま、お元気ですか? 花穂は自作自演を毎日一生懸命がんばってます!
早くお兄ちゃまのクソスレを1000まで行かせたくって、もう待ちきれないくらい!!
お兄ちゃまに「花穂のおかげでこのスレが1000まで行ったよ」って言ってもらうのが、
花穂のちっちゃい頃からの夢なんだぁ……★
お兄ちゃま、花穂の自作自演、楽しみにしててね!




50 :Java太郎 ◆DMVtSSFzcg :03/03/15 15:29
>>47
(コイツもか・・・)
妹、居ないけど、( ´Д`)なにか?
・・・2ちゃん風に決めたぜ!よっしゃ!!

51 :デフォルトの名無しさん:03/03/15 15:29
>>1の妹の可憐です。
大好きなお兄ちゃん。この前お兄ちゃんが立てたスレ、とっても大切にしています。
どうしたって毎日1回はスレを見てしまうの。1の書き込みを見ているとお兄ちゃんの
声が聞こえるみたいな気がする不思議なスレ……。
でもみんなはこのスレをクソスレって言うの。とってもすてきなスレなのに・・・。
でも、可憐だけはお兄ちゃんの味方だよ・・・。お兄ちゃん……大好き。


52 :Java太郎 ◆DMVtSSFzcg :03/03/15 15:31
>>48
すごい!!当たってるw
知識と経験が全然足りないよ・・・
初心者Javaのスレに行っても、話がわからないし。

53 :デフォルトの名無しさん:03/03/15 15:31
1の妹の沙織です。
このたびはお兄ちゃんがごめいわくおかけして
どうもごめんなさい。(ペコリ)
はぁ……なんでこんなことになっちゃったんだろ。
昔のお兄ちゃんは、優しくて、家族思いで、頭だってテスト100点
ばっかりだったし、お友達に囲まれていっつも楽しそうだった。
でも、あの日の後、もうお兄ちゃんはお兄ちゃんじゃなくなっちゃった。

はっ!? お兄ちゃん!? いつの間に私の後ろに居たの!?
まあいいや、お兄ちゃんも一緒にみんなに謝っ……あっ、うふぅ、な、なに!?
いきなりどうしたの、お兄ちゃん!?
いや、やめて!! そ、そんなところ触らないでぇ!!
私達兄妹……はぁん、だめぇ〜、そ、そんなに揉んだら……あはぁん。
あんっあんっ、ダ…メ……わ、わた……し……も……う…………



54 :Java太郎 ◆DMVtSSFzcg :03/03/15 15:33
1の妹シリーズって読んでると疲れるし、面白くないね。
しかも、コピペでしょ〜
はぁ・・・それでも読んでるオレってピュアだ!!

55 :デフォルトの名無しさん:03/03/15 15:33
1の妹の咲耶です。
……お兄さま。とうとう見つけたわ。
ねぇ、お兄さま、最近私のこと避けていない?
昔はよく一緒に遊んだり、TV見たり、お風呂に入ったりしたのに、
最近は学校から帰るとすぐに出かけるか、部屋にこもっちゃうのよね。
ちゃんとお喋りしたのって、もういつのことだか忘れちゃったわ。
お兄さま……。私、ずっとお兄さまのこと見てたわ。
勉強してるときも、友達と居るときも、いつでもお兄さまのことが頭から離れなかったわ。
でも、いくらニブいお兄さまでも、やっと私の気持ちに気づいていてくれたのかしら?
だから最近避けてるのね?
でも、ダメ。逢えないほど、お喋りできないほど、私の想いは募ってしまうの。
もう、私、我慢できない。
だから、悪い子だってわかってるのだけど、お兄さまの部屋、黙って入っちゃったわ。
お兄さま、いつも一人でパソコンに向かってたわね。
パソコンに残ってたデータを見て、私ショックだったわ。
お兄さまも苦しんでいたのね・・・つらかったのね。
わざとめちゃくちゃなスレッドを立てて、他のみんなと喧嘩して、
フラストレーションを発散させていたんだってわかって、私、涙が止まらなくなったわ。
お兄さま。無理しなくていいの。我慢しなくていいの。
私、もう心の準備はできてるから。
16年前、お兄さまの妹に生まれてから、ずっとお兄さまのことが好きだったんだから。
お兄さま。学校から帰ってきて、この書き込み読んだら、私の部屋に来て。
私、今日はもうお兄さまと離れていたくないの。
だから………お願い………
死んでちょうだい。


56 :Java太郎 ◆DMVtSSFzcg :03/03/15 15:34
>>51
やさしいね、ありがとう( ´Д`)

57 :デフォルトの名無しさん:03/03/15 15:35
>>1の妹の咲耶です。うちのお兄様が皆さんに迷惑をかけてしまった
みたい、お兄様にかわってお詫びするわね。

お兄様ったら今日私たちに逢えるって楽しみに出かけたらしんだけど、
手違いで逢うことができなかったの。私も凄く寂しかったんだけど…、
お兄様はどうやらそれ以上だったみたい。だからこんなトコロで寂しさを
紛らわせていたのね、ふふっ仕方ないお兄様。

でも皆さんご安心ください。これからは私の魅力でお兄様を寂しい思い
なんてさせませんから。このようなことは無くなると思うの。

あ、今からお兄様とお風呂に入るので失礼するわね。

58 :Java太郎 ◆DMVtSSFzcg :03/03/15 15:35
>>53
近親相姦に興味ない( ´Д`)

59 :デフォルトの名無しさん:03/03/15 15:35

>>1の妹の白雪ですの!
にいさま〜、大変ですの!きっと、にいさまにはストレスが溜まってますの!
さあ、今すぐ家に帰って姫の手料理を御馳走してさしあげますの!
うふふ、皆さんごめんなさいですの!
にいさまはきっと機嫌が悪かったんですの!いつもは優しいにいさまなんだけど・・・。
最近はにいさまったらパソコンに夢中で時々人が変わるんですの・・・。
突然、「ゴルァ!」とか叫ぶから・・・姫、ちょっと怖いんですの・・・。
鈴凛ちゃんが言うには、「2ch病ね」らしいんですけど姫なんのことかサッパリですの。
でももう大丈夫ですの!姫が来たからにはにいさまの無様な姿は見せませんの!
さ、にいさま!早くお家に帰るんですの。
それでは失礼しますの、皆様ご機嫌ようですの。
あっ、にいさまの立てたスレは鈴凛ちゃんにお願いして何とかしてもらいますの!
にいさま、もうこんなことしちゃダメですのよ・・・




60 :Java太郎 ◆DMVtSSFzcg :03/03/15 15:36
>>55
まだ死なない( ´Д`)

61 :デフォルトの名無しさん:03/03/15 15:37
>>1の妹の千影だ…
兄くん…駄スレは立てないでくれと…いつも言っているだろう・・・
そうでないと…きっと…兄くんの身に…不幸な災いが…ふりかかる…
ホラ…見てみろ…。兄くんのせいで…こんなにも多くの…愚者が…稚拙なレスを……。
兄くん…、いいかい?もう…こんなスレ立てないと…約束してくれ
でないと…兄くんの命が…危ないことになる…
それでは兄くん…また…来世…

62 :Java太郎 ◆DMVtSSFzcg :03/03/15 15:37
>>57
他人とお風呂入るの嫌なの知ってるじゃん( ´Д`)

63 :デフォルトの名無しさん:03/03/15 15:38
1の妹のはるかです。
このたびはお兄ちゃんがごめいわくおかけして
どうもごめんなさい。ペコリ。
はぁ、なんでこんなことになっちゃったんだろ。
昔のお兄ちゃんは、優しくて、家族思いで、
頭だってテスト100点ばっかりだったし、
お友達に囲まれていっつも楽しそうだった。
でも、あの日の後、もうお兄ちゃんは
お兄ちゃんじゃなくなっちゃった。
お兄ちゃんは、少しも悪くないんだ。
悪いのは、あいつ。
なにか、皆さんに、
おわびしてあげられることがあると、いいんだけど。
ううん、待ってて。
私が、お兄ちゃんを元通りのお兄ちゃんにしてみせる。
そして、お兄ちゃん自身が、
自分でこのあやまちをつぐなうんだ。
だから、ほんの少しだけ、待ってて。
ごめんね、おねがいします。

64 :デフォルトの名無しさん:03/03/15 15:38
>>1の妹の春歌ともうします。

近頃兄君さまの様子がおかしいとは思っていたのですが、こんなことになるな
どとは・・・。

 今日の昼食を兄君さまの部屋に運んでいきますと兄君さまは今日もワタクシに
飛び掛り、「ageるんじゃないageるんじゃない」と言って部屋の扉を閉め、私の背
中を嘗めまわしながらワタクシの股間に腰を押しつけ始めましたので、いつものよ
うに兄君さま用のリモコンで兄君さまの首輪を締め上げ、少し黙らせていたとこ
ろ、兄君さまが首を押さえながら(というのも私が更にリモコン操作でもって
兄君さまの首に電流を走らせたせいもあったのでしょうが)ぱそこんに向かっ
て、きいぼおど(というのでしょうか)を用いて、なにやら猥褻な言葉なの
でしょう、信じられない速度で不思議な言葉を叩き始めたのです。
 ワタクシはその時の兄君さまの顔に走る喜悦をもって、兄君さまが変わってしまった
こと、兄君さまに生きる資格がもはやないのだということを実感するに至りま
した。

 そう実感すると、ワタクシは薙刀で兄君さまの後頭部を激しく2回打ち付
けておりました。兄君さまはそのまま一声も発せずにきいぼおどの上に倒れこ
んでゆきました。

 その後でいすぷれいにはまだ何文字か下劣な言葉が生まれました。兄君さま
は最期の力を振り絞ってそれを送信しますと、もう二度と動くことのな
い肉となってしまったのです。

65 :Java太郎 ◆DMVtSSFzcg :03/03/15 15:38
>>59
なんでスレを立てたぐらいで、命がどうのこうのって話になるんだよ( ´Д`)
どこから仕入れたんだろ・・・妹シリーズ。

66 :デフォルトの名無しさん:03/03/15 15:40
 今兄君さまの体は、使用人が埋めてくれている所だろうと思います。しばし
茫然としておりましたが、ともかくワタクシは兄君さまが生前に固着しつづけたこの
にちゃんねるというものがいかにあの優しかった兄君さまを蝕んだのか(兄君
さまの名誉のためにのみ申すのですが、数年前に日常の言葉を失って部屋に閉
じこもる以前の兄君さまはそれはそれはお優しく聡明な方でございました)を
知りたくて、兄君さまのぱそこんからあくせすしている次第でございます。
 しかし、兄君さまのここでの行状を知るに及び、みなさんに一言謝っておく
のが本義だろうと思い、きいぼおどを取らせて頂きました。大変はしたない
ことを書いてしまいましたが、いまだ動機の収まらぬ兄殺しの書いた文と思
い、どうぞお捨て置かれますように。

 ああ、兄妹揃ってのご無礼をどうぞお許しくださいませ。そのような次第
でございます。どうか不憫な兄君さまのことを悪く思わないでやってください
ませ。兄君さまいつまでもおかわいそう方でございました。
                            かしこ

67 :Java太郎 ◆DMVtSSFzcg :03/03/15 15:40
1の妹シリーズへ
もう似たようなネタしかないね・・・
やめよう( ´Д`)


68 :デフォルトの名無しさん:03/03/15 15:40
>>1の妹の雛子でーす!!
みんな、おにいたまの立てたスレッドに来てくれてありがとねっ☆
おにいたまは、ちょっと頭が弱いところもあるけど、
とっても、とーっても優しいおにいたまなんだよ!!
今日も、さっきまでいーっぱいいいーーっぱい、ヒナに優しくしてくれたし、
おにいたま、大好きっ。って、あっ、言っちゃった!
はずかしーよーーぅ
みんな、ヒナがおにいたまの事言っちゃったって、内緒だよ?
ほんとに、ほんとに内緒だよ??
あっ、今おにいたまが戻ってきた。
今度はいっしょにゲームしてくれるんだって!くししし、楽しみだなー。
じゃぁ、いってきまーーす!!

69 :デフォルトの名無しさん:03/03/15 15:41
>>1の妹の衛です。
このたびはあにぃがこんなスレッドを立ててしまってごめんなさい。
あにぃは最近、嫌な事があってこんなスレを立てちゃったみたいなんだ・・・。
あにぃはね、本当はこんなスレは立てない優しいあにぃなんだよ!
よほど嫌な事があったんだろうね・・・。
でも駄スレを立ててしまったのは悪い事だし、ボクからもあやまるよ。
ボクがあにぃを元の優しいあにぃに戻すから、それまであにぃの話題にのってあげてね・・・

じゃ、これからあにぃとスノボにいってくるから失礼するね。

70 :デフォルトの名無しさん:03/03/15 15:42


>>1の妹の四葉デス。
兄チャマ!あれほど言ったのに、まだそんなカキコするデスか!もう許しませんデス!
兄チャマのこと許すわけにはいかないデス!こんなカキコでレスたくさん付くとでも思ってるなんて頭おかしいデス!
兄チャマみたいなバカは初めて見マシタ!兄チャマみたいなバカ、ゴキブリ以下デス!
兄チャマみたいなバカ、ウジ虫以下デス!死んでほしーデス!むしろ死ぬべきデス!兄チャマは絶対に許されないデス!
勘違いしたバカを許すわけにはいかないのデス!面白半分にいい加減なカキコする兄チャマを四葉許さないデス!
キャラメルコーンのピーナッツをケツの穴に詰めて死んでしまえデス!!!
今まで兄チャマがどんな生き方してきたか知らないけど、どーせひどい生き様だったと想像出来るデス!
兄チャマのカキコから読みとれるデス!バカ特有の 匂いがするデス!
兄チャマのことが全く理解出来んデス!兄チャマを絶対許さんデス!
死んでも許さんデス!地獄で苦しむデス!それでも足りないデス!
豆腐の角に頭ぶつけて死んでしまうデス!!!
兄チャマもっと現実を知るデス!いつまでも引きこもってネクラなことしてる場合じゃないデス!
でも、もー手遅れデス!兄チャマは何をやってもダメデス!
この世に生まれてきたことを後悔してもダメデス!兄チャマは生まれ変わってもどうせダメ人間に決まってるデス!
絞め殺したいけど兄チャマに触るのが嫌なので やめるデス!でも、兄チャマみたいなカスは死ねよデス!
風呂の排水溝に吸い込まれて死ねよデス!!!
兄チャマみたいなヤツは絶対許せないデス!早く消えてほしいデス!
さっさとこの世からいなくなってデス!!!
いつまでも勘違いしたまま生きていけると思ったら大間違いデス!
このまま生きてても兄チャマにはいーことなんにもないデス!
何でもいいからさっさと死ねよデス!!!

71 :デフォルトの名無しさん:03/03/15 15:42
>>1の妹の鈴凛です。
アニキは、すっかりダメになってしまいました。
ううん、元々ダメな奴だったんだよ、あの男は。
まともに人と口をきけないし、何をやっても中の下で、いいとこなし。
でもねえ、素直で純粋なのが取り柄だと、今まではそれでも思ってたんだよ。
それなのに。
ああっ!もう思い出しただけで腹が立つ!!
私がアニキを一番好きなのに!
あの男は空想の女に恋してるんだよ。まっじで。おえ。
引きこもってるからさ、普段は部屋のぞく隙がないんだよ。
でもあの日は、年一回のイベントがあるとかで、母さんから金せびって早朝から居なかった。
ふらふらと、入っちゃったんだ。何年ぶりかの部屋だった。
……もう、言いたくない。1の、アニキの書きこみから、想像つくでしょ。

72 :デフォルトの名無しさん:03/03/15 15:46
抽象化能力のない人間がプログラマになって、
オブジェクト指向がわからなくて、まわりから馬鹿にされて、
オブジェクト指向のスレを荒らして憂さ晴らしってパターンは
多いようだ。

かわいそうな話ではあるが、人には器というものがある。


73 :デフォルトの名無しさん:03/03/15 15:49
妹レスも読みつかれた。しつこすぎ。
マンネリには飽きた。他板でやれ。

んで>>1は何を理解したんだ?

74 :デフォルトの名無しさん:03/03/15 15:50
>>72
オブジェクト指向なんて算数でいえば九九みたいなもん。
器もなにもない。
確かに九九が出来ない小学生もいるだろうが。

75 :デフォルトの名無しさん:03/03/15 15:57
あえて言うなら「九九ではなく微分みたいなもの」としておこう。
意味のない微分と同様に、意味のないオブジェクト化をする人間もいる。
困ったものだ。

76 :Java太郎 ◆DMVtSSFzcg :03/03/15 15:58
>>73
ぶっちゃけ、具体的に質問したい事はない。
まず、本を熟読する事が今の目標。
ただ、わざわざクラスを作らなくても動かせるプログラムがあると
ちょっと、気持ち悪いかな。
基礎を学ぶためだからしょうがないけど。

77 :Java太郎 ◆DMVtSSFzcg :03/03/15 15:59
>>72
人には器というものがある
↑これって荒らしに対して?

78 :Java太郎 ◆DMVtSSFzcg :03/03/15 16:00
>>74
九九ならできる!!ヽ(´∇`)ノ

79 :Java太郎 ◆DMVtSSFzcg :03/03/15 16:01
>>75
オブジェクト化する必要が無いものまでしてると
ちょっと読みづらくなる・・・


80 :デフォルトの名無しさん:03/03/15 16:04
>>77
そう。
だが、実際、それはすべてのプログラマにあてはまる。
そして複数の人間でプログラムを開発する場合、
プロジェクト内のレベルに合わせて、簡易化されたラップを
用意することを理解するためにも必要な前提なのだ。
言い方を変えれば、自分と相手の器を理解するプログラマは、
質のよいプログラマでもある。

81 :Java太郎 ◆DMVtSSFzcg :03/03/15 16:08
>>72
図星みたいだね
1の妹シリーズが止まったよw

82 :デフォルトの名無しさん:03/03/15 18:43
昔Delスレだかで観た「ギコ猫オブジェクト」が非常におもしろかった。

83 :Java太郎 ◆DMVtSSFzcg :03/03/15 19:06
>>82
え?なにそれ〜
独り占め?
ズルイぞ!ズルイぞ!...(´З`)チュッ

84 :デフォルトの名無しさん:03/03/16 04:37
静かだ・・・

85 :デフォルトの名無しさん:03/03/16 07:00
おい、J太郎出て来い

86 :Java太郎 ◆DMVtSSFzcg :03/03/16 09:05
>>85
J太郎って、オレの弟か?
どうなんだよ!?隠すんじゃねーよ!!
コンチクショー

87 :デフォルトの名無しさん:03/03/16 09:06
オ・バ・ケの・・・

88 :Java太郎 ◆DMVtSSFzcg :03/03/16 09:19
>>87
Q太郎か?
お前、年いくつだよ?
オヤジスレにするつもりかよ!!

89 :デフォルトの名無しさん:03/03/16 09:31
何も書き込むことが無い

90 :デフォルトの名無しさん:03/03/16 09:38
オブジェクト定食

91 :デフォルトの名無しさん:03/03/16 09:47
ここ、本当にプログラム組める奴、何人ぐらい居るんだろう?

92 :Java太郎 ◆DMVtSSFzcg :03/03/16 09:49
>>89
書き込んでるじゃーん!!
ビックリ人間だな・・・オマエ

93 :Java太郎 ◆DMVtSSFzcg :03/03/16 09:50
>>90
名前だけじゃ、どんなものが出されるのかわからないな・・・
み、味噌汁はついてるのかなぁ?ぐへへ・・・

94 :Java太郎 ◆DMVtSSFzcg :03/03/16 09:52
>>91
それは愚問だ!
一応、答える
A.オレしか居ないぜ!!(素

95 :デフォルトの名無しさん:03/03/16 10:07
>>Java太郎
ひまそうですね。

96 :デフォルトの名無しさん:03/03/16 10:13
>>94
何言語だよ

97 :デフォルトの名無しさん:03/03/16 10:22
オブジェクト指向の概念において、(私の父:公務員)が
“私の父は公務員”というインスタンスとクラスの関係を意味する
としたとき、同じ関係となるものはどれか。


 ア (赤い車:乗り物)     イ (オーストラリア:国)

 ウ (私の父:私の母)     エ (私の部屋:私の家)

98 :デフォルトの名無しさん:03/03/16 11:06
何このスレ・・・・・・・?
             /ヽ       /ヽ
            / ヽ      / ヽ
  ______ /U ヽ___/  ヽ
  | ____ /   U    :::::::::::U:\
  | |       // ___   \  ::::::::::::::|
  | |       |  |   |     U :::::::::::::|
  | |      .|U |   |      ::::::U::::|
  | |       | ├―-┤ U.....:::::::::::::::::::/
  | |____ ヽ     .....:::::::::::::::::::::::<
  └___/ ̄ ̄      :::::::::::::::::::::::::|
  |\    |           :::::::::::::::::::::::|
  \ \  \___      ::::::



99 :デフォルトの名無しさん:03/03/16 11:06
>>97

オ(ウホッ:いい男)

100 :デフォルトの名無しさん:03/03/16 11:50
オブジェクト指向を深く理解する上で、やがてキーワードになるのが、「オートマトン」という概念だ。
一方でオートマトンと対になるのが「関数」である。
オートマトンは内部の状態の情報をもつため、同じ引数で呼び出したとしても、
返ってくる結果が同じだとは限らない。
一方で、関数は引数が同じならば、同じ結果が得られる。
この区別をつけるため、オブジェクト指向に対する操作は、
「メソッド」と呼ばれ、関数と区別されるが、
メソッドも広義に関数と呼ばれることがあり、用語はやや混乱している。

オートマトンにおいては、内部状態が変化するため、その状態遷移図を
設計することが重要になる。また、その状態をプロパティとして、
get/set のメソッドで取り出したり、変更したりできるようにするのが、一般的である。

このような内部状態を持つオートマトンであるオブジェクトは、
A「ね〜、今日、暇?」(get)
B「うん、暇だよ。」(返り値)
A「遊びに行こうよ」(set)
B「いいねえ」(返り値)
と、コミュニケーションモデルで設計するのが
比較的分かりやすいため、メッセージを送る/受け取ると
いうメッセージパッシングとして実装される。

101 :デフォルトの名無しさん:03/03/16 12:01
>>100
間違い

102 :デフォルトの名無しさん:03/03/16 13:23
これは面白い現象ではあるが、また、残念な現象とも言える。
抽象概念の真偽は、知性によって判断され、知識によっては判断されない。
つまり、「知っている」と「理解している」が明暗を分かつ場面でもある。
オブジェクト指向型のプログラミング言語を便利に使えるということは、
正しい知識と持つことだけでなく、正しく理解することが必要である。
同時にオブジェクト指向を使えない人たちは、理解よりも知識を求める。
オブジェクト指向を使えない人たちは同じ作業を繰り返して上手になることを望むが、
オブジェクト指向を使う人たちは、同じ作業を繰り返さずに済む方法を考える。
そして、その差は知性によって判断される。

103 :デフォルトの名無しさん:03/03/16 13:45
>102
そーいう能力は個人差があるからね。別の能力でいうと
モテる男は最小の労力でいい女をゲットできるが
モテない男はいろんな女にトライするしかないつーこと。
努力でカバーできればまだマシなほうだよな。いくらか
妥協している人も結構多いのでは・・・。


104 :デフォルトの名無しさん:03/03/16 13:48
知性はフツーで十分です。


105 :デフォルトの名無しさん:03/03/16 14:53
俺はJavaの
インターフェースとインプリメンツの違いが
よくわかんねーよ。


106 :デフォルトの名無しさん:03/03/16 14:59
かたまり、かたまり
カプセル、カプセル

107 :デフォルトの名無しさん:03/03/16 15:06
>>105
引退しろ

108 :デフォルトの名無しさん:03/03/16 15:20
>>107
あはっ、Javaは趣味でやってまつから。
関りたくネーヨ>Java。


109 :デフォルトの名無しさん:03/03/16 15:23
protectedに何を置けばいいのか分からない…(Delphi)

110 :デフォルトの名無しさん:03/03/16 15:35
            ☆ チン
        ☆ チン  〃  Λ_Λ   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・) < 鞠絵マダ〜?
             \_/⊂ ⊂_ )   \___________
           / ̄ ̄ ̄ ̄ ̄ ̄ /|
        | ̄ ̄ ̄ ̄ ̄ ̄ ̄|  |
        | .          |/
         ̄ ̄ ̄ ̄ ̄ ̄ ̄


111 :デフォルトの名無しさん:03/03/16 15:39
インターフェースは抽象的なメソッドの定義である。
インプリメンツは具体的な実装プログラム記述である。

例えば文字出力を考える。文字出力は抽象概念である。
しかし、画面に文字出力をするオブジェクトと
通信で他のコンピュータにデータを送るオブジェクトでは、
まったく実装方法が異なる。
しかし同一の文字出力インターフェースを定義することにより、
アプリケーションは、送り先が画面なのか通信線なのかという
具体的な区別をすることなく、単に文字を送ればよい。
文字出力インターフェースを持ったオブジェクトは
すべて同一に操作が出来る。

このように、アプリケーションが送り先のオブジェクトが
何であるかを知らなくても、同じ操作が出来る利点が生まれる。
実際には送る側はアプリケーションである必要さえなく、
オブジェクトでもなんでもかまわない。便利である。

112 :105:03/03/16 15:58
>>111
ありがとう、本とか読んでもヤッパリピンとこないんだよね。
同じ機能に思えるし。
例えば
Blackクラスがあって、インターフェイスにBlack_Aという文字変数が用意されている場合。
WhiteクラスはBlackクラスに対してBlack_Aだけを意識すればいいということ?

Blackクラス内にあるBlack_Aと同ちがうんだ?と思ってしまう。

自分的には、インターフェース=Public 宣言という認識ですがいいのかな?

----------------
ここにMatherクラスと、それに対して子クラスが
A0クラス〜AN(N>0)で任意動的に作成される場合。
Matherクラスと、Aとのクラスとの会話はインターフェースで会話した方が
楽つーことかな?Aクラス内部にわざわざメソッドを定義して会話するよりも
インターフェースのファイルを書き換えれば手間が済むと。




113 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/16 16:04
OOの前に正しいサブルーチンの作り方を会得しろ。
まあ才能のある奴はそうは居ないけどな。
OOはその次だ。
正しいサブルーチン作れない奴にOOは無謀。

114 :デフォルトの名無しさん:03/03/16 16:12
>>105
implementsはinterfaceを実装するときに記述するものだ。
>>111の説明は誤解を招く部分がある。
>>105はまず実際にinterfaceを実装したクラスを作って
プログラミングしてみろ。

intercface は class と比較して考えるものだ。
implements は extends と比較して考えるものだ。

>自分的には、インターフェース=Public 宣言という認識ですがいいのかな?
No. それだけでは恒真ではない。
interface とは インスタンスを作れない、メソッドの実装を許さない(public abstractメソッドしか許さない)、
public static finalなフィールドを持つことしか許さない、多重継承を許すpublic abstractなクラスの特殊な形態ことである。

implementsはextendsの代わりに使うものであり、interfaceを実装したいクラスに記述する。

115 :デフォルトの名無しさん:03/03/16 16:14
interfaceをimplementsする。
とても解り易いと思うんだがな。

116 :デフォルトの名無しさん:03/03/16 16:15
>>112
> 楽つーことかな?Aクラス内部にわざわざメソッドを定義して会話するよりも
> インターフェースのファイルを書き換えれば手間が済むと。
ぜんぜん解ってない。

本を読むだけで終わらせないで
interfaceを実装したサンプルプログラムを書いてコンパイルして実行しろ。
実際に動かしてみてコンパイルエラーがでて初めて理解できる。

117 :&&@rrlo:03/03/16 16:21
同意

118 :105:03/03/16 16:24
>interface とは インスタンスを作れない、メソッドの
>実装を許さない(public abstractメソッドしか許さない)、
>public static finalなフィールドを持つことしか許さない、
>多重継承を許すpublic abstractなクラスの特殊な形態ことである。

クラスA、クラスB、インターフェースCがあって、
クラスBが親クラスでクラスAに継承し、クラスBがインターフェースCを持つ場合。

   C
   |
 A←B

があったとする。んで、クラスAのインタンスを複数(1〜n個)作ったとする。

A0 A1 ・・・・ An

で、この時A1〜Anまでを利用するが、Cで定義された変数はA1〜Anまで
すべて共通の値を持つということでよい?。


119 :デフォルトの名無しさん:03/03/16 16:29
俺は、基本的にinterfaceってのは
プログラマに実装上の留意を促し、
実装ミスを防ぐ為にあるのが50%、
C++と比べてClassの多重継承ができない事に
対する代用策としてが50%と考えてる。

120 :デフォルトの名無しさん:03/03/16 16:31
ぬるぽをいかに抽象化するかってことだな

121 :デフォルトの名無しさん:03/03/16 16:31
>>119

不正解。

122 :105:03/03/16 16:33
>interface とは インスタンスを作れない、メソッドの
>実装を許さない(public abstractメソッドしか許さない)、
>public static finalなフィールドを持つことしか許さない、
>多重継承を許すpublic abstractなクラスの特殊な形態ことである。

えっと少し変更。
クラスA、クラスB、クラスC、インターフェースDがあって、
クラスB、Cが親クラスでクラスAに継承し、クラスB、CがインターフェースDを持つ場合。

   +−B(*1)
   |
 A←+
   |
   +−C(*1)

(*1)ーD

があったとする。んで、クラスAのインタンスを複数(1〜n個)作ったとする。

A0 A1 ・・・・ An

で、この時A1〜Anまでを利用するが、Cで定義された変数はA1〜Anまで
すべて共通の値を持つということでよい?。


123 :デフォルトの名無しさん:03/03/16 16:35
インターフェースが威力を発揮するのは、
同一のインターフェースが複数のクラスでインプリメントされる場合である。

・画面オブジェクト ・プリンタオブジェクト ・音声合成オブジェクト
の3つが同一のインターフェースをインプリメントされたとする。

ラーメンタイマー・オブジェクトは「お時間がきました」と文字列を出力する。
ラーメンタイマーとバインド(接続)されるオブジェクトが
実行時に自由に選べると便利だ。出力先はセレクターオブジェクトでも作って
ユーザーに選択させる。セレクタは、ラーメンタイマーに誰に出力先を渡す。
ラーメンタイマーは、相手が何クラスであるかを知る必要はない。
ただ、「お時間がきました」と文字出力メソッドにわたすだけだ。
そしてそのインターフェースは同一である。

バインド先が画面ならば、文字列は画面に。
バインド先がプリンタなら文字列は紙に。
バインド先が音声合成なら文字列は音に出力されるだろう。
ここで、楽になったのはラーメンタイマーのプログラムである。

同時に、将来、「メールクラス」を追加するときにも、
ラーメンタイマーは書き換える必要がない。
メールクラスを同じ「文字出力」インターフェースで
インプリメントすれば、ラーメンタイマーは
一行も書き換えることなしに使える。
「お時間がきました」という通知はケータイで受け取れるだろう。
便利である。

124 :デフォルトの名無しさん:03/03/16 16:36
>>121
不正解と3文字だけ書くことなら
馬鹿にでもできる

125 :デフォルトの名無しさん:03/03/16 16:38
>>105
念のため確認したいんだけど、
Polymorphismの事くらいは知ってて書いてるんだよな。

126 :デフォルトの名無しさん:03/03/16 16:40
>>122
>クラスB、Cが親クラスでクラスAに継承し
JAVAでclassの多重継承はできまへん

127 :デフォルトの名無しさん:03/03/16 16:41
>>125
>Polymorphism
知らない。



128 :105:03/03/16 16:43
>>126
ああっそうだった。
やべっ混乱してきた。


129 :デフォルトの名無しさん:03/03/16 16:43
>>127
じゃ、知っとけ。

130 :デフォルトの名無しさん:03/03/16 16:43
>>122
> えっと少し変更。
> クラスA、クラスB、クラスC、インターフェースDがあって、
> クラスB、Cが親クラスでクラスAに継承し、
Javaではそのような実装の多重継承を許さない。

>クラスB、CがインターフェースDを持つ場合。
「持つ」という意味と「実装する」という意味は全く異なります。
「BとCはDを実装する」といっているつもり?
持つ、といったら「集約」を意味する。

恐らくあなたは多重継承とポリもーフィズムとを取り違えていると思われ。

131 :デフォルトの名無しさん:03/03/16 16:43
(゚∀゚;)

132 :デフォルトの名無しさん:03/03/16 16:51
オブジェクト指向やJavaのinterfaceは全然分からんが
>>105が何も分かっていないことだけは分かる。

133 :119:03/03/16 16:52
>>121
いや、不正解と言われても。。。
あくまで俺なりの解釈なんで、
正解も不正解もないんだが。

134 :デフォルトの名無しさん:03/03/16 16:54
>>122 での矢印の使い方から、105は馬鹿ってことに決定。

135 :デフォルトの名無しさん:03/03/16 16:55
>>Cが親クラスでクラスAに継承し
このアタリもまずいような気がする。

136 :デフォルトの名無しさん:03/03/16 17:03
馬鹿馬鹿言わんと教えてやれや

137 :プロの逝って良しの2 ◆KgOWTAR7IU :03/03/16 17:03
ゲッツ!

138 :105:03/03/16 17:21
>>123
ラーメンクラスと、interfaceと、その他の追加するクラス関係が分かれば
納得すると思う。できれば図キボンヌ。

ラーメンタイマークラス
インターフェース
[その他]
画面クラス
プリンタクラス
音声クラス


139 :デフォルトの名無しさん:03/03/16 17:46
interfaceAにBというメソッドがあるとすれば
interfaceAをインプリメントしたクラスはBメソッドが実装されていることが保証される。

140 :デフォルトの名無しさん:03/03/16 17:46
「持つ」といったらこういう意味だからな。

interface C{
 public static final int VALUE = 1;
 public abstract void runMethod();
}

class B {
 private C c;
 
 public B(C c){
  this.c = c;
 }

 getC(){
  return c;
 }
}

「実装する」の意味
class B implements C{
 public void runMethod(){
  //ここに実装
 }
}


141 :デフォルトの名無しさん:03/03/16 17:50
>>133

独自の考えはやめた方が。

142 :105:03/03/16 17:56
>>140
class B {

class B interface C{
だよね?




143 :デフォルトの名無しさん:03/03/16 17:58
>142
それ、何言語?

144 :105:03/03/16 17:59
やべ、142でまた変な事書いてしまったかな?
はぁ。Javaの本を探しに逝ってくる。


145 :Java太郎 ◆DMVtSSFzcg :03/03/16 18:01
>>144
ダメ!行かないで!!
ヽ(´Д`ヽ)(/´Д`)/イヤァ〜ン

146 :デフォルトの名無しさん:03/03/16 18:03
>>142
お前はちゃんとプログラミングしているのか?

机上の空論だけで済ますのは止めれ。

ちゃんとコンパイルしろ。
んで自分の目でちゃんと確かめろ。

147 :デフォルトの名無しさん:03/03/16 18:08
それは机上の空論か?

148 :デフォルトの名無しさん:03/03/16 18:20
机上の空論というよりも論にすらなってない。

149 :デフォルトの名無しさん:03/03/16 18:26
なんかキモイやつらばかりだね、ここは。

150 :デフォルトの名無しさん:03/03/16 18:27
そうだな。とくに>>149とか

151 :デフォルトの名無しさん:03/03/16 18:29
implementsとinterfaceを混同してしまっているんだろう。

152 :Java太郎 ◆DMVtSSFzcg :03/03/16 18:34
>>150
わかってないな!おまえ・・・
一番キモイのはオレだ!!
ポリモルフィズムの利点がよくわからない、今日この頃ヾ(´ー` )ノ

153 :デフォルトの名無しさん:03/03/16 18:37
JAVAの場合、Runnableとか見れば多少の利便性は解るだろうに。
Threadクラスの作成者はJAVAのプログラマがどんなクラスを実装
するのか知る事はできない。
だが、Runnableというインターフェースを定義しておく事で
ユーザの任意の元、未知のクラスにrun()というメソッドが
実装される事が保障され、Threadクラスから呼び出す事ができる。

154 :デフォルトの名無しさん:03/03/16 18:37
>ラーメンクラスと、interfaceと、その他の追加するクラス関係が分かれば
>納得すると思う。できれば図キボンヌ。

interface 文字出力{
  void StrOut( String a );
}

class 画面クラス implements 文字出力
class プリンタクラス implements 文字出力
class 音声クラス implements 文字出力
であれば、

ラーメンタイマーは文字出力のクラス変数 tmpOut を持つことができる。
文字出力 tmpOut;

tmpOut の実態のクラスが何であるかにかかわらず
     tmpOut.StrOut("お時間がきました");
というメソッドが使える。
もちろんtmpOut変数にはセレクタから、実体を渡されて代入されている必要がある。
ラーメンタイマーが出力先の実体クラスを知る必要はない。
便利である。

155 :デフォルトの名無しさん:03/03/16 18:41
ダメポ銀行のA嬢

A嬢は、ダメポ銀行に入行して2年目、窓口業務もかなり板についてきた。
実はA嬢はひそかにファンドマネージャになりたいと思って、
自己研鑽を重ねている。その成果が現れたのか、最近では
先輩社員がいろいろと相談を持ちかけてくれる。
上司も見る目も変わってきたようだ。
でも、まだまだ配置換えは期待できそうにない。
内心歯がゆい思いをしながら、今日も窓口に座る。
一旦窓口に座れば、窓口業務をこなさなくてはならない。
その時間はA嬢は、お客さまと銀行を取り持つ窓口係という、
大切なインタフェースの役割を果たしている。

156 :デフォルトの名無しさん:03/03/16 18:42
>>153
初心者にスレの話しても混乱するだけと思われ

157 :デフォルトの名無しさん:03/03/16 18:49
コンストラクタに自分の上位インタフェース渡すパターンって何?

158 :デフォルトの名無しさん:03/03/17 10:28
天気いいなぁ・・・

159 :デフォルトの名無しさん:03/03/17 11:05
なんですかラーメンタイマーって。
じゃあ俺もぽりもーひずむの利点を麺にちなんで例えてみる。

俺は製麺工場の技術主任。
架空の製麺機をプログラミングで作ってみたい。

工場ではうどん、蕎麦、ラーメンの3種を製造してる。
作る過程や材料は全部てんでバラバラ。共通性は殆ど無し。
共通していることといえば、麺を作るという事だけ。

という事で俺はまず製麺interfaceなるものを定義してみた。
これはJAVAでいうところのinterfaceですな。
メソッドはひとつ、製麺ボタン()を定義したのみ。
定義したといっても、製麺interface自体は空っぽ、
実体は無い。何の製麺機かすらも決まってない。

つづく

160 :デフォルトの名無しさん:03/03/17 11:10
> 製麺ボタン()を定義したのみ。
> 製麺interface自体は空っぽ

定義したのか、空っぽなのか、どっちやねん。
それに、メソッド名が名詞てなんやねん。



161 :デフォルトの名無しさん:03/03/17 11:16
>>159の続き

じゃ、そろそろ、うどん製麺機、蕎麦製麺機、
ラーメン製麺機を作ってみますか。。
ここで俺は当初の予定通り、製麺機を実装するにあたって、
それぞれの製麺機に"製麺interface"をインプリする事にした。
それって具体的にはどういう事か?
それぞれの製麺機は全く異なる機械で、内部動作や外見は異なるんだが
どの機械にも同じように製麺ボタン()を実装する、という事だ。
どの製麺機もこの製麺ボタン()さえ押せば、材料を加工して麺が
できあがるされる事が保障される。これだけ。
でも中でやってる事はとっても複雑なんだけどね。

つづく

162 :Java太郎 ◆DMVtSSFzcg :03/03/17 11:18
定義して空っぽって
抽象メソッドみたいだね。

HAS-A関係(?)を使って
擬似的に多重継承できないのかな?

163 :デフォルトの名無しさん:03/03/17 11:23
>>161の続き

工場の生産ラインには常時青鼻を垂らしてるバイト君が働いている。
彼には入社時に製麺インターフェースの操作方法だけ教え込んだ。
彼のできる事といえば、製麺インターフェースを実装してある
3つの製麺機を目の前にして、ひたすら製麺ボタン()を押すのみ。
彼は頭が足りないので、麺がどのような工程で作られている
のかを知らない、というか、それ以前に目の前の製麺機が何の
製麺機なのかすら知らない。。いや、知る必要すらないのだ。
何故なら何の製麺機であろうと、製麺ボタン()さえ押せれば
麺が出来上がるのだから。。

つづく

164 :デフォルトの名無しさん:03/03/17 11:32
>>163のつづき

工場の生産ラインは順調だ。
バイト君の目前に製麺interfaceを実装した製麺機を置いてやれば、
それが何の製麺機であろうと、彼は麺を見事に作り上げていく。
近々、新商品としてスパゲッティを新たに手がける予定だ。
当然パスタ製麺機も製麺インターフェースをインプリした
機械にする予定なので、新たにバイトを増やす必要も無く、
既存のバイト君に新たな教育をする手間もかからないだろう。


165 :デフォルトの名無しさん:03/03/17 11:45
話をややこしくするだけの人ってたまにいるね。
プロジェクトに入ってくるととても迷惑。

166 :デフォルトの名無しさん:03/03/17 11:50
いいたいことはわかるのだけどね。

あらかじめ言いたいことが分かってる私には、なんでもないけれど、
分かってる人だけにわかればいい文章なんて、ここに書く意味ないし、
分かってない人に分かってもらうには、あまりにも不親切な誤りを含んでいる。


167 :デフォルトの名無しさん:03/03/17 11:54
>不親切な誤りを

向学のため、指摘していただけると有りがたい。

168 :デフォルトの名無しさん:03/03/17 11:56
>>106 で指摘したけれど、

中身が空っぽの interface

中身が空っぽの method
の違いをキチンと理解、区別しようね。

169 :デフォルトの名無しさん:03/03/17 11:59
それは機械として中身は空っぽという事を言ったつもりなんだけど。
機械に例えたりプログラムに例えたりと
曖昧な例え方がいけなかったかな?

170 :デフォルトの名無しさん:03/03/17 12:03
機械として中身が空っぽであるなら、ボタンなんてものも無い、と
読むのが普通ではないかい?

まあ、単なる比喩を元に突っ込んだ議論をしてもあまり意味がないと
思うけどさ。曖昧な例え方がいけないんじゃなく、日本語の記述に
無頓着なのがいけない気がする。

171 :デフォルトの名無しさん:03/03/17 12:05
まあこのスレの趣向から言って
ポリィモーフィズムの雰囲気さえ
掴めれば問題ないんでない?
JAVAの話が主体じゃないんだし

172 :デフォルトの名無しさん:03/03/17 12:07
>>170
悪かったよ。
もう余計な口は出さん事にするよ。

173 :デフォルトの名無しさん:03/03/17 12:11
>>172

ありがとう。
ほんとうにそうたのむよ。

174 :デフォルトの名無しさん:03/03/17 12:23
>173
ご満悦そうだな(w

175 :デフォルトの名無しさん:03/03/17 17:08
>>162
そういうのは多重継承とはいわんよ。
単に集約してるといえばいいのさ

176 :Java太郎 ◆DMVtSSFzcg :03/03/17 17:18
>>175
あなた頭いいでしょ?
わかる!!わかるんだよ・・・オレには。

多重継承ではないと、後から気づきましたよ!
ハッハッハ、こりゃ一本取られましたなw

集約なんだ・・・勉強になりました。

177 :デフォルトの名無しさん:03/03/17 17:38
C++と比べてJAVAはクラスの
多重継承ができない代わりか
どうか知らんけど、
implemetsというキーワード
を提供しているが、それによって
良くなった点と悪くなった点を
誰か挙げてくれないか?

178 :デフォルトの名無しさん:03/03/17 17:47
>>177
implementsはクラスへのinterface実装専用。

悪くなった点 : ちょっと記述が長くなったという程度。
MixJuiceやRubyのようなモジュール分割がしにくい。

よくなった点 : クラス継承においてダイヤモンド継承によるメソッドやフィールドのバッティングの心配がなくなった。
インターフェースがインターフェースを継承する場合は、この問題は起こりうるので要注意。

実装の多重継承は混乱のもとといわれてきた。それをコンパイラが禁止することで
プロジェクトでこっそり実装の多重継承をするプログラミングをさせないことで
バッティング問題を解消できる。

179 :デフォルトの名無しさん:03/03/17 17:52
でも綿密に管理されたコードだったとして、
バッティングの心配とかを抜きにすれば、
多重継承できない事でコーディング量が増えたり
不便になったという事は考えられるんでない?

180 :デフォルトの名無しさん:03/03/17 17:56
ATLとか見るとな

181 :デフォルトの名無しさん:03/03/17 18:14
>良くなった点と悪くなった点を誰か挙げてくれないか?

まあ、広域変数とgoto文もそうだけど、誰が使ったか、
影響があるのはどこかを完全に把握してれば問題は回避できるけど、
分からなくなったらグチャグチャになったら取替えしが
つかないってことだよね。
おれは予防のコストはあとから大変になることを考えれば十分に見合う気はする。
特に複数の人でプロジェクトを進める場合はね。
でも、このコスト感覚は人によって違うと思う。

182 :デフォルトの名無しさん:03/03/17 19:15
>>179
実装の多重継承の危険性はソフトウェア工学の研究で実証済み

183 :デフォルトの名無しさん:03/03/17 19:23
>>182
だから、危険か危険じゃないかは人によって違うだろ。
使う人間によっては便利にもなるし、危険にもなる。
そもそも、お前のように自分の観点でしか物を見れない
奴がいるから危険なんだよ、バーカ。

184 :デフォルトの名無しさん:03/03/17 19:31
独りで書いて使うぶんにゃとても便利だろうな。
多人数が同時に書いたり使ったりだと大変だろう。

185 :デフォルトの名無しさん:03/03/17 19:32
そもそも多重継承できない事で代替の方法でコーディング量が増えることは少ないわけだが。
逆に減ることもあるわけでな


186 :デフォルトの名無しさん:03/03/17 19:54
CPPの多重継承の機能はJAVAの
interfaceでは完全に代替できない。
コードの再利用という観点からすれば
実装を継承できるのとできないとでは
やっぱ色々と違うでしょ

187 :デフォルトの名無しさん:03/03/17 21:23
わからん・・・。
手続き型言語のサブルーチンじゃだめなの?
どこから呼び出しても使える便利なサブルーチンをたくさん作ってさ、あとはメインルーチンからどれをどう呼び出すかだけプログラムすればいいようにすれコーディングは十分ラクできるじゃん。
オブジェクト指向はさらに何をラクしたくてできた言語なわけ?
よくできたサブルーチン集を作ることとの決定的な違いってなによ?

188 :デフォルトの名無しさん:03/03/17 21:41
よくできたサブルーチン集と、それが内部で使うデータを一塊にする

あと、オブジェクト指向は言語じゃない

189 :デフォルトの名無しさん:03/03/17 21:43
>>187
コードの再利用とか不必要な情報の隠蔽とか利点はいろいろあると思う。
まあ特に必要を感じないんだったら従来どおりにやればいいと思うよ。

190 :デフォルトの名無しさん:03/03/17 21:45
>>188
低能な突っ込みやめれ。
言いたいことは解るだろう?

191 :デフォルトの名無しさん:03/03/17 21:51
モジュールとして完成度の高いプログラムはアセンブリ言語でも書くことが出来る。
したがって、オブジェクト指向型の言語は必須ではない。
しかし、オブジェクト指向型言語は、モジュールの完成度を高めるための支援を言語レベルで行う。
いわゆる勘違いによる間違いが減る。それだけである。が、これは圧倒的な生産性の向上を意味する。
よく出来たサブルーチンを作れる人ならば、オブジェクト指向の支援を便利に感じるであろう。
まずは良く出来たサブルーチンの条件、モジュール強度と
モジュール結合度などから学びはじめるのが良いだろう。

192 :デフォルトの名無しさん:03/03/17 22:02
>いわゆる勘違いによる間違いが減る。それだけである。

それだけじゃないと思うが(w

193 :デフォルトの名無しさん:03/03/17 22:10
オブジェクト指向の利点が理解できないひとは
もう無理にオブジェクト指向を理解しなくてもいいと思う
しょうがないよ、脳みその出来は個人差があるんだから
世の中にはポインタですら理解できない人もいるんだから


194 :デフォルトの名無しさん:03/03/17 22:14
>>187
生産性。

OOPだと、ポリモーフィズムとか、色々融通が利く。サブルーチンではこうもすっきり
いかないで、引数の型違いとかの名前や内容が微妙に違う関数とかを作らなくては
ならないケースが出てしまい、それを使う側のコードもそれ用に書かなければならず、
その手間が面倒になり、結果、生産性が落ちる。

OOでは、インターフェースさえきちんと設計しておけば、メンテはめっちゃくちゃ楽。

・・・とかいいつつ、全然初心者だったりする儂。

195 :デフォルトの名無しさん:03/03/17 22:17
>>193
短絡的な意見ありがとうございます。

196 :デフォルトの名無しさん:03/03/17 22:29
オブジェクト指向によるコードが再利用できる程度が知れてます。

197 :デフォルトの名無しさん:03/03/17 22:33
struct 男;
struct 女;

void 男絶頂(){}
void 女絶頂(){}

class 人間{
絶頂()
}
class 男:人間{}
class 女:人間{}

人間.絶頂()

手続きだと性別ごとに絶頂を呼び出さないとだめだが、オブジェクト指向でクラスをつかい継承すると絶頂が1つで済む。

198 :デフォルトの名無しさん:03/03/17 22:37
>>187
構造化手法だけではカプセル化という概念を導入できない。

UMLかJavaの勉強をすればオブジェクト指向を素早く理解できる。

構造化手法だけでは各コンポーネント間の結合度を凝集度を下げることは
容易ではない。

各ソフトウェアコンポーネントは互いに低い結合度で結びつきあっていることが望ましい。
一つのコンポーネントは互いに関連のある責務だけから形成されていることが望ましい。

これが構造化手法の研究成果であるという。

199 :デフォルトの名無しさん:03/03/17 22:51
ときに、人間クラスがあったとして、そこから男・女クラスが
派生しているとして、sex() はOO的にどこに実装されるのが
妥当ですか?

200 :デフォルトの名無しさん:03/03/17 22:57
>>199
sexは名詞というの分かっているか?

201 :199:03/03/17 22:59
ああ、では fuck (w でもいいですが。

202 :デフォルトの名無しさん:03/03/17 23:05
Sexは一見動詞に、つまりメソッドであるように思えます。
しかし、この分析はよくある間違いです。
Sexは誰かが持っているものでもないし、何人でやる行為であるかさえ決まっていないからです。
Sexとは柔軟で複雑な関係のことを指す言葉です。
従って、関係を表すSexインターフェイスを作り、NomalSexオブジェクトを実装するかたちにしたほうが良いでしょう。
参加者はentryメソッドで集い、startメソッドで宴が始まるのです。

203 :199:03/03/17 23:09
なるほどなるほど、至極納得であります>>202

204 :デフォルトの名無しさん:03/03/17 23:17
男ばかりがエントリされたときはstart時にアブノーマル例外を送出

205 :デフォルトの名無しさん:03/03/17 23:18
public class Sex {
 public static final UNKNOWN = 0;
 public static final MALE = 1;
 public static final FeMALE = 2;
 public static final HOMOSEXUAL = 3;
 private int sex;
 public Sex(int sex) throws SexException {
  try {
   if(0 <= sex & sex <= 3)
    this.sex = sex;
   } else {
    throw new SexException("そんな性別はありません");
   }
  } catch(SexException e){
   e.printStackTrace();
  } catch(Exception e){
   e.printStackTrace();
  }
 }
 public int getSex(){
  return sex;
 }
}
public class Person {
 private Sex sex;
 private String name;
 public Person(String name, Sex sex){
  this.sex = sex;
  this.name = name;
 }
}

206 :デフォルトの名無しさん:03/03/17 23:33
お前ら熱いね

207 :デフォルトの名無しさん:03/03/17 23:37
public interface Penis {
public String getPenisSize();
}
public abstract class Man implements Penis{}
public class Takeshi extends Man implements Penis {
public String getPenisSize() { return "大きい";}
}
public class Masaru extends Man implements Penis {
public String getPenisSize() { return "小さい";}
}
public class Woman {
public void sex( Penis p ) { System.out.println( "あなたの ちんこ" + p.getPenisSize() + "のね" ); }
}
Woman woman = new Woman();
woman.sex( new Takeshi() );
woman.sex( new Masaru() );

208 :デフォルトの名無しさん:03/03/17 23:38
中の人も大変だな

209 :デフォルトの名無しさん:03/03/17 23:38
Man implements Penis は余計だった

210 :デフォルトの名無しさん:03/03/17 23:43
オブジェクト指向の基本は、現実世界の事象をできるだけ
近い形でコンピュータ上にモデル化すること。
現実社会がコミュニケーションで成り立っているように、
オブジェクト同士もメッセージのやり取りで成り立つ。
メッセージパッシングこそ、オブジェクト指向のエッセンス。
継承なんかは後付けの考えだ。

これは、例を挙げれば、俺が弁当屋に行って海苔弁を買い、
おもちゃ屋に行ってPS2を買うというのを、素直にモデル化するなら、
「弁当屋」「おもちゃ屋」「海苔弁」「PS2」「お金」「注文」
というオブジェクトが出てくる。
「弁当屋」に「お金」と「注文」を渡せば、「海苔弁」が、
「おもちゃ屋」に「お金」と「注文」を渡せば、「PS2」が、
それぞれ返ってくる。

いわゆる
海苔弁 弁当屋.売れ(お金, 注文)
PS2 おもちゃ屋.売れ(お金, 注文)
となる。

これがオブジェクト指向の基本。

(つづく)


211 :デフォルトの名無しさん:03/03/17 23:44
しかし、弁当屋は海苔弁ばかり置いてあるわけではなく、
唐揚げ弁当や焼き肉弁当もある。

ここで頭の良いヤシは、海苔弁と唐揚げ弁当と焼き肉弁当の
共通点に気が付く。どれも弁当だと。単におかずの違いだと。
そこで、「弁当」をもっと考えてみる。
「弁当」は「おかず」と「ごはん」から構成されていて、
「値段」がついていると。

海苔弁の場合は
「ごはん」コシヒカリ
「おかず」海苔
「値段」280円
であり、
焼き肉弁当の場合は
「ごはん」コシヒカリ
「おかず」焼き肉
「値段」480円
であると。

オブジェクト指向では、この場合「弁当」をクラスといい、
「ごはん」「おかず」「値段」などをクラスの属性という。

そして「弁当」を考え出したことで、より汎用的な
次のメッセージが出来ることに気がつく。

弁当 弁当屋.売れ(お金, 注文)

(つづく)


212 :デフォルトの名無しさん:03/03/17 23:44
頭の冴えているヤシは、さらに「弁当屋」と「おもちゃ屋」にも
共通点があることに気がつく。いわゆる「商店」であり、
なんらかの「商品」を売って、「お金」をもらうのであると。

「商店」をより具体化した「弁当屋」は弁当という商品を売る商店であり、
「おもちゃ屋」はおもちゃという商品を売る商店であったのである。

オブジェクト指向では、こういう場合、
「商店」と「弁当屋」は継承関係にあるといい、
「商店」をスーバークラス、基底クラスなどといい、
「弁当屋」をサブクラス、派生クラスなどとのたまう。

思考の流れとは逆なのが面白いだろう。

(つづく)


213 :デフォルトの名無しさん:03/03/17 23:45
さて、「弁当屋」と一口に言っても、おなじみのほかほか亭もあれば、
ちょっと値段の高い味美弁当屋もある。バイト代が入って懐が暖かい
ときは、味美弁当屋にかぎる。こういう風に、実際に行く弁当屋は
一軒一軒具体的な違いを持っている。

オブジェクト指向では、ほかほか亭や味美弁当屋を「弁当屋」クラスの
具体的な実体、すなわちインスタンスと考える。
紙に書いた弁当屋では弁当は買えない。実際の弁当屋に行かなければ。
すなわち、基本的にはインスタンスに対してメッセージを送ることで
処理は進められていく。
クラスは、インスタンスの雛形であり、インスタンスを作るのに
利用されるというのが基本である。
もし君が弁当屋をはじめるなら、他の弁当屋を参考にするだろう。
そういうことである。

(つづく)


214 :デフォルトの名無しさん:03/03/17 23:45
さて、このヤシはたまに友達からレアものビデオなんかも買うのである。

レアものビデオ 友達.売れ(注文,お金)

というわけである。ここでヤシは思索する。
はたして、友達は「商店」なのかと。
しかし、時には「商店」と同じようにものを売ってくれると。
「売れ(注文,お金)」というメッセージは、「商店」だけじゃなく、
友達にも通用すると。
それじゃ、そのメッセージだけ切り出して、「買い物」という
名前にしておこうと。

オブジェクト指向では、この「買い物」をインタフェースとよび、
「買い物」が出来る相手なら誰にでも
「売れ(注文,お金)」というメッセージを送ることができる。
「友達」が「商店」ではないように、
インタフェースを使うことで、継承関係を超えて、
ダイナミックなモデルを実現できるのだ。

そして「友達」はいつも「買い物」のインタフェースでいるわけではなく、
いろんなインタフェースを使ってこのヤシと関係を作り上げている。
さらに、「友達」は親に対しては「息子」のインタフェース、
先生に対しては「生徒」のインタフェースを使っているかもしれない。

215 :デフォルトの名無しさん:03/03/17 23:46
みなさん食い物に例えすぎ(w
別にいいけど。。。
どんどん書いてくれ

216 :デフォルトの名無しさん:03/03/17 23:57
C++では普通に多重継承してて、JAVAでは出来ないので正直設計がしにくい言語だと思った。
もう慣れたが。


217 :デフォルトの名無しさん:03/03/18 00:03
正直>>207はわかりやすい

218 :なおしとけ:03/03/18 00:21
public interface Penis {
  public String getPenisSize();
}
public abstract class Man implements Penis{}
public class Takeshi extends Man {
  public String getPenisSize() { return "大きい";}
}
public class Masaru extends Man {
  public String getPenisSize() { return "小さい";}
}
public class Woman {
  public void sex( Penis p ) { System.out.println( "あなたの ちんこ" + p.getPenisSize() + "のね" ); }
}
Woman woman = new Woman();
woman.sex( new Takeshi() );
woman.sex( new Masaru() );

219 :デフォルトの名無しさん:03/03/18 00:26
良スレ認定

220 :デフォルトの名無しさん:03/03/18 01:52
sexを属性(フィールド)にする手法とどっちがいい?

221 :デフォルトの名無しさん:03/03/18 02:11
僕の部屋はクラスがないので
グローバル変数だらけです

222 :デフォルトの名無しさん:03/03/18 02:37
>>221
どういう喩えでつか?  

223 :デフォルトの名無しさん:03/03/18 02:38
>>222
要は本棚とか無いんじゃないの?

224 :なんとなく:03/03/18 02:41
>218
なんで/TakeshiとMasaruだけ固有名詞のクラスになってんのかね。
s/Takeshi/LargePenisMan/
s/Masaru/SmallPenisMan/

225 :デフォルトの名無しさん:03/03/18 03:28
public abstract class Okama implements Penis{}
public class Hiroshi extends Okama {
  public String getPenisSize() { return "取っちゃった";}
}

Woman woman = new Woman();
woman.sex( new Hiroshi());

何故ManクラスからPenis Interfaceを分離してるかと言えば、
Manクラスの他にもgetPenisSizeメソッドを持つクラスを拡張させられるようにするためである。
もし仮にManクラスにgetPenisSizeメソッドを持たせてあると、このような拡張は不可能である。
これがInterfaceを分離することのメリットである。


226 :デフォルトの名無しさん:03/03/18 08:00
つまり、バター犬をManから派生させるのではなく、
chinko インターフェースをつくって
Manと ButterDog の両方にインプリメント(実装)すべきだということだな。
このやりかたなら、将来、バイブレーターを作ったときも、同じインターフェースが使える。
バイブレーターと Man は継承関係の必然性がないし。

227 :デフォルトの名無しさん:03/03/18 09:05
>>224
抽象化のセンス無し

228 :デフォルトの名無しさん:03/03/18 09:07
>>226
いやーわかりやすい。(w

229 :デフォルトの名無しさん:03/03/18 09:13
>>226
public abstract class Man implements Penis{}
はどういう意味、働きをもってくるの?

230 :229:03/03/18 09:14
あっ却下
>>218

231 :デフォルトの名無しさん:03/03/18 09:21
>>218
これって多重継承に似ているね。
引数でクラス名を渡しているところが異なるだけで、
クラスを隠蔽化する為に、Java開発者が無理やりinterfaceやabstractを
とってつけたみたいだ。
なぜなら、Javaは全てクラスで表現するという制約を自ら課しているから。

232 :デフォルトの名無しさん:03/03/18 09:27
public class Woman {
  public void sex( Penis p ) { System.out.println( "あなたの ちんこ" + p.getPenisSize() + "のね" ); }
}
は、Penisを引数の型に使っても起こられない?


233 :デフォルトの名無しさん:03/03/18 09:34
>>229
Manという言葉があっても、それは単に概念とか分類であって
実際にManという"物"が存在する訳ではない。
TakeshiやHiroshiは"物"として存在するが、Manは存在しないという事。
でも後々、TakeshiやHiroshiを個人の単位ではなく、
Manという分類で扱いたくなるかもしれない。

234 :デフォルトの名無しさん:03/03/18 09:38
>>232
言葉の意味から考えれば、
public void sex( Man m )
が相応しい。
或いは、
public void insert( Penis p )
など。

235 :デフォルトの名無しさん:03/03/18 10:16
>>225 >>218
そもそもhas-aの関係にあるものをそうやってimplementsする
形式にすべきかも疑問。
それじゃis-aの関係になってしまう。
"He is a penis."

集約、コンポジション集約で十分ではないか?

>>231
>なぜなら、Javaは全てクラスで表現するという制約を自ら課しているから。
オブジェクト指向だから当たり前。JavaソースはUMLクラス図でちゃんと表現できる。
C++のソースはどんなソースでもクラス図で表現できるとは限らない。
interfaceやabstract同様の機能はM$がJavaを真似て作ったC#でも取り入れられている。

236 :デフォルトの名無しさん:03/03/18 10:25
別に問題ないんじゃない
PenisはHourseにだってimplementsできる。
woman.sex( new Hourse )とか、、
そんな獣姦ビデオとかあるし。

237 :デフォルトの名無しさん:03/03/18 10:37
知識は沢山持ってても抽象化のセンスが乏しい奴はいる。
そういうSEは結構いたな。
抽象化ってのは別部分の能力なんだろうか。
要は分類だよな。

238 :デフォルトの名無しさん:03/03/18 10:42
>>235
>abstract同様
抽象クラスと純化相関数入りのクラスにどれほどの違いがあるんですか?

239 :デフォルトの名無しさん:03/03/18 11:11
>>238
抽象クラスにも実装済みで継承可能なメソッドを入れることができるでしょう。
抽象クラスは中に少しでもabstractなメソッドがあればクラスも抽象(abstract)と見なされる。
抽象クラスは継承した具象クラスがないと使えない。
抽象クラスはインスタンスを作れない。

Javaには仮想関数という用語は無い。
Javaはvirtualをつけなくても継承できる。
変わりにfinal宣言をすると継承を禁止する。
いうまでもなく、finalとabstractを併用することはできない。

つーか純仮想関数って何?
UMLでもそんな言葉聞きません。

240 :デフォルトの名無しさん:03/03/18 11:18
>要は分類だよな。
Sヨ板がいまだに学問・理系カテにありますから・・・。

241 :デフォルトの名無しさん:03/03/18 12:45
>>239
C++も知らないくせにC++との差別化とかほざいてるわけか。浅いな。そこが。

242 :デフォルトの名無しさん:03/03/18 12:53
>純仮想関数
純粋仮想関数の typo だと思われ

243 :デフォルトの名無しさん:03/03/18 13:33
>>241
Javaも知らないくせにJavaを批判しているわけか。浅いな。そこが。

そもそも純仮想関数という言葉もUMLでは通じないぞ。
C++の用語はUMLでは殆ど死語と化している。

244 :デフォルトの名無しさん:03/03/18 13:35
>>243
言語機能とオブジェクト指向用語とごっちゃになってない?

245 :デフォルトの名無しさん:03/03/18 14:18
純粋仮想関数ってJavaでいうabstractメソッドのことか。

C++の場合オーバーライドし忘れてもコンパイルエラーにならないのか。
Javaだとエラーが出てくれるのでメンテナンスが楽。

C++ではこう定義するのか
virtual void doMethod() = 0;

ちょっと奇怪に見え

246 :デフォルトの名無しさん:03/03/18 14:19
低能な奴ほど言葉の問題にやたらこだわろうとするな。
もちろん言葉は大切、慎重に選んで使わなきゃならないが、
ここで重要なのは指向または志向または思考なわけで、
大体のニュアンスが伝わればなんら問題ない。

247 :デフォルトの名無しさん:03/03/18 14:21
>C++の場合オーバーライドし忘れてもコンパイルエラーにならないのか。
エラーになるよ。純粋仮想関数を含んだクラスのインスタンスは
生成できないし、それを継承したクラスが純粋仮想関数をオーバー
ライドしなければやっぱりインスタンスは生成できない。

248 :デフォルトの名無しさん:03/03/18 14:28
>virtual void doMethod() = 0;
>
>ちょっと奇怪に見え
確かに。
vtable へのポインタを 0 で初期化するという意味らしい。

249 :デフォルトの名無しさん:03/03/18 19:06
>235
じゃあ「interface Penisable」だったらいいのか?


250 :書き直し:03/03/18 19:13
public interface Penisable {
  public String getPenisSize();
}
public abstract class Man implements Penisable{}
public class Takeshi extends Man {
  public String getPenisSize() { return "大きい";}
}
public class Masaru extends Man {
  public String getPenisSize() { return "小さい";}
}
public class Woman {
  public void sex( Penisable p ) { System.out.println( "あなたの ちんこ" + p.getPenisSize() + "のね" ); }
}
Woman woman = new Woman();
woman.sex( new Takeshi() );
woman.sex( new Masaru() );

その後、Okamaクラスを追加する必要が出てきた。
public abstract class Okama implements Penisable{}
public class Hiroshi extends Okama {
  public String getPenisSize() { return "取っちゃった";}
}

Woman woman = new Woman();
woman.sex( new Hiroshi());

251 :デフォルトの名無しさん:03/03/18 19:27
>>249
>>225>>226>>236を読みなさい。
俺は変える必要は何も無いと思う。
そもそもPenisableって意味わからん。

252 :デフォルトの名無しさん:03/03/18 19:28
>>251
陰根可能

253 :デフォルトの名無しさん:03/03/18 20:02
fuckableのほうがいいよ

254 :デフォルトの名無しさん:03/03/18 20:16
>>246
人にわかりやすく説明するならクラスやメソッドなどのネーミングにこだわることは重要。
ネーミングが変な名前だと混乱するだろう。

>>249-250 >>253-252
なんか笑える。

>>251
-ableという命名パターンはJavaのAPI、インターフェースでは良く見られるものです。

255 :デフォルトの名無しさん:03/03/18 21:27
>>254
普通ableは動詞につけるもんだと思うが。
なんでもかんでもableつければいいってもんじゃないですよ。

256 :デフォルトの名無しさん:03/03/18 21:34
>>255
ableに詳しい人発見!! 質問させてください
ときどきcompatibleのように単純にable追加したら駄目なのがありますよね
なにか規則でもあるのですか?

257 :デフォルトの名無しさん:03/03/18 21:37
>>256
コンパチはダメな英語ですか?

258 :デフォルトの名無しさん:03/03/18 21:50
>>257
すいません。意味が良く輪からないのですが
駄目なのは自分の英語力です

辞書にのってるやつならいいのですが
複写可能とか辞書にのってないやつはどうしたらいいのか…
間違ってると恥ずかしいので


259 :デフォルトの名無しさん:03/03/18 21:50
>>255
それで>>253「ファッカボー」に改名?

260 :デフォルトの名無しさん:03/03/18 21:53
>>258
もし間違っていたらあとでリファクタリング

261 :デフォルトの名無しさん:03/03/18 21:56
>>258
「〜する + 〜できる」だから
動詞にくっつけるぶんには外人さんにも意味は通るんじゃない?
不安なら作った言葉をgoogleとかで検索してみるといいよ。

262 :デフォルトの名無しさん:03/03/18 22:00
penisable
http://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=UTF-8&oe=UTF-8&q=panisable

fuckable
http://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=UTF-8&oe=UTF-8&q=fuckable

263 :デフォルトの名無しさん:03/03/18 22:03
>>261
! ありがとうございます! なるほど、気づきませんでした。

264 :デフォルトの名無しさん:03/03/18 22:20
>>1は糞だが良スレだな。
やっぱりスレの明暗をわかるのは>>2なんだな。

265 :デフォルトの名無しさん:03/03/18 22:53
勉強しろよ
低脳

266 :デフォルトの名無しさん:03/03/18 23:48
>>264>>2だろ?w
全体を見ないと、良スレかどうかなんてわからない。

267 :デフォルトの名無しさん:03/03/19 14:03
>>266
「低脳」は余計だよね

268 :デフォルトの名無しさん:03/03/19 17:39
Fuckableだとおかしいかね?

Penisでも、おかしいときはおかしいわけで、
例えば、女もPenisを実装できてしまう。
やっぱりFackableかね?
そんでStateパターンのif文で男女判別。

269 :デフォルトの名無しさん:03/03/19 17:52
>女もPenisを実装できてしまう。
ワラタ

亜乱・毛異がないてるぞ。

270 :デフォルトの名無しさん:03/03/19 17:53
>例えば、女もPenisを実装できてしまう。

ふたなり(;´Д`)ハァハァ

271 :デフォルトの名無しさん:03/03/19 18:21
PenisableだかFuckableインターフェース
ManクラスやWomanクラス、HomoSexual(Okama)クラス、
両性具有クラス、奇形児クラス、性別不明クラス
をpackage化して

PenisableだかFuckableインターフェース
からpublic宣言をはずしてpackage外部からアクセスできないようにしたほうがええと思ったわい。

それか PenisだかSexualOrgans(生殖器)インターフェースを作って
(生殖器インターフェースがあるならPenisインターフェースいらない?)

コンポジション集約でhas-aの関係で人間クラスに生殖器フィールドを
設ければいいんじゃないかと。 

272 :デフォルトの名無しさん:03/03/19 18:23
Penisを男性器として解釈するならば、interface名としては相応しくない。
だが、PenisをPenis形状の物として解釈するならば、問題は無い。
Fuckという言葉は性交するという意味合いで使われる事が一般的、
よって意味合いから言えば女性にも実装可能。よって相応しくない。
なにがなんでもableを使いたい人は、Insertableとするのが吉。
Insertableであればバイブにも大根にも実装可能。

273 :デフォルトの名無しさん:03/03/19 18:26
>>271
HomoSexualとOkamaは同列に扱ってほしくない……

274 :デフォルトの名無しさん:03/03/19 18:27
>>271
だからね、Penisableとか言う意味不明な言葉を
当たり前のように使うのは止めなさいね。


275 :デフォルトの名無しさん:03/03/19 18:44
>>273
じゃ、こう? おかまを英訳するとHomoSexualとGayとQueerがでてしまう。
とりあえずQueerを同性愛者にして
Queer == Gay
interface Man
interface Woman
interface Queer
class Lesbian implements Queer, Woman
class HomoSexual implements Queer, Man



//ついでに、別表現
//男の中の女(おかま、ホモ)
class Man {
private Woman woman;
}
//女の中の男(おなべ、レズ)
class WoMan {
private Man man;
}

//漢(おとこ)の中の漢(おとこ)
class Man {
private Man man;
}


276 :デフォルトの名無しさん:03/03/19 18:59
>>275
同性愛者の総称がHomoSexual
・Gayが男性同性愛者
・Lesbianが女性同性愛者
(※Queerは蔑称として使われることがあるらしい)

実際の性別に違和感を覚える人の総称がトランスジェンダー(TG)
・いわゆる「おかま」はMtF(Male to Female)
・いわゆる「おなべ」はFtM(Female to Male)

いわゆる「ふたなり」はインターセクシュアル(IS)と呼ばれ、TGとは異なる。

以上、設計にあたっての用語定義ね。間違ってたら訂正歓迎よん。

277 :デフォルトの名無しさん:03/03/19 19:10
interfaceを引数にとるclassを設計してみると、色々と見えてくる
ことがあると思うんだけどな。

278 :デフォルトの名無しさん:03/03/19 19:23
なんでもかんでもinterfaceにすりゃいいってもんじゃないだろ?

279 :デフォルトの名無しさん:03/03/19 19:25
なんでもかんでもinterfaceにしろとも言ってないわけだが。

280 :デフォルトの名無しさん:03/03/19 19:26
両刀使いってのもあるだろ?BiSexual?

281 :デフォルトの名無しさん:03/03/19 19:27
>>278
>>277はもっと知る事ができるって言いたいのでは?

282 :278:03/03/19 19:31
277に対する文句じゃなかったが、場所が悪かったな。

283 :デフォルトの名無しさん:03/03/19 19:32
interfaceの使いすぎはソースコードの健康を損なう恐れがあります。
使いすぎには注意しましょう


284 :デフォルトの名無しさん:03/03/19 19:33
今気づいたが引数にとるクラスじゃなくて引数にとるメソッドだな。

・変化する可能性のある概念はカプセル化せよ(interfaceで実装を隠蔽)
・実装に対してではなくインターフェースに対してプログラムせよ

この2つを学んだときはなるほどなと思ったよ。SwingのBorderクラス
とか見ていると面白い。自分でカスタムボーダー作って勉強してみる
のがいいと思う。

285 :デフォルトの名無しさん:03/03/19 19:34
ソースコードの健康状態を知るにはどうすればいいのですか?

286 :デフォルトの名無しさん:03/03/19 19:37
変化する可能性のある概念って何?
例えばどんなの?
いい例があったらおせーて。

287 :デフォルトの名無しさん:03/03/19 19:58
>>286
たとえば、ファイルを圧縮するクラスを作ろうとしたと思いねぇ。

class FilePress {
  public void compress(String inputfile, String outputfile);
  public long expand(String pressedfile)
}

ところが、圧縮アルゴリズムはランレングスで実装したのだが、
あとからLZHやらZIPやらSITやらのアルゴリズムを追加したく
なったとする。圧縮アルゴリズムが増えるたびにメソッドを実装
しなおすのは効率が悪いので、

interface PressAlgorithm {
  public void compress(String inputfile, String outputfile);
  public long expand(String pressedfile)
}

abstract class FilePress imprements PressAlgorithm {
}

とかやっといて、FilePressLZHとかFilePressZIPとかのクラスを
FilePressから継承して作れば、追加アルゴリズムだけを作れば
すむことになる。

288 :デフォルトの名無しさん:03/03/19 19:58
>>286
static finalでないインスタンスフィールドのことをいっているんだと思う。

289 :デフォルトの名無しさん:03/03/19 20:27
>>287
なるほど。抽象化の基本ですね。

290 :デフォルトの名無しさん:03/03/19 22:58
ガーベッジコレクションってプログラマーは意識するんですか?

291 :デフォルトの名無しさん:03/03/19 23:12
しない

292 :デフォルトの名無しさん:03/03/19 23:14
ゴミ集めは無意識のうちに実行されます

293 :デフォルトの名無しさん:03/03/20 06:22
ガーベッジコレクションを意識するというより、参照が無くなったこと(不可到達っていうんだっけ?)は
意識します。ただ、うっかりわすれても大抵かってに開放されちゃって問題はでにくい。
自作のコレクションとか作った時に死んだ参照をのこしたりしなきゃ大抵大丈夫。

294 :デフォルトの名無しさん:03/03/20 06:35

           _∧_∧
        / ̄ ( ・∀・)⌒\ ガッ!!
   __    /  _|     |   |
   ヽヽ   /  /  \    |   |           ,,,,,,,iiiiillllll!!!!!!!lllllliiiii,,,,,,,
    \\|  |____|   .|   |           .,llll゙゙゙゙゙        ゙゙゙゙゙lllll,
     \/  \       |   |           .|!!!!,,,,,,,,       ,,,,,,,,,!!!!|
     | ヽ_「\      |   |、         |  ゙゙゙゙!!!!llllliiiiiiiiiilllll!!!!゙゙゙゙ .| 
     |    \ \――、. |   | ヽ         .|     .゙゙゙゙゙゙゙゙゙゙     |
     |   / \ "-、,  `|  |  ヽ       |               |
  _/   /    "-, "' (_  ヽ  ヽ      .|               |
/    __ノ      "'m__`\ヽ_,,,, ヽ      |               |
`ー― ̄          ヽ、__`/ー_,,,, ゙゙゙゙!!!!!!!lllllllliii|               |
                    \゙゙゙゙゙゙゙!!!!!lllllllliiiii|               |
                      \   ヽ   |               |
                       ヽ   \  |               |
                        |     \.|               |
                        `ヽ、,,_ノ|               |
                              ゙゙!!!,,,,,,,,       ,,,,,,,,,!!!゙゙
                                   ゙゙゙゙!!!!llllliiiiiiiiiilllll!!!!゙゙゙゙
                                /.// ・l|∵ ヽ\  ←>>1



295 :コピペ天職:03/03/20 08:27

           _∧_∧
        / ̄ ( ・∀・)⌒\ ガッ!!
   __    /  _|     |   |
   ヽヽ   /  /  \    |   |           ,,,,,,,iiiiillllll!!!!!!!lllllliiiii,,,,,,,
    \\|  |____|   .|   |           .,llll゙゙゙゙゙        ゙゙゙゙゙lllll,
     \/  \       |   |           .|!!!!,,,,,,,,       ,,,,,,,,,!!!!|
     | ヽ_「\      |   |、         |  ゙゙゙゙!!!!llllliiiiiiiiiilllll!!!!゙゙゙゙ .| 
     |    \ \――、. |   | ヽ         .|     .゙゙゙゙゙゙゙゙゙゙     |
     |   / \ "-、,  `|  |  ヽ       |               |
  _/   /    "-, "' (_  ヽ  ヽ      .|               |
/    __ノ      "'m__`\ヽ_,,,, ヽ      |               |
`ー― ̄          ヽ、__`/ー_,,,, ゙゙゙゙!!!!!!!lllllllliii|               |
                    \゙゙゙゙゙゙゙!!!!!lllllllliiiii|               |
                      \   ヽ   |               |
                       ヽ   \  |               |
                        |     \.|               |
                        `ヽ、,,_ノ|               |
                              ゙゙!!!,,,,,,,,       ,,,,,,,,,!!!゙゙
                                   ゙゙゙゙!!!!llllliiiiiiiiiilllll!!!!゙゙゙゙
                                /.// ・l|∵ ヽ\  ←>>294


296 :デフォルトの名無しさん:03/03/20 10:54
( ´Д`)/< 先生!!こんなのを見つけました。
http://muryou.gasuki.com/hankaku/jaz08.html
http://muryou.gasuki.com/hankaku/jaz07.html
http://muryou.gasuki.com/hankaku/jaz10.html
http://muryou.gasuki.com/hankaku/jaz09.html
http://muryou.gasuki.com/hankaku/jaz06.html
http://muryou.gasuki.com/hankaku/jaz05.html
http://muryou.gasuki.com/hankaku/jaz04.html
http://muryou.gasuki.com/hankaku/jaz03.html
http://muryou.gasuki.com/hankaku/jaz02.html
http://muryou.gasuki.com/hankaku/jaz01.html


297 :デフォルトの名無しさん:03/03/21 10:15
そと寒いね。

298 :デフォルトの名無しさん:03/03/21 11:47
評議に時間制限は無い

299 :デフォルトの名無しさん:03/03/21 13:00
オブジェクト指向型言語が威力を発揮するのはある程度複雑な
関連をもった構造を構築するときである。
私はオブジェクト間の関連を図に書くとき紙と鉛筆を使う。
正確には鉛筆ではなく、ペンテルのGraphGear1000という
シャープペンシルで0.3mmの芯を使っている。1000円である。
このシャープペンシルは先端がシャキーンと格納できるので
体感的にも良質な筆記用具といえよう。
私の筆箱には「ペンテル入ってる」状態で消しゴムとグラフギアが集約されている。

私はドキュメントの中に手書きの関連図をスキャナで取り込み、保存する。
ある程度美的感覚が要求される場合にはパソコン上で図を描くが、
比較的時間を取られる作業であるので、ほとんどの場合、手書きである。
設計の作業にはある意味での「試行錯誤」が伴う。
そこで図面上で思考実験を行うわけである。
同じ機能を実現する方法は数多くあるが、良い設計は実装の進化に対する
許容度が高く、時間と共に良いものが出来てくる。
設計で失敗すると、時間と共に実装がボロボロになってくる。

300 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/21 13:28
オブジェクト指向はインチキ。
真の生産性の向上は粒度の小さいサブルーチン型モジュール指向によって成される。


301 :デフォルトの名無しさん:03/03/21 13:35
ふーん、あっそ。で?


302 :デフォルトの名無しさん:03/03/21 13:42
サブルーチン型モジュール指向はインチキ。
真の生産性の向上は可読度の小さいextern宣言外部変数指向によって成される。



303 :デフォルトの名無しさん:03/03/21 13:51
>>299
UML使え。
クラス図くらいツールで描け。

304 :デフォルトの名無しさん:03/03/21 14:21
馬鹿だな。ツールは清書用だろ?
ツールなんて使ってたら、思考の妨げになる。
コピーの裏紙に書きなぐるのが基本だろ。

305 :デフォルトの名無しさん:03/03/21 14:44
ひとそれぞれ、最適な方法は人によって変わるということも
おまえたちは理解しないのですか?

306 :デフォルトの名無しさん:03/03/21 14:51
しかし普通の人は紙とペンで勉強し続けてきたはずだ。
そんな人が急に禿げたらどうなると思う?結果は明白だ。

307 :50:03/03/21 15:06
紙をペンで黒く塗って、
それを頭に。。

308 :デフォルトの名無しさん:03/03/21 15:44
紙に書くって
なんかいい感じだね。

309 :Java太郎 ◆DMVtSSFzcg :03/03/21 16:07
オラ!オラ!オラ!オラ!!

310 :デフォルトの名無しさん:03/03/21 23:19
最高ですか?

311 :デフォルトの名無しさん:03/03/22 01:05
>>305
部品は黙ってろ

312 :デフォルトの名無しさん:03/03/22 05:15
これからはウンコ指向だね。オブジェクトウンコ指向言語Cウンコ、Javaウンコ
C#ウンコ...etc.

313 :デフォルトの名無しさん:03/03/22 08:18
だんだん真っ赤に燃えるんだ

314 :デフォルトの名無しさん:03/03/22 08:49
これが本当のヤケクソ

315 :デフォルトの名無しさん:03/03/22 13:37
コーダとはなにか?

316 :デフォルトの名無しさん:03/03/22 15:01
ソフトウェア開発を設計工程と製造工程とを分けるとすれば、make 実行させている十数秒が製造工程で、それ以外は設計工程である。


317 :デフォルトの名無しさん:03/03/22 15:47
はて?

318 :デフォルトの名無しさん:03/03/22 16:09
●   これがオブジェクトだ

↓あとよろしく

319 :デフォルトの名無しさん:03/03/22 16:10
>>315
ヨーダなら知ってる

320 :デフォルトの名無しさん:03/03/22 16:14
★男はココを見るべし★女と金とサンプルムービー★
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
http://www.pink-angel.jp/betu/linkvp2/linkvp.html

321 :デフォルトの名無しさん:03/03/22 16:20
★ これがメソッドだ


322 :デフォルトの名無しさん:03/03/22 20:53
>>318
うんこみたい

323 :デフォルトの名無しさん:03/03/23 12:51
発言がヤバイ

324 :デフォルトの名無しさん:03/03/23 13:21
こんなスレがだらだら続いてしまう理由はいったい何でしょうか。

325 :デフォルトの名無しさん:03/03/23 13:22
自分もオブジェクト指向の意味が
よく理解できてないんで質問したいんですが、
要するにオブジェクト指向ってのは同じ結果を生み出す
プログラムのソースをどれだけ簡略化できるかってことなのですか?

326 :デフォルトの名無しさん:03/03/23 13:25
長い目で見て。

327 :デフォルトの名無しさん:03/03/23 13:28
>>324
お前みたいな奴が書き込むからです。

328 :デフォルトの名無しさん:03/03/23 13:29
>325
オレの中級レベルの中途半端な知識の範囲で答えると。。。
それは違うと思うw


329 :デフォルトの名無しさん:03/03/23 13:30
>>325
拡張性、移植性、再利用性、堅牢性、コードの可読性を高めるためにもある。

ソースコードを修正せずにクラスを一つ追加するだけで拡張できる
手法と言うものがある、これができるのはオブジェクト指向以外にほかならない。


330 :デフォルトの名無しさん:03/03/23 13:32
オブジェクト指向の利点は、プログラムをオブジェクトと呼ばれる
ブロックに分割して開発できることだ。
だから、分担しての多人数の開発もやりやすいし、改良する場合も
必要なオブジェクトだけ変更すれば良い。

もちろん、オブジェクト指向を使わなくてもルーチン毎、ソース毎
の分割はできるわけだが、オブジェクト指向を使えばもっと見通しが
良くなり、データを不正なアクセスから隠蔽できたりもする。

331 :デフォルトの名無しさん:03/03/23 13:32
thisが曲者ですよね

332 :デフォルトの名無しさん:03/03/23 13:33
>>329
という事はJavaには明るい未来があると?

333 :デフォルトの名無しさん:03/03/23 13:35
>325
ぶっちゃけて言っちゃうと。。。。
何かプログラムを作ろうとする時に
「こういうクラスが必要だろう」って感じでクラスを設計していくと
全体の構想が浮かびやすいんだな。

で、細かいメリットは>329の言う通りなんだけど。


334 :デフォルトの名無しさん:03/03/23 13:38
最近人生がおもしろくない。
そう思いのあなた!
http://www5e.biglobe.ne.jp/~rgxt5nl/index.htmlのページをお試しください!
100種類のタダで遊べるゲームに、
おもしろいパクリ物を集めたコーナーや、
管理人がすぐに素材にしてくれる素材掲示板
ほかにも、2ちゃん掲示板もありますよ!
自作フラッシュもあります。
とにかくいろんなコンテンツが豊富です!
常連になってくれる人大募集!


335 :デフォルトの名無しさん:03/03/23 13:38
>>332
ブロックの組み合わせでプログラムを作るなら、より多くの強力な
ブロックが手に入りやすい環境の方が開発の手間が省けるわけで、
Javaはその辺、微妙というか中途半端というか。

336 :デフォルトの名無しさん:03/03/23 13:39
>>332
なんでJavaが?

337 :デフォルトの名無しさん:03/03/23 13:40
>>330
オブジェクトというブロック?
クラスじゃあないん?

338 :デフォルトの名無しさん:03/03/23 13:45
>>325
違う。

オブジェクト指向とは、現時点では使わない事が分かっているのに、
将来もしかしたら使うかも知れない「機能」をべたべた貼り付けて
「安全性&完全性」を高める手法の事だ。

他国で戦争が起こった為に、万一を考えて某レジャー施設の手荷物検査を
する何処かの国みたいなものだな。

339 :デフォルトの名無しさん:03/03/23 13:47
>>338
なぜ安全性&完全性が高まるのかわかりません

340 :デフォルトの名無しさん:03/03/23 13:48
同じ結果を生み出すプログラムを、いかに単独で完結した部品にできるか。

341 :デフォルトの名無しさん:03/03/23 13:48
構造化手法では関数同士の名前のバッティング、
関数の依存関係の影響
(依存される方を修正すると依存されるほうも修正しなければならないという地獄)
を最小限に抑えることができない。

複数人か長きに渡ってでプログラミングしようものならなおさらのこと。
昔自分が書いたコードを覚えていないなんて事態に直面したときに泣きを見る。
また、関数同士の相互作用が馬鹿にならない。
関数の数が3個の時は相互作用の数は6個。
4個の時は12個、5個の時は20個、6個の時は30個

関数の数がn個の時は相互作用はn^2 - n 個

つまり関数の数が1000個の時は、一個の関数を修正すると
99万9000個もの関数を修正しなければならない恐れがあるということ。
これはたまらない。とてもやっていられない。

そこでオブジェクト指向が生まれた。

342 :デフォルトの名無しさん:03/03/23 13:54
それは名前空間と依存解決の説明であって、オブジェクト指向違う。

343 :デフォルトの名無しさん:03/03/23 13:55
>>341
>そこでオブジェクト指向が生まれた。

オブジェクト指向が生まれたのはそういう理由じゃないんけど。
元々はSmalltalkのメッセージパッシングという手法

344 :デフォルトの名無しさん:03/03/23 14:04
「在る物を、在るがままに」

345 :デフォルトの名無しさん:03/03/23 14:04
オブジェクトとは、いくつかの状態を持ち、メッセージを受け付ける何かである。しかしいまではその定義は、神話の中にしか無い。
まず愚かにも実装効率を優先した者たちにより、オブジェクトはクラスとインスタンスとに分断された。
次にメッセージの送出は自身のポインタを渡す特殊な関数呼び出し、すなわちメソッド呼び出しに変わり、オブジェクト指向は汚されたのである。

346 :デフォルトの名無しさん:03/03/23 14:19
>>345
そなの?メッセージを送るときって、
"単にメッセージを送る"んじゃなくて
"なにかして欲しいから、その意思表示としてメッセージを送る"んでしょ?
ってゆうことは、
"メッセージ送出とメソッド呼び出しは等価"なんじゃない?

オブジェクトがクラスとインスタンスに分断されていないことの
利点が思い付かないし。単純に想像してみても、
"その物が、何であるか(クラス)"と言うことと、
"その物が、そこにある(インスタンス)"と言うことは、全く別のことであると思うし、
つまり
"オブジェクトがクラスとインスタンスに分けられたことにより、オブジェクト指向はより美しくなった"....
とすら言えると思うのだけど。

347 :デフォルトの名無しさん:03/03/23 14:23
>>342
そういば漏れの先輩の担当したコード、
どのクラスのメンバ関数みても static だったなぁ。
その先輩、今は違うプロジェクトに移ってC言語でコード書いてるみたいなんだけど、
「C++はいいなぁ、名前のバッティングがないもんな」とかゆってた。

348 :デフォルトの名無しさん:03/03/23 14:26
>>346
彼は意味わからずに書いてんだから、いちいち相手しなくていいよ。

349 :デフォルトの名無しさん:03/03/23 14:32
さっきから上げてるやつは同一人物か

350 :デフォルトの名無しさん:03/03/23 14:34
>>346
>利点が思い付かないし。

「思いつく、思いつかない」は、一に本人の頭の構造に依存する。

まず、その様な設計の言語が無いか調べれ。
もし見つかったら、それがどう機能しているか(他人の評価を)調べれ。

それならば、(ちゃんと行えば)誰もが同じ結果を示せる。
話しはそれからだ。

351 :デフォルトの名無しさん:03/03/23 14:38
おー中山!!オッスオッス!!

352 :デフォルトの名無しさん:03/03/23 14:40
>>350
ふーん、自分の言葉ではインスタンスとクラスを分離しないことの利点を語れないんだ。
ま、そんな奴と話してもしょうがないね。

353 :デフォルトの名無しさん:03/03/23 14:43
なるほど。なんだか人によってオブジェクト指向の捉え方が違うみたいですね。
とりあえず自分も教えて君ではいけないと思ってe-wordで調べてみました。

 ソフトウェアの設計や開発において、操作手順よりも操作対象に重点を置く考え方。
 関連するデータの集合と、それに対する手続き(メソッド)を「オブジェクト」と呼ばれる一つのまとまりとして管理し、その組み合わせによってソフトウェアを構築する。
 すでに存在するオブジェクトについては、利用に際してその内部構造や動作原理の詳細を知る必要はなく、外部からメッセージを送れば機能するため、特に大規模なソフトウェア開発において有効な考え方であるとされている。
 データやその集合を現実世界の「モノ」になぞらえた考え方であることから、「オブジェクト」指向と呼ばれる。
 例えば、我々がテレビを操作する際には、テレビ内部でどのような回路が働いているかを理解する必要はない。ただテレビの操作方法だけを知っていれば、それでテレビを使うことができる。
 すなわち、「テレビ」というオブジェクトは、自身(の内部を構成する電子回路)を動作させる手続きを知っており、それを利用するためには、(例えばリモコンで)適切なメッセージを与えるだけでよい。
 このように、何らかの「データ」と、それを操作するための「メソッド」の組み合わせが「オブジェクト」である。
 個々の操作対象に対して固有の操作方法を設定することで、その内部動作の詳細を覆い隠し、利用しやすくしようとする考え方と言える。この考え方を応用したプログラミング技法が、オブジェクト指向プログラミング(OOP)である。

要するにユーザーにも開発者にも易しいプログラムの作り方ってことですか?

354 :353:03/03/23 14:44
353は325です。ネーム入れるの忘れてました。

355 :デフォルトの名無しさん:03/03/23 14:46
>>353
長いので全然読んでないけど、

>とりあえず自分も教えて君ではいけないと思ってe-wordで調べてみました。

と書いておきながら、

>要するにユーザーにも開発者にも易しいプログラムの作り方ってことですか?

で締めるのはどうかと。

356 :デフォルトの名無しさん:03/03/23 14:47
>>353
大体正しいけど、「ユーザー」ってのは「ユーザープログラマ」な。


357 :デフォルトの名無しさん:03/03/23 14:49
>>353
なんか、「要するに」って言葉の使い方が
技術に明るくない管理職っぽい感じ。


358 :デフォルトの名無しさん:03/03/23 14:57
>>353
分かったなら、ちょっとここで
「オブジェクト指向」と「構造化手法」の違いを
まとめてみれ。

359 :353:03/03/23 15:00
>>355
そうですねw
でも
>個々の操作対象に対して固有の操作方法を設定することで、その内部動作の詳細を覆い隠し、利用しやすくしようとする考え方と言える。この考え方を応用したプログラミング技法が、オブジェクト指向プログラミング(OOP)である。
ってあるから、ユーザーが操作しやすいようにするってことですよね?
ということは、パソコンで例えると
ユーザーはアイコンをダブルクリックするだけでファイルを開けるけど、
開発者はその裏でfopenだとか色々練らなければいけない。
となりますよね?(多分)
こういう仕組みのことをオブジェクト指向というのでしょうか?

360 :デフォルトの名無しさん:03/03/23 15:06
本に載ってる例題とかって基本的なことばかりだから
オブジェクト指向って素晴らしい!とは思えないなぁ・・・

361 :デフォルトの名無しさん:03/03/23 15:07
>>359
それがほんとに例え話なら、まぁ正しい理解だ。


362 :353:03/03/23 15:07
>>358
えっと、オブジェクト指向ってのは、さっきも書いたようにユーザー(プログラマ)が、
実際パソコンの中でどんなコトが起こっているのか意識しないでも使える手法?
構造化手法ってのは、ユーザー(プログラマ)がいちいちパソコンに直接指令を与えて
情報を引き出す手法?
全くのカンですw

363 :デフォルトの名無しさん:03/03/23 15:11
>>360
デザインパターンの本とか読むといい。
ソースコードから、無様な部分がだいぶ減る。
( プログラミング技法としてのオブジェクト指向の
  能力と使い方が理解できるはずだ。)


364 :デフォルトの名無しさん:03/03/23 15:15
>>359
>開発者はその裏でfopenだとか色々練らなければいけない。
それをやらなくてよい言語が作られたら、
それがOOPか非OOPかに関係なく、
俺は今すぐその環境に移行するのだが・・・

365 :デフォルトの名無しさん:03/03/23 15:15
>>362
ちがうぅ〜
例えば、ファイルを開く関数 fopen() をコールした時、パソコン内部で
何がおこってるのかを知らなくても、プログラマはプログラムを書けるでしょ?
でも、fopen() は、オブジェクト指向的な関数じゃない。


366 :362:03/03/23 15:22
>>365
そう言われてみればそうですねw
じゃあ、ライブラリのstdio.h(自分はCですので)の中の
fopen()関数を定義した人が、本当のオブジェクト指向における開発者だと
言えるのでしょうか?
関数によってオブジェクト指向であるとかもあるんですか?
Cを勉強してる限りだとオブジェクト指向って言葉は耳にしません。
前にC++がオブジェクト指向だとか聞いたような聞かなかったような・・・。

367 :デフォルトの名無しさん:03/03/23 15:31
クラスツリーを変更したくなったとき困るとか、
複数クラスにまたがるようなアクセスが面倒くさい時とかいうのありますよね?
どうするのそこんとこ。

368 :デフォルトの名無しさん:03/03/23 15:32
>>366
fopen()とか、stdio.hで定義されてる全てのものは、
オブジェクト指向的ではありません。というか、
C言語はオブジェクト指向をサポートしません。

オブジェクト指向はメッセージの受け渡しによって
記述するプログラミングパラダイムです。(続く)

369 :デフォルトの名無しさん:03/03/23 15:33
>>367
リファクタリングだ。

370 :368:03/03/23 15:33
続き
例えばファイル読み込みについて書くと、
非オブジェクト指向だと、
1. "ファイルを開く関数"を呼ぶ
2. "ファイルからデータを読み込む関数"を呼ぶ
3. "ファイルを閉じる関数"を呼ぶ

オブジェクト指向だと
1. "ファイル"を表現する、オブジェクト(インスタンス)を作る。
2. そのオブジェクトに"開く"というメッセージを送る
3. そのオブジェクトに"読み込み"というメッセージを送る
4. そのオブジェクトに"閉じる"と言うメッセージを送る。

非オブジェクト指向のときは、どの関数の名前にも"ファイルを〜"と付いてる。
オブジェクト指向のときは、どの操作も"そのオブジェクトにメッセージを送る"となってる。


371 :367:03/03/23 15:36
あと、modern c++ designみたいなのって、自分じゃ作る気にならなくない?
また、使おうにもコンパイラがうまく対応してくれなくて面倒ってのない?
どうするのそこんとこ。

372 :デフォルトの名無しさん:03/03/23 15:36
>>363
ありがとう、今度読んでみます

373 :デフォルトの名無しさん:03/03/23 15:36
>>362
次は「オブジェクト指向」と「カプセル化」の
違いをまとめてみよう。

(一般には「カプセル化」と「オブジェクト指向」は
包含関係ではあるが同値関係ではないと言われているので・・・)

374 :デフォルトの名無しさん:03/03/23 15:38
>>370
非オブジェクト指向とオブジェクト指向の違いはなんとなくわかるけど
それで?ってカンジになっちゃいます(・_・、) グスン

375 :デフォルトの名無しさん:03/03/23 15:40
>>370
じゃあ、Cでfopen()を使っていても、それを
「"FILE *" に "fopen" メッセージを送る」
と呼びさえすれば、それでオブジェクト指向といえるのですか?(w

376 :デフォルトの名無しさん:03/03/23 15:40
プログラミング言語っぽく書くとこんな感じ
File f("filename"); // "filename" ファイルに対応するオブジェクトを作る。
f <- open; // そのファイルオブジェクトに"開く"メッセージを送る。
buf = f <- read; // ファイルオブジェクトに"データを読み込む"メッセージを送る(で、そのデータをバッファに置く)
f <- close; // ファイルオブジェクトに、"閉じる"メッセージを送る。


377 :367:03/03/23 15:42
カプセル化って
#define private public
ってやられたとき困らない?
どうすんのそこんとこ。

やるやつがアホだし、class宣言のトップにprivateなやつならべりゃいいけどさ。

378 :362:03/03/23 15:46
>>370
なるほど。「呼ぶ」と言う動作さえも非オブジェクト指向となるのですか。
自分はCしか出来ないので、オブジェクト指向の言語を勉強するようになったら
より理解を深められると思います。
「オブジェクト指向」と「カプセル化」ですか?
全く分かりませんが、「カプセル化」ってのはモジュラプログラミングのことでしょうか?


379 :デフォルトの名無しさん:03/03/23 15:50
>>378
なんで異なる言葉で呼ばれる概念を = で結ぼうとするのだろう。

380 :デフォルトの名無しさん:03/03/23 15:51
>>377
#ifdef private
#undef private
#endif
か、
#ifdef private
#error ヴォケ!死ね!
#endif

381 :デフォルトの名無しさん:03/03/23 15:54
>>370

Javaの本では普通に「メソッドを呼び出す」という言い回しを
使っているから、そういうのは誤解を招くぞ。

382 :デフォルトの名無しさん:03/03/23 15:58
っていうか、メソッド呼び出しやめて、
すべてのインスタンスにメッセージキューを持たせよう。


383 :デフォルトの名無しさん:03/03/23 15:59
>380
ソースコードを直接いじられたとき困らない?
どうすんのそこんとこ。

384 :デフォルトの名無しさん:03/03/23 16:00
>>381
"メッセージを送ると、結果としてメソッドが呼ばれる"
ってふうには説明されていないのかなぁ。だとしたら鬱だ。

385 :デフォルトの名無しさん:03/03/23 16:01
>>382
全部のメソッドがスレッド(プロセス?)を異にする?

386 :362:03/03/23 16:02
>>379
ですよね。一緒のはずありませんよね。
ちょっとぐぐって調べてみます。

387 :デフォルトの名無しさん:03/03/23 16:02
>>383
なんで困るの?

388 :デフォルトの名無しさん:03/03/23 16:02
Java厨キタ━━━━━(゚∀゚)━━━━━!!!!!

389 :デフォルトの名無しさん:03/03/23 16:03
和ジオ/AnimeComic-Name/7676/

390 :デフォルトの名無しさん:03/03/23 16:05
>>380
ワラタ
こういう心温まるコードを見ると感動すら覚える。

391 :デフォルトの名無しさん:03/03/23 16:07
"fopen"をメッセージを送ると捉えることもできる。
その際、メッセージを送る先は FILE** ではなくシステム。


392 :デフォルトの名無しさん:03/03/23 16:10
>>384
C++やJavaの構文では、「送る」というより、
まさに「呼び出す」という雰囲気が当てはまるから、
言い回しをそれほど意識する必要はない。

393 :362:03/03/23 16:12
調べてみました。
が、
これってそのまんまオブジェクト指向と同じじゃないですか?
違いがわかりません。

394 :デフォルトの名無しさん:03/03/23 16:19
>>393
マメだねぇ。
カプセル化って言うのは「機能とデータをひとまとめにする」ってこと。
オブジェクト指向って言うのは「オブジェクト間のメッセージのやり取りでコードを書く」ってこと。

" オブジェクト指向で扱うオブジェクトは、
  カプセル化されていないと扱いづらい "

対立する概念じゃなくて、独立してるけど関連性の深い概念、だね。


395 :OOモナー:03/03/23 16:21
ったく。
おまいら、オブジェクト指向って何だか分かってんの?
これ以上、「OO=訳分かんない無気味なもの」という状態を
放置したくないので、マジレスする。

Objectを手もとの英和辞典で引いてみろ。
おそらく、
Object:モノ、対象、目的
などの意味が出ているはずだ。
日本の馬鹿な技術者がObject=モノと考えてしまったために、
OO技術の浸透はかなり遅れてしまったわけだ。
いまでもドキュソ入門書では、「モノ(Object)」などという
書き方をしているものが多いはず。
モノ?ふざけるな。そんな不明な定義でオブジェクト指向が
理解できるはずもない。「モノを指向する」とか言われて、
おまいらが混乱するもの無理はない。
だが、考えてみろ。Data Orientedは、扱うデータを中心に
分析設計を行うことである。Object Orientedとはなんぞや。
(続く)


396 :OOモナー:03/03/23 16:21
あえて批判を恐れずにいえば、オブジェクトのより理解しやすい
訳は、「対象」である。ソフトウェアに置ける対象とは、
システム化を行う対象のことである。
ゆえに、Object Orientedは「システム化対象指向」という
訳の方が適切である。つまり、システム化対象を中心に考える
ということである。
たとえば、いままで経理担当者が社員から領収書を受け取って、
帳簿に交際費を計算して記載し、帳尻を合わせた後、社員に
お金を支給していたところをシステム化したいと考えた場合、
オブジェクト指向ではまず、システム化対象を中心に考えるので、
「経理担当者」「社員」「領収書」「帳簿」「交際費」「お金」
など、現実の運用を行う上で、何らかの役割を担っている概念を
ピックアップすることから問題を考えていくのだ。
(気が向いたら続く)

397 :デフォルトの名無しさん:03/03/23 16:25
>>395,396

そんな教科書をコピペしたような説明じゃ分からないから、
こんなスレがたつんだろ。

398 :デフォルトの名無しさん:03/03/23 16:25
>>396
"Object"を”システム化対象”ととらえ直したのに、
システム化対象の例として"「経理担当者」「社員」"など、
"モノ"っぽいものばかり挙げたのでは、何のために
"モノ"という訳語を拒否したのか解りませぬ。

399 :デフォルトの名無しさん:03/03/23 16:31
>>394
>オブジェクト指向って言うのは「オブジェクト間のメッセージのやり取りでコードを書く」ってこと。

goto >>375

400 :デフォルトの名無しさん:03/03/23 16:33
>>396
"システム化対象"と訳したのでは、
もっと抽象的なオブジェクトを扱う段階に進む際の妨げとなるような気がします。
オブジェクト指向の本質とは関係ありませんが、
しかしOOPLを用いてプログラミングする際、
デザインパターンなどは必須な訳です。
その際、Object = システム化対象 という認識では不足です。
たとえば Mediater は、システム化される以前に存在しているシステム化対象ではありません。
旧来の Object = モノ と言う認識の方が優れていると思います。

401 :362:03/03/23 16:33
>>394
そうなのですか。
なんとなく頭では理解できました。
でも、やっぱり実践経験がないのにどーのこーの言うのは良くないですね。
近いうちにオブジェクト指向の言語の勉強を始めようと思います。
それで、是非みなさんにオブジェクト指向を勉強するならこれ!ってな言語を教えて欲しいのですが・・・。

402 :デフォルトの名無しさん:03/03/23 16:34
>>399

>>391

403 :デフォルトの名無しさん:03/03/23 16:38
データ+メソッド

404 :デフォルトの名無しさん:03/03/23 16:38
>>401
Javaでもやっとけば?

405 :401:03/03/23 16:44
Javaですか。じゃあ、ちょっとやってみようと思います。
自分はCしか知らないのですが、そこから入ると考えても
やっぱりJavaが最適でしょうか?

406 :デフォルトの名無しさん:03/03/23 16:45
>>402
∴C言語⊂オブジェクト指向言語

Q.E.D.

何か?

407 :デフォルトの名無しさん:03/03/23 16:46
>>396
すんません、まず >>396 のいう「システム」とは
何かが分からないのですが。

408 :デフォルトの名無しさん:03/03/23 16:47
情報+手続き

409 :デフォルトの名無しさん:03/03/23 16:50
>>406
ちょっと話を逸らすけど、
∴と⊂ってなんの記号ですの?

  MM
 ⊂゚Д゚つ∴スンマソン
  UU

410 :OOモナー:03/03/23 16:57
>>400
そうかな。
「モノ」っていわれて分かる香具師どのくらいいんの?
「モノ」って訳は最低だと思うけどね。
まあ、「システム化対象」ってのも必ずしもいいとはいえないが、
OOの基本的な出発点は、「現実世界の事象を、できるだけ
忠実にソフトウェア上にマッピングする」ってことだ。
まあ、実際にはそれは無理なので、デザインパターンなどの
テクニックが生み出されてきたわけだが。そういう意味では
デザインパターンは、OOを駆使していく過程で生み出された、
後付けのテクニックといえる。それはOOをある程度やってみて
はじめてその必要性がわかるものだ。



411 :デフォルトの名無しさん:03/03/23 17:00
>>402
Cはオブジェクト指向言語ではない。
オブジェクト指向をサポートするような機能がないから。

ただ、Cで書かれたコードを、オブジェクト指向的に理解することはできる。
その際、 「fopen() メッセージをシステムに送信する」などのように
無理のある解釈を行わなければならない場合が多い。

また、オブジェクト(システム化対象?)を軸としてモジュール分割したCのソースコードでは、
"他のモジュールの関数を呼び出す"ことを"他のモジュールにメッセージを送る"
と捉えた方が、理解しやすいかもしれない。
そのような場合であっても、それはそのコードがオブジェクト指向なのであって、
C言語自体がオブジェクト指向な訳ではない。

412 :デフォルトの名無しさん:03/03/23 17:05
>>410
>OOの基本的な出発点は、「現実世界の事象を、できるだけ
>忠実にソフトウェア上にマッピングする」ってことだ。
それはOOの出発点ではなくて、システム構築の
出発点ではないかと・・・

413 :デフォルトの名無しさん:03/03/23 17:06
>>410
そうか、初学者には「システム化対象」の方が分かりやすいのかもねぇ。
んでなれた頃に、システム化対象だけじゃなく、
もっと抽象的なモノもオブジェクトとして扱われることを教えていく、と。

企業とかで研修する際や学生向けにはいいかもね。

414 :デフォルトの名無しさん:03/03/23 17:09
>>411
さて、そこらで一つ >>325

「オブジェクト指向」とは何か、

を教えてはくれないだろうか?

415 :デフォルトの名無しさん:03/03/23 17:11
おまえら難しく考えすぎじゃねーの?

あれだよ、自転車に乗れるようになるまでを考えてみよう。

教える人はどう乗ればいいか分かっている、が言葉でどう伝えたら分からない。
教わるほうはいくら言葉で説明されても理解できない。

じゃあどうすればいいのか? 
答えは実際に何度もこけて、自分で「自転車に乗る」という感覚を身をもって知るしかない。

オブジェクト指向が理解したければ、自分自身で何度も設計を繰り返すのだ。
そうしてやっとオブジェクト指向の感覚が身についていく。

416 :デフォルトの名無しさん:03/03/23 17:12
>>414

    な ん じ ゃ そ り ゃ 。

417 :デフォルトの名無しさん:03/03/23 17:13
オブジェクトとは森羅万象なのだ。
Java/C#でいうObjectクラスに該当する。
全てのクラスのスーパークラスは森羅万象を構成するもの、
すなわちオブジェクトである。

418 :デフォルトの名無しさん:03/03/23 17:24
>>409

∴ = 蕎麦畑 = 蕎麦 = 粋

⊂ = (右辺は左辺に)発情している = 大好き = 憧れ

要するに、

「(余計な機能をたくさん背負い込んだ)"C++" は 粋な "C" に憧れている」

419 :デフォルトの名無しさん:03/03/23 17:30
>>417
んじゃ、俺もObject?

420 :デフォルトの名無しさん:03/03/23 17:51
>>415
>答えは実際に何度もこけて、自分で「自転車に乗る」という感覚を身をもって知るしかない。

言いたい事は分かった。

しかし、一人で散々苦労した挙げ句、やっと乗れるようになって
有頂天になっていた矢先、通りすがりの人に

「それ、(自転車じゃなくて)三輪車だよ」

って指摘されたら萎えるだろ?

421 :OOモナー:03/03/23 17:52
構造化とオブジェクト指向について結合度の観点から考えてみるよ。

構造化分析ってのは、システムを初期化処理、主処理、終了処理という
構造で考えていくことだ。それぞれの部分が、さらに
細分化されて、モジュールという単位になる。
細かく細分化されることで、確かに一つ一つのモジュールの
機能は分かりやすくなったが、解決されない問題もある。
それは結合度の問題。トップから始まるピラミッド形の構造が、
モジュールの結合を強固にしてしまっている。
簡単にいえば、処理する順番が決まっているということだな。
そこで、共通モジュールというのを抽出して、
いろんなところから利用できるようにするというのが
行われる。共通モジュールはいつでも呼び出せるので
結合度が低い。

OOは、結合殿観点からいえば、総共通モジュール化を
狙ったものととらえることができる。時系列に依存する
部分をできるだけ内側に綴じ込め、いつでもどこからでも
処理を呼び出せるようにして、結合度を低く押さえるわけだ。
つまり、OOでは構造化のようなモジュール分割ではなく、
小さなモジュールの見通しの良さを生かしつつ、逆に
オブジェクトの内部に、そのオブジェクトをうまく使うための
初期化処理(これは通常コンストラクタが担う)
終了処理(デストラクタなどが担う)
を内包させ、初期化後は自由に使えるようにしたわけだ。
発想が逆なのがおもしろいね。

422 :デフォルトの名無しさん:03/03/23 18:13
>>420
あーそのとおりだね。 すいませぬ。

423 :デフォルトの名無しさん:03/03/23 18:15
>421
要するにトップダウンではなく
ボトムアップで設計すれば
「オブジェクト指向」になる、ってこと?

424 :デフォルトの名無しさん:03/03/23 18:19
>>423
ならねぇ。
なんでトップダウンやボトムアップって言葉が出て来たんだ?

425 :デフォルトの名無しさん:03/03/23 18:32
>>419
そーいうことになる。
この世に存在するもの全てがオブジェクト、地球も宇宙も生も死もすべてオブジェクト。

オブジェクト指向と似たような概念はプラトン哲学ですでに語られていたらしい。

426 :OOモナー:03/03/23 18:32
>>423
結合度の問題とはちょっとずれるけど、そういう側面はあるよ。
ボトムアップってのは、おそらくシステムの構成要素を
まず事前に洗い出して、それを組み合わせていくってことだろ。
こう書くと、何か難しいことのようだが、実はOOじゃなくても
システムの構成要素の洗い出しってのは、要件分析の初期段階で
やっているはずなんだよね。
構造化の場合は、その分析の結果、このシステムは
○○システムであると大きく捉えて、構造化手法によって
それを再構成しながら実現方式を考えていくけど、
OOの場合は、洗い出した個々の構成要素をできるだけ生かしつつ、
設計・実装まで持っていこうとする。

427 :OOモナー:03/03/23 18:43
>>425
プラトンのイデア論だろ。
クラスとインスタンスの関係を説明するには面白いが、
個人的には、そういうテツガク的な側面を強調する限り、
OOの理解は進まないだろうなと思う。


428 :デフォルトの名無しさん:03/03/23 18:53
>>427
( ´∀`)オマエモナー

429 :デフォルトの名無しさん:03/03/23 18:54
>>427
いや、あれは面白かった。
不変の「永遠の型」、イデアがクラスで、実体がオブジェクトやインスタンス
これは解りやすかった。

あの、小説「ソフィーの世界」にでてくる「ソフィーがいる」世界がクラスで
「ソフィーを小説の登場人物としてその小説を読んでいる側のヒルデと少佐の世界」
が現実世界でありオブジェクトやインスタンスという表現は面白かった。

430 :デフォルトの名無しさん:03/03/23 18:57
恒例のOO派対非OO派のアプリ製作対決して

431 :Java太郎 ◆DMVtSSFzcg :03/03/23 19:05
やい!やい!やい!やい!
テメェら!!

432 :デフォルトの名無しさん:03/03/23 19:53
やいのやいの言うんじゃねぇよ

433 :デフォルトの名無しさん:03/03/23 20:22
>>430
そんなもんどんなアプリ作るかで対決がどうこういってられる問題でなくなる。

434 :デフォルトの名無しさん:03/03/23 23:18
>>430
よーし、それじゃ
「広島県庁の給与計算システム」でどうよ?

435 :デフォルトの名無しさん:03/03/23 23:29
>>434
却下

436 :デフォルトの名無しさん:03/03/23 23:37
んじゃぁ、「PRePで動くBeOS用のGeForce2のドライバ」でどう?

437 :デフォルトの名無しさん:03/03/23 23:57
>>436
却下繚乱

438 :Java太郎 ◆DMVtSSFzcg :03/03/24 08:03
お前ら、夢を作れ!!

439 :デフォルトの名無しさん:03/03/24 08:43
クラスとインスタンスが分断されたことで、オブジェクトは柔軟性を失った。
かつて神話の時代、フィールドやメソッドは、実行時に追加や変更、削除が可能であった。
フィールドにnullなどを代入せずとも、フィールドそのものを「無」として扱えたのだ。

440 :デフォルトの名無しさん:03/03/24 08:46
>434
出席簿に○付けて、学校に行った事にしてくれるプログラム。

441 :デフォルトの名無しさん:03/03/24 08:49
あ、リンク間違った。
>>430

442 :デフォルトの名無しさん:03/03/24 08:50
>>439
単なるMapじゃないの、それ。

443 :デフォルトの名無しさん:03/03/24 08:53
>439
つーか、フィールドって何?
スロットの事?

444 :デフォルトの名無しさん:03/03/24 09:01
最新の音楽情報満載。音楽ファン必見のサイト 
アンケートに答えると、もれなく音楽ギフト券!!
http://camellia16.fc2web.com/ongakudb.html

445 :デフォルトの名無しさん:03/03/24 09:11
>>439
つーかJavaScriptでも使ってれば?
いやマジで
http://www.tokumaru.org/JavaScript/

446 :デフォルトの名無しさん:03/03/24 09:58
キチガイが居るようですが、、

447 :デフォルトの名無しさん:03/03/24 15:00
>>423
ボトムアップはXP (eXtreme Programming)じゃないか?

448 :デフォルトの名無しさん:03/03/24 21:33
プログラムパラダイムとソフトウェア工学を混乱しているヤツが
とても多いようだ。

449 :デフォルトの名無しさん:03/03/24 22:02
>>447
設計はトップダウンでしょ。
コーディングはユニットテストの助けがあるから好きにやれって感じ。

450 :デフォルトの名無しさん:03/03/24 22:04
いや、こうか。
s/設計/分析/
s/コーディング/設計-コーディング/

451 :Java太郎 ◆DMVtSSFzcg :03/03/24 23:20
>>448
解説願います

452 :デフォルトの名無しさん:03/03/25 01:16
>>448
是非

453 :OOモナー:03/03/25 02:16
>>448はおそらく、OOは新しいパラダイムの提示であり、
ソフトウェア工学の範疇では捉えられないといいたいのでは
ないかと思う。
たとえるなら、天動説を信じてる香具師に地動説を示しても、
すぐには理解できないように、OOは新しい世界観の提示であり、
OO以前に固執する限り超えがたい壁があるといいたいのだろう。
いわゆるパラダイムシフトが必要だと。

よく聞く話だし、多少は考える視点を変える必要があるとも
思うが、俺は別な考え方を持っているよ。
OOは、ソフトウェア工学の成果を踏まえた延長上にある
技術だと思っている。その意味でこれまでのソフトウェア工学の
知識はOOを理解する上で、助けになることが多いと思う。
OOは決して特別なものじゃないし、ソフトウェア工学の
側面からOOを利点や欠点を捉えていくことも可能だと
思っている。
だから、いたずらに哲学的なベールをかぶせたり、
必要以上の壁を作るのにはあまり賛成したくない。

454 :デフォルトの名無しさん:03/03/25 02:35
>>114
>implementsはextendsの代わりに使うものであり
Interfaceに対してプログラミングするんだろうがよ。
まぁ、やり方はいろいろあるが。
てめぇは言語仕様から引用してるだけ。実装したことある?

455 :デフォルトの名無しさん:03/03/25 02:55
>>454
キツイね・・・

456 :デフォルトの名無しさん:03/03/25 04:08
もうこんな時間かよ!!

457 :448:03/03/25 08:07
おはよ。
トップダウンであろうがボトムアップであろうが、
どんな分析過程を経たとしても、
設計段階でOOを用いるのか、構造かプログラミング用いるのは任意。
あまつさえXPなんて言葉が出て来たしな。



458 :デフォルトの名無しさん:03/03/25 08:25
任意ってあーた、分析→設計の連続性がOOの特徴だよ。


459 :デフォルトの名無しさん:03/03/25 09:04
で?その時はボトムアップでアプローチしなきゃなんないわけ?


つか、分析・設計の連続なんて構造化プログラミングでも同じだろ?
何で問題解決プロセスとプログラミング技法をバインドしたがるんだよ。
藻まえらの脳をストラテジーパターンを使ってリファクタリングしろよと(w

460 :デフォルトの名無しさん:03/03/25 09:54
OO と大雑把にいうと、 OOA や OOD も含まれるんでないかい。

461 :459:03/03/25 12:50
>>460
で?
オブジェクト指向分析は、ボトムアップでアプローチしなきゃならないわけ?

462 :デフォルトの名無しさん:03/03/25 13:00
いんや。
OO のプロセス技法なんて腐るほどあるし、
トップダウンでもボトムアップでもサンドイッチでも、
採用するプロセスや工程に応じてどれかになるだろうね。
このトップダウンとかって、プロセスがそう捉えられるってだけで、
そうしなければならないってものじゃないし。

463 :459:03/03/25 14:02
ということだ。
>>OOモナー氏など

464 :デフォルトの名無しさん:03/03/25 15:23
「オブジェクト指向」とは、あくまで考え方。
その考え方に基づいたプログラム手法がオブジェクト指向プログラミングであり
同様な設計手法がオブジェクト指向設計。同様に分析手法が(略

で、オブジェクト指向という考え方がどういうものかというと、
「オブジェクトを単位に物事を考える」こと。

オブジェクトとは、内部に状態を持ち、その状態により振る舞いが変わる。
その振る舞いの結果、(自分自身も含めて)他のオブジェクトにメッセージを送る。
メッセージを受けたオブジェクトは、そのメッセージに対応した
状態変化を起し、あらたな振る舞いの結果、またメッセージ送信が行われる。

これが基本。

465 :464:03/03/25 15:34
オブジェクトを単位に考えるにあたり、一つ一つを厳密に細部まで考えるのは人間の頭には無理。
だから、ある程度大雑把に考える。

タロもジロも犬。
ミケもタマも猫。

この、「犬」や「猫」というようにその性質を大雑把に捉える。
この考え方が、オブジェクト指向の一端。
「犬」がクラスで、「タロ」「ジロ」がインスタンス。

ある、クラスを具象化(抽象化の反意語)したものがインスタンス。

これがクラスとインスタンスの関係。

466 :464:03/03/25 15:45
「犬」「猫」に加えて「鼠」「牛」「虎」「兎」「馬」「羊」「猿」「猪」など
沢山、考えなければならない対象が増えてくる。

すると、さらに大雑把に考える。
「ほ乳類」

これが親クラスと子クラスの関係。
親クラス「ほ乳類」の性質を子クラス「犬」を引き継ぐ。
この性質を引き継ぐという概念が「継承」

ここで、親クラスと子クラスの関係は、クラスとインスタンスの関係に似ている事に気づくと思う。
この二種類の関係を区別するのが、クラスのあるオブジェクト指向。
区別しないのが、クラスの無いオブジェクト指向。

一般的にオブジェクト指向と言うのは前者。

467 :デフォルトの名無しさん:03/03/25 16:35
だからさー
そんな教科書みたいな説明したって分かるわけないじゃん。。。。

一言
「クラス使ってプログラミングすると楽なんだぞー」
でいいじゃん。
「何で便利なの?」って聞かれたら。。。。
「関数が100個あるよりクラスが10個ある方が分かりやすいでしょ?」
って答える。
一番大事なのはクラスの独立性であって
多態性とか継承とかは付録みたいなもんだから。。。
それが初心者には分かりやすいと思うけどね。


468 :デフォルトの名無しさん:03/03/25 19:19
何の疑問ももたずにオブジェクト指向を身につけた人が
人に「オブジェクト指向とは」っていうのを教えると、決まって例え話を
持ち出すのは何故なんだろうか。

まぁ分かりやすく説明しようっていう努力は認めるけど…
結果は>>467になることが少なくないよなぁ。

個人的には、ある特定のシステム(経理システムとか、在庫管理システムとか)について、
構造化手法とオブジェクト指向でそれぞれ作って、大きく異なる点と、ほとんど変わらない点を
図やコードで対比させて、異なる理由・変わらない理由を説明もらえると分かりやすいかも、と思う。

469 :デフォルトの名無しさん:03/03/25 20:46
>>467
>「関数が100個あるよりクラスが10個ある方が分かりやすいでしょ?」
何もわかって無い奴にそんな説明だけだと
「10個のクラスに10個のstaticメソッドをを実装しただけじゃん。
メソッド名の頭に暮らす名をつければ解決することじゃん。」
といわれるオチ

470 :デフォルトの名無しさん:03/03/25 20:48
つーか、どう見ても467は分かって無いだろ

>「クラス使ってプログラミングすると楽なんだぞー」
>「関数が100個あるよりクラスが10個ある方が分かりやすいでしょ?」
>一番大事なのはクラスの独立性であって
>多態性とか継承とかは付録みたいなもんだから。。。
(゚Д゚)ハァ?

471 :デフォルトの名無しさん:03/03/25 22:00
467の語るオブジェクト指向の利点は余りに小手先過ぎる。

デザインパターンをいくつか例示するなどしないと、
プログラミングテクニックとしてのOOに魅力は感じにくい。


比較的簡単で、非OOの人にも威力が分かりやすい、
ステートパターンのサンプルなど見せるといいかも。

472 :464:03/03/25 22:14
えーとねぇ、あくまで俺が(途中まで)した説明は「オブジェクト指向」であり、
OOPでもOOAでもOODでもないし、ましてやOO言語でもないのよ。
基本の考えを理解しないうちに、設計なんかしたってダメダメなのができるのがオチ。

もちろん、OOはソフトウェアパラダイムだからOOPとかと関連づけた説明が
欲しいってのも分かるけど、OOPってのはOOが前提だからね。

散々ガイシュツだけどC++を使えば、OOなシステムを必ず作れるわけでもないが
Cを使ってOOなシステムを作ることは出来る。
そういう意味で、考え方という基本が重要だと思うけど。

あと、OOに対する考えは世間では「難しい」という根本的な誤解があると思うんだけど
全然、難しくない。むしろ簡単。自然な人間の思考パターンなわけ。
だから、大上段に構える必要は全然ない。

473 :デフォルトの名無しさん:03/03/25 22:15
哺乳類クラスから犬猫サル人クラスに〜っていうのは典型的な
悪いOOの説明だよな。実際、そういう設計思想で作ると無駄だけ
増えてすっきりした実装にはならない。

つまるところ、より抽象的な機能を上位クラスに、より具象的な
機能を下位クラスに、汎用化できる部分はabstract classとか
interfaceを利用して、より少ないコード記述量で使いまわしが
きくように作ることだと思うんだが。

474 :デフォルトの名無しさん:03/03/25 22:30
 オブジェクト指向というのは世界観でしょう。元々潜在的にオブジェクト指向という世界観を持って
ないとJAVAやってもオブジェクト指向にならないのでは?先にオブジェクト指向という世界観が
ありであってJAVAがありでないでしょう。JAVAはオブジェクト指向という世界観に気づくきっかけ
を作ることはできても元々オブジェクト指向という世界観を持ってない人には理解不可能と思うが。

 結論、JAVAを使うにはオブジェクト指向という世界観が事前に必要ということ?
オブジェクト指向という世界観が無い人はプログラマーに向かない人?


475 :464:03/03/25 22:46
466までがis-a関係の説明。
で、今回がpart-of関係を説明してみる。

また、ありがちな例けど、自動車を考えてみる。
一口に自動車と言っても、実際は「タイヤ」「ボディ」「エンジン」等の
様々な部品から構成される。
このように、オブジェクトの中にオブジェクトを含む事を「集約」と呼ぶ。
この時の「自動車」と「タイヤ」の関係がpart-of。
タイヤは自動車の部品である、と。

これも、人間の大雑把に考える思考法。
「自動車」とは文字どおり自動車であり、「タイヤ」「ボディ」「エンジン」等の集まりとは考えない。
「タイヤ」「ボディ」「エンジン」等が特定のルールで集まった塊を「自動車」と考える。

476 :464:03/03/25 23:03
カプセル化と情報隠蔽について

多くの人が混同しているが「カプセル化」とは、「状態と振る舞いを一体として扱う事」だけ。
これは半ば、オブジェクトの定義の話。

オブジェクトの内部構造が見えない。ブラックボックス化されている、という概念は
「カプセル化」ではなく「情報隠蔽」
カプセル化したオブジェクトをどのように扱うか、という話が情報隠蔽。

で、これも人間の自然な思考パターン。
前に書いた例の「ほ乳類」だったら、その性質をイチイチ頭に思い浮かべたりはしない。

「地球上の生物の全種類のうち、ほ乳類の数は1%にも満たないんだって」
「へ〜、そうなんだ」

こんな会話の途中に「ほ乳類とは胎生のセキツイ動物で四肢があり、その種別には犬猫鼠…」なんて
思い浮かべることはない。

同様に、自動車を運転している時に
「エンジンのガソリンと空気の混合比がm:nだから、タイヤの回転数が毎秒xになり、これによるボディの耐久性の低下は…」
なんてのも考えない。

人間は、
「一度、まとまりとして認識したものは、まとまりのまま認識し続け、
 必要にならないかぎり詳細は考えない」
この考え方がオブジェクト指向。

477 :デフォルトの名無しさん:03/03/26 03:23
>476

http://e-words.jp/w/E382ABE38397E382BBE383ABE58C96.html

カプセル化
データとそれを操作する手続きを一体化して「オブジェクト」として定義し、
オブジェクト内の細かい仕様や構造を外部から隠蔽すること。

478 :467:03/03/26 04:16
分かってる人には当然のことでも、
それを分かってない人に教えることが極めて難しい概念、
というのはどんな分野でもある。
プログラミングにおけるオブジェクト指向はまさにそれなんだよ。

上級者が納得するような厳密な説明をしようとすれば初心者には意味不明な抽象論となってしまい、
初心者に分かりやすく端折って説明すると「それは間違った説明だ!」と上級者に叩かれる。

オレは>467で説明したのは(焦って書いたのでまとまりがなかったが)
「もし仮に、どんなプログラミングの初心者にでもオブジェクト指向の利点が分かるように
説明するとすれば」という意図から書いたものだ。
もちろんこの説明が上級者から見ればあまりにオブジェクト指向の本質を
無視した説明であるのは承知だ。

だが、初心者に「デザインパターンとは?」とか「多態性のメリットは?」なんて教えるのは
小学生に微積分を教えようとするのと同じレベルなんだよ。いくら説明したって分かるわけがない。

オレは今までに、どんな初心者にでも分かるようなオブジェクト指向の説明を聞いたことがない。
まあ、世の中の大抵のことは自分で経験しなければ理解できないのだから、
初心者に分かる説明は元々不可能であるし、する必要も無いのかもしれないが。


479 :デフォルトの名無しさん:03/03/26 04:17
★男はココを見るべし★女と金と???★
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
http://www.pink-angel.jp/betu/linkvp2/linkvp.html

480 :デフォルトの名無しさん :03/03/26 04:33
すげーレベルだな。
おまいらの設計&ソース見なくても想像つくわ。
今日中に辞表出しとけ。
以上

481 :デフォルトの名無しさん:03/03/26 07:24
畑違いですまんが、仏教の教典によれば、悟りを得る初心者には
四種類あると解かれている。

1.発起衆。教えてくん。とにかく疑問があればとりあえず質問しちゃうやつ。
2.当機衆、OO以前の経験あり。例え話大好き、
3.血縁衆。OOの理論を理解してこつこつ覚える。
4.影響衆。わからんけど、はやってるからとにかくやっちゃうぞ。

仏様は、それぞれに合わせて別な説明のし方をするんだそうだ。

482 :Oザッパ:03/03/26 09:33
レーザープリンタでもドットインパクトプリンタでもサーマルプリンタでも
インクジェットプリンタでもデイジープリンタでもプロッタプリンタでも
プログラム上からは全部プリンタとして扱うことができる。

もちろんそれ以外の方式を採用したプリンタがでてもプリンタとしての
インターフェースを持っていれば同様に扱うことができる。
プリンタとして扱って欲しければプリンタのインターフェースを備えればいい。

レーザープリンタはプリンタとして汎用的に使うこともできるし
レーザープリンタとして特有の機能を使っても良い。


483 :デフォルトの名無しさん:03/03/26 16:53
>>482
良いメタファですね。

# 「じゃぁ、プリンタやプリンタドライバはオブジェクト指向なんですね。」
# とかいう厨が出てきそうな気もするけど。

484 :デフォルトの名無しさん:03/03/26 21:39
>>478
>「もし仮に、どんなプログラミングの初心者にでもオブジェクト指向の利点が分かるように
>説明するとすれば」という意図から書いたものだ。

>オレは今までに、どんな初心者にでも分かるようなオブジェクト指向の説明を聞いたことがない。

( ´,_ゝ`)プッ

485 :デフォルトの名無しさん:03/03/28 13:54
??

486 :デフォルトの名無しさん:03/03/28 20:09
素朴な疑問ですが、OOってデバッグ大変じゃありませんか?
何がどう動いてるか調べるために追いかけて行くと
クラス階層まで入ってってしまってわけわかめになるんですけど。

487 :デフォルトの名無しさん:03/03/28 20:25
>>486
非OOの方がデバッグが大変
OOはデバッグや保守、改良などをしやすくするために考えられ、洗練されてきた、と個人的に思う

488 :デフォルトの名無しさん:03/03/28 20:33
>>486 設計が歪んでいると泥沼。正しいとパラダイス。
OOPはそこんとこ、重要。

489 :デフォルトの名無しさん:03/03/28 20:37
>>486
言語による。
クラスを作らなくてもO.K.なオブジェクト指向もどきな言語はデバッグが大変だが、

グローバル関数など余計なものを使用禁止にしている
オブジェクト指向専用言語ではオブジェクト指向言語の方がデバッグが楽。

490 :デフォルトの名無しさん:03/03/28 22:10
>>487
○ >488
× >489

491 :デフォルトの名無しさん:03/03/28 22:39
>>488

漏れとしては歪んでてもなんでもとりあえず形だけでもいいから
らしくOOPしていただきたい。

492 :デフォルトの名無しさん:03/03/28 22:42
なんだかんだ言って、みんなオブジェクト指向に興味あるんじゃない。
って言うか、みんな自分が思っているオブジェクト指向の理解度に自信が
無いからかな?まーここのスレ全部が正解かな?
この件に関して堂々と答えられる人間はどこのベンダーにもいないネ。

493 :デフォルトの名無しさん:03/03/28 23:28
この件ってどの件?

494 :デフォルトの名無しさん:03/03/28 23:40
>>493
馬鹿ニマジレス

495 :デフォルトの名無しさん:03/03/28 23:42
>>494
ネタにマジレス

496 :デフォルトの名無しさん:03/03/28 23:57
>>495
バカ登場

497 :デフォルトの名無しさん:03/03/29 00:16
>>496
一番のバカ・・・

498 :デフォルトの名無しさん:03/03/29 00:17
>>497
2番目にバカ?

499 :デフォルトの名無しさん:03/03/29 00:34
なにを〜 オレの方がバカだぞ!

500 :デフォルトの名無しさん:03/03/29 00:37
犬とかネコとか山田さんとかそういうことは理解できるんだけど
それを実際のアプリ製作に当てはめようとするとどうもいまいちわからない。

作成するアプリを書いたら、どういうクラスが必要かをレスしてくれるスレはないかなあ

501 :デフォルトの名無しさん:03/03/29 00:43
ない。以上。

502 :デフォルトの名無しさん:03/03/29 00:44
>>500
それが一番楽しい作業じゃないのか?>クラスの洗い出し

503 :デフォルトの名無しさん:03/03/29 01:01
>>502
病気ですね。

504 :デフォルトの名無しさん:03/03/29 01:15
>>478
しゃべればしゃべるほどわかってないのが、浮き彫りだね!


505 :デフォルトの名無しさん:03/03/29 01:25
まぁ、許してやんなよ。
若い頃、小難しい本読んで、すべて理解出来た気になってたのが、
歳とって何度も読み返すたびに、奥の深さを知ってどんどんわからなくなる、そんな経験無い?
あの頃わかった気になってたのって、一体何だったんだろうって。

506 :デフォルトの名無しさん:03/03/29 01:28
>>500
激しく同意。

俺の場合も、逝く度かの渡来&エラーを繰り返して、今も試行錯誤してる途中。
学の無い者による独学ほど非効率なものは無いと痛感。人生死ぬまで修行僧(意味不明

例えば経理システムをOOでどう構築しようかと(経理知識ゼロの俺が)思案してるんだけど、
とりあえず、最終出力たる各種帳票ごとに、対応するクラスをまず作ろうかと思ってる。
この各帳票に対応するクラスを「すごろくのアガリ」と考え、経理のネーチャンが端末から
各種データ(おそらくこれもクラス化の対象になるだろう)を入力してから「上がる」までに
どのような処理が必要かを考え、各種クラス・メソッド・DBレイアウト等をぼちぼち追加していく。

粘り強くやっていけば、いつかはパライソにたどり着くという目論見だが、多分この辺の
要件分析からクラス設計までの話は、学術的・体系的に確立されたものがあるような気がする。
2ちゃんねるではあまり見かけない気がするけど。

507 :デフォルトの名無しさん:03/03/29 01:29
>>505
それは、単純に内容を忘れていただけの場合もある

508 :506補足:03/03/29 01:38
ただし、道筋に沿って最終目標へ近づけていくアプローチ自体は
むしろ構造化手法そのものなんじゃないかと悩み中。

いくつかの道を辿っていくうちに、以前設計したクラスと似た構成の
クラスが必要になったり、あるクラスの一部分の構成を別クラスとして
切り出して、他クラスにも持たせる必要が出てきたりすると思う。

そのときには、共通関数や共通モジュールのような「単なる共通系〜」を
作らないように気をつけてる。「オブジェクトとして表現すべきものか」を考えてる。
言葉にするのが難しいので、「この辺はやってみて、体で覚えて」としか言えない
のが心苦しいんだけど。

509 :デフォルトの名無しさん:03/03/29 01:39
>>507
内容を忘れてたら、誰だって忘れてることに気づくよ。
書いてある文章の意味を理解することと、本質を理解することの違いの話なんだけど。

510 :デフォルトの名無しさん:03/03/29 01:46
>>508 10年くらい前入社したての頃に
同じ様なこと考えてたから気持ちはわかる
ただそんな処にいる人にオブジェクト指向の
なんたるかを語られてもなあ

511 :デフォルトの名無しさん:03/03/29 01:56
http://www.agemasukudasai.com/bloom/

512 :506:03/03/29 01:57
>>510
スマン、OOのなんたるかを語れるほどの者じゃないことを
冒頭で断った上でのレスだと理解してください。おながいします。

大上段から語ってるように見えたんなら申し訳ない。
「とりあえず、比喩によるOOのお話」レベルから一歩進めるきっかけを
持ってほしくて>>508,510を書いただけでつ。

513 :デフォルトの名無しさん:03/03/29 02:12
>>505

> 最終出力たる各種帳票ごとに、対応するクラスをまず作ろうかと思ってる。

イイと思いますよ。

> 粘り強くやっていけば、いつかはパライソにたどり着くという目論見

なんだけど、貴方のリファクタリングが認められてない開発プロセスが導入
されていたなら、それも不可能になっちゃうのよね・・・。

(そんな当たり前の権利も与えられてない漏れ)

514 :506:03/03/29 02:47
>>513
> > 粘り強くやっていけば、いつかはパライソにたどり着くという目論見
>
> なんだけど、貴方のリファクタリングが認められてない開発プロセスが導入
> されていたなら、それも不可能になっちゃうのよね・・・。
そもそも実務で「粘り強く」設計するやり方自体があまりよろしくn(r

この辺は、初学者が「OOによる設計」を会得するための幾つかの手法のうちの、
比較的愚かな手法を実践してます、という事例紹介程度と捉えてくださいまし。

#ちなみに私はソフトウェア・エンジニアリング以前のレベルという自覚はあります。

とりあえず、「単なる比喩による説明」と「実務で使われるOO」とを結ぶ接点さえ>>500氏が
掴んでくれれば、私は満足です。

515 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/29 03:11
あ、ひでー。
初心者洗脳してやんの。

OOはインチキ宗教みたいなもんで、効率は上がりません。
ただの流行であってソフトウエア工学ではない。
そしてハッタリ屋の道具。

そんなものよりちゃんと工学的な基礎を身につけることです。
・OSやスレッドの仕組み
・BIOS
・フェイルセーフ
・割りこみ処理
・自動プログラミング
・システム工学


516 :デフォルトの名無しさん:03/03/29 03:19
>>515 が煽りで釣りを楽しんでる香具師、と分かっていても、やはりこう言いたくなるな。

「OOは効率が上がる」

517 :デフォルトの名無しさん:03/03/29 03:26
フツーにプログラミングしてりゃOOはどう考えても要ることが分かるぞ・・・。515 はひでぇなぁ。

518 :デフォルトの名無しさん:03/03/29 03:31
>>48
抽象的な概念を導入することでなんで作業を一般化することになるの?

519 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/29 04:22
>516と517はセンスの無い奴だろうな

まあ、OOに教えられるまで再利用を知らなかったような程度の低いところなら
上がるかもね。
でも所詮底辺のレベルでとてもとてもトップの技術競争に勝てるようなレベルではない。


520 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/29 04:26
ああ、最近来た人は知らないだろうけど、OOと非OOで効率を調べる為に
実証実験をこの板でやったんだけど、非OOで三日で終わったオセロが
OOだと3ヶ月たってもついに完成しなかった事を伝えておく。
OO本に書いて有る事を鵜呑みにするもんじゃあない。
それは洗脳だってえの。

521 :デフォルトの名無しさん:03/03/29 04:39
>>520
それは、アンタのアンチの執念が3日で完成させただけかと…

やる気のあるなしと、方法論とは関係無いな。

522 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/29 05:10
そりゃ言い逃れだつうの。
コードを比べた分析によっても、OOオセロがうまく行かなかった原因は
コード量が多いのもあるが、
拡張性や再利用の予測が外れるとOOは途端に効率が落ち、それは容易に起こる事が判る。

OOの宣伝本はその予測リスクについて全く触れていない酷い詐欺だ。


523 :デフォルトの名無しさん:03/03/29 05:16
わらた。
面白い漫才スレをありがとう。
脳みその凝りがほぐれたよ。

524 :デフォルトの名無しさん:03/03/29 06:13
>>523
こんなんで笑える脳味噌なら捨てちまえ!

525 :わが持論:03/03/29 06:15
巷に馬鹿はたくさん居るが、

真実=己の視界の範囲

と判断する奴は、もっとも有害な馬鹿。

526 :デフォルトの名無し職人:03/03/29 09:45
>>525

「真実」はその人の視界の範囲以外に厳然とあって、そしてあんたはそれをわかるというわけだ。

527 :デフォルトの名無しさん:03/03/29 09:45
>>525
これは再帰か?

528 :デフォルトの名無しさん:03/03/29 10:06
>525

http://www.amy.hi-ho.ne.jp/%7Elepton/program/prog/prog70.html

こういうことを言いたいわけでしょ?



529 :デフォルトの名無しさん:03/03/29 10:10
「人間、だれしも自分の経験の範囲内でしかモノを語れないわけで、
そんなことはあたりまえのことなわけですが、
世の中には、自分の経験の範囲内が世界の全てだ、
と勘違いしているおめでたい人間も沢山いて、
そういう勘違い人間には閉口してしまうことも多いです。」


530 :Java太郎 ◆DMVtSSFzcg :03/03/29 13:15
愛だ!!愛!!!!(´д`)ハァハァ

531 :デフォルトの名無しさん:03/03/29 14:40
>>522

OO じゃないと予測うんぬん以前に修正さえできねーじゃんかよ

532 :デフォルトの名無しさん:03/03/29 14:48
今の世の中のソフトウェアのほ必ずOOらしいことやってるだろ。負けを認めろ!

533 :デフォルトの名無しさん:03/03/29 15:01
クラスで役割が定義されていて適切な名前がつけられているのがどれだけありがたいことか。

ただ関数一覧表がずらーっ・・・と並んでいるプロジェクト見たことある。
彼らと仕事するには神の認識力が必要だなと思った。

534 :デフォルトの名無しさん:03/03/29 16:21
オブジェクト指向の理解度

A. オブジェクト指向を理解している。
B. オブジェクト指向を理解していないことを自覚している。
C. オブジェクト指向を理解していないのに理解していると思っている。

なぜか、C はオブジェクト指向を説明するのに熱心なので、
ほとんどの人が B から C へいく。

535 :デフォルトの名無しさん:03/03/29 16:40
漏れとしては形だけでも理解してなくてもいいからとりあえず OO を始めていただきたい。

536 :デフォルトの名無しさん:03/03/29 16:44
案ずるより産むが易し。習うより慣れろ。

古人はいいこというね。

537 :デフォルトの名無しさん:03/03/29 17:05
OO、OOといいながら、OOAもOODもしてないのに
製造にOOPだけ押し付けるのはやめてくれ。

538 :デフォルトの名無しさん:03/03/29 17:51
とりあえず、構造化プログラミング+そのとき必要になったクラスを
随時追加って感じで作り出しちゃってもいいですかね?

539 :tantei:03/03/29 17:54
★あなたのお悩み解決致します!!
●浮気素行調査
彼氏、彼女、妻、夫の浮気を調査致します!!
●盗聴器盗撮機発見
あなたの部屋に誰かが仕掛けているかも!!
●行方調査
行方不明になっている家族の消息を調査致します!!
●電話番号から住所割り出し
一般電話、携帯から住所を割り出し致します!!
●ストーカー対策
社会問題ともなっているストーカーを撃退致します!!
その他人生相談からどんなお悩みでも解決いたします!!
 直通  090−8505−3086
URL  http://www.h5.dion.ne.jp/~grobal/
メール  hentaimtt@k9.dion.ne.jp
   グローバル探偵事務局 



540 :XPマンセー:03/03/29 18:20
「オブジェクト指向はこう使え!!」

設計の終焉?
http://objectclub.esm.co.jp/eXtremeProgramming/IsDesignDead.html

541 :デフォルトの名無しさん:03/03/29 20:12
OOに則ったコード設計は実に難しいと思う。

542 :デフォルトの名無しさん:03/03/29 21:09
>>541

コード書き始めから完璧ってことは、どんなにOO設計大好き野郎でも不可能なんだし。

とにかく何らかの意図をもってクラス分けすりゃいいと思うよ。

543 :デフォルトの名無しさん:03/03/29 21:11
ASPからC#に移行するメリットはオブジェクト指向で設計実装できることだけしか無いのだが、
会社のPGどもがそれを理解できない奴らばかりなので困ってる


544 :デフォルトの名無しさん:03/03/29 21:15
>>542
禿胴。

1.最初は思いつきで大まかなクラス設計
2.推敲や実装作業のなかでよさげな構成に修正

というのは普通だよね?ウォーターフォールマンセー馬鹿じゃなければ。

545 :デフォルトの名無しさん:03/03/29 22:27
それではクラス設計しないで適当に実装するのとかわらん。
現実に無理とはわかっても、最初からカンペキなものを作る覚悟で設計しないと


546 :544:03/03/29 22:37
>>545
分析レベルで完璧にしても、実装してみたらいろいろ不都合が起きるものですよ。
そういうことを言いたかったんだけど、誤解される文章でスマソ。

547 :544:03/03/29 22:40
でもって、そういう不都合が全く発生しないような分析/設計フェーズの
実践が可能、などと思い込んでいる、現実しらずをさしてマンセー馬鹿と
よんでみました。

548 :デフォルトの名無しさん:03/03/30 00:06
つーか改造/改良にこそOOが威力を発揮すると思うのだが。

549 :デフォルトの名無しさん:03/03/30 01:30
改良しようとしてもOOしてなきゃコードが読めん。

550 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/30 03:04
ダメ過ぎ

551 :デフォルトの名無しさん:03/03/30 03:09
>>550
貴方ほどじゃ…

552 :デフォルトの名無しさん:03/03/30 03:22
(^Д^) オブジェクト思考でオブジェクト指向しようよ!

553 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/30 04:10
ダメ過ぎ

554 :デフォルトの名無しさん:03/03/30 05:09

          /´⌒´⌒\
.          / 〃 ハ  ヾヽ     
        | ノ∠、ノ,ムヾ |    / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
        (|| ━` i ━ ||)  < オブジェクツ!!
       ∩{   r ┘ 、 }∩   \_________
       _|└9 k='=ヶ} 6┘|_
      /  にニ}、_ ̄´_/にニ} \
    |ヾ  トーイ{≫又≪}ト―イ 〃 |

555 :デフォルトの名無しさん:03/03/30 10:48
>>522の言い草がアマリにも…なので、チョッと勇気を出してみますた。
2chのこの板でソース晒すのは、正直スゲー怖いですけど。

http://solidlancer.tripod.co.jp/ReversiSrc.jar

半年前に、後輩にOOを教えるための教材代わりに、2日(6時間)ほどで作ったソース
です。一応リバーシのゲーム盤として動作するはずの、Javaのソースです。拡張子
がjarですが、zip書庫ですのでunzipしてください。

Observerパターンをモデル-ビュー間のやり取りに利用にしたオーソドックスなMVC
モデルにしてあります。細かい実装はいい加減ですが、そういうところをどうこう
するためのソースじゃないので、その辺の突っ込みはカンベンしてください。

jp.javauser.reversi.Controllerがmainメソッドのあるクラスです。
あと、ソースのコメントは全部Shift_JISになってますので、もしWin以外の場合は
コンパイル時に気をつけてください。

この程度のサイズでOOの利点全てをどうのこうの言うこともできないと思いますが、
見通しのよい構造を実現できることを説明できる程度にはなっているのではないか
と思っています。感想をお聞かせください。

>>プロの逝ってよしの1の中の人

556 :デフォルトの名無しさん:03/03/30 12:41
プロの逝って良しの1 ってC++スレとかにも顔出してる
日本語の不自由なかわいそうな人ですか?

557 :デフォルトの名無しさん:03/03/30 13:36

実務経験経験豊富な肩に質問!
J2EEの開発やっているものなのですが、オブジェクト指向分析って必要ですか?
とくにWeb系ではBCE出すのって、あんまりメリットないような気がするのですが。
(画面サンプルや画面遷移図書いたほうがよっぽどわかりやすい)

開発やってると、だいたい
 要件定義(ユースケース、画面、非機能要件、概念モデル作成)
→画面設計・コンポーネント設計・DB設計・アーキテクチャ設計
→クラスの詳細設計
→実装

という流れになることがおおいです。

それとも
オブジェクト指向分析=エンティティモデル構築+データ項目洗い出し
と理解すればいいのでしょうか

#データベースアプリで無理にOOするなゴラァという話もあり・・・


558 :デフォルトの名無しさん:03/03/30 14:31
>>557

画面遷移図とかあったほうが分かりやすいならそれを書くのがいい。


それは OO の本質とは違うところで、設計として OO を考えるタイミングとしては、
メソッド名が同じで機能が違う、みたいなものが見つかれば、抽象クラスする価値が
あるね、くらいのことで。

例えば、検索条件をプラグイン的に追加したいために、絞込み条件をクラス化することだったり、
予約タスクをクラス化することだったり。ログインしたユーザによって絞込み条件を変えるって
ことだったら、ユーザオプジェクトに絞込みオブジェクトをセットすることだったり。

税金の計算方法がちょくちょく変わるとかだったら、計算クラスでも作って、
利用者に選択できるようにするとか。

OO が要るところはそういうことで、ページをオブジェクトでマッピングするのもそれはそれで
便利だけど、それは設計ってわけじゃなくて、技術基盤として便利だねってことで、それは
分析、とはあまりいわないんじゃないかしら。

559 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/30 16:44
いまさら提出して「二日でできました」つうのも、もう詐欺っぽさ満点だというのは
置いておくとしてもだ。

そのコード量じゃねえ。
再利用できない無意味なモデルだし。

560 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/30 16:46
まあ、OOは作り捨てに向いているってことかな。
パターンマニア向けでしかないね。
仕事では使えない。

561 :デフォルトの名無しさん:03/03/30 16:49
>>560
どうやってその結論に到達したの?
飛躍し過ぎでサパーリ解らない。

562 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/30 16:56
もう10スレの費やしての説明で疲れました。

実証と理論的検証両面からOOはダメつう結論です。
必死に反対してる信者がいますが、現実を見ない者は滅ぶだけ。

563 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/30 16:57
俺に抗議しても現実は変わらんよ。

564 :デフォルトの名無しさん:03/03/30 17:00
OOに興味が無いならのぞきに来なければいいだろうに。

565 :デフォルトの名無しさん:03/03/30 17:03
業務だからOOなんでは?
OOは大人数、大規模プロジェクトで複数の人がコードを参照し
仕様変更による改良・改変しデバッグをしやすいというのが売りなんだから
リバーシのような個人が数日で作れるようなソフトではプロセスをそのまま
コーディングする非OOの方が慣れてる人が多い分、早くても自然だと思います。
コードの量が増えるにしたがってOOが有利になると思います。

改良・改変・デバッグに費やす時間(ソースの量Nの増加として)
非OO:OO = N:Log N って感じかと。

566 :デフォルトの名無しさん:03/03/30 17:16
◎◎を使えねえやつはいりませぬ。文句を言っても◎◎を使えるやつは
貴重だな。

567 :デフォルトの名無しさん:03/03/30 17:21
>現実を見ない者は滅ぶだけ

・・・どっちが?

568 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/30 21:10
>>565
笑った。
しょーもな。


569 :デフォルトの名無しさん:03/03/30 21:31
オレルールで開発するのが楽なのは当たり前。
OO だと既存の開発プロセスや設計手法が沢山あり、
それに従って開発するのが OO だと思われているので、
不適合なプロセスを選択すると不自由を感じながら開発することになる。

570 :デフォルトの名無しさん:03/03/30 21:34
>>563
「現実」ってのは『非OOを支持してるのがお前だけ』だということを指してるわけか?

571 :デフォルトの名無しさん:03/03/30 21:58
oo = 北朝指向

572 :デフォルトの名無しさん:03/03/30 22:10
プ1はどういう経緯でOOに恨みを持ったのか…
よっぽどろくでもない生兵法馬鹿に粘着でもされたのかな。

コンサルだとか名乗って使いこなせてないOOを売り文句に
詐欺営業して大金を巻き上げるろくでもない連中が、確か
にいるからなあ…

573 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/30 22:28

「OOはすぐに結果の出るものではありません。5年先、10年先を見て行うものです」

と言ったコンサルが居たそうだ。
笑っちゃうね。

574 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/30 22:30
洗脳されてる奴が周りにいると仕事やりづらいので世論を軌道修正すべく
日夜2ちゃんで広報活動に勤しんでいるだけで、別に恨みは無い。

575 :デフォルトの名無しさん:03/03/30 22:32
>>573
おそらくそのコンサルは10年間寄生虫になることを目論んでいるロクデナシだった
んだと思うが、
アンタみたいな硬直した脳みそがイッパイいる企業を再教育するのには、確かに10
年みないといかんかもね。

576 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/30 22:32
>>565なんか本に書いてある事そのまんまでしょうが。
オウムなんかに引きこまれたらさぞかし疑問を持たず、
教えられた教義をただ繰り返す人なんだろうなと思う。

577 :デフォルトの名無しさん:03/03/30 22:37
OOだろうがコーディングの規約レベルだろうが流行のフレームワークだろ
うが、アンタ(あるいは俺)の俺様マンセースタイルに何らかの制約を掛けるの
は当たり前。
そのトレードオフは開発効率や保守性の向上。対企業システム開発なら
その実現は満たすべき重要な機能だと思われ。他人にとって見通しのよい
構造にしておくのは、単に動作するかどうかの次くらいに重要(なはずなん
だが、アマリにも実装能力の低い糞集団は、この機能を無視するんだよな)
だとおもわれ。

俺だっていつも俺様マンセーで開発したいとは思うが、人から与えられた
仕事をやる限りは、そうもいってられないでそ。


578 :デフォルトの名無しさん:03/03/30 22:37
ooセミナーwとかして、信者候補生だまして
飯をくいてーなー。
信者はもっと普及活動しろよ。
オブジェクト指向って言うだけで金が
はいるんだもんな。
イイ世の中だw
IT国家まっしぐらだw

579 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/30 22:39
いやー、OO反対だと「硬直した脳みそ」ですか。

それもOOが宗教である証拠だ。
疑問を持つものをそうやって葬るシステムになっている。

OOの本には
「従来は〜でしたがOOになって〜になりました」とでたらめが書いてあって、
「ソフトウエア産業ではかねてから生産性の向上が求められてきました・・
 OOの導入は従来型の古い思考の持ち主には合わない面があります」

などと、疑問を持つものや反対者を「生産性を下げる人」とレッテルを貼るのと同じ
洗脳の手法によって、洗脳に対して免疫の無い若い人を中心に布教したんだ。

580 :デフォルトの名無しさん:03/03/30 22:39
>>576
あいたたたたた
前に進むことも見ることもしなくなった、単なる古いオッサンじゃねーかよ
お前みたいなのがいるとこっちが仕事やりにくいだろ

年取ると新しいことは覚えずらいかもしれないけど学習しろよ
置いていかれるぞ?

581 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/30 22:44
>>577
それもソフトウエア業界の問題の一つ。
集団による開発効率向上の手法は、しばしばその手法を正しく適用できる人がおらず、
単なる原理原則論の非実際的な適用によって返って効率を落としている。
その手の集団手法を好む会社は、例えばどうみても5人年で済む仕事に
30人年投入してたりする。

582 :575=577:03/03/30 22:45
おれもOOがカンペキでスバラシイなどとは一つも思ってないが、

・要件分析→設計までを一貫した成果物のスタイルに落とすことができ
て、他人が後からトレースするのが簡単
・クラスの分割、パッケージ分割などをきれいにしておくと、整理された
戸棚みたいに、特定機能の位置の把握がしやすい

あたりは便利だと思ってるな。
別に開発スタイルの一種だと思えば、それに従ってやるだけでしかな
いよ、折れは。仕事だし。

本読んだだけで分かった気になって、上司の攻撃に利用するマンセー
厨新入社員が大嫌いなのは、俺も同じだ(ワラ

583 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/30 22:46
学習ときたか。
やれやれだ。
本人大真面目なんだもんな。

584 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/30 22:49
以前OOマンセーだったこの板の人達にコード出させたら、全然OOじゃなかった
という話も付け加えておこう。


585 :デフォルトの名無しさん:03/03/30 22:51
>>584
OOを完全否定か? あんたは?

586 :575=577:03/03/30 22:52
なんだかプ1って意外とまともな気がしてきたな。

>>581
ああ、あるべき論で現実離れした標準化プロセスを合議制で作ってる
馬鹿なプロジェクトがウチにもあったよ。関わっているやつは
高級管理職連中。現場を分かってない奴が作ったから、成果はみるも
無残。誰の現実も救っていない標準なんて、単なる無駄な稼動の原因
でしかないな。

で、OOもその類だというわけね、あんたは。

587 :575=577:03/03/30 22:56
>>584
そりゃOOとは関係無いな。
そのマンセー野郎が馬鹿だっただけでしょ。

588 :デフォルトの名無しさん:03/03/30 22:57
指向や思想を売ったり、押し付けたりするのは
どれに限らずおかしい事なんだよ。

だいたい指向ってなんだよ?指向ってよ?
新しいパラダイム?はぁ?
おまえらはさぞかしパラダイムシフトしたんだろうな?
オブジェクト指向のほかに何指向があるってんだよ。
俺は、アヤヤ指向だ。

589 :575=577:03/03/30 22:59
>>584
ああ、OOマンセーといいながら使いこなせていない糞が
巷に腐るほどいて、現実問題のの解決に対して足を引っ張
っている=OOがダメっていうことか。

まあ、それはOOを別の概念にさしかえれば、どれにでも言え
る話だな。


590 :デフォルトの名無しさん:03/03/30 23:03
「使いこなす」って表現が出る次点で
おかしいだろうがよ。
指向なんだろ?

マジで、洗脳ッテコワイネ...

591 :デフォルトの名無しさん:03/03/30 23:06
hoge指向

592 :デフォルトの名無しさん:03/03/30 23:08
>>588
>オブジェクト指向のほかに何指向があるってんだよ。

お前にいい言葉を教えてあげよう。「教えてください、お願いします。」
この言葉を覚えるとそのうちいいことがあるぞ。

593 :デフォルトの名無しさん:03/03/30 23:12
>>588
オブジェクト指向というけど、実際にこの単語を使うときは
「(狭義の)オブジェクト指向という思想に基づく数々の手法」
の総称をオブジェクト指向と呼ぶほうがおおいようなきがする
な。

アスペクト指向==AspectJとか、そういう人多いよ。

594 :デフォルトの名無しさん:03/03/30 23:13
>>592
偉そうに・・・
キショイんだよ。
お前、金八指向な。

595 :デフォルトの名無しさん:03/03/30 23:15
なんか、活発に議論してますねー

OOは駄目ですか、では僕は何を勉強するべきなのでしょうか?
すいません。道を示してください。

596 :デフォルトの名無しさん:03/03/30 23:15
>>594
>金八指向
いかん、ツボにはまった。激藁

597 :デフォルトの名無しさん:03/03/30 23:15
「プロの逝って良しの1 」氏の言は、漏れにとっては新鮮だ。
「オブジェクト指向は素敵」と聞いて、漏れはあっさり信じちゃったからな。
確かに、疑いの目を向けてみることは必要かも。科学的にね。

ただまぁ、実感としてオブジェクト指向は素敵だと感じてる。
「問題を分析する際に、その問題を構成してる『モノ』達と、
そのモノたちの間で交わされる『メッセージ』を基盤とする」
と言うことよりも優れた分析方法ってのを知らないから、
漏れは当分オブジェクト指向にしがみつくしかないけど。
モノを基盤とせず、操作(?)を基準とした問題分析って、難しいんだよなー。

598 :デフォルトの名無しさん:03/03/30 23:17
>>593
アリがd

599 :575=577:03/03/30 23:18
俺はOOがダメなんていってないよ。
詐欺コンサルや提灯記事に安易に流されて、理解していない
ことを「手持ちの道具」扱いするなといっているだけ。


600 :デフォルトの名無しさん:03/03/30 23:18
まともな奴が使えば効果が上がり、馬鹿が使えば悲惨なことになる?
んなの、何だってそうだろが、ボケェが!

601 :575=577:03/03/30 23:20
>>600
そのとおり。だが、一方で「どんな物事でも一様に悲惨にする」
馬鹿が業界には大勢いて、でも多くのまともな人間が、そいつら
と仕事せにゃならん現実もあるわけで。

602 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/30 23:20
>>595
勘を磨くとか、対人関係スキル上げるとか。

603 :デフォルトの名無しさん:03/03/30 23:22
>>603
とりあえず、歯を磨くことにしまつ。

604 :575=577:03/03/30 23:24
いっとくけど、おれはOOを分かってないよ。
OOで作られたシステムとそのプロセスにかかわり、それを通じて
観察したことがあるだけ。見えなかったことは知らんので、あて
にせんでくれ。

605 :デフォルトの名無しさん:03/03/30 23:35
>>602
いえいえいえいえ、そのようなことではなくて、それが大切なことはわかりますが
とりあえず、設計方法のほうをお願いします。

606 :デフォルトの名無しさん:03/03/30 23:44
>>605
きびしいなぁ。アンチOOなだけの人に、
まともな設計方法の提示ができるわけ無いじゃないですか。
敵の退路は立ってはいけません.それは、予想外の事態を生みます.
まったりちゅらさんでも見るヨロシ.

607 :デフォルトの名無しさん:03/03/30 23:48
プログラミングしてたら、OOは自然と身につくもんだから。

設計をあらたまって勉強するとか、もう止そうぜ。

クソセミナーやクソコンサルに騙されちゃいかん。

608 :607:03/03/30 23:54
プログラミングを学習する上でOOを意識するのは極めて有効なのは確かだ。

609 :デフォルトの名無しさん:03/03/30 23:56
エンジニアなら技術で勝負しろっつーの。
OOがスキルだと思うな。良いのや悪いのや詐欺やらを
判断しながら、自分なりに取捨選択して
取り入れていけばいいんだよ。要はセンス。技術者なんだから。
そこにある要求定義に対して自分のセンスをぶつければいいんだよ。
小泉風に言えば、柔軟かつ冷静に対応。

610 :デフォルトの名無しさん:03/03/30 23:56
>>606
おーい、「まったりちゅらさん」ってなんだよ!
ぐぐッたけど、なんもでてこねーよ!

611 :デフォルトの名無しさん:03/03/31 00:01
>>610
その場合の「まったり」は形容詞だ。
本体とは分離しなければ望む結果は得られないだろう。
オブジェクトの切り出しを誤ってはいけない。

612 :575=577 :03/03/31 00:01
OOだろうがなんだろうが、現実にその手法で設計を行い、後で評価して
フィードバックする作業を繰り返すことナシに、ガッコのオベンキョだ
けですばらしい設計手法が身につくと思っているアホは、しんで欲しい。

613 :デフォルトの名無しさん:03/03/31 00:02
>>610
読点なくてスマソ.ことえりよりアホだとは想定しなかったので.
「まったり」は「見る」にかかる福祉で、
つまり、
「まったり、『ちゅらさん』を見なさい」といういみでつ。

614 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/31 00:05
>>609
「柔軟かつ大胆に対応する」だろ

>>605
手続き型で書こう

615 :デフォルトの名無しさん:03/03/31 00:07
プ1が考えてることっていうのは、上流とか下流とかあって
設計する人とコーディングする人が分かれてるとうまくいかねーって
ことではなかろうか。

ここらへんの議論は開発方法論(XPの話題とか)でいろいろ言われてる。
(どう考えたって、プログラマが設計しなきゃいけない)


OOを悪用してヒエラルキーを作りたがる勢力がいて、
ここらへんの利権がらみの解決を行うのは、不可能に近い。

616 :デフォルトの名無しさん:03/03/31 00:13
>>615
> プ1が考えてることっていうのは、上流とか下流とかあって
> 設計する人とコーディングする人が分かれてるとうまくいかねーって
> ことではなかろうか。

どこがそんな風に読めたんだろう.


617 :615:03/03/31 00:16
>>616

>>573 あたりで

618 :デフォルトの名無しさん:03/03/31 00:17
俺指向でいけ

619 :デフォルトの名無しさん:03/03/31 00:17
>>614
すいません、手続き型+αしたものがオブジェクト指向というものではないのですか?

>手続き型プログラミングでは、5つの基本的な考え方があります。それは「連接」「繰返し」「判断」「部品化」「再帰」です。

今見たページにこう書いてあったのですが、オブジェクト指向も同じことするのでは?
勘違い指摘してください。

620 :デフォルトの名無しさん:03/03/31 00:20
>>617
573>>「OOはすぐに結果の出るものではありません。5年先、10年先を見て行うものです」
573>>と言ったコンサルが居たそうだ。
573>>笑っちゃうね。
と、
615>>プ1が考えてることっていうのは、上流とか下流とかあって
615>>設計する人とコーディングする人が分かれてるとうまくいかねーって
615>>ことではなかろうか。
の間にミッシングリンクがある気がする,,,,


621 :デフォルトの名無しさん:03/03/31 00:24
>>619
手続き型であれば、そこに無条件分岐とか、
構造化されてないのものも含まれるはず。

たぶんあなたはDQNサイト観てる。
チバミソーリヨー

622 :デフォルトの名無しさん:03/03/31 00:28
>>621
無条件分岐? gotoのことですね。

構造化されてないものも含むって・・・え? 
手続き型を学ぶとはそういうものを駆使しろということですか?

623 :デフォルトの名無しさん:03/03/31 00:28
>>619

勘違いしてるとこなんてございません。

+α の部分を言うならば、OOすると複雑な分岐を省略することができます。

624 :デフォルトの名無しさん:03/03/31 00:39
>>622
gotoなどを駆使しろ、と言うのではなく、
「『手続き型』と『構造化』を混同してるんじゃないの」って突っ込み.

625 :デフォルトの名無しさん:03/03/31 00:39
OOは手続き型を含めてOO。とか言ってるカキコを前にみたなぁ。
まあそうだと思いこんだとしても、
それでどこがパラダイムシフトなのかと小一時間(ry

626 :デフォルトの名無しさん:03/03/31 00:41
C→C++、Pascal→Delphi、Perl→Perl5
と手続き型をベースに OO の機能を乗っける言語が多いからねえ。

627 :デフォルトの名無しさん:03/03/31 00:44
>>625
もう、訳わからないのです。 パラダイムシフトかどうかはどうでもいいんです。
なぜOOは否定されたのですか? 

手続き型はオブジェクト指向の土台ではないのですか?
何で土台に家を建てたら駄目なのか、ヒントをください。

628 :デフォルトの名無しさん:03/03/31 00:45
>>623
OOじゃなきゃ、複雑な分岐を省略できないわけでも、
手続き型だと、複雑な分岐になるわけでもない。
お前の発言には、何の意味もない。

629 :デフォルトの名無しさん:03/03/31 00:45
>>626
だ か ら な に?

630 :「メッセージのやり取り」厨:03/03/31 00:50
>>627
オブジェクト指向は、問題の分析とか設計とかを、
「オブジェクトと、その間のメッセージのやり取り」
と、捉えること.

手続き型は、俺はよく知らないけど、
「その問題の中で行われる操作」を中心に問題を分析すること、だろ。
コンテキストフルに.

全く異なる概念だね.
どっちかがどっちかの土台であるわけでは無い.


631 :623:03/03/31 00:55
Perlでもくだらねーif文の嵐を回避するテクは存在するがな

632 :デフォルトの名無しさん:03/03/31 00:56
>>630
ところが、JavaだのC++だのは、メッセージのやり取りを操作とやら?
で表現するんですよ。

633 :デフォルトの名無しさん:03/03/31 00:58
>>627

まあ一緒か別かはこの際どうでもよくてさ、
プロジェクトが成功しないっていう統計や、
ソースコードの再利用性とか、保守性とか、
可読性とか、べつに上がるわけじゃないって
統計でてるんだって。
オセロ合戦とかやってた時期に散々言われてたよ。
統計のソースはプ1がもってるんじゃないかな?

OOを好んで作ったっていいんだけど、素人には
おすすめできないってことだろう。プロならなおさら
慎重になれって。

634 :デフォルトの名無しさん:03/03/31 00:58
>>630
なるへそ!
ちょっとわかった気がします。

で結論、OOも手続き型も知ってても損はしないだろうから
どっちも勉強して実際に設計、コーディングしてみようと思います。

ありがとうございました。

635 :デフォルトの名無しさん:03/03/31 01:00
>>632
いや、「(メソッドの起動に限定された)メッセージのやり取り」で表現されてるはずだ。
非OO的な、メッセージのやり取りとして判断するのが困難な、
「その問題に置ける操作をいきなり抽出する」って方法は、あまりとられないはず。


636 :デフォルトの名無しさん:03/03/31 01:07
>>635
現実には、そういうコーディングを注意深くすれば、そうなるという
レベルなんだけどね。

637 :デフォルトの名無しさん:03/03/31 01:10
つうか、>>600- で、「手続き型」って語が不用意に使われてるが、
「手続き型」ってのは「順序に意味がある」ってこと。
これの対義語は「関数型」であって
「順序がどうであっても、結果は同じ」ってことなのです。

この分類でいくと、普通のオブジェクト指向言語とかは、
各オブジェクトが状態を持つことを許すので、
「手続き型」のサブカテゴリーとも捉え得ます.



638 :デフォルトの名無しさん:03/03/31 01:12
>>637
あ、調べてる途中、なんかそう感じました。
やっぱり手続き型とOOは仲間ですか?

639 :デフォルトの名無しさん:03/03/31 01:14
>>636
意味が分かんない. 例えば、Javaで普通に設計すると
「全部のメソッドをpublic staticにしたクラスが林立する」
ってことも、あなたの主張に含まれますか?

640 :デフォルトの名無しさん:03/03/31 01:20
>>638
いえ、全く関係のない概念です。
依存し合うわけではないし、排他的なわけでもありません。

「手続き的なオブジェクト指向」
「手続き的な非オブジェクト指向」
「関数的なオブジェクト指向」
「関数的な非オブジェクト指向」
の、どれもがあり得ます.
ただ、世の中でもてはやされてるのは「手続き的なオブジェクト指向」。



641 :デフォルトの名無しさん:03/03/31 04:03
非OOで新規開発するのと、OOで新規開発するのは、若干ながらOOで
開発するほうが工数がかかると思う。ただ、OOで最初から開発しておけば
後々の拡張を考えたとき、非OOよりは工数が少なくなると思う。

非OO、OOとも、まともに設計されていれば、だけど。
ただ両者の差がどれくらいになるかはつまるところ開発要員によるわけで。
あまりどっちがどうのと優劣をつける問題でもないような気がする。人的な
問題のほうが手法的問題よりはるかに大きい。

優劣を論じたり、OOは使えないとか非OOは古いとかっていう二元論に
持ち込もうとする人間が最大のガンなんだろうと思う。

642 :デフォルトの名無しさん:03/03/31 04:14
>>641
禿胴!

643 :デフォルトの名無しさん:03/03/31 07:16
プ逝1はオブジェクト指向を理解していないので反論は無意味です。

644 :デフォルトの名無しさん:03/03/31 07:46
> 非OOで新規開発するのと、OOで新規開発するのは、若干ながらOOで
> 開発するほうが工数がかかると思う。ただ、OOで最初から開発しておけば
> 後々の拡張を考えたとき、非OOよりは工数が少なくなると思う。
幻想です。優劣を論じたいのは貴方ですね。




645 :デフォルトの名無しさん:03/03/31 07:51
オブジェクト指向を使いたくない人は使わなければ済む話なのに…

646 :デフォルトの名無しさん:03/03/31 08:03
>>645
個人開発ばっかりやってる人ですか?

647 :デフォルトの名無しさん:03/03/31 11:08
OOな言語で開発したいけど
マイコンとかだとそうもいかないんだよな。
ROM32k RAM4k だとなかなかC++使う気にはならない
しょうがないから、考え方だけOOを使って
アセンブラやCで組んだりするわけだ。
設計にはOOの概念使った方がいい意味で手抜きできるし

648 :デフォルトの名無しさん:03/03/31 11:29
★プロの逝って良しの1のパターン★

間違ったオブジェクト指向の定義に基づいて批判する
             ↓
オブジェクト指向の定義が間違っていることを指摘される
             ↓
オブジェクト指向の定義が間違っているという指摘を無視する
             ↓
間違ったオブジェクト指向の定義に基づいて批判する
             ↓
オブジェクト指向の定義が間違っていることを指摘される
             ↓
オブジェクト指向の定義が間違っているという指摘を無視する
             ↓
間違ったオブジェクト指向の定義に基づいて批判する
             ↓
オブジェクト指向の定義が間違っていることを指摘される
             ↓
オブジェクト指向の定義が間違っているという指摘を無視する
             ↓


間違ったオブジェクト指向の定義に基づいて、オブジェクト指向を
批判するというプ逝1の詐欺行為はいつまで続くのだろう…

649 :デフォルトの名無しさん:03/03/31 11:45
>>627
アンチOOな江戸幕府と、開国を迫る先進技術を誇るOOなアメリカ。
アンチOOはOOを妬んでいるのです。

OOを否定する連中はクラスを作るとコードが余分にふえて面倒くさいから、
重くなるから使いたくないとか不平ばかりいう連中なのです。

650 :デフォルトの名無しさん:03/03/31 14:04
OOが単純にヨイと言い切れないのは、似非SE、似非コン猿がマッチポンプだからだ。

651 :デフォルトの名無しさん:03/03/31 15:45
>>649
何のたとえ話ですか?
江戸幕府は、アメリカを妬んでいたのですか?

652 :Java太郎 ◆DMVtSSFzcg :03/03/31 16:50
ヤイ!ヤイ!ヤイ!ヤイ!

653 :デフォルトの名無しさん:03/03/31 17:02
>649 クラスを作るとコードが余分にふえて面倒くさい

確かにJavaのソースを見てるとアクセサばかりで
中身のないクラスとか結構多いからね。。。。

で、「Delphiはプロパティがあって便利だぞ!」
というDelphi厨の話になるんだがw


654 :デフォルトの名無しさん:03/03/31 17:20
>>653
VB(モゴモゴ

655 :デフォルトの名無しさん:03/03/31 19:59
>>647
ってか,重要なのは考え方じゃない?Javaでもひとつのクラスに全部機能を実装
するヤシも実在するらしいし


656 : ◆2X.Isr1tR. :03/03/31 20:28
トリップテスト

657 : ◆2X.Isr1tR. :03/03/31 20:28
第二のテスト

658 :デフォルトの名無しさん:03/03/31 20:56
>>655
Utils系は漏れもそうしてるぞ

659 :デフォルトの名無しさん:03/03/31 21:19
>>655
あるCOBOLerが初めてJavaを使ったときに
すべての処理を一つのクラス、main()メソッド内
に書いてしまってオブジェクト指向言語の特長を
全く生かしていなかったという話があった。
有名な話らしい。

660 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/31 22:26
おまいら釣られてるんじゃない
http://java-house.jp/ml/archive/j-h-b/021822.html#body


661 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/03/31 22:47
>>659
ある会社はコーディング規則でそう決まっているのだ。
コボラーのせいではないのだ。

662 :デフォルトの名無しさん:03/03/31 22:48
なんかJava=OOと思い込んでるアフォがいませんか。

663 :デフォルトの名無しさん:03/03/31 22:58
>>661
確かに子簿ラーのせいではないね。 
オブジェクト指向を理解しようとしないやつのせいだね

664 :デフォルトの名無しさん:03/03/31 23:07
それは>>662だけです。

665 :641:03/03/31 23:11
>>644
話のごく一部だけの揚げ足を取って「優劣をつけたいのはあなた」とか
言われても説得力ゼロなわけですが。
つーか>>641の内容を全部読んで、それで優劣を比較するという結論
に達した時点でアフォですか?としか・・・
あたしゃ非OOの開発も否定してないですよ。ていうか、現実的には
非OOがまだまだ主流じゃないですかね。ただ、OOによる再設計とか
をうまく使うことができれば(あくまで「使うことができれば」ね)工数は
減りますよ。JDKのコンポーネントの設計を見ていると、うまく再利用
とか拡張ができるように工夫されてるのがよくわかります。

666 :デフォルトの名無しさん:03/04/01 00:46
オブジェクト指向型言語の不得意な分野も指摘しておこう。
顕著な例はメモリマネージメント機能を持たず
メモリの少ない組み込みマイコンである。
ダイナミックなインスタンスの生成および消滅が困難である。
また同時に存在するインスタンスがどれだけになるか予測がつかない場合、
しばしばメモリがオーバーフローする。
このような場合手続き型言語のほうが便利であるし、オブジェクト指向言語を
手続きのグルーピングとして使用する程度の意味合いしかないのは事実である。
携帯ゲームのプログラマはC++をあまり好まない。

オブジェクト指向型言語は抽象化によるメリットが高い場合に
利用効果が上がる。一方で具体的なハードウェアを直接操作する場合、
汎用化を行うことは出来ても抽象化はあまり意味がない。

オブジェクト指向型言語の習得は修行ではない。
便利なら使えば良いし、不便なら使ってはいけないのである。
そしてこの判断が出来るかどうかは
悲しいことであるが設計者の知性のレベルに依存するのである。

667 :デフォルトの名無しさん:03/04/01 00:50
>>665-666
バカの長文氏ね Σ(´Д`lll)

668 :デフォルトの名無しさん:03/04/01 01:06
以上、オブジェクト指向=Javaという前提でお送りしました。
======================ここまで======================


669 :デフォルトの名無しさん:03/04/01 01:08
>>666の上司は賢明なので勘違いOO信者の言うことをすべて却下しました

670 :デフォルトの名無しさん:03/04/01 17:48
>>648
ワラタ

671 :デフォルトの名無しさん:03/04/01 22:28
インスタンス変数をpublicで直接いじるのでは
なく、privateにして、setter、getterメソッドで
アクセスさせる方法が定石なのはなぜなのか、
違い(というか、できたらからくりも)
お前ら教えてください。

672 :デフォルトの名無しさん:03/04/01 22:50
>>667
 長さを支えるだけの構成力があれば、長文もバカに出来ないゾ。
 長文=バカと言いきってしまうのはどうか。

 とマジになってみるテスト。

673 :デフォルトの名無しさん:03/04/01 22:51
>>671
そうしておくと、そのオブジェクトの変数を変更しようとする人は、
必ずメソッドコールしてることになるでしょ。

そうすると、誰がいつ変更しようとしたかが分かるわけさ。
ワケワカランとんでもない値入れようとしたら拒否してみたり、変更の履歴
を取ったり、そういう仕事をメソッド内部に追加できるわけさ。
でもって、そういうものを追加しても、(メソッドシグネチャは変わ
らんので)ユーザに迷惑掛けないわけさ。

誰がいつどのように変更して、整合性の取れない状態変数の集合に
なっても全然かまわないクラスなら、全部変数publicでもかまわない
けど、普通クラスに複数の変数を宣言するときって、それぞれの変数
が全部"なんでもいい"って事は、ないことが多いでしょ?

674 :デフォルトの名無しさん:03/04/02 00:50
>>671
publicな変数を1つ使って実現していた機能が、変数2つに変更したいとする。
外部から直接変数を操作していると、操作する個所すべてに修正を入れる
必要がある。1箇所2箇所ならいいが、数百箇所もあったらバグるのは目に
見えている。

setter/getterメソッドを使って実現していると、メソッドの呼び出し形式が変更
されない限り、変数の操作はクラス内部に隠蔽される。よって、変更箇所も
クラス内部だけですみ、修正工数もバグも激減することになる。

675 :デフォルトの名無しさん:03/04/02 01:07
なんか必死に書いてるのがいるけど、
オブジェクトのインタフェースは、その実装方法に依存してはならない
っていう原則があるからなんだよ。

メンバ変数を公開してしまうと、何かの都合でオブジェクトに変更が入ったとき、
それを利用している他のオブジェクトも一緒に修正しなきゃならなくなるでしょ。

JavaわからんからC++で書くけど、悪い例で言うと
class Foo {
public:
double double_data;
} foo;
void examine(double &d);
みたいなのを作ってたとして、 exsamine(foo.double_data); みたいなコードが
どっかに一カ所でもあると、これをdouble->floatやmona::bignum とかに
置き換えようとしたとき、このクラスを使ってるとこ全部見なおさなきゃ逝けないわけ。

せっかくオブジェクトとして分離、隠蔽してるのに、メンバ変数を一個公開しただけで
そのクラスも、そのクラスを利用する他のクラスも、メンバ変数の実装方法に
依存した設計・実装をしなきゃ逝けなくなるの。


676 :デフォルトの名無しさん:03/04/02 01:15
相手に見せる仕様は最小限に、とか、どっかの本に書いてなかった?

setter/getterは、コード量が増えて面倒に思えるけど、実装方法を
隠蔽したまま、相手に最小限のインタフェースを提供することが出来るわけ。

まあ、集約だけしたコンテナクラスなんかつくってると、いちいち書くのが
面倒とか、委譲できない言語は駄目とか思ったりするわけだけど、
オブジェクトのあり方をしっかり考えながらを繰り返し設計・実装していけば
setter/getterがなんで必要なのか体感できるようになるかも。

外からいじるため(だけ)に作る集約オブジェクトは、setter/getter
いらない場合もあると思うよ。


677 :デフォルトの名無しさん:03/04/02 01:23
>>671
隠蔽しないと個々のオブジェクトとして設計していく意味がないから。

この辺りのことは入門書でも詳しく触れられているんじゃないすか。
読めよ。


678 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/02 01:38

>>640に洗脳されたアフォはこの先見こみが無いので転業しなさいね。

679 :デフォルトの名無しさん:03/04/02 01:43
>>676
getter/setter 方式のメリットは、今は本当にメンバ変数を return したりそれに
代入したりするだけの処理をしていたとしても、クラスを修正したり、それを
継承した子クラスで処理が予想と変わり、get や set する際に何かしら演算を
してからメンバ変数に代入したり、メンバ変数の値を演算したものを返したり
することになることがあるとき。

リファクタリングで言う引数オブジェクトなんかは、とりあえず public な
メンバ変数でもいいのだろうけど。


680 :デフォルトの名無しさん:03/04/02 01:46
>>679 微妙にsetter/getterの意味を読み違えてるやつ


681 :デフォルトの名無しさん:03/04/02 01:48
>>672
どう考えても、「バカは長文書くな」って意味だと思うよ。

682 :671:03/04/02 07:01
どうも、みなさんありがとうございました。
カプセル化(隠蔽)の必要性は本等で
読んでいます。
なので、公開する必要性のあるデータ
のみの話です。

1行のア/サクセサをつらつら書いておくのも
実際には今後の保守や拡張の為の保険って
いうのが主な理由なのですね。

683 :デフォルトの名無しさん:03/04/02 08:20
>>678
おまえも非OOの布教活動に躍起になってますね。 
どうですかOOから非OOへの洗脳はうまくいきますか?

684 :デフォルトの名無しさん:03/04/02 09:14
手続き型も関数型も同じじゃん。procedure か function でしょ。
要するに、void かそれ以外の型を返すか。

685 :デフォルトの名無しさん:03/04/02 09:18
>>684
エイプリルフールは終わりましたよ・・・

686 :デフォルトの名無しさん:03/04/02 11:06
OOって、データのクラスとそれらを使って何かやる人のクラスと
あると思うんだけど、正式な名称って何?
UMLとか勉強すれば書いてあるのかな
アクターってやつがそうなの? アクトレスは?
きまぐれオレンジロードの主題歌って誰が歌ってたんだっけ?

687 :デフォルトの名無しさん:03/04/02 11:31
>>686
ユースケース図とクラス図を行動しているなおまいは

688 :デフォルトの名無しさん:03/04/02 11:53
>>682
違った面から見た理由をいうと
予めアクセサをつらつら書いておく必要があるのは、
メンバ変数のアクセスとメンバ関数呼び出しとで書き方が違うから。
同じ書き方であれば、必要になってからアクセサを書くで充分だったりする。

アクセサはせっかく隠蔽してあるものを透かしてしまう働きがあるとかで
多用すべきではないという話を聞いたことがある。

689 :デフォルトの名無しさん:03/04/02 11:54
>671-679
Delphiにはプロパティがあって・・・(以下略


690 :デフォルトの名無しさん:03/04/02 14:12
>>682
Beanにしたい ってこともあるんじゃないですか。

691 :デフォルトの名無しさん:03/04/02 18:21
>>684
そのネタ飽きた。

692 :デフォルトの名無しさん:03/04/02 20:57
>>686
エンティティ、コントロール、バウンダリ
ロバストネス図を調べてみ。


693 :デフォルトの名無しさん:03/04/02 23:27
>>692

なんか、こういう技巧を凝らした用語がOOに対する偏見とか
批判対象を作ってしまうような気がしてる。

694 :デフォルトの名無しさん:03/04/03 00:35
全部読んだ。ココ、本当にスゲー!!!
会社で、ここにいるSE程レベルの高い人間が居る?って思っちゃう位。

プロ・アマ含めて相当なスキルある人間集まってると思う。

誰か箇条書きで挙げてくれる人います?

たとえば..

・絶対継承外すのは、譲れないね!理由は...
・多重継承は許さんね!名背なら...

みたいな達人達!

695 :デフォルトの名無しさん:03/04/03 00:37
オブジェクト指向のオブジェクトとは物体ではなく、対象・目的という意味合いが強い。
解説書には「物として扱う」などとかかれているが、それは微妙にニュアンスが異なる。
「対象として扱う」と記述したほうがより理解が進むであろう。

漏れはオブジェクト指向は目的思考とでも言ったほうが良かった気がする。
objectとまったく同じニュアンスを持つ日本語が存在しないために
苦肉の策としてオブジェクトというカタカナを使ったのだとは思うが、
物体思考だと勘違いする香具師がいかんせん多すぎはしないか。

696 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/03 01:02
OOマンセーやってた会社はどんどん潰れてるから、昔よりOO派の声が小さい。


697 :デフォルトの名無しさん:03/04/03 01:06
>>696
> OOマンセーやってた会社はどんどん潰れてる
ソースキボン


698 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/03 01:16
>>695
そんなネタしか無いのか?

699 :デフォルトの名無しさん:03/04/03 01:17
>>696
OOコンサルなんかやってた詐欺師連中は、新しいネタ探しにいってるだろな。
IT関連のベンチャーなんて、開発なんか本心ではドウデモイイと思ってる山師バ
ッカリだからナー。

普通に使える人がイッパイいる会社では、普通に使ってるんじゃないのかね。

700 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/03 01:18
でも、その調子で、「OOだ、OOだ」と言いながら
巧いこと騙して手続き型に導くのも手だな。

701 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/03 01:51
>>697
仮定法

702 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/03 01:54
4月。
新入社員の中には「OOやります」という会社の説明を受けて入ってみたら
クラス名が番号だったり、mainメソッドに全部書くキマリの会社だったり
するのが居るだろう。


703 :デフォルトの名無しさん:03/04/03 02:06
>>700

漏れは非OOと見せかけてOOするステルスOOやってますた

704 :デフォルトの名無しさん:03/04/03 02:28
>>702
そういうダメダメな会社はOO以前につぶれる罠。

705 :デフォルトの名無しさん:03/04/03 02:35
適度に荒れているなぁ
>695
『プログラマがやりたいことをオブジェクトにやらせる』
つうのが基本でしょうなぁ.

そういや,オブジェクト指向の説明で『車.走る』なんて
説明していたのもあったなぁ.こんな説明したら初心者は
混乱するのに……

本当は『車.走らせる(プログラマが)』つうのが正解ですな

706 :デフォルトの名無しさん:03/04/03 02:45
オブジェクト指向の本質は必要な時にオブジェクトが生成できて、
メソッドの実行結果をオブジェクトに格納させられることだと思う。

C言語(非オブジェクト指向)なら、
メソッドの実行結果を構造体に格納する場合があると思うけど、
オブジェクト指向言語なら、オブジェクトのメソッドを実行して、
その結果をオブジェクトに持たせることができる。

■C言語(非オブジェクト指向)
int ret;
KOUZOUTAI *kekka;
ret = methodA(param,kekka);

■JAVA(オブジェクト指向)
int ret;
OBJECT_SAMPLE obj = new OBJECT_SAMPLE
ret = obj.methodA(param) ← 結果はobjに格納




707 :デフォルトの名無しさん:03/04/03 03:08
オブジェクト指向の本質はポリモーフィズムだよね。

>>706 のことは、メソッド名は同じでも返り値が違うってのもポリモーフィズム、、、と言っていいのかどうか。

708 :デフォルトの名無しさん:03/04/03 05:22
OO厨はオブジェクト指向の本質1つ
       意見がまとめられないのかよ・・・


709 :デフォルトの名無しさん:03/04/03 06:20
>>705
> 本当は『車.走らせる(プログラマが)』つうのが正解ですな

車.走れ();

だろう。


710 :デフォルトの名無しさん:03/04/03 06:41
>>706
> int ret;
> KOUZOUTAI *kekka;
> ret = methodA(param,kekka);

int ret;
KOUZOUTAI kekka;
ret = methodA(param,&kekka);

の間違いか?

711 :デフォルトの名無しさん:03/04/03 07:20
>>708
ほとんどのOO厨がちゃんとしたOOPの定義を知らないで
OOPとはこんなものだろうと推測してOOPの定義を勝手に
つくっているので統一されることはありません。

712 :デフォルトの名無しさん:03/04/03 07:23
理系もおちたな

713 :デフォルトの名無しさん:03/04/03 07:26
あいかわらずアフォばっかりだな

714 :デフォルトの名無しさん:03/04/03 07:28
>>705
>>709
つーか現実世界の物体に投射しようとするところがそもそも間違いだと
思うのよ。プログラムで扱いたいことってそういう「物体の表現」ではない
わけでさ。そういう意味では>>695の説明が実に的確だと思うんだが。

715 :デフォルトの名無しさん:03/04/03 07:31
まあそれにしても

>オブジェクト指向の本質は必要な時にオブジェクトが生成できて、
>メソッドの実行結果をオブジェクトに格納させられることだと思う。

こんなこと正気で考えているなら、今すぐ業界から足洗ったほうがいいよ。
きっと上司も冷たいだろう。

716 :デフォルトの名無しさん:03/04/03 07:35
指向のオブジェクトがあるなら究極のオブジェクトもあるんですか?

717 :デフォルトの名無しさん:03/04/03 08:31
>>715

面白くない煽りは要らない。


漏れはOO大好き野郎だが、OOはいろんな側面がある。教科書的には
1)カプセル化(encapsulation)
2)継承(inheritance)
3)多様性(polymorphism)
4)均一性(uniformity)

基本要素はこれ。その中でも多様性がブッチギリで重要かつ便利な機能であることは確かだ。

718 :デフォルトの名無しさん:03/04/03 09:03
>>714
オブジェクト指向の object は、物体の意味じゃなくて、subject に対する object でしょ。
だから、subject(プログラマ)が、object(対象)に命令する形が自然。
だからメソッド名は命令形なんだよ。

car.run(); // 「車よ、走れ」とこっちが相手に命令



719 :デフォルトの名無しさん:03/04/03 09:13
subject は、主体、相手を服従させるという意味、つまりすべての権限を握っている者、
つまりプログラマのこと。
object は写真撮影の被写体とかいうけど、ようするにいじくり回されるものの意味。
つまり、A Programmer subjects objects. (プログラマがオブジェクトを支配する、
思い通りにいじくり回す)という発想。
オブジェクト指向を「物指向」と訳した人は、この語感がわからなかったんだろうね。

つまり、OO では、object が独立してあるわけじゃなくて、そこには subject に
支配されることが前提という語感がある。
「物指向」と訳しちゃった人は、object が自律的に動く、現実世界の「物」に対応
させたけれど、それは誤り。


720 :デフォルトの名無しさん:03/04/03 09:23
>>718-719
サブジェクトがメソッドを使ってオブジェクトをいじくり回すということね。

おれはむかし、'90 年頃、オブジェクト指向の話を聞いて、とりあえず .c を
みんな .obj にしておいて、そこからどうにかするとリンクからだから速く作れて
便利なものだと勝手に理解していた。



721 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/03 09:37
>>719
死ね

722 :デフォルトの名無しさん:03/04/03 09:57
>>719
ということはエージェント指向は、subjectの意識に逆らって
objectが自立しって動く指向なのですね?

723 :デフォルトの名無しさん:03/04/03 10:15
誤った定義でも批判出来なかったのですね?

724 :デフォルトの名無しさん:03/04/03 10:26
>>722
そう。


725 :デフォルトの名無しさん:03/04/03 10:30
非OOが入力プロンプトで人間が動くソフトウェアドリブンな方式
OOがマウスクリックなどのイベントでソフトウェアが動くイベントドリブンな方式

のような印象があるな。

726 :デフォルトの名無しさん:03/04/03 10:31
>>722
自立はしませんね。自律はするけど。
でもまあ、いままで subject - object という枠組みだったから、agent な
object がある程度の裁量権を持つというのはそれなりに画期的だったから、
それがわかる人には注目されてきたわけだ。


727 :デフォルトの名無しさん:03/04/03 10:32
>>725
OO とイベント・ドリブンとは関係がない。ただ、イベント・ドリブンなフレームワークに
OO はなじみやすいというのは確か。


728 :デフォルトの名無しさん:03/04/03 10:34
>>721
知らなかったからって、まあ、怒るな。マターリいきませう。


729 :デフォルトの名無しさん:03/04/03 10:42
>>722
別の環境でいろいろといじくり回されるということ。
こっちからどっかに転送されてしまったエージェントは、どっかで
どうメソッドを呼ばれるのかわからない。
やられたい放題。
だから、セキュリティを確保するために、どこにいっちゃっても、
本当にめちゃくちゃにいじりまわされないような合意が必要。


730 :デフォルトの名無しさん:03/04/03 11:50
>>716
究極のオブジェクト=ぶろぶ

COBOLerなんかが作ってくれるらしいよ。

731 :デフォルトの名無しさん:03/04/03 20:54
>>717

違います。ポリモーフィズムが重要なのは
設計以下であり、全般的にわたって重要かつ基本なのは
メッセージパッシングとカプセル化です。

これがわかってないとクラスの責務の重要性
が理解できない。





732 :デフォルトの名無しさん:03/04/03 22:19
宗方指向

733 :デフォルトの名無しさん:03/04/03 22:25
>>717
> 4)均一性(uniformity)

基本要素にこれが入るってあまり聞いたことがない。
少し調べてみたけど、多様性との違いがわからなかった。

734 :デフォルトの名無しさん:03/04/03 22:48
で、1は理解できたのか?

735 :デフォルトの名無しさん:03/04/03 23:04
自分で考えようとしない奴には誰が教えたって同じさ。

736 :デフォルトの名無しさん:03/04/03 23:05
ここはやはりアプリを作ってだな・・・

737 :デフォルトの名無しさん:03/04/04 00:04
>>731
細かい役割担当者の組み合わせで大きな仕組みを実現する、っていう
構造が再帰するような構造にしとくと、馬鹿なオイラにも分かりやす
い。

OOはヘンな宗教じゃなくて、物覚えの悪い馬鹿に優しい仕組みだと、
おいらは思うじょ。

738 :デフォルトの名無しさん:03/04/04 00:22
>>731

>細かい役割担当者の組み合わせで大きな仕組みを実現する

731がいいことゆうた。

739 :デフォルトの名無しさん:03/04/04 00:24
>>738

737のまちがえ。

740 :デフォルトの名無しさん:03/04/04 01:02
>OOはヘンな宗教じゃなくて、物覚えの悪い馬鹿に優しい仕組みだと、
>おいらは思うじょ。

まったくもって同感。
オブジェクト指向は難しいものだと思い込んでる人に、そう説いた経験がある。
現在はその相手もそう思ってると聞きました。

741 :737:03/04/04 01:13
いや〜、今日、死ぬほどたくさんのプリミティブ値の配列を準備して、全てその
配列への操作と大量のスイッチ文でプログラムを実現する、「根性の賜物」ソー
スを追う羽目になりまして、「ああ、コレ作った奴がOOをちょっとでも知ってたら、
オイラも楽だし、作った奴も楽だっただろうにな〜…何がなんだか分からんよ つд`)」
と思ったのデス。

根性なしのオイラからみると、作者はある意味えらいとおもうんだけど、その根性
をすこしでも情報収集に向けてくれてれば…

742 :705:03/04/04 02:03
>709
確かに命令形の方がわかりやすいけど,あえて使役の形にしたのは
「車を走らせるためにプログラマがお膳立てをしている」
というニュアンスを含めたかったから.
……まあ,大した意味は無いけどね

>714
オブジェクト指向の良いところは,(生まれてきてから何度となく繰り返して
きている)現実世界での行動との相似性を利用できるところだから,
『現実世界の物体に投射しようとする』のはそんなに的外れじゃないよ.
#方向は逆だけどさ

>717
要素ではあるけれど,本質じゃないよ.
結局,『繰返し習得して身につけた現実世界のメタファをプログラムに利用する』
つうのがオブジェクト指向の良いところじゃないのかな?

>719
英語で"object"が『物体』『目的』『対象』という意味を持つように,向こうさん
にとっては,このあたりの概念はかなり混然としたものなんじゃないのかな?
抽象的な概念を『物体』のように扱ったり……ただのヨタです.外国人のこと
良く知らないし.

>737
人間3つ以上のことは同時に憶えていられないから……
良くできたライブラリがあれば,かなり乱暴なプログラムをしてもマトモに
動作するからねぇ




743 :デフォルトの名無しさん:03/04/04 04:02
> オブジェクト指向の良いところは,(生まれてきてから何度となく繰り返して
> きている)現実世界での行動との相似性を利用できるところだから,
あと、パラメータを追加した時に外部の変更を最小限に抑えられる
とか、実行フローからの独立性が高くなるとか。

744 :Java太郎 ◆DMVtSSFzcg :03/04/04 08:05
>>734
いいえ。
最近、さぼってました。
マルチスレッドの所で疲れました(プログラミングレッスン下巻)
しばらく、休みます・・・ゴホッゴホッ。

745 :デフォルトの名無しさん:03/04/04 14:53
>>743
その引用部分は笑うところだと思うんだが。

746 :デフォルトの名無しさん:03/04/04 15:21
現実世界の物体に自律して動くものがどれだけあるつうの?
殆どは受動的だよ。

747 :デフォルトの名無しさん:03/04/04 15:34
>>1
ついでに、

「貴様ら!エージェント指向を教えろ!」
「貴様ら!アスペクト指向を教えろ!」

スレも立ててくれ


748 :ヽ(´ー`)ノ:03/04/04 15:49
あー aspect 指向興味あるんだよな。関連スレ立ってなかったけ?

749 :名無し@沢村:03/04/04 18:53
>>746
>現実世界の物体に自律して動くものがどれだけあるつうの?
殆どは受動的だよ。

ヌヒよ、すべての物体は自立して動いてるよ。わかるか?
ヌヒよ、すべての物体は原子からなっており、原子核の周りを電子が回ってるよ。能動的にな。
ヌヒよ、すべての物体は能動的なんだよ。わかるかな?


750 :デフォルトの名無しさん:03/04/04 19:10
>>746
ネコ。

751 :デフォルトの名無しさん:03/04/04 19:32
くされ、だな。現実世界で、お金がもらえなければみっともねーだろう。

752 :デフォルトの名無しさん:03/04/04 19:32
>すべての物体は原子からなっており、原子核の周りを電子が回ってるよ。能動的にな。
本気で言ってるのか?

753 :デフォルトの名無しさん:03/04/04 20:48
電子は自らの意思で原子核の周り、つかず離れずの位置を保っている。
この電子の意図は神すらも計りえない。これをハイゼンベルグの不確定性原理という。

754 :705:03/04/04 21:48
>753
そこまでいくと受動も能動もクソもミソも無いだろうに。
疑似問題で言葉遊びされてもなぁ。

755 :デフォルトの名無しさん:03/04/05 00:25
モノが能動的に動いていようがそうでなかろうが、モノを観察する人、
使用する人にとっては、モノに対するどんなアクションにどんなリア
クションがかえってくるかということ以外に、興味はないですの。

756 :デフォルトの名無しさん:03/04/05 02:32
>>753
電子に聞いたのか? おまえは電子の何がわかる? おまえは電子の何なんだ!
電子が本当にそういったんだな? 電子がいったのだったら謝るが、それが何?


757 :デフォルトの名無しさん:03/04/05 03:20
>>756
おまえは聞いたことないのか? おまえはわからないのか? おまえは知らないのか!
当然そういったんだよ! 早く謝れよ! だから何? 

758 :デフォルトの名無しさん:03/04/05 03:36
(プッ

759 :デフォルトの名無しさん:03/04/05 03:36
>>757
ごめんなさい。


760 :デフォルトの名無しさん:03/04/05 03:40
>>753
> これをハイゼンベルグの不確定性原理という。

言わないって。

761 :デフォルトの名無しさん:03/04/05 05:04
× ハイゼンベルグ
○ ハイゼンベルク

762 :デフォルトの名無しさん:03/04/05 06:51
>>745
>その引用部分は笑うところだと思うんだが。
同意。


763 :デフォルトの名無しさん:03/04/05 07:18
>>742
クラスは抽象データ型の雛型です。
現実世界の雛型という定義は本質からズレてる。

764 :デフォルトの名無しさん:03/04/05 07:44
液晶テレビ「AQUOS」が当たるチャンス
http://camellia16.fc2web.com/gpoint.html

765 :デフォルトの名無しさん:03/04/05 11:06
死死死死死死死死死死死死死死死死死死死死

766 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/05 17:59
受動的なオブジェクトを支配下においてメインは手続き型で書く。
部品化可能なモジュールは見とおしが良いからすぐ思いつく。
逆に無理やり部品化したようなのは破綻しやすい。
上位層は構造化。
UML図は無用の長物。
これがあるべきプログラミングの最終結論。

767 :デフォルトの名無しさん:03/04/05 18:17
すいません。
オブジェクト指向って、情報隠蔽、継承、多態性が柱だそうなんですが、
多態性って柱とまで言うほとのものなんですか?
だって結局のところ同じメッセージ受け付けるかどうかってだけですよね?

768 :デフォルトの名無しさん:03/04/05 19:32
>>767

例えば COM とか UDDI とかのインタフェイス抽象のことを考えると
多態性ってのの実用性もわかると思うけど。

あとテンプレートとかメソッド名での late binding な Smalltalk みたいな
言語とかを使うと、「同じメッセージ受け付けるだけ」ってのが案外便利な
技法だってことに気付くと思う。

769 :デフォルトの名無しさん:03/04/05 22:01
>>767
ダイナミックバインディングの便利さを知っているか?


770 :デフォルトの名無しさん:03/04/05 22:09
ここは実装ヲタばっかりだな。継承やポリモが
重要というやつの実装は概念モデルがめちゃくちゃ
で他人には容易に理解できないという罠。

771 :d:03/04/05 22:09
最新情報です。
甘く見てると痛い目にあう典型みたいなヤツだな。w

http://www.deai-navi.net/linkrank/linkrank.cgi?mode=in&id=fdeai

772 :デフォルトの名無しさん:03/04/05 23:08
オブジェクト指向、Strict-XHTMLと極右思想
http://tmp.2ch.net/test/read.cgi/sisou/1049523041/l50

773 :デフォルトの名無しさん:03/04/06 00:32
オブジェクト指向とは・・・
簡単に言うと、「スポーツ」って言葉がある。
このスポーツに属する物に「サッカー」とか、「野球」とかってあって、それが・・・

             (中略3379文字)

・・・いてはいけないよ!って言ってお茶を飲んだ。


774 :デフォルトの名無しさん:03/04/06 03:13
>>766
perlのこと?

775 :デフォルトの名無しさん:03/04/06 03:47
金・銀パール
プレゼント!


776 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/06 15:51
>>774
めまいがする言語はカンベンして

777 :デフォルトの名無しさん:03/04/06 15:54
>>776
じゃあおまえはどの言語ならめまいがしないんだよ

778 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/06 15:58
パール以外

779 :デフォルトの名無しさん:03/04/06 17:16
>>778
オブジェクト指向言語は別にいいのか?

780 :デフォルトの名無しさん:03/04/06 17:42
>>778
関数型言語は?


781 :デフォルトの名無しさん:03/04/06 18:11
関数型言語はメンテしやすいよ。
副作用が表に出てくる言語なんかより保守性はずっと上だし、
リファクタリングも掛けやすい。
副作用をストリームに隠蔽したりする考え方は、他の言語で
書くときも応用できる。

782 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/06 18:27
普通に仕事で使う言語以外しらんな。

783 :あぼーん:03/04/06 18:28
   ______________
 /:\.____\
 |: ̄\(∩´∀`) \  <先生!こんなのがありました!
 |:在  |: ̄ ̄ U ̄:|
http://saitama.gasuki.com/aomori/

784 :佐々木健介:03/04/06 18:30
     ______
    /_      |
    /. \ ̄ ̄ ̄ ̄|
  /  /  ― ― |
  |  /    -  - |
  ||| (5      > |
 | | |     ┏━┓|   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
| | | |     ┃─┃|  < こんなサイトを見つけた
|| | | |  \ ┃  ┃/    \  正直、スマンカッタ
| || | |    ̄         \_________
http://saitama.gasuki.com/hiroyuki/

785 :あぼーん:03/04/06 18:32
 ( ・∀・)< こんなのみつけたっち♪ 
http://muryou.gasuki.com/moe/hankaku09.html
http://muryou.gasuki.com/moe/hankaku10.html
http://muryou.gasuki.com/moe/hankaku07.html
http://muryou.gasuki.com/moe/hankaku08.html
http://muryou.gasuki.com/moe/hankaku05.html
http://muryou.gasuki.com/moe/hankaku06.html
http://muryou.gasuki.com/moe/hankaku03.html
http://muryou.gasuki.com/moe/hankaku04.html
http://muryou.gasuki.com/moe/hankaku01.html
http://muryou.gasuki.com/moe/hankaku02.html

786 :あぼーん:03/04/06 18:33
             ∩
        ∧_∧   | |   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
       (  ´Д`)//  < 先生!こんなのを発見シマスタ!
      /       /    |
     / /|    /      \  http://saitama.gasuki.com/koumuin/
  __| | .|    |         \
  \   ̄ ̄ ̄ ̄ ̄ ̄ ̄\     \_____________
  ||\             \
  ||\|| ̄ ̄ ̄ ̄ ̄ ̄ ̄|| ̄
  ||  || ̄ ̄ ̄ ̄ ̄ ̄ ̄||
     .||              ||

787 :あぼーん:03/04/06 18:35
   ,.´ / Vヽヽ
    ! i iノノリ)) 〉
    i l l.´ヮ`ノリ <先生!こんなのがありました!
    l く/_只ヽ    
  | ̄ ̄ ̄ ̄ ̄|
http://muryou.gasuki.com/sinagawa/

788 :デフォルトの名無しさん:03/04/06 18:52
>>782
勉強しろよ

789 :デフォルトの名無しさん:03/04/06 19:33
無知が癇癪を起こしている

790 :767:03/04/06 20:55
結局多態性ってのは単に「同じメッセージを受け取れる」ってことに名前を付けただけなんですね。
dynamic bindingが便利かどうかなんてこのさいどうでもいいんでしょ?

791 :デフォルトの名無しさん:03/04/06 20:56
うん

792 :デフォルトの名無しさん:03/04/06 20:58
>>790
話に参加したかったら基礎的な用語ぐらい勉強してからにしようね。

793 :デフォルトの名無しさん:03/04/06 21:00
大した物じゃないけど、いざ実装してみると色々便利だったりする。
OOにシフトする際になんかめりっとあるかって言われたとき、
実装レベルの便利さを立ててあげてもいいんでないかなあ。

794 :デフォルトの名無しさん:03/04/06 21:05
プログラミングに大した物なんてない。
その中で最高の物の一つが多態性。

795 :デフォルトの名無しさん:03/04/07 00:00
>>794
手続き(関数)をスッキリ構造化する手段として、便利ですが。

JavaDocとか、最近はやりのUMLベースIDEみたいな、クラス構造に関するドキュメントを
自動生成してくれるフレームワークがあると、仕様の後追いがすごい楽でつ。


796 :デフォルトの名無しさん:03/04/07 00:18
メンバ変数をprivateにしてメンバ関数からアクセスさせて壊れにくくさせると
いいますが、けっきょくクラス内部で条件指定などをしてあげないと
壊れにくくならないので、それって普通の関数でも同じじゃんと思ってしまうのは
漏れだけでしょうか?

797 :bloom:03/04/07 00:21
http://www.agemasukudasai.com/bloom/

798 :デフォルトの名無しさん:03/04/07 00:24
>>796
そのメンバ変数はそのクラスのメンバ関数以外からは変更されない

普通の関数と同じじゃないだろ

799 :767:03/04/07 00:30
>>792
こういう何か言ってそうで何も言ってない(言えない。言うだけの頭がない)人間との話になんて参加したくもありませんよ。


800 :デフォルトの名無しさん:03/04/07 00:34
その 「だけ」 のことが便利だから柱の一つと呼ばれてるんだが。
このスレを 1 から読むなりデザパタでも調べろ。

801 :デフォルトの名無しさん:03/04/07 01:10
>>799
はあ、そうですか。 だから? 何?

802 :デフォルトの名無しさん:03/04/07 01:55
>>799
参加したくない場合に取るべき行動は何かわかるか?
ここに来るなってことだよ。

さっさと消えな。

803 :705:03/04/07 02:31
>多態性
多態性というよりも、グルーピングといったほうがピンと来そうだけど……

せっかくオブジェクトとしてそれぞれ独立させたんだったら、相手の
オブジェクトのことは(必要最低限のこと以外は)知らなくても良いように
したくない?

多態性があると、『このオブジェクト群には、こう命令すれば動いてくれる』
といった感じに何種類かのオブジェクトをひとまとめにして取り扱うことが
できるので、そのオブジェクト群を使うオブジェクトが、そのオブジェクト群を
個別に扱う必要が無くなる->オブジェクトがシンプルになる。という訳。
wigetなんかの設計をするときに多態性がなかったら死んでますな………

#さらにこの考えを推し進めると、もっと便利になるよ。
#Rubyだと、そもそも同じ名前のメソッドだったら、継承関係の無い
#オブジェクトでさえも同じように扱える。

このへんは現実世界でも良くあることで、例えば
・テレビ用のリモコン
・AVコンポ用のリモコン
・エアコン用のリモコン
なんかは、とりあえずpowerボタンを押せば、それぞれの装置のことを
あまり詳しく知らなくてもスイッチを入れることができるよね。
多態性って、そのあたりのメタファーなんじゃない?


804 :デフォルトの名無しさん:03/04/07 02:38
つーかさ、VBでも多態性簡単に実装できるんだけど・・・。
なんか勘違いしてない?

805 :デフォルトの名無しさん:03/04/07 02:42
どっから VB の話が?

806 :デフォルトの名無しさん:03/04/07 02:47
Cでも多態性実装できますね。
アセンブラでも実装できますね。

807 :705:03/04/07 02:50
つづき
次に逆の方向になるけど、次のようなケースも多態性が必要になるケースですな。
すでにできあがっている/作りかけのシステムに機能(仕組み)を追加したくなった。
その機能は全く新しい機能なので、既存のオブジェクトを調整するだけでは
実現できないけど、機能を実現するための仕組みは従来のオブジェクトを
操作する方法を利用できそうだ。
(実際うまく設計できれば、様々な機能を同じ仕組みの上で実現することができる)

そこで、『このオブジェクト群と同じ命令を受け付ける様にする』すなわち多態性を
利用することによって、既存のシステムの仕組みを変更することなく新しい機能を
追加することができる。
こっちのほうがいわゆる『多態性』になるのかな?

このへんも現実世界で良くあることで、タイプライターとコンピュータのキーボード
なんかは良い例ですな。

つまり、多態性によって『機能』と『仕組み/操作方法』を分離することができるつうのが
『多態性』を重要なものにしている要因だと思うんだけど、どう?


808 :デフォルトの名無しさん:03/04/07 05:33
>>806
VBと違って専用の命令ないけどね。

809 :デフォルトの名無しさん:03/04/07 06:41
>>808
VB は命令で多態性を指示するのか。
悔しかったら VB で Template Method パターンをやてみろ。


810 :デフォルトの名無しさん:03/04/07 06:43
>>806
昔、オブジェクト指向言語が簡単に手に入らなかったときに、
前向きにやろうということでそういうのを掛け声にすることは
あったけど、何が悲しくていまさらそんなことを。


811 :デフォルトの名無しさん:03/04/07 07:34
ポータビリティのため。

812 :デフォルトの名無しさん:03/04/07 07:50
>>811
厳しい環境だね。ご苦労さん。


813 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/07 10:04
多態デムパが暴れてるスレはココですか?

814 :デフォルトの名無しさん:03/04/07 12:49
>>808
VBって、どんな命令でかくの?

815 :デフォルトの名無しさん:03/04/07 12:54
>>770

いいことゆうた。ここみてるとオブジェクト指向って
実装レベルでしか浸透してないなーとおもふ。

816 :デフォルトの名無しさん:03/04/07 12:56
>>809
へぇ〜 継承が出来ないから、Template Method"は" できないの知ってるみたいだね。
でも継承を使わないパターンは実装できるんだよ。
もちろん多態性が必要なパターンもね。

>>814
多態性といえばimplementsでしょ。Javaと同じ。


817 :デフォルトの名無しさん:03/04/07 13:48
>>816
質問っす。
最近Implements (VB)知ったんだけど,べつにこれ使わなくても多態はできるん
だよね。ただ、他の強制力が多少はたらくっつーか、コードが書きやすくなる
っていうくらいで。

818 :デフォルトの名無しさん:03/04/07 13:56
VB.NETがでたんだから、VBのクラスはもういいじゃん。

819 :デフォルトの名無しさん:03/04/07 14:24
>>817
アーリーバインドとレイトバインドの違いもある。
オレとしてはコードのカキ易さ(+読みやすさ)も重視したいところだが。

820 :デフォルトの名無しさん:03/04/07 15:02
実装(少なくとも定義)忘れが無くなるのはかなり便利だと思う。

821 :デフォルトの名無しさん:03/04/07 15:31
>>816
インターフェースの継承しかできないじゃん。
「できる」っていえばできるけど、両足を縛られて 100 m 走をやれって
ゆうようなもんだよ。


822 :デフォルトの名無しさん:03/04/07 15:36
VB6 までで、まともなオブジェクト指向設計しようとすると、
やってみればわかるけど、インターフェースの継承しかできないばっかりに、
かなりひねくれた設計になるぞ。
たとえば、メソッドの引き上げは不可能だから、別のクラスにして、すべての
子クラスからそれを呼ぶようにするとか。
かなりひずんだ設計になる。


823 :デフォルトの名無しさん:03/04/07 15:39
> たとえば、メソッドの引き上げは不可能だから、別のクラスにして、すべての
> 子クラスからそれを呼ぶようにするとか。
要するに委譲のことですね。委譲は別に歪んだ設計じゃありませんよ。


824 :デフォルトの名無しさん:03/04/07 15:40
>>821
始めっからインターフェースの継承の話しかしてないじゃん。
なに一人であつくなってんの?

825 :ヽ(´ー`)ノ:03/04/07 15:40
委譲自体は歪んだ設計じゃないけど、委譲だけの設計ってのも異常だよなぁ…。
…あ、いや、シャレじゃなく。

826 :デフォルトの名無しさん:03/04/07 15:41
>>823
委譲というか、オブジェクト・コンポジション。
オブジェクト・コンポジションはひずんだ設計じゃないが、メソッドの
引き上げをする場面でオブジェクト・コンポジションを使うと言うのは
ひずんだ設計だよ。


827 :デフォルトの名無しさん:03/04/07 15:42
委譲っていうのは、自分自身のインスタンスをどれか別のクラスに渡すこと。


828 :デフォルトの名無しさん:03/04/07 15:44
なんでメソッドの引き上げってリファクタリングの話してんだ?
設計の話だろ。VBなんだからVB用の設計をするだけの話だろ。

829 :デフォルトの名無しさん:03/04/07 15:44
>>824
> 始めっからインターフェースの継承の話しかしてないじゃん。

ちがうねえ。VB で多態性ができるという話が始まったんだねえ。
インターフェースの継承も多態性のひとつだけど、抽象クラスの継承も
多態性なんだね。


830 :デフォルトの名無しさん:03/04/07 15:45
>>828
リファクタリングは設計です。


831 :デフォルトの名無しさん:03/04/07 15:45
VBでオブジェクト指向の話をすると
かならずメソッドの引き上げとtemplate methodの話で対抗する
奴がいますねぇ(w

832 :デフォルトの名無しさん:03/04/07 15:46
>>829
> インターフェースの継承も多態性のひとつだけど、
結論。VBで多態性は実装できる。

833 :デフォルトの名無しさん:03/04/07 15:46
>>831
OO の定石だからね。できないとすごく不便。まともなクラス設計はできない。
すごくひずんだ設計になる。
って、OO のクラス設計をやったことがないとわからないか……


834 :デフォルトの名無しさん:03/04/07 15:47
>>830
残念ながら違います。そんなアフォな事言っているのは貴方だけです。

835 :デフォルトの名無しさん:03/04/07 15:47
>>832
VB で多態性は中途半端に実装できる。


836 :デフォルトの名無しさん:03/04/07 15:48
>>835
中途半端ではないですね。ちゃんと多態性になっているのですから。

837 :デフォルトの名無しさん:03/04/07 15:49
>>833
あなたはCでOOやったことありませんね。

838 :デフォルトの名無しさん:03/04/07 15:51
CでOO出来るって言っておきながらVBでは出来ないって言っている
奴もいるくらいだからねぇ。
まぁ、認めたくないものは認められないって強い信念を持っている奴は
人間的に認められないね。

839 :デフォルトの名無しさん:03/04/07 15:51
>>834
それは、古い「計画的設計」の頃のお話。
http://objectclub.esm.co.jp/eXtremeProgramming/IsDesignDead.html
進化的設計ではふつうの話。

>>836
クラスの継承で多態性ができないのは、中途半端。

>>387
C で OO はできるけれど、昔、OO 言語で納品できなかった頃の、前向きな
掛け声。できるできないといったらできる。でもひずんでいる。コードも増える。


840 :デフォルトの名無しさん:03/04/07 15:51
>>815
実装しないで何すんの?

841 :デフォルトの名無しさん:03/04/07 15:52
>>388
VB でも OO はできるが、とてもひずんだ設計になってしまう。


842 :デフォルトの名無しさん:03/04/07 15:53
じゃー VB でも多態性の実現はできるけど、C で OO やってるぐらいに
歪んでいる、というのでファイナルアンサー?

843 :デフォルトの名無しさん:03/04/07 15:54
C や VB で OO なんて、環境が整ったいまとなっては、わざわざやる意義はない。



844 :デフォルトの名無しさん:03/04/07 15:54
>>842
C よりはマシでファイナルアンサー。


845 :デフォルトの名無しさん:03/04/07 15:54
>>842
Cよりは歪んでないね。多態性が中途半端にできるのだから。

で、ファイナルアンサー。

846 :デフォルトの名無しさん:03/04/07 15:55
要するに、VBで多態をやりたきゃ VB.NET を使ってろってこった。
// 俺は使ったことないから実体はしらんが。

847 :デフォルトの名無しさん:03/04/07 15:56
>>846
その方が賢明。


848 :デフォルトの名無しさん:03/04/07 15:56
>>846
× 要するに、VBで多態をやりたきゃ
○ 要するに、VBで継承をやりたきゃ



849 :デフォルトの名無しさん:03/04/07 15:58
>>848
多態をやると、多くの場合どうしてもメソッドの引き上げがでてくる
(でないと「ただ一度」の原則が守れず、バグが散在する)から、訂正する
必要はないです。


850 :デフォルトの名無しさん:03/04/07 15:58
中途半端中途半端いっておきながら、
実際自分がVBで作ると多態性やっている罠。

851 :デフォルトの名無しさん:03/04/07 16:00
> 多態をやると、多くの場合どうしてもメソッドの引き上げがでてくる
ただ設計が悪いだけだろ(藁


852 :デフォルトの名無しさん:03/04/07 16:02
>>851
違うね。
同じ継承ツリーにあるってことは、どの子クラスにも共通した
処理って言うのがあるんだよ。多くの場合。やってみればわかるけど。
何の関係もないクラスを同じ親から継承しているんなら別だけど。


853 :デフォルトの名無しさん:03/04/07 16:03
>>851
VCL や Java SDK の継承ツリーを見てみろ。


854 :デフォルトの名無しさん:03/04/07 16:03
オブジェクト指向のやりやすさ
Java・C#・VB.NET > C++・Delphi > VB > C > アセンブラ

855 :デフォルトの名無しさん:03/04/07 16:04
>>854
そんな感じだろうね。


856 :デフォルトの名無しさん:03/04/07 16:06
どうせオブジェクト指向で継承使いまくるのって
GUIの部分ぐらいじゃん。
他は一段くらい継承して終わりでしょ。
GUIがコンポーネントとしてまとめられている場合、
継承なんかほとんど使わないよ。

857 :デフォルトの名無しさん:03/04/07 16:07
>>856
VCL や Java SDK のソースの GUI じゃない所を見てから家。


858 :デフォルトの名無しさん:03/04/07 16:08
>>857
へぇ〜。具体的にどこかなぁ〜。w

859 :デフォルトの名無しさん:03/04/07 16:09
>>856
1 段でも、同じ親から継承した子クラスで同じ処理が出てきたときは、
1 つのメソッドにまとめて親クラスに持っていくんだよ。
OO したことがない人が想像で言っているんだろうけど、
「どうせ」も何もない。
そんな場面は、たくさん出てくる。


860 :デフォルトの名無しさん:03/04/07 16:10
>>858
TBDEDataSet とか、よく読んでみろよ。


861 :デフォルトの名無しさん:03/04/07 16:11
http://yahooo.s2.x-beat.com/linkvp/linkvp.html

862 :デフォルトの名無しさん:03/04/07 16:14
↑死にさらせ

863 :デフォルトの名無しさん:03/04/07 16:16
>>858
Java やったら java.io のストリーム系、たとえば java.io.BufferedOutputStream あたり
おもしろいよ。


864 :デフォルトの名無しさん:03/04/07 16:16
>>856
え、コンテナクラスはGUIでない継承を使いまくった例だが、
お前は使ったこと無いんだろうな。

865 :デフォルトの名無しさん:03/04/07 16:20
>>856>>858
C++ なら std::iterator とその派生クラスとか楽しいよね。


866 :デフォルトの名無しさん:03/04/07 16:22
>>864
そうか、そういう人が多いからメソッドの引き上げなんてできなくてもいいなんて
変なことを堂々と言えちゃう人がいるわけだ。


867 :デフォルトの名無しさん:03/04/07 16:23
論破され無知を暴露する馬鹿な>>856でしたとさ。

868 :デフォルトの名無しさん:03/04/07 16:26
結局継承使って実装することってなさそうだな。
使用すべきところはライブラリの範囲ばかりだ。

869 :デフォルトの名無しさん:03/04/07 16:27
>>868
じゃあ、オリジナルの処理は OO で書かないんですね。


870 :デフォルトの名無しさん:03/04/07 16:28
>>869
まだうまく自前の処理を OO で書けないから、そういった例がライブラリだけの
ことだと思い込んでるのでは。


871 :デフォルトの名無しさん:03/04/07 16:28
やっと話が落ち着いてきたな。
俺的にはVBでも多態ができることが分かって勉強になったよ。

872 :デフォルトの名無しさん:03/04/07 16:29
>>868
君には必要ないよ。だってCOBOLerでしょ?

873 :デフォルトの名無しさん:03/04/07 16:29
>>870
でも実際ないしね。

874 :デフォルトの名無しさん:03/04/07 16:30
>>870
それか、ものすごく規模の小さいプログラムとか。たとえば、フォームに
部品を貼り付けて、イベント・ハンドラに数行書く程度の。


875 :デフォルトの名無しさん:03/04/07 16:31
>>873>>874
それなら、メソッドの引き上げもないね。


876 :デフォルトの名無しさん:03/04/07 16:32
>>873
設計のうちに入らんな。お勉強サンプルぐらいか。


877 :デフォルトの名無しさん:03/04/07 16:32
いや、OOはいるけど継承はいらないよ。

878 :デフォルトの名無しさん:03/04/07 16:33
Hello,Worldを書くためにはOOは必要ないな。

879 :デフォルトの名無しさん:03/04/07 16:34
VB や Delphi でメモ帳もどきを作るのにも OO も継承もいらないね。

880 :デフォルトの名無しさん:03/04/07 16:36
要らないケースしか知らないから、要らないと言い張ってるのか。

881 :デフォルトの名無しさん:03/04/07 16:36
>>871
そのおかげで、VBUnit なんかがかろうじて作れたりする。
けど、完全に OO してないから、コア部分は VC++ 製の DLL にして逃れているけどね。


882 :デフォルトの名無しさん:03/04/07 16:40
データベースから値ひっぱってきてHTML吐くだけでもいらないね。

883 :デフォルトの名無しさん:03/04/07 16:42
>>881
> コア部分は VC++ 製の DLL にして逃れているけどね
うそつけ。

884 :デフォルトの名無しさん:03/04/07 16:45
OO必要ないプログラムしか作ってない人が、OOなんて無意味っていうのって
電車で会社と家の往復だけの生活してる人が、高速道路なんて必要ないから無意味っていってるのと同じ感じですね。

885 :デフォルトの名無しさん:03/04/07 16:46
うんうん。地球で生活している人が宇宙船なんかいらないと言っているのと同じだ。

886 :デフォルトの名無しさん:03/04/07 16:54
vbUnitのコアはVBソースつきなんだけどなぁ。
Dependancy Walker使ったらちゃんとMSVBVM60.DLLリンクされてるし。

887 :デフォルトの名無しさん:03/04/07 16:57
>>883
嘘でした。


888 :デフォルトの名無しさん:03/04/07 16:58
うんうん。家に包丁がない人が砥石なんていらないと言っているのと同じだ。


889 :デフォルトの名無しさん:03/04/07 16:58
うんうん、手が使えない人がペンなんて不要だと言っているのと同じだ。


890 :デフォルトの名無しさん:03/04/07 17:00
結局実生活じゃいらないんじゃん。

891 :デフォルトの名無しさん:03/04/07 17:00
うんうん。頭が使えない人が理論なんて不要だと言っているのと同じだ。



892 :デフォルトの名無しさん:03/04/07 17:01
うんうん、OO で設計しない人が OO なんていらないといってるのと同じだ。


893 :デフォルトの名無しさん:03/04/07 17:02
でもOO設計できる人がいらないって言ってんだから間違いないだろうね。

894 :デフォルトの名無しさん:03/04/07 17:03
>>893
s/OO設計できる人/OO設計できると思っている人/

895 :デフォルトの名無しさん:03/04/07 17:05
>>893 は、同じ処理があっちこっちにあって、バグもあっちこっちにあって、
汚いプログラムを書いているか、>>874 のようなのしか作ったことないか、
だろう。


896 :デフォルトの名無しさん:03/04/07 17:06
OOいるって言っている人がOO設計できると思い込んでるんだからたち悪いね。

897 :デフォルトの名無しさん:03/04/07 17:06
まあいらないと思う人は使わなければいいだけでしょ。俺は必要だから
使う。それだけ。

898 :デフォルトの名無しさん:03/04/07 17:08
うんうん。OO で設計できると思い込んでいる人が、OO がいらないと言っているのと同じだ。


899 :デフォルトの名無しさん:03/04/07 17:11
うんうん。OO で設計できると思い込んでいる人が、OO がいると言っているのと同じだ。

900 :デフォルトの名無しさん:03/04/07 17:11
.

901 :デフォルトの名無しさん:03/04/07 17:12
なんも無いんかい…

902 :デフォルトの名無しさん:03/04/07 17:13
うんうん。OO のライブラリしか見たことがない人が、OO の設計はライブラリだけのものだと言っているのと同じだ。


903 :デフォルトの名無しさん:03/04/07 17:13
うんうん。OO のライブラリ _すら_ 見たことがない人が、OO の設計はライブラリだけのものだと言っているのと同じだ。

904 :デフォルトの名無しさん:03/04/07 17:14
でも真実はOO使いこなしている人がOOいらないといってるんだから間違いないでしょ。

905 :デフォルトの名無しさん:03/04/07 17:17
でも真実はOO使いこなしていると思い込んでいる人がOOのライブラリをのぞいたこともないといってるんだから間違いないでしょ。


906 :デフォルトの名無しさん:03/04/07 17:17
OO使いこなしてる人って誰さ

907 :デフォルトの名無しさん:03/04/07 17:18
まっそういうデマを信じちゃう奴には何をいってもダメなわけで。

908 :デフォルトの名無しさん:03/04/07 17:18
>>904
メソッドの引き上げって、C マガとかの初心者向けの記事にも出てくるよな。
επιστημηさんよりすごいのかい。君は。


909 :デフォルトの名無しさん:03/04/07 17:19
>>906
OOいるって言っている人にとって都合のいい架空の人物。

910 :デフォルトの名無しさん:03/04/07 17:20
>>908
その通り。

911 :デフォルトの名無しさん:03/04/07 17:21
>>904
そこまでいうなら、
http://www.freeml.com/ctrl/html/MLInfoForm/cppll@freeml.com
で、επιστημη氏はじめたくさんのエンジニアの前で論破してみろ。
cppll ML で待っている。


912 :デフォルトの名無しさん:03/04/07 17:22
>>911
匿名じゃなくなるので却下。

913 :デフォルトの名無しさん:03/04/07 17:23
>>912
Hotmail でもいいんだよ。匿名メールの制限は設けられていないから。


914 :デフォルトの名無しさん:03/04/07 17:23
結局>>868のような奴が一番OOの恩恵を受けてるわけですね。


915 :デフォルトの名無しさん:03/04/07 17:25
>>914
そういうやつのための OO でもあるからね。
知らないうちに OO を使っている。そのうち自分でも OO の設計ができるようになる。
向上心があれば。

916 :デフォルトの名無しさん:03/04/07 17:29
うんうん〜系の1行レスには反論する価値さえないわけだが。
まあリファクタリングもしない奴には継承の有用性もわからんのだろう。

917 :デフォルトの名無しさん:03/04/07 17:32
継承が有用と思えない奴はリファクタリングしても継承しないと思いますが何か?

918 :デフォルトの名無しさん:03/04/07 17:35
>>917
思えないんだったらもう仕方ないね。


919 :デフォルトの名無しさん:03/04/07 17:36
>>917
きみの OO 技術がいかに優れているのか、匿名メールでもいいから cppll ML で
紹介して、人類文化の発展に寄与してくれたまへ。

920 :デフォルトの名無しさん:03/04/07 17:41
うんうん系 うんうん系 継承は
うんうん系 うんうん系 いらないよ
そんな 運動


921 :デフォルトの名無しさん:03/04/07 17:42
続きが思いつかなかった……


922 :デフォルトの名無しさん:03/04/07 17:45
じゃあ取りあえず、OOでOS作ってくれ。
OOでないOSならばいくつかあるんで、OSを作れたらOOは素晴らしいと認めよう。

923 :デフォルトの名無しさん:03/04/07 17:47
OO のライブラリを見たこともない人が OO で作ったものの評価ができるわけがない。


924 :デフォルトの名無しさん:03/04/07 17:47
姉さん、OO で設計できない人が OO で作ったものの評価ができるわけもなく……

925 :デフォルトの名無しさん:03/04/07 17:51
あれあれ、OSという複雑なものこそOOで作る価値が無いかい?
OSが出来ないならコンパイラでもいいよ。

926 :デフォルトの名無しさん:03/04/07 17:54
>>922
もうある。評価しろ。
http://www.csl.sony.co.jp/project/Apertos/



927 :デフォルトの名無しさん:03/04/07 17:54
BeOSとかいってみよう。
少なくともWindowsでさえもOOしていると思うんだけどな
(程度の問題はおいといて)

928 :デフォルトの名無しさん:03/04/07 18:02
OO もわからないしライブラリの継承ツリーも調べたことがないやつに、
分散オブジェクトとか言っても「はあ?ぼくちゃんわからない」でせう。


929 :デフォルトの名無しさん:03/04/07 18:09
>>926
ソースがねーぞ。論文だけじゃねーか。言語は何で作ったんだ?
>>927
BeOSって「コンパイル時に存在しないクラス」を使えるようになったんだっけ?
> 少なくともWindowsでさえもOOしていると思うんだけどな
MFCがOOしていると主張するなら、まぁOOしてますね。

930 :デフォルトの名無しさん:03/04/07 18:15
>>929
http://www.ipsj.or.jp/members/Magazine/Jpn/3608/article014.html
の論文からたどれる。


931 :デフォルトの名無しさん:03/04/07 18:16
>>920
うんうん系は、なくてもいいけどあったらいいこともあるよ、っていってるん
ですが

932 :デフォルトの名無しさん:03/04/07 18:31
>>930
本文のリンクをクリックするとユーザ名とパスワードを求められるんですが、
やっぱり会員登録しなくちゃ駄目ですか?

933 :デフォルトの名無しさん:03/04/07 19:47
浅海さんがゆうてるように継承はOOの主要な
要素ではない。

934 :デフォルトの名無しさん:03/04/07 20:04
>>933
なんだ、人の受け売りか。


935 :デフォルトの名無しさん:03/04/07 20:26
>>934
おまえこそ、お前の持ってる99.99%の知識は人の受け売りだろう?
それを馬鹿にしてもしょうがないぞ?

936 :デフォルトの名無しさん:03/04/07 20:27
別に主要な要素かどうかを問題にしているわけではないでしょ。
ここまでの流れでは、必要と思う人には必要という結論がすでに。
いらないよねーといってる人は、本当にいらないか、意味がなにも
わかってないか、どっちかなんでしょう。

937 :デフォルトの名無しさん:03/04/07 20:39
OOは、手続き型、データ&構造中心の設計を許容する。
オブジェクト内でどんなコードが動いてようと、オブジェクトの
切り分けとメッセージのやりとりさえ決まっていれば、それで十分だろ?


938 :デフォルトの名無しさん:03/04/07 21:36
許容したら糞コードといいますよ。

939 :デフォルトの名無しさん:03/04/07 22:32
>>929
>コンパイル時に存在しないクラスを使えるようになったんだっけ
ってなんだ?
コンパイル時に存在しないクラス?使えるに決まってるじゃんか。
おまえ、非OOでも、プログラム書けない...書いたこと無いだろ。

940 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/07 23:26
正しいプログラムはオブジェクトを手続きの中に封じ込めたもの。
分散オブジェクトは失敗したでしょうが。

941 :デフォルトの名無しさん:03/04/07 23:28
>>940
RPCは成功したの?

942 :デフォルトの名無しさん:03/04/07 23:55
>>941
RPCってリモートオブジェクト?

943 :デフォルトの名無しさん:03/04/07 23:56
DCOMやらRMIやらは、とりあえず一定の成果をあげたといえる。

944 :デフォルトの名無しさん:03/04/07 23:56
>>940
ハァ?EJBは分散オブジェクトそのまんまですが。

945 :デフォルトの名無しさん:03/04/08 00:12
分散システムが協調処理行うときに、分散オブジェクト以外に何が有力というのだろうか。。。

946 :デフォルトの名無しさん:03/04/08 00:25
俺もマジでわからん、オブジェクト指向ってやつが。
かろうじてDelphiで実体験したのが"継承"。
その他にどういった要素が揃えばオブジェクト指向プログラミング足り得るのだろうか。

10数年前、勉強会に参加したCobolerの中には、いまだに
"オブジェクト指向=細かいルーチン化"と思ってるオッサンもいるぞ。

本当に頭のいいヤツは、バカでもわかる比喩をこなせる筈、
>>22がいい線行ってると思ったが、実際どうなんだよ。
どういう概念でもってソースを組めば、誰にも恥じる事のないオブジェクト指向による組み方になるのだろう。



947 :デフォルトの名無しさん:03/04/08 00:34
>>946
>>210付近を読め

948 :デフォルトの名無しさん:03/04/08 00:38
>>946
>その他にどういった要素が揃えばオブジェクト指向プログラミング足り得るのだろうか。

ということを厳密にやろうとすると、上で繰り広げられてることが起きるので、漏れはパス。
どういった要素が揃えばJazz足り得るのだろうか、という問いに似て、厳密には難しい。

結局はJazzを勉強したミュージシャンが演奏すればそれはJazzになる、
ということが言えるとすれば
オブジェクト指向を勉強したプログラマが組めばそれはオブジェクト指向プログラムになる
といえるかもしれない。

949 :sage:03/04/08 00:41
今までのやり方の延長で試してみても、上っ面だけになりがち。
一度頭を空白にして、「今まで君が読み飛ばしてきた」数多くの
オブジェクト指向に関する文献を、読み直してみるといいよ。

キーボードのないところで、出来ればコーヒーでも飲みながら、
まったりと。


950 :デフォルトの名無しさん:03/04/08 00:41
やりなおし。

Jazzを勉強したミュージシャンがその技術を生かして演奏すれば
それはJazzになる、ということが言えるとすれば
オブジェクト指向を勉強したプログラマがその技術を生かして組めば
それはオブジェクト指向プログラムになるといえるかもしれない。

951 :946:03/04/08 00:58
なるほど。弁当屋の例えはわかりやすかったです。
Fuckable から読む気無くしました。根気ないですね、おれ。
ちなみにDelphiでやってた"継承"というのは、
画面フォームの提示様式とボタンの機能を統一するため、
最小限の基本機能(画面の見た目、パネル分け、PFキー、確認ボタン類)をクラス定義して、
各アプリはそのクラスを利用して造り込んでいく、というものです。

この時問題になったのは、クラス内部の(結果的に)冗長的な一機能が、派生先の仕様によっては足枷になる場合が開発末期に生じたという事です。
また関数一つとっても、各プログラマが"俺の部品こそ効率的"と、みんな互いに譲らず独自に別個の関数をダラダラ書きやがったという問題もありました。
(俺も書きやがった一人ですが) …まあ、その程度の経験しかないす。

オブジェクト指向って、決して同一ではないが似たような手続きを複数箇所にダラダラ書くのはダサイから、
一つにまとめて能率よく処理できるよう工夫を凝らそうといったものになるんでしょうか。
ある種ゲージツ的センスで意見が分かれそうで集団開発にどこまで向いているのかちと疑問にも思ったりします。
ちゅーか、それこそ"指向"に左右されるのだなぁなんてね。




952 :デフォルトの名無しさん:03/04/08 01:10
>>951
そういう観点で言うなら、いかにプログラムを分割して
関連のあるものを近いところに、関連のないものを遠くにおくか、とか
まとめて変更する可能性のあるものをいかにまとめるか、とか。

だから、集団開発、という点でいえば、おおきなプログラムを
集団で作るときに、ある機能を担当している人が作るプログラムが
他の機能を担当している人のプログラムの影響を受けない・影響を与えない
ようにという方向で設計ができる、という点でオブジェクト指向が良い。

953 :952:03/04/08 01:17
コードが似ている・似ていないが判断基準になるのではなく
概念的に似ている・似ていないが判断基準になる。
結果的には、コードが似ている・似ていないでまとめることになる場合が多い
のだけど、それは結果論。

ある時点でコードが似ているからという理由でまとめると、あとで泣く。

954 :デフォルトの名無しさん:03/04/08 01:19
「OOは必要か」という質問には答えがない。
答えがない質問は、質問自身が間違っているからである。
正しい質問は「OOは便利か」である。便利である。
OOの最大の利点は「差し替え可能」であることと言っても過言ではない。
同じインターフェースあるいは同じ起源をもつオブジェクトは
差し替え可能であり、LEGOのように組換え可能である。
スライムをマンドリルに差し替えたところで、
剣と魔法のインターフェースを備えていれば、同様に扱うことが出来る。
IF文やSWITCH文で振り分ける必要がない。
便利である。

それにしてもこのスレは良く伸びている。良いことである。

955 :デフォルトの名無しさん:03/04/08 01:23
>>954
なんとなくあんた良いこといった!

956 :952:03/04/08 01:30
>>951
> 足枷になる場合が開発末期に生じたという事です。

という部分だけど、開発ライフサイクルを考えると、開発末期には
開発をコントロールすることが難しくなるのは、どのような技術を
使っても起こり得る。
いまのところオブジェクト指向を取り入れた開発が、その飛距離が長い。

957 :デフォルトの名無しさん:03/04/08 01:52
OOを採用したプロジェクトがなかなか成功しない
と言われる原因は何ですか?


958 :デフォルトの名無しさん:03/04/08 01:59
>>957
全体的にプロジェクト自体の規模が大きくなり、予算・納期は縮小する傾向が
あるので、プロジェクトが成功しにくくなっているというのがある。
だから、OOを採用してなければ成功していたかというと、難しい。

また、新技術にはやはりリスクがあるので、OOを採用したからといって
最初からその利点の恩恵にあずかれるものでもない。

ただ言えるのは、最近の開発で成功しているプロジェクトは
OOを採用している割合が高くなっている。

959 :デフォルトの名無しさん:03/04/08 02:01
現実社会だってインターフェースに満ち溢れているわけで、
それはつまりそれが人間にとって楽なわけだよね。携帯電話の
中の実装知らないと電話できないんじゃ、話にならんよね。
各社ごとにキーボードが違ったら、つらいよね。
だから、プログラムだってインターフェース指向の方が楽なはず。
OOってオブジェクトのコラボレーション云々ってよく言われるけど、
そんなことよりインターフェースをどう切るか、ってところの方が
重要だと俺は思う。また、インターフェースによる切り分けと差し替え
が出来るところが、OOの良さっていうか楽な所だと思う。どうかな?

960 :デフォルトの名無しさん:03/04/08 02:08
インターフェースだけなら、オブジェクト指向使う必要ないじゃん。
インターフェースと継承ぐらいあればいいんじゃないの?
オブジェクトなんて出てくる必要ない。

961 :デフォルトの名無しさん:03/04/08 02:14
オブジェクト指向が特に便利というわけじゃなく、
その周辺に用意されたものが、たまたまニーズに
合ってるだけかもしれない。
オブジェクト指向は「狼の皮を被った羊」なんじゃないのか、と。

962 :デフォルトの名無しさん:03/04/08 02:17
>>961
オブジェクト指向は、羊に狼の皮を提供する。

963 :デフォルトの名無しさん:03/04/08 02:18
>>962
文盲は黙ってろ。

964 :デフォルトの名無しさん:03/04/08 02:20
>>963
じゃあ、おまえが黙ってろ。

965 :デフォルトの名無しさん:03/04/08 02:23
何か言い返さないと気がすまないのですね、そんな性格じゃ損するだけだよ

966 :デフォルトの名無しさん:03/04/08 02:24
>>963
突拍子なく来るな

967 :デフォルトの名無しさん:03/04/08 02:28
>>961
なるほど。
多態や継承とかは、別にオブジェクト指向でなくてもできるよな。
純なオブジェクト指向つーと、メッセージ受け渡し程度だから、
まあ無くてもいいわな。

968 :962:03/04/08 02:32
へんなちゃちゃが入ってるようだけど、オブジェクト指向のおかげで
プログラムをあまり勉強しなくても、ある程度部品を組み合わせれば
ある程度のものができるようになっている。

あと、>>961の言うような「周辺に用意されたもの」の多くは
オブジェクト指向を核に研究開発されている。
それは情報処理学会誌なんかを読んだ感想。

969 :デフォルトの名無しさん:03/04/08 02:35
おまえら「オブジェクト指向」に騙されてるぞ。
「オブジェクト指向」と一括りにされて、うやむやにされた技術は、
実はほとんどが「オブジェクト指向」とは全く関係ないものばかりだ。
俺達は「オブジェクト指向」という言葉に踊らされているのさ。


970 :デフォルトの名無しさん:03/04/08 02:37
>>968
>オブジェクト指向のおかげで
オブジェクト指向のおかげじゃない。
オブジェクト指向の周辺技術のおかげだ。


971 :デフォルトの名無しさん:03/04/08 02:38
言われてみるとそんな気もするな。

972 :デフォルトの名無しさん:03/04/08 02:40
>>968
>部品を組み合わせればある程度のものができる
これはオブジェクト指向とは何の関係も無いな。

973 :962:03/04/08 02:47
>>970
そのオブジェクト指向の周辺技術はオブジェクト指向のおかげではない?

974 :デフォルトの名無しさん:03/04/08 02:50
>>969
なんかこれ、真理を突いてるっぽい。
初心者がプログラムするときなんか、メッセージなんて概念は
頭に出てこないだろうし。最近の言語の傾向見てると、
純粋な「オブジェクト指向」という意味自体も消えかかってる。

975 :959:03/04/08 02:51
>>960
確かに、インターフェースと継承があるだけでよいかも。
メッセージングの重要性、ってのをあんまり感じたことないし。
それよかインターフェース合わせるとか、多態で楽するとかの方が重要だ。
>>967のニーズにあっているというのは、なんとなく理解できる。

>>969
となると、純なオブジェクト指向=メッセージング程度という>>967の意見と、
オブジェクト指向の周辺技術がニーズにあっているという感覚からすると、
少なくとも俺はオブジェクト指向の派生物を便利便利と言っているわけで、
そうなると俺は何指向だ?オブジェクトデリバティブ指向とかか?


976 :デフォルトの名無しさん:03/04/08 02:54
庶民はとくに指向でなくてよい。

977 :デフォルトの名無しさん:03/04/08 02:59
>>973
それは老人の戯言と同じ。
使う側からすれば知る価値はない。

978 :959:03/04/08 02:59
>>976
まあ、確かにそうかもしれん。
でもやっぱりプログラムするときはいつもインターフェース
意識するから、しいて言うなら俺はインターフェース指向かな。
オブジェクト指向ではないことは、>>961の発言で確定したし。

979 :デフォルトの名無しさん:03/04/08 03:05
まあ、最近の「オブジェクト指向」という言葉の使われ方は、
あいまいな表現の部類に入るな。
「オブジェクト指向」だけでは密な会話が成立する事なんて少ないし。

980 :デフォルトの名無しさん:03/04/08 03:06
>>977
ふーん。じゃあいいや。

そうやってオブジェクト指向をもとにした周辺技術だからこそ
核となるオブジェクト指向を知る必要がないものになるわけだけど。
そして>>968に続くわけだ。

981 :デフォルトの名無しさん:03/04/08 03:15
>>980
その研究者達も「オブジェクト指向」という言葉の語呂がいいから使うだけで、
純な意味のオブジェクト指向原理主義な人なんていないと思うよ。
いたとしても、自分のやってることが良くわかってない盲信者だろうね。

982 :959:03/04/08 03:19
>>979
学術用途で抽象度の高かったオブジェクト指向が、実装レベルが
近くなるにつれ実用上有用な技術がどんどん引っ付いてしまい、
学者が言うオブジェクト指向と実装者が思うオブジェクト指向が
乖離している。学者は核が、実装者は周辺技術がテリトリーであるため、
一向にオブジェクト指向の利点、特徴が一意に語られないため、
「オブジェクト指向」という言葉があいまいで、踊らされている。
こんなところかな?となるとさ、周辺技術をカテゴライズして
やれば、見通しよくなりそうだよね。

983 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/08 03:28
メソッド呼び出しもメッセージだなどと言ってる人が居ますが全然違います。
あれは制御。
呼んだら戻さなきゃいけないところがメッセージと根本的に違う。
メッセージ送って自分は消滅とか出来ないんでジャヴァで往生した。

984 :デフォルトの名無しさん:03/04/08 03:28
>>982
そんなとこだと思う。
オブジェクト指向だけが全面に出てくる今の状況はおかしい。
理系の考え方じゃない。

985 :980:03/04/08 03:30
>>981
まぁ、研究分野でも、オブジェクト指向は当たり前の技術みたいな感じになっている
ようなので、専門に研究してる人は少ないかも。
ソフトウェアシンポジウムのレジュメなんかでも97年あたりからオブジェクト指向
のセッションが少なくなってる。
そのあとの流行は「プロセス」だったけど、最近はどうなんだろう。。。

986 :デフォルトの名無しさん:03/04/08 03:30
逝って良しが来たのでそろそろ退散するとしよう。

987 :デフォルトの名無しさん:03/04/08 03:35
>>984
エンジニアリングは理系じゃないからね。


988 :デフォルトの名無しさん:03/04/08 03:36
>>984
同意。
オブジェクト指向の本はあんなに分厚い必要はない。
なんつーか、うまく分離できないものかね。

989 :959:03/04/08 03:41
>>985
Java界だと、「フレームワーク」とかになるのかな?
フレームワークって、やっぱりインターフェース指向だよ。

>>987
深いね。

990 :980:03/04/08 03:45
>>989
そういえば、オブジェクト指向の次にはパターンが流行った。

991 :デフォルトの名無しさん:03/04/08 03:47
>>951
> また関数一つとっても、各プログラマが"俺の部品こそ効率的"と、みんな互いに譲らず

ちゃんと測定して裏を取ればよかったんだよ。


992 :980:03/04/08 03:53
核という言葉はまずかったな。前提、だな。

993 :デフォルトの名無しさん:03/04/08 03:57
>>983
Smalltalk-80も本質的にはサブルーチン・コールに過ぎないわけで、
これもオブジェクト指向のベースモデルのアクター理論が実装で
歪められた例の一つですね。

994 :デフォルトの名無しさん:03/04/08 03:58
なんかスレの最後でまともっぽい話になったな。

995 :959:03/04/08 04:07
>>993
実装で歪められた、って所はおもしろいね。
htmlのタグも実用ではだいぶ歪んだ使われ方がされていて、
あまつさえそれがテクニックとして世に出回ったり
しているから、OOにもこうゆう要素が少なからずあるということ
だよね?

996 :デフォルトの名無しさん:03/04/08 04:08
   /⌒\
  (    )
  |   |
  |   |
  ( ・∀・)   1000ハ
   )   ノ
  (_⌒ヽ
    )ノ `J

   /⌒\
  (    )
  |   |
  |   |
  ( ・∀・)   ワタサナイヨ
   )   ノつ
  / __  /
∠ '´ )ノ

997 :デフォルトの名無しさん:03/04/08 04:09
    ∧_∧    ∧_∧
    ( __ __)   ( __ __)
   (6 ・ 」・).  (6 ・ 」・)  ボクタチダッテ
    (  ∀)   (  ∀)
   /    \ /    \
  ⊂ )   ノ\つ )  ノ\つ
    (_⌒ヽ  (_⌒ヽ
     ヽ ヘ }   ヽ ヘ }
      ノノ `J   ノノ `J

     ∧_∧     ∧_∧
     ( __ __)   ( __ __)
    (6 ・ 」・).   (6 ・ 」・)  マケナイヨ
     (  ∀)    (  ∀)
    /    \  /    \
   ⊂ )   ノ\つ )   ノ\つ
    / __ <   / __ <
  /  '´ ヽ ) /  '´ ヽ )
∠/    ノノ∠/    ノノ

998 :デフォルトの名無しさん:03/04/08 04:09
    ∧_∧    ∧_∧
    ( __ __)   ( __ __)     /⌒\
   (6 ・ 」・).  (6 ・ 」・)    (    )
    (  ∀)   (  ∀)    |   |
   /    \ /    \   |   |
  ⊂  )   ノ\つ )  ノ\つ  ( ・∀・)
    (_⌒ヽ  (_⌒ヽ     )   ノ  ( ・∀・)  ショウブノ
     ヽ ヘ }   ヽ ヘ }   (_⌒ヽ   (_⌒ヽ
      ノノ `J   ノノ `J     )ノ `J    )ノ `J

     ∧_∧     ∧_∧
     ( __ __)   ( __ __)    /⌒\
    (6 ・ 」・).   (6 ・ 」・)   (    )
     (  ∀)    (  ∀)    |   |
    /    \  /    \   |   |
  ⊂  )   ノ\つ )   ノ\つ ( ・∀・)
    / __ <   / __ <      )   ノつ ( ・∀・)  ハジマリダネ
  /  '´ ヽ ) /  '´ ヽ )   / __  /  / __  /
∠/    ノノ∠/    ノノ  ∠ '´ )ノ ∠ '´ )ノ

999 :999:03/04/08 04:10
999

1000 :デフォルトの名無しさん:03/04/08 04:11
ははは

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

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

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)