トップページ⇒tech
1001コメント369KB

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

レス数が1000を超えています。これ以上書き込みはできません。
0001Java太郎NGNG
理解してるんだったら、教えやがれ！！
0002デフォルトの名無しさんNGNG
勉強しろよ
低脳
0003デフォルトの名無しさんNGNG
お尻の穴が少し広がった
00043NGNG
誤爆ｽﾏｿ
0005デフォルトの名無しさんNGNG
そろそろコタツのしまいどきですね
0006デフォルトの名無しさんNGNG
T>>1=class(T2chaneller)
public
property Hikikomori defaut True;
procedure CreateKusoThread;
procedure Jisakujien;
end;
0007デフォルトの名無しさんNGNG
つくしの子が恥ずかしげに顔を出す頃なんだなぁ
0008デフォルトの名無しさんNGNG
VB太郎の間違いじゃないの？
0009デフォルトの名無しさんNGNG
キャベツ太郎
0010デフォルトの名無しさんNGNG
>>3
どの板の誤爆か大体予想つくｗ
0011デフォルトの名無しさんNGNG
>>1
Javaができるなら自分でクラス作りながら勉強しろ
コンパイルエラーがお前にオブジェクト指向を教えてくれるぞ
0012Java太郎NGNG
オレはコンパイルエラーが大嫌いだ！！
オレが間違っているのではない！マシンが悪いのだ！！！
0013デフォルトの名無しさんNGNG
なんかの罰ゲームですか？
0014デフォルトの名無しさんNGNG
>>11
クラス!=オブジェクト指向
いくらクラスを作ってもオブジェクト指向は理解できない
0015デフォルトの名無しさんNGNG
　　　　　　　　　　　　　　　　　　　　　　　　　　'i､
　　　　　　　　　　　　　　　　　　　　　　　　　　 ﾞl、
　　　　　　　　　　　　　　　　　　　.-,,,　　　　　　.′　　　　　 _
　　　　　　　　　　　　　　　　　　　　　ﾞﾞ''　　.,r･'''''''''┐　　 ﾞﾞﾞ″
　　　　　　　　　　　　　　　　　　　　　　　 .,i´ﾟ ∀ ﾟ .ﾞl コンパイルエラー
　　　　　　　　　　　　　　　　　　　　　　　 .ﾋ　　　　 ,ｨ°
　　　　　　　　　　　　　　　　　　　　　　　　　.ﾟ!,,,　ﾞ,i´　　　　｀ﾟ'-、
　　　　　　　　　　　　　　　　　　　　　　　　　.°　　　　　　　 .｀
　　　　　　　　　　　　　　　　　　 .,ノ　　　　　　　　 ﾞi､
　　　　　　　　　　　　　　　　　　 ′　　　　　　　　　.°
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 .／¨ﾞﾞヽ コンパイキタイー
　　　　　　　　　　　　　　　　 .,-‐''''''r,コンパイラー 　　　　 l　 ﾟ∀ﾟ ヽ、
　　　　　　　　　　　　　　　 .,i´ﾟ∀ﾟ　　ﾄ　　　　　　　　　　　 .|　 .,,,,　　.ﾞ'ｰ､,
　　　　　　　　　　　　　　　 .ﾞl　 .,,,,,｀　ﾞl　　　　　　　　　　 .｣° .:ﾞﾞ°　　　 ｀'‐，
　　　　　　　　　　　　　　　　,｝　ﾞﾞﾞﾞ　　.ヽ　　　　　　　　　 |′　　　　　 .|ヽ,　　ﾞ'-、
　　　　　　　　　　.＿,,,,,,.--'″　　　　　,.:'r,　　　　　　　　 .|　,,,　　　　　 |　.ﾞﾞ''ｰ-,,,'i､
　　　　　　　　　　”'''-､＿_　　　　　　　　.,.ﾟ'Ｌ　　　　　　　'･'゛.|　　　　　.|　　　　　″
　　　　　　　　　　　　　　 ￣￣!　　　　 .:'ｉ＼,＼　　　　　　　 .|　　　　　 ﾞl
　　　　　　　　　　　　　　　　　|　　　　　　ﾞ'l,`i､ `i､　　　　　　.｝　 .〟　　 |、
　　　　　　　　　　　　　　　　 ..}　　　　　　 .〔　.ﾞ'-,＼　　　　 .,lﾞ　.,i´ﾞl，　　|
　　　　　　　　　　　　　　　　 .|　　　 j㍉　　ﾞ|　　 .ﾞ''7　　　　.lﾞ ,／　 :ﾟi､　.lﾞ
　　　　　　　　　　　　　　　　 .|　　　 |　ﾞ'i､　.ﾞl　　　　　　　　l／　　　　ヽ.lﾞ
　　　　　　　　　　　　　　　 .,r"　　 ,i´　　ﾞ'-,｣　　　　　　　　°　　　　　.”
　　　　　　　　　　　　　　　 ―---┘
0016デフォルトの名無しさんNGNG
>>15
激しく同意
0017Java太郎NGNG
オブジェクト＝インスタンスってのがわからねぇぜ！！
0018デフォルトの名無しさんNGNG
>>12
そんなこといってる奴には、
いつまでたっても、オブジェクト指向どころか
プログラミングを極めることができない。
0019デフォルトの名無しさんNGNG
>>18
極める？バカじゃないの？
そんなことできるはず無いじゃん
居るんだよね～少しプログラミングできるからって、「極めた」って言う奴が。
そういう発言は慎め！
002019NGNG
>>18
お前のせいで名前を入れ忘れたじゃねぇか！！
チｯ・・・お前が居ると調子狂うぜ、まったくよｗ
0021デフォルトの名無しさんNGNG
>>19-20
いいからよく本を読んで勉強しろ
がんがれ
0022デフォルトの名無しさんNGNG
スライムから、バブルスライムやメタルスライムを派生させる。
これで継承は完璧。

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

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

できあがったら、ＲＰＧコンテストで賞金をもらえ。
0023Java太郎NGNG
>>21
お前、いい奴だな・・・
オレの一番の下僕にしてやるぞ♪
0024Java太郎NGNG
>>22
継承の例えは誉めてやる
メッセージパッシングはまぁまぁだな
シリアライゼーションなんて知らねぇよ！！
オレが知らないって事は、存在しないんだよ！！
このウソツキめ！！
0025デフォルトの名無しさんNGNG
>>22
さらにいうならデータの保存はMementoパターンだろ
0026デフォルトの名無しさんNGNG
個人スレたてんなボケ
0027デフォルトの名無しさんNGNG
>>24
java.io.Serializableを調べよ
0028Java太郎NGNG
>>25
そ、そうだ！！それだ・・・
（なんだよそれ・・・((((；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ）
0029Java太郎NGNG
>>27
はい！先輩！！
0030デフォルトの名無しさん NGNG
個人スレたてんなボケ
0031Java太郎 ◆adhRKFl5jU NGNG
ごめんなさいもうしません削除依頼出してきます
このスレは終了しますた。
-----------------------------------------------
冬
0032デフォルトの名無しさんNGNG
昨日のperl馬鹿か？
0033Java太郎NGNG
>>31
偽者ｷﾀ━━━━━━＼(T▽T)／━━━━━━ !!!!!
それだけ、オレが人気者って証拠だな♪
0034Katjusha extenderNGNG
倉庫に落ちました。。。
0035デフォルトの名無しさんNGNG


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


0036Java太郎 ◆DMVtSSFzcg NGNG
甚だ不本意だが、トリップつけてやるぜ！！
人気を奪われちゃー金を手に入れれねぇからな！！
0037デフォルトの名無しさんNGNG
極論、オブジェクト指向っていうのは、特別な理論じゃなくて、開発しやすいからごく自然に使われてるってだけ。普通にプログラミングすればオブジェクト指向にたどりつくと思うんだよね。
0038デフォルトの名無しさんNGNG
はぁ？

　　　　　　　　　　,,―‐．　　　　　　　　　　　　　　　　　 r-、　　　　＿,--,、
　　　　　,―-、　.| ./''i､│　　r-,,,,,,,,,,,,,,,,,,,,,,,,―ｰ．　　　 ﾞl, ｀"ﾞﾞﾞﾞﾞ￣＾　　　＼
　　　 ／　　　＼ ヽ,ﾞ'ﾞ_,/　　 .ﾞl、　　　　　　　　　`i､　　　＼ _,,―ｰ'''/　　.,ｒ'"　　　　　
.,,,、.,,i´　.,/＾'i､　｀'i､｀｀　　　　 ｀--‐'''''''''''''''"'''''''''''ﾞ　　　　 ｀゛　　 .丿　 .,　　　　　　　
｛ ""　 ,/｀　　ヽ、 ｀'i､　　　　　　　　　　　　　　　　　　　　　　　 丿　 .,/｀ 　　　　
.ヽ、　丿　　　　＼　 .＼　　　　　　　　　　　　　　　　　　　　　 ,/′ 、ヽ,,、 　　　　　
　 ﾞ'ｰ'"　　　　　　ﾞ'i､　 ‘i､.r-、　　　　　 ＿_,,,,,,,,--、　　　　 ／　.,／＼　`'-,、 　　
　　　　　　　　　　　ヽ　　.]ﾞl ｀ﾞﾞﾞﾞ"ﾞﾞﾞﾞ￣￣　　　　　｀'i､　　,／ .,,／　　 .ヽ　　＼
　　　　　　　　　　　　ﾞヽ_/ .ヽ_.,,,,--―――――ｰ-ノ_,／ﾞ,,／′　　　　 ﾞl　　 ,"
　　　　　　　　　　　　　　　　 ｀　　　　　　　　　　　　 ﾞ‐''"｀　　　　　　　　ﾞ'ｰ'"
0039Java太郎 ◆DMVtSSFzcg NGNG
>>37
そういう事なのか！？！？
あとほんの少しだけ、勉強してやる。
兄貴！待ってろよ
0040Java太郎 ◆dcpChnLpNk NGNG
>>36>>39
かってに騙るなボケ。トリップまでつけて厚かましいんだよ、もう来るな。
0041デフォルトの名無しさんNGNG
// 手続き型
function("hoge");
// オブジェクト指向
class instance i = new class();
i.method("hoge");

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

//おまえに馴染の深いサンプルでも読んで
//オブジェクト指向を理解しろ。
Humen javaTaro = new Humen(parents);
if (javaTaro.madeThreadLikeExcrement()) {
 i.say("逝って良し".javaTaro);
}
0042デフォルトの名無しさんNGNG
>>28
GoFデザインパターンの一種
オブジェクトの状態を一時的に保存するデザインパターン
保存するときに、Serializableを使ってファイルに保存してしまえばさらに便利。
初心者に優しい結城浩のデザインパターン本でも読むことをお勧めする。

オブジェクト指向を使いこなすならデザインパターンも知らなくては。
0043Java太郎 ◆DMVtSSFzcg NGNG
はぁ・・・なんだか色々難しいぜ！！（ウソ）
しょうがない、殺るか！
0044Java太郎 ◆DMVtSSFzcg NGNG
>>42
Java言語プログラミングレッスンの下を読みはじめたよ
ふぅ・・・だるくてやる気が出ないのが本音（ウソ）
0045デフォルトの名無しさんNGNG
ある男がらくだと共に砂漠を旅していました。
しかし思った以上に長く続く砂漠に、若い男の性欲は耐える事が出来ませんでした。
そこで男は思い付きました。
「そうだ！らくだとやろう！」
男はらくだの後ろへまわると早速自分のものを入れようとしました。
しかしその時らくだはトトッと数歩前へ。それに男が近づき再びチャレンジ。
しかしらくだはまたもやトトッと数歩前へ。その後、何度も試したけど同じ事の繰り返し。
男は行為をあきらめ、再びらくだと旅を続けました。
そしてしばらく歩いていると、なんと前方にきれいな女性が倒れているではありませんか！
男は女性に言いました。
男：「大丈夫ですか？」
女：「あ…あの、のどが乾いて死にそうなんです…」
男はここぞとばかりに言いました。
男：「じゃあ、水をあげたらなんでも言う事をきいてくれますか？」
女：「はい…言う通りにします……」
男は水をあげた。
女：「ああ、ありがとうございました。おかげで助かりました」
男：「よし。言う事をきいてもらうぞ」
女：「…はい……」
男：「じゃあ、らくだ押さえといて」


0046Java太郎 ◆DMVtSSFzcg NGNG
>>45
（一応、反応するか・・・(　´Д｀)）
スゴイ！涙が出ちゃう話だね・・・
最近、涙もろくてｗ
ハハもう年かな？
0047デフォルトの名無しさんNGNG
>>1の妹の亞里亞です。
このたびは兄やがこんなスレッドを立ててしまってごめんなさい・・・。
兄や、最近亞里亞のところに来てくれないの・・・。くすんくすん。
じいやに聞いたらね、兄やはどこか遠い世界に逝ってしまったって急に怒るの。
そんなときのじいやはとっても怖いんです。
兄や、どうして亞里亞をひとりぼっちにするの･･･？くすん。

兄や・・・早く帰ってきてください・・・くすん。
亞里亞、兄やのお馬さんじゃないと楽しくないの。
じいやにまた怒られるかもしれないけど、兄やとまたお馬さんごっこしたいな。
0048デフォルトの名無しさんNGNG
プログラムって何回も何回も似たような単純作業をすることが多いから、
抽象的な概念を導入することで作業を一般化して、
同じ作業を繰り返す手間を省こうって話なんだよなあ。
ある程度、普通にプログラムを書いていれば、
モジュール化をしてゆくようになるし、
いろんなプログラムからモジュールを使えば、
モジュール強度なんかも気になってくる。
で、言語レベルでそのサポートをしてくれるのが
オブジェクト指向の言語だから、
単に便利だから使ってるってだけ。
その便利さが分からないってことは、
知識と経験が足りないって可能性は高いかも。
0049デフォルトの名無しさんNGNG
>>１の妹の花穂ですっ★
お兄ちゃま、お元気ですか？　花穂は自作自演を毎日一生懸命がんばってます！
早くお兄ちゃまのクソスレを1000まで行かせたくって、もう待ちきれないくらい!!
お兄ちゃまに「花穂のおかげでこのスレが1000まで行ったよ」って言ってもらうのが、
花穂のちっちゃい頃からの夢なんだぁ……★
お兄ちゃま、花穂の自作自演、楽しみにしててね！


0050Java太郎 ◆DMVtSSFzcg NGNG
>>47
（コイツもか・・・）
妹、居ないけど、(　´Д｀)なにか?
・・・２ちゃん風に決めたぜ！よっしゃ！！
0051デフォルトの名無しさんNGNG
>>１の妹の可憐です。
大好きなお兄ちゃん。この前お兄ちゃんが立てたスレ、とっても大切にしています。
どうしたって毎日１回はスレを見てしまうの。１の書き込みを見ているとお兄ちゃんの
声が聞こえるみたいな気がする不思議なスレ……。
でもみんなはこのスレをクソスレって言うの。とってもすてきなスレなのに･･･｡
でも、可憐だけはお兄ちゃんの味方だよ･･･｡お兄ちゃん……大好き。
0052Java太郎 ◆DMVtSSFzcg NGNG
>>48
すごい！！当たってるｗ
知識と経験が全然足りないよ・・・
初心者Javaのスレに行っても、話がわからないし。
0053デフォルトの名無しさんNGNG
1の妹の沙織です。
このたびはお兄ちゃんがごめいわくおかけして
どうもごめんなさい。（ペコリ）
はぁ……なんでこんなことになっちゃったんだろ。
昔のお兄ちゃんは、優しくて、家族思いで、頭だってテスト１００点
ばっかりだったし、お友達に囲まれていっつも楽しそうだった。
でも、あの日の後、もうお兄ちゃんはお兄ちゃんじゃなくなっちゃった。

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

0054Java太郎 ◆DMVtSSFzcg NGNG
１の妹シリーズって読んでると疲れるし、面白くないね。
しかも、コピペでしょ～
はぁ・・・それでも読んでるオレってピュアだ！！
0055デフォルトの名無しさんNGNG
1の妹の咲耶です。
……お兄さま。とうとう見つけたわ。
ねぇ、お兄さま、最近私のこと避けていない？
昔はよく一緒に遊んだり、TV見たり、お風呂に入ったりしたのに、
最近は学校から帰るとすぐに出かけるか、部屋にこもっちゃうのよね。
ちゃんとお喋りしたのって、もういつのことだか忘れちゃったわ。
お兄さま……。私、ずっとお兄さまのこと見てたわ。
勉強してるときも、友達と居るときも、いつでもお兄さまのことが頭から離れなかったわ。
でも、いくらニブいお兄さまでも、やっと私の気持ちに気づいていてくれたのかしら？
だから最近避けてるのね？
でも、ダメ。逢えないほど、お喋りできないほど、私の想いは募ってしまうの。
もう、私、我慢できない。
だから、悪い子だってわかってるのだけど、お兄さまの部屋、黙って入っちゃったわ。
お兄さま、いつも一人でパソコンに向かってたわね。
パソコンに残ってたデータを見て、私ショックだったわ。
お兄さまも苦しんでいたのね･･･つらかったのね。
わざとめちゃくちゃなスレッドを立てて、他のみんなと喧嘩して、
フラストレーションを発散させていたんだってわかって、私、涙が止まらなくなったわ。
お兄さま。無理しなくていいの。我慢しなくていいの。
私、もう心の準備はできてるから。
16年前、お兄さまの妹に生まれてから、ずっとお兄さまのことが好きだったんだから。
お兄さま。学校から帰ってきて、この書き込み読んだら、私の部屋に来て。
私、今日はもうお兄さまと離れていたくないの。
だから………お願い………
死んでちょうだい。
0056Java太郎 ◆DMVtSSFzcg NGNG
>>51
やさしいね、ありがとう(　´Д｀)
0057デフォルトの名無しさんNGNG
>>1の妹の咲耶です。うちのお兄様が皆さんに迷惑をかけてしまった
みたい、お兄様にかわってお詫びするわね。

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

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

あ、今からお兄様とお風呂に入るので失礼するわね。
0058Java太郎 ◆DMVtSSFzcg NGNG
>>53
近親相姦に興味ない(　´Д｀)
0059デフォルトの名無しさんNGNG

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


0060Java太郎 ◆DMVtSSFzcg NGNG
>>55
まだ死なない(　´Д｀)
0061デフォルトの名無しさんNGNG
>>1の妹の千影だ…
兄くん…駄スレは立てないでくれと…いつも言っているだろう･･･
そうでないと…きっと…兄くんの身に…不幸な災いが…ふりかかる…
ホラ…見てみろ…。兄くんのせいで…こんなにも多くの…愚者が…稚拙なレスを……。
兄くん…、いいかい？もう…こんなスレ立てないと…約束してくれ
でないと…兄くんの命が…危ないことになる…
それでは兄くん…また…来世…
0062Java太郎 ◆DMVtSSFzcg NGNG
>>57
他人とお風呂入るの嫌なの知ってるじゃん(　´Д｀)
0063デフォルトの名無しさんNGNG
1の妹のはるかです。
このたびはお兄ちゃんがごめいわくおかけして
どうもごめんなさい。ペコリ。
はぁ、なんでこんなことになっちゃったんだろ。
昔のお兄ちゃんは、優しくて、家族思いで、
頭だってテスト１００点ばっかりだったし、
お友達に囲まれていっつも楽しそうだった。
でも、あの日の後、もうお兄ちゃんは
お兄ちゃんじゃなくなっちゃった。
お兄ちゃんは、少しも悪くないんだ。
悪いのは、あいつ。
なにか、皆さんに、
おわびしてあげられることがあると、いいんだけど。
ううん、待ってて。
私が、お兄ちゃんを元通りのお兄ちゃんにしてみせる。
そして、お兄ちゃん自身が、
自分でこのあやまちをつぐなうんだ。
だから、ほんの少しだけ、待ってて。
ごめんね、おねがいします。
0064デフォルトの名無しさんNGNG
>>1の妹の春歌ともうします。

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

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

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

　その後でいすぷれいにはまだ何文字か下劣な言葉が生まれました。兄君さま
は最期の力を振り絞ってそれを送信しますと、もう二度と動くことのな
い肉となってしまったのです。
0065Java太郎 ◆DMVtSSFzcg NGNG
>>59
なんでスレを立てたぐらいで、命がどうのこうのって話になるんだよ(　´Д｀)
どこから仕入れたんだろ・・・妹シリーズ。
0066デフォルトの名無しさんNGNG
　今兄君さまの体は、使用人が埋めてくれている所だろうと思います。しばし
茫然としておりましたが、ともかくワタクシは兄君さまが生前に固着しつづけたこの
にちゃんねるというものがいかにあの優しかった兄君さまを蝕んだのか（兄君
さまの名誉のためにのみ申すのですが、数年前に日常の言葉を失って部屋に閉
じこもる以前の兄君さまはそれはそれはお優しく聡明な方でございました）を
知りたくて、兄君さまのぱそこんからあくせすしている次第でございます。
　しかし、兄君さまのここでの行状を知るに及び、みなさんに一言謝っておく
のが本義だろうと思い、きいぼおどを取らせて頂きました。大変はしたない
ことを書いてしまいましたが、いまだ動機の収まらぬ兄殺しの書いた文と思
い、どうぞお捨て置かれますように。

　ああ、兄妹揃ってのご無礼をどうぞお許しくださいませ。そのような次第
でございます。どうか不憫な兄君さまのことを悪く思わないでやってください
ませ。兄君さまいつまでもおかわいそう方でございました。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　かしこ
0067Java太郎 ◆DMVtSSFzcg NGNG
１の妹シリーズへ
もう似たようなネタしかないね・・・
やめよう(　´Д｀)
0068デフォルトの名無しさんNGNG
>>1の妹の雛子でーす！！
みんな、おにいたまの立てたスレッドに来てくれてありがとねっ☆
おにいたまは、ちょっと頭が弱いところもあるけど、
とっても、とーっても優しいおにいたまなんだよ！！
今日も、さっきまでいーっぱいいいーーっぱい、ヒナに優しくしてくれたし、
おにいたま、大好きっ。って、あっ、言っちゃった！
はずかしーよーーぅ
みんな、ヒナがおにいたまの事言っちゃったって、内緒だよ？
ほんとに、ほんとに内緒だよ？？
あっ、今おにいたまが戻ってきた。
今度はいっしょにゲームしてくれるんだって！くししし、楽しみだなー。
じゃぁ、いってきまーーす！！
0069デフォルトの名無しさんNGNG
>>1の妹の衛です。
このたびはあにぃがこんなスレッドを立ててしまってごめんなさい。
あにぃは最近、嫌な事があってこんなスレを立てちゃったみたいなんだ・・・。
あにぃはね、本当はこんなスレは立てない優しいあにぃなんだよ！
よほど嫌な事があったんだろうね・・・。
でも駄スレを立ててしまったのは悪い事だし、ボクからもあやまるよ。
ボクがあにぃを元の優しいあにぃに戻すから、それまであにぃの話題にのってあげてね・・・

じゃ、これからあにぃとスノボにいってくるから失礼するね。
0070デフォルトの名無しさんNGNG


>>1の妹の四葉デス。
兄チャマ！あれほど言ったのに、まだそんなカキコするデスか！もう許しませんデス！
兄チャマのこと許すわけにはいかないデス！こんなカキコでレスたくさん付くとでも思ってるなんて頭おかしいデス！
兄チャマみたいなバカは初めて見マシタ！兄チャマみたいなバカ、ゴキブリ以下デス！
兄チャマみたいなバカ、ウジ虫以下デス！死んでほしーデス！むしろ死ぬべきデス！兄チャマは絶対に許されないデス！
勘違いしたバカを許すわけにはいかないのデス！面白半分にいい加減なカキコする兄チャマを四葉許さないデス！
キャラメルコーンのピーナッツをケツの穴に詰めて死んでしまえデス！！！
今まで兄チャマがどんな生き方してきたか知らないけど、どーせひどい生き様だったと想像出来るデス！
兄チャマのカキコから読みとれるデス！バカ特有の 匂いがするデス！
兄チャマのことが全く理解出来んデス！兄チャマを絶対許さんデス！
死んでも許さんデス！地獄で苦しむデス！それでも足りないデス！
豆腐の角に頭ぶつけて死んでしまうデス！！！
兄チャマもっと現実を知るデス！いつまでも引きこもってネクラなことしてる場合じゃないデス！
でも、もー手遅れデス！兄チャマは何をやってもダメデス！
この世に生まれてきたことを後悔してもダメデス！兄チャマは生まれ変わってもどうせダメ人間に決まってるデス！
絞め殺したいけど兄チャマに触るのが嫌なので やめるデス！でも、兄チャマみたいなカスは死ねよデス！
風呂の排水溝に吸い込まれて死ねよデス！！！
兄チャマみたいなヤツは絶対許せないデス！早く消えてほしいデス！
さっさとこの世からいなくなってデス！！！
いつまでも勘違いしたまま生きていけると思ったら大間違いデス！
このまま生きてても兄チャマにはいーことなんにもないデス！
何でもいいからさっさと死ねよデス！！！
0071デフォルトの名無しさんNGNG
>>1の妹の鈴凛です。
アニキは、すっかりダメになってしまいました。
ううん、元々ダメな奴だったんだよ、あの男は。
まともに人と口をきけないし、何をやっても中の下で、いいとこなし。
でもねえ、素直で純粋なのが取り柄だと、今まではそれでも思ってたんだよ。
それなのに。
ああっ！もう思い出しただけで腹が立つ！！
私がアニキを一番好きなのに！
あの男は空想の女に恋してるんだよ。まっじで。おえ。
引きこもってるからさ、普段は部屋のぞく隙がないんだよ。
でもあの日は、年一回のイベントがあるとかで、母さんから金せびって早朝から居なかった。
ふらふらと、入っちゃったんだ。何年ぶりかの部屋だった。
……もう、言いたくない。1の、アニキの書きこみから、想像つくでしょ。
0072デフォルトの名無しさんNGNG
抽象化能力のない人間がプログラマになって、
オブジェクト指向がわからなくて、まわりから馬鹿にされて、
オブジェクト指向のスレを荒らして憂さ晴らしってパターンは
多いようだ。

かわいそうな話ではあるが、人には器というものがある。
0073デフォルトの名無しさんNGNG
妹レスも読みつかれた。しつこすぎ。
マンネリには飽きた。他板でやれ。

んで>>1は何を理解したんだ？
0074デフォルトの名無しさんNGNG
>>72
オブジェクト指向なんて算数でいえば九九みたいなもん。
器もなにもない。
確かに九九が出来ない小学生もいるだろうが。
0075デフォルトの名無しさんNGNG
あえて言うなら「九九ではなく微分みたいなもの」としておこう。
意味のない微分と同様に、意味のないオブジェクト化をする人間もいる。
困ったものだ。
0076Java太郎 ◆DMVtSSFzcg NGNG
>>73
ぶっちゃけ、具体的に質問したい事はない。
まず、本を熟読する事が今の目標。
ただ、わざわざクラスを作らなくても動かせるプログラムがあると
ちょっと、気持ち悪いかな。
基礎を学ぶためだからしょうがないけど。
0077Java太郎 ◆DMVtSSFzcg NGNG
>>72
人には器というものがある
↑これって荒らしに対して？
0078Java太郎 ◆DMVtSSFzcg NGNG
>>74
九九ならできる！！ヽ(´∇｀)ノ
0079Java太郎 ◆DMVtSSFzcg NGNG
>>75
オブジェクト化する必要が無いものまでしてると
ちょっと読みづらくなる・・・
0080デフォルトの名無しさんNGNG
>>77
そう。
だが、実際、それはすべてのプログラマにあてはまる。
そして複数の人間でプログラムを開発する場合、
プロジェクト内のレベルに合わせて、簡易化されたラップを
用意することを理解するためにも必要な前提なのだ。
言い方を変えれば、自分と相手の器を理解するプログラマは、
質のよいプログラマでもある。
0081Java太郎 ◆DMVtSSFzcg NGNG
>>72
図星みたいだね
１の妹シリーズが止まったよｗ
0082デフォルトの名無しさんNGNG
昔Ｄｅｌスレだかで観た「ギコ猫オブジェクト」が非常におもしろかった。
0083Java太郎 ◆DMVtSSFzcg NGNG
>>82
え？なにそれ～
独り占め？
ズルイぞ！ズルイぞ！．．．(´З｀)ﾁｭｯ
0084デフォルトの名無しさんNGNG
静かだ・・・
0085デフォルトの名無しさんNGNG
おい、J太郎出て来い
0086Java太郎 ◆DMVtSSFzcg NGNG
>>85
Ｊ太郎って、オレの弟か？
どうなんだよ！？隠すんじゃねーよ！！
コンチクショー
0087デフォルトの名無しさんNGNG
オ・バ・ケの･･･
0088Java太郎 ◆DMVtSSFzcg NGNG
>>87
Q太郎か？
お前、年いくつだよ？
オヤジスレにするつもりかよ！！
0089デフォルトの名無しさんNGNG
何も書き込むことが無い
0090デフォルトの名無しさんNGNG
オブジェクト定食
0091デフォルトの名無しさんNGNG
ここ、本当にプログラム組める奴、何人ぐらい居るんだろう？
0092Java太郎 ◆DMVtSSFzcg NGNG
>>89
書き込んでるじゃーん！！
ビックリ人間だな・・・オマエ
0093Java太郎 ◆DMVtSSFzcg NGNG
>>90
名前だけじゃ、どんなものが出されるのかわからないな・・・
み、味噌汁はついてるのかなぁ？ぐへへ・・・
0094Java太郎 ◆DMVtSSFzcg NGNG
>>91
それは愚問だ！
一応、答える
Ａ．オレしか居ないぜ！！（素
0095デフォルトの名無しさんNGNG
>>Java太郎
ひまそうですね。
0096デフォルトの名無しさんNGNG
>>94
何言語だよ
0097デフォルトの名無しさんNGNG
オブジェクト指向の概念において、（私の父：公務員）が
“私の父は公務員”というインスタンスとクラスの関係を意味する
としたとき、同じ関係となるものはどれか。


　ア　（赤い車：乗り物）　　　　　イ　（オーストラリア：国）

　ウ　（私の父：私の母）　　　　　エ　（私の部屋：私の家）
0098デフォルトの名無しさんNGNG
何このスレ・・・・・・・？
　　　　　　 　　　　　　/ヽ　　　　　　 /ヽ
　　　　　　　　　　　　/　ヽ　　　　　 /　ヽ
　　＿＿＿＿＿＿ /U　ヽ＿＿＿/　　ヽ
　　|　＿＿＿＿　／　　　U　　　　:::::::::::U:＼
　　| |　　　　　　 /／ ＿__　　　＼　　::::::::::::::|
　　| |　　　　　　 |　　|　　 |　　　　　U :::::::::::::|
　　| |　　　　　　.|U　|　　　|　　　　　　::::::U::::|
　　| |　　　　　　 |　├―-┤　U.....:::::::::::::::::::/
　　| |＿＿＿＿　ヽ　　　　　.....:::::::::::::::::::::::<
　 └＿＿＿／￣￣　　　　　　:::::::::::::::::::::::::|
　　|＼　　　 |　　　　　　　　　　　:::::::::::::::::::::::|
　　＼ ＼　 ＼＿＿＿　　　　　 ::::::

0099デフォルトの名無しさんNGNG
>>97

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

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

このような内部状態を持つオートマトンであるオブジェクトは、
Ａ「ね～、今日、暇？」(get)
Ｂ「うん、暇だよ。」(返り値)
Ａ「遊びに行こうよ」(set)
Ｂ「いいねえ」(返り値)
と、コミュニケーションモデルで設計するのが
比較的分かりやすいため、メッセージを送る/受け取ると
いうメッセージパッシングとして実装される。
0101デフォルトの名無しさんNGNG
>>100
間違い
0102デフォルトの名無しさんNGNG
これは面白い現象ではあるが、また、残念な現象とも言える。
抽象概念の真偽は、知性によって判断され、知識によっては判断されない。
つまり、「知っている」と「理解している」が明暗を分かつ場面でもある。
オブジェクト指向型のプログラミング言語を便利に使えるということは、
正しい知識と持つことだけでなく、正しく理解することが必要である。
同時にオブジェクト指向を使えない人たちは、理解よりも知識を求める。
オブジェクト指向を使えない人たちは同じ作業を繰り返して上手になることを望むが、
オブジェクト指向を使う人たちは、同じ作業を繰り返さずに済む方法を考える。
そして、その差は知性によって判断される。
0103デフォルトの名無しさんNGNG
>102
そーいう能力は個人差があるからね。別の能力でいうと
モテる男は最小の労力でいい女をゲットできるが
モテない男はいろんな女にトライするしかないつーこと。
努力でカバーできればまだマシなほうだよな。いくらか
妥協している人も結構多いのでは・・・。
0104デフォルトの名無しさんNGNG
知性はフツーで十分です。
0105デフォルトの名無しさんNGNG
俺はＪａｖａの
インターフェースとインプリメンツの違いが
よくわかんねーよ。
0106デフォルトの名無しさんNGNG
かたまり、かたまり
カプセル、カプセル
0107デフォルトの名無しさんNGNG
>>105
引退しろ
0108デフォルトの名無しさんNGNG
>>107
あはっ、Ｊａｖａは趣味でやってまつから。
関りたくネーヨ＞Ｊａｖａ。
0109デフォルトの名無しさんNGNG
protectedに何を置けばいいのか分からない…(Delphi)
0110デフォルトの名無しさんNGNG
　　　　　　　　　　　　☆ ﾁﾝ
　　　 　 　 ☆　ﾁﾝ　　〃　 Λ＿Λ　　　／￣￣￣￣￣￣￣￣￣￣￣
　 　 　 　 　　ヽ　＿＿_＼（＼・∀・）　＜　鞠絵ﾏﾀﾞ～？
　　 　 　 　 　 　 ＼＿／⊂　⊂＿ )　　 ＼＿＿＿＿＿＿＿＿＿＿＿
　　 　 　 　 　 ／￣￣￣￣￣￣ ／|
　　　　　　　　|￣￣￣￣￣￣￣|　 |
　　　　　　　　| .　　　　　　　　　 |／
　　　　　　　　￣￣￣￣￣￣￣
0111デフォルトの名無しさんNGNG
インターフェースは抽象的なメソッドの定義である。
インプリメンツは具体的な実装プログラム記述である。

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

このように、アプリケーションが送り先のオブジェクトが
何であるかを知らなくても、同じ操作が出来る利点が生まれる。
実際には送る側はアプリケーションである必要さえなく、
オブジェクトでもなんでもかまわない。便利である。
0112105NGNG
>>111
ありがとう、本とか読んでもヤッパリピンとこないんだよね。
同じ機能に思えるし。
例えば
Blackクラスがあって、インターフェイスにBlack_Aという文字変数が用意されている場合。
WhiteクラスはBlackクラスに対してBlack_Aだけを意識すればいいということ？

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

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

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


0113プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
ＯＯの前に正しいサブルーチンの作り方を会得しろ。
まあ才能のある奴はそうは居ないけどな。
ＯＯはその次だ。
正しいサブルーチン作れない奴にＯＯは無謀。
0114デフォルトの名無しさんNGNG
>>105
implementsはinterfaceを実装するときに記述するものだ。
>>111の説明は誤解を招く部分がある。
>>105はまず実際にinterfaceを実装したクラスを作って
プログラミングしてみろ。

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

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

implementsはextendsの代わりに使うものであり、interfaceを実装したいクラスに記述する。
0115デフォルトの名無しさんNGNG
interfaceをimplementsする。
とても解り易いと思うんだがな。
0116デフォルトの名無しさんNGNG
>>112
> 楽つーことかな？Aクラス内部にわざわざメソッドを定義して会話するよりも
> インターフェースのファイルを書き換えれば手間が済むと。
ぜんぜん解ってない。

本を読むだけで終わらせないで
interfaceを実装したサンプルプログラムを書いてコンパイルして実行しろ。
実際に動かしてみてコンパイルエラーがでて初めて理解できる。
0117&&@rrloNGNG
同意
0118105NGNG
>interface とは インスタンスを作れない、メソッドの
>実装を許さない(public abstractメソッドしか許さない)、
>public static finalなフィールドを持つことしか許さない、
>多重継承を許すpublic abstractなクラスの特殊な形態ことである。

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

　　　Ｃ
　　　｜
　Ａ←Ｂ

があったとする。んで、クラスＡのインタンスを複数（１～n個）作ったとする。

Ａ0 A1 ・・・・　Ａn

で、この時Ａ1～Ａnまでを利用するが、Ｃで定義された変数はＡ1～Ａnまで
すべて共通の値を持つということでよい？。
0119デフォルトの名無しさんNGNG
俺は、基本的にinterfaceってのは
プログラマに実装上の留意を促し、
実装ミスを防ぐ為にあるのが50％、
C++と比べてClassの多重継承ができない事に
対する代用策としてが50%と考えてる。
0120デフォルトの名無しさんNGNG
ぬるぽをいかに抽象化するかってことだな
0121デフォルトの名無しさんNGNG
>>119

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

えっと少し変更。
クラスＡ、クラスＢ、クラスＣ、インターフェースＤがあって、
クラスＢ、Ｃが親クラスでクラスＡに継承し、クラスＢ、ＣがインターフェースＤを持つ場合。

　　　＋－Ｂ(*1)
　　　｜
　Ａ←＋
　　　｜
　　　＋－Ｃ(*1)

(*1)ーＤ

があったとする。んで、クラスＡのインタンスを複数（１～n個）作ったとする。

Ａ0 A1 ・・・・　Ａn

で、この時Ａ1～Ａnまでを利用するが、Ｃで定義された変数はＡ1～Ａnまで
すべて共通の値を持つということでよい？。
0123デフォルトの名無しさんNGNG
インターフェースが威力を発揮するのは、
同一のインターフェースが複数のクラスでインプリメントされる場合である。

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

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

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

同時に、将来、「メールクラス」を追加するときにも、
ラーメンタイマーは書き換える必要がない。
メールクラスを同じ「文字出力」インターフェースで
インプリメントすれば、ラーメンタイマーは
一行も書き換えることなしに使える。
「お時間がきました」という通知はケータイで受け取れるだろう。
便利である。
0124デフォルトの名無しさんNGNG
>>121
不正解と3文字だけ書くことなら
馬鹿にでもできる
0125デフォルトの名無しさんNGNG
>>105
念のため確認したいんだけど、
Polymorphismの事くらいは知ってて書いてるんだよな。
0126デフォルトの名無しさんNGNG
>>122
＞クラスＢ、Ｃが親クラスでクラスＡに継承し
JAVAでclassの多重継承はできまへん
0127デフォルトの名無しさんNGNG
>>125
＞Polymorphism
知らない。

0128105NGNG
>>126
ああっそうだった。
やべっ混乱してきた。
0129デフォルトの名無しさんNGNG
>>127
じゃ、知っとけ。
0130デフォルトの名無しさんNGNG
>>122
> えっと少し変更。
> クラスＡ、クラスＢ、クラスＣ、インターフェースＤがあって、
> クラスＢ、Ｃが親クラスでクラスＡに継承し、
Javaではそのような実装の多重継承を許さない。

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

恐らくあなたは多重継承とポリもーフィズムとを取り違えていると思われ。
0131デフォルトの名無しさんNGNG
(ﾟ∀ﾟ;)
0132デフォルトの名無しさんNGNG
オブジェクト指向やJavaのinterfaceは全然分からんが
>>105が何も分かっていないことだけは分かる。
0133119NGNG
>>121
いや、不正解と言われても。。。
あくまで俺なりの解釈なんで、
正解も不正解もないんだが。
0134デフォルトの名無しさんNGNG
>>122 での矢印の使い方から、105は馬鹿ってことに決定。
0135デフォルトの名無しさんNGNG
>>Cが親クラスでクラスAに継承し
このアタリもまずいような気がする。
0136デフォルトの名無しさんNGNG
馬鹿馬鹿言わんと教えてやれや
0137プロの逝って良しの2 ◆KgOWTAR7IU NGNG
ゲッツ！
0138105NGNG
>>123
ラーメンクラスと、interfaceと、その他の追加するクラス関係が分かれば
納得すると思う。できれば図ｷﾎﾞﾝﾇ。

ラーメンタイマークラス
インターフェース
[その他]
画面クラス
プリンタクラス
音声クラス
0139デフォルトの名無しさんNGNG
interfaceAにBというメソッドがあるとすれば
interfaceAをインプリメントしたクラスはＢメソッドが実装されていることが保証される。
0140デフォルトの名無しさんNGNG
「持つ」といったらこういう意味だからな。

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(){
　　//ここに実装
　}
}
0141デフォルトの名無しさんNGNG
>>133

独自の考えはやめた方が。
0142105NGNG
>>140
class B {
は
class B interface C{
だよね？


0143デフォルトの名無しさんNGNG
>142
それ、何言語？
0144105NGNG
やべ、142でまた変な事書いてしまったかな？
はぁ。Ｊａｖａの本を探しに逝ってくる。
0145Java太郎 ◆DMVtSSFzcg NGNG
>>144
ダメ！行かないで！！
ヽ(´Д｀ヽ)(/´Д｀)/イヤァ～ン
0146デフォルトの名無しさんNGNG
>>142
お前はちゃんとプログラミングしているのか？

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

ちゃんとコンパイルしろ。
んで自分の目でちゃんと確かめろ。
0147デフォルトの名無しさんNGNG
それは机上の空論か？
0148デフォルトの名無しさんNGNG
机上の空論というよりも論にすらなってない。
0149デフォルトの名無しさんNGNG
なんかキモイやつらばかりだね、ここは。
0150デフォルトの名無しさんNGNG
そうだな。とくに>>149とか
0151デフォルトの名無しさんNGNG
implementsとinterfaceを混同してしまっているんだろう。
0152Java太郎 ◆DMVtSSFzcg NGNG
>>150
わかってないな！おまえ・・・
一番キモイのはオレだ！！
ポリモルフィズムの利点がよくわからない、今日この頃ヾ(´ー｀ )ノ
0153デフォルトの名無しさんNGNG
JAVAの場合、Runnableとか見れば多少の利便性は解るだろうに。
Threadクラスの作成者はJAVAのプログラマがどんなクラスを実装
するのか知る事はできない。
だが、Runnableというインターフェースを定義しておく事で
ユーザの任意の元、未知のクラスにrun()というメソッドが
実装される事が保障され、Threadクラスから呼び出す事ができる。
0154デフォルトの名無しさんNGNG
＞ラーメンクラスと、interfaceと、その他の追加するクラス関係が分かれば
＞納得すると思う。できれば図ｷﾎﾞﾝﾇ。

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

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

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

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

A嬢は、ダメポ銀行に入行して２年目、窓口業務もかなり板についてきた。
実はA嬢はひそかにファンドマネージャになりたいと思って、
自己研鑽を重ねている。その成果が現れたのか、最近では
先輩社員がいろいろと相談を持ちかけてくれる。
上司も見る目も変わってきたようだ。
でも、まだまだ配置換えは期待できそうにない。
内心歯がゆい思いをしながら、今日も窓口に座る。
一旦窓口に座れば、窓口業務をこなさなくてはならない。
その時間はA嬢は、お客さまと銀行を取り持つ窓口係という、
大切なインタフェースの役割を果たしている。
0156デフォルトの名無しさんNGNG
>>153
初心者にスレの話しても混乱するだけと思われ
0157デフォルトの名無しさんNGNG
コンストラクタに自分の上位インタフェース渡すパターンって何？
0158デフォルトの名無しさんNGNG
天気いいなぁ・・・
0159デフォルトの名無しさんNGNG
なんですかラーメンタイマーって。
じゃあ俺もぽりもーひずむの利点を麺にちなんで例えてみる。

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

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

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

つづく
0160デフォルトの名無しさんNGNG
> 製麺ボタン()を定義したのみ。
> 製麺interface自体は空っぽ

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

0161デフォルトの名無しさんNGNG
>>159の続き

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

つづく
0162Java太郎 ◆DMVtSSFzcg NGNG
定義して空っぽって
抽象メソッドみたいだね。

HAS-A関係（？）を使って
擬似的に多重継承できないのかな？
0163デフォルトの名無しさんNGNG
>>161の続き

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

つづく
0164デフォルトの名無しさんNGNG
>>163のつづき

工場の生産ラインは順調だ。
バイト君の目前に製麺interfaceを実装した製麺機を置いてやれば、
それが何の製麺機であろうと、彼は麺を見事に作り上げていく。
近々、新商品としてスパゲッティを新たに手がける予定だ。
当然パスタ製麺機も製麺インターフェースをインプリした
機械にする予定なので、新たにバイトを増やす必要も無く、
既存のバイト君に新たな教育をする手間もかからないだろう。
0165デフォルトの名無しさんNGNG
話をややこしくするだけの人ってたまにいるね。
プロジェクトに入ってくるととても迷惑。
0166デフォルトの名無しさんNGNG
いいたいことはわかるのだけどね。

あらかじめ言いたいことが分かってる私には、なんでもないけれど、
分かってる人だけにわかればいい文章なんて、ここに書く意味ないし、
分かってない人に分かってもらうには、あまりにも不親切な誤りを含んでいる。
0167デフォルトの名無しさんNGNG
＞不親切な誤りを

向学のため、指摘していただけると有りがたい。
0168デフォルトの名無しさんNGNG
>>106 で指摘したけれど、

中身が空っぽの interface
と
中身が空っぽの method
の違いをキチンと理解、区別しようね。
0169デフォルトの名無しさんNGNG
それは機械として中身は空っぽという事を言ったつもりなんだけど。
機械に例えたりプログラムに例えたりと
曖昧な例え方がいけなかったかな？
0170デフォルトの名無しさんNGNG
機械として中身が空っぽであるなら、ボタンなんてものも無い、と
読むのが普通ではないかい？

まあ、単なる比喩を元に突っ込んだ議論をしてもあまり意味がないと
思うけどさ。曖昧な例え方がいけないんじゃなく、日本語の記述に
無頓着なのがいけない気がする。
0171デフォルトの名無しさんNGNG
まあこのスレの趣向から言って
ポリィモーフィズムの雰囲気さえ
掴めれば問題ないんでない？
JAVAの話が主体じゃないんだし
0172デフォルトの名無しさんNGNG
>>170
悪かったよ。
もう余計な口は出さん事にするよ。
0173デフォルトの名無しさんNGNG
>>172

ありがとう。
ほんとうにそうたのむよ。
0174デフォルトの名無しさんNGNG
>173
ご満悦そうだな（ｗ
0175デフォルトの名無しさんNGNG
>>162
そういうのは多重継承とはいわんよ。
単に集約してるといえばいいのさ
0176Java太郎 ◆DMVtSSFzcg NGNG
>>175
あなた頭いいでしょ？
わかる！！わかるんだよ・・・オレには。

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

集約なんだ・・・勉強になりました。
0177デフォルトの名無しさんNGNG
C++と比べてJAVAはクラスの
多重継承ができない代わりか
どうか知らんけど、
implemetsというキーワード
を提供しているが、それによって
良くなった点と悪くなった点を
誰か挙げてくれないか？
0178デフォルトの名無しさんNGNG
>>177
implementsはクラスへのinterface実装専用。

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

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

実装の多重継承は混乱のもとといわれてきた。それをコンパイラが禁止することで
プロジェクトでこっそり実装の多重継承をするプログラミングをさせないことで
バッティング問題を解消できる。
0179デフォルトの名無しさんNGNG
でも綿密に管理されたコードだったとして、
バッティングの心配とかを抜きにすれば、
多重継承できない事でコーディング量が増えたり
不便になったという事は考えられるんでない？
0180デフォルトの名無しさんNGNG
ATLとか見るとな
0181デフォルトの名無しさんNGNG
＞良くなった点と悪くなった点を誰か挙げてくれないか？

まあ、広域変数とgoto文もそうだけど、誰が使ったか、
影響があるのはどこかを完全に把握してれば問題は回避できるけど、
分からなくなったらグチャグチャになったら取替えしが
つかないってことだよね。
おれは予防のコストはあとから大変になることを考えれば十分に見合う気はする。
特に複数の人でプロジェクトを進める場合はね。
でも、このコスト感覚は人によって違うと思う。
0182デフォルトの名無しさんNGNG
>>179
実装の多重継承の危険性はソフトウェア工学の研究で実証済み
0183デフォルトの名無しさんNGNG
>>182
だから、危険か危険じゃないかは人によって違うだろ。
使う人間によっては便利にもなるし、危険にもなる。
そもそも、お前のように自分の観点でしか物を見れない
奴がいるから危険なんだよ、バーカ。
0184デフォルトの名無しさんNGNG
独りで書いて使うぶんにゃとても便利だろうな。
多人数が同時に書いたり使ったりだと大変だろう。
0185デフォルトの名無しさんNGNG
そもそも多重継承できない事で代替の方法でコーディング量が増えることは少ないわけだが。
逆に減ることもあるわけでな
0186デフォルトの名無しさんNGNG
CPPの多重継承の機能はJAVAの
interfaceでは完全に代替できない。
コードの再利用という観点からすれば
実装を継承できるのとできないとでは
やっぱ色々と違うでしょ
0187デフォルトの名無しさんNGNG
わからん・・・。
手続き型言語のサブルーチンじゃだめなの？
どこから呼び出しても使える便利なサブルーチンをたくさん作ってさ、あとはメインルーチンからどれをどう呼び出すかだけプログラムすればいいようにすれコーディングは十分ラクできるじゃん。
オブジェクト指向はさらに何をラクしたくてできた言語なわけ？
よくできたサブルーチン集を作ることとの決定的な違いってなによ？
0188デフォルトの名無しさんNGNG
よくできたサブルーチン集と、それが内部で使うデータを一塊にする

あと、オブジェクト指向は言語じゃない
0189デフォルトの名無しさんNGNG
>>187
コードの再利用とか不必要な情報の隠蔽とか利点はいろいろあると思う。
まあ特に必要を感じないんだったら従来どおりにやればいいと思うよ。
0190デフォルトの名無しさんNGNG
>>188
低能な突っ込みやめれ。
言いたいことは解るだろう？
0191デフォルトの名無しさんNGNG
モジュールとして完成度の高いプログラムはアセンブリ言語でも書くことが出来る。
したがって、オブジェクト指向型の言語は必須ではない。
しかし、オブジェクト指向型言語は、モジュールの完成度を高めるための支援を言語レベルで行う。
いわゆる勘違いによる間違いが減る。それだけである。が、これは圧倒的な生産性の向上を意味する。
よく出来たサブルーチンを作れる人ならば、オブジェクト指向の支援を便利に感じるであろう。
まずは良く出来たサブルーチンの条件、モジュール強度と
モジュール結合度などから学びはじめるのが良いだろう。
0192デフォルトの名無しさんNGNG
＞いわゆる勘違いによる間違いが減る。それだけである。

それだけじゃないと思うが（ｗ
0193デフォルトの名無しさんNGNG
オブジェクト指向の利点が理解できないひとは
もう無理にオブジェクト指向を理解しなくてもいいと思う
しょうがないよ、脳みその出来は個人差があるんだから
世の中にはポインタですら理解できない人もいるんだから
0194デフォルトの名無しさんNGNG
>>187
生産性。

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

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

・・・とかいいつつ、全然初心者だったりする儂。
0195デフォルトの名無しさんNGNG
>>193
短絡的な意見ありがとうございます。
0196デフォルトの名無しさんNGNG
オブジェクト指向によるコードが再利用できる程度が知れてます。
0197デフォルトの名無しさんNGNG
struct 男;
struct 女;

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

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

人間.絶頂()

手続きだと性別ごとに絶頂を呼び出さないとだめだが、オブジェクト指向でクラスをつかい継承すると絶頂が１つで済む。
0198デフォルトの名無しさんNGNG
>>187
構造化手法だけではカプセル化という概念を導入できない。

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

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

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

これが構造化手法の研究成果であるという。
0199デフォルトの名無しさんNGNG
ときに、人間クラスがあったとして、そこから男・女クラスが
派生しているとして、sex() はＯＯ的にどこに実装されるのが
妥当ですか？
0200デフォルトの名無しさんNGNG
>>199
sexは名詞というの分かっているか？
0201199NGNG
ああ、では fuck (w でもいいですが。
0202デフォルトの名無しさんNGNG
Sexは一見動詞に、つまりメソッドであるように思えます。
しかし、この分析はよくある間違いです。
Sexは誰かが持っているものでもないし、何人でやる行為であるかさえ決まっていないからです。
Sexとは柔軟で複雑な関係のことを指す言葉です。
従って、関係を表すSexインターフェイスを作り、NomalSexオブジェクトを実装するかたちにしたほうが良いでしょう。
参加者はentryメソッドで集い、startメソッドで宴が始まるのです。
0203199NGNG
なるほどなるほど、至極納得であります>>202
0204デフォルトの名無しさんNGNG
男ばかりがエントリされたときはstart時にアブノーマル例外を送出
0205デフォルトの名無しさんNGNG
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;
　}
}
0206デフォルトの名無しさんNGNG
お前ら熱いね
0207デフォルトの名無しさんNGNG
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() );
0208デフォルトの名無しさんNGNG
中の人も大変だな
0209デフォルトの名無しさんNGNG
Man implements Penis は余計だった
0210デフォルトの名無しさんNGNG
オブジェクト指向の基本は、現実世界の事象をできるだけ
近い形でコンピュータ上にモデル化すること。
現実社会がコミュニケーションで成り立っているように、
オブジェクト同士もメッセージのやり取りで成り立つ。
メッセージパッシングこそ、オブジェクト指向のエッセンス。
継承なんかは後付けの考えだ。

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

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

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

（つづく）
0211デフォルトの名無しさんNGNG
しかし、弁当屋は海苔弁ばかり置いてあるわけではなく、
唐揚げ弁当や焼き肉弁当もある。

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

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

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

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

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

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

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

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

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

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

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

（つづく）
0214デフォルトの名無しさんNGNG
さて、このヤシはたまに友達からレアものビデオなんかも買うのである。

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

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

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

そして「友達」はいつも「買い物」のインタフェースでいるわけではなく、
いろんなインタフェースを使ってこのヤシと関係を作り上げている。
さらに、「友達」は親に対しては「息子」のインタフェース、
先生に対しては「生徒」のインタフェースを使っているかもしれない。
0215デフォルトの名無しさんNGNG
みなさん食い物に例えすぎ（ｗ
別にいいけど。。。
どんどん書いてくれ
0216デフォルトの名無しさんNGNG
C++では普通に多重継承してて、JAVAでは出来ないので正直設計がしにくい言語だと思った。
もう慣れたが。
0217デフォルトの名無しさんNGNG
正直>>207はわかりやすい
0218なおしとけNGNG
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() );
0219デフォルトの名無しさんNGNG
良スレ認定
0220デフォルトの名無しさんNGNG
sexを属性(フィールド)にする手法とどっちがいい？
0221デフォルトの名無しさんNGNG
僕の部屋はクラスがないので
グローバル変数だらけです
0222デフォルトの名無しさんNGNG
>>221
どういう喩えでつか？　　
0223デフォルトの名無しさんNGNG
>>222
要は本棚とか無いんじゃないの？
0224なんとなくNGNG
>218
なんで/TakeshiとMasaruだけ固有名詞のクラスになってんのかね。
s/Takeshi/LargePenisMan/
s/Masaru/SmallPenisMan/
0225デフォルトの名無しさんNGNG
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を分離することのメリットである。
0226デフォルトの名無しさんNGNG
つまり、バター犬をManから派生させるのではなく、
chinko インターフェースをつくって
Manと ButterDog の両方にインプリメント(実装)すべきだということだな。
このやりかたなら、将来、バイブレーターを作ったときも、同じインターフェースが使える。
バイブレーターと Man は継承関係の必然性がないし。
0227デフォルトの名無しさんNGNG
>>224
抽象化のセンス無し
0228デフォルトの名無しさんNGNG
>>226
いやーわかりやすい。（ｗ
0229デフォルトの名無しさんNGNG
>>226
public abstract class Man implements Penis{}
はどういう意味、働きをもってくるの？
0230229NGNG
あっ却下
>>218
0231デフォルトの名無しさんNGNG
>>218
これって多重継承に似ているね。
引数でクラス名を渡しているところが異なるだけで、
クラスを隠蔽化する為に、Ｊａｖａ開発者が無理やりinterfaceやabstractを
とってつけたみたいだ。
なぜなら、Ｊａｖａは全てクラスで表現するという制約を自ら課しているから。
0232デフォルトの名無しさんNGNG
public class Woman {
　　public void sex( Penis p ) { System.out.println( "あなたの ちんこ" + p.getPenisSize() + "のね" ); }
}
は、Penisを引数の型に使っても起こられない？
0233デフォルトの名無しさんNGNG
>>229
Manという言葉があっても、それは単に概念とか分類であって
実際にManという"物"が存在する訳ではない。
TakeshiやHiroshiは"物"として存在するが、Manは存在しないという事。
でも後々、TakeshiやHiroshiを個人の単位ではなく、
Manという分類で扱いたくなるかもしれない。
0234デフォルトの名無しさんNGNG
>>232
言葉の意味から考えれば、
public void sex( Man m )
が相応しい。
或いは、
public void insert( Penis p )
など。
0235デフォルトの名無しさんNGNG
>>225 >>218
そもそもhas-aの関係にあるものをそうやってimplementsする
形式にすべきかも疑問。
それじゃis-aの関係になってしまう。
"He is a penis."

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

>>231
>なぜなら、Ｊａｖａは全てクラスで表現するという制約を自ら課しているから。
オブジェクト指向だから当たり前。JavaソースはUMLクラス図でちゃんと表現できる。
C++のソースはどんなソースでもクラス図で表現できるとは限らない。
interfaceやabstract同様の機能はM$がJavaを真似て作ったC#でも取り入れられている。
0236デフォルトの名無しさんNGNG
別に問題ないんじゃない
PenisはHourseにだってimplementsできる。
woman.sex( new Hourse )とか、、
そんな獣姦ビデオとかあるし。
0237デフォルトの名無しさんNGNG
知識は沢山持ってても抽象化のセンスが乏しい奴はいる。
そういうSEは結構いたな。
抽象化ってのは別部分の能力なんだろうか。
要は分類だよな。
0238デフォルトの名無しさんNGNG
>>235
＞abstract同様
抽象クラスと純化相関数入りのクラスにどれほどの違いがあるんですか？
0239デフォルトの名無しさんNGNG
>>238
抽象クラスにも実装済みで継承可能なメソッドを入れることができるでしょう。
抽象クラスは中に少しでもabstractなメソッドがあればクラスも抽象(abstract)と見なされる。
抽象クラスは継承した具象クラスがないと使えない。
抽象クラスはインスタンスを作れない。

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

つーか純仮想関数って何？
UMLでもそんな言葉聞きません。
0240デフォルトの名無しさんNGNG
>要は分類だよな。
Ｓヨ板がいまだに学問・理系カテにありますから・・・。
0241デフォルトの名無しさんNGNG
>>239
C++も知らないくせにC++との差別化とかほざいてるわけか。浅いな。そこが。
0242デフォルトの名無しさんNGNG
>純仮想関数
純粋仮想関数の typo だと思われ
0243デフォルトの名無しさんNGNG
>>241
Javaも知らないくせにJavaを批判しているわけか。浅いな。そこが。

そもそも純仮想関数という言葉もUMLでは通じないぞ。
C++の用語はUMLでは殆ど死語と化している。
0244デフォルトの名無しさんNGNG
>>243
言語機能とオブジェクト指向用語とごっちゃになってない？
0245デフォルトの名無しさんNGNG
純粋仮想関数ってJavaでいうabstractメソッドのことか。

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

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

ちょっと奇怪に見え
0246デフォルトの名無しさんNGNG
低能な奴ほど言葉の問題にやたらこだわろうとするな。
もちろん言葉は大切、慎重に選んで使わなきゃならないが、
ここで重要なのは指向または志向または思考なわけで、
大体のニュアンスが伝わればなんら問題ない。
0247デフォルトの名無しさんNGNG
>C++の場合オーバーライドし忘れてもコンパイルエラーにならないのか。
エラーになるよ。純粋仮想関数を含んだクラスのインスタンスは
生成できないし、それを継承したクラスが純粋仮想関数をオーバー
ライドしなければやっぱりインスタンスは生成できない。
0248デフォルトの名無しさんNGNG
>virtual void doMethod() = 0;
>
>ちょっと奇怪に見え
確かに。
vtable へのポインタを 0 で初期化するという意味らしい。
0249デフォルトの名無しさんNGNG
>235
じゃあ「interface Penisable」だったらいいのか？
0250書き直しNGNG
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());
0251デフォルトの名無しさんNGNG
>>249
>>225や>>226や>>236を読みなさい。
俺は変える必要は何も無いと思う。
そもそもPenisableって意味わからん。
0252デフォルトの名無しさんNGNG
>>251
陰根可能
0253デフォルトの名無しさんNGNG
fuckableのほうがいいよ
0254デフォルトの名無しさんNGNG
>>246
人にわかりやすく説明するならクラスやメソッドなどのネーミングにこだわることは重要。
ネーミングが変な名前だと混乱するだろう。

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

>>251
-ableという命名パターンはJavaのAPI、インターフェースでは良く見られるものです。
0255デフォルトの名無しさんNGNG
>>254
普通ableは動詞につけるもんだと思うが。
なんでもかんでもableつければいいってもんじゃないですよ。
0256デフォルトの名無しさんNGNG
>>255
ableに詳しい人発見！！　質問させてください
ときどきcompatibleのように単純にable追加したら駄目なのがありますよね
なにか規則でもあるのですか？
0257デフォルトの名無しさんNGNG
>>256
コンパチはダメな英語ですか？
0258デフォルトの名無しさんNGNG
>>257
すいません。意味が良く輪からないのですが
駄目なのは自分の英語力です

辞書にのってるやつならいいのですが
複写可能とか辞書にのってないやつはどうしたらいいのか…
間違ってると恥ずかしいので
0259デフォルトの名無しさんNGNG
>>255
それで>>253「ファッカボー」に改名？
0260デフォルトの名無しさんNGNG
>>258
もし間違っていたらあとでリファクタリング
0261デフォルトの名無しさんNGNG
>>258
「～する　+ ～できる」だから
動詞にくっつけるぶんには外人さんにも意味は通るんじゃない？
不安なら作った言葉をgoogleとかで検索してみるといいよ。
0262デフォルトの名無しさんNGNG
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
0263デフォルトの名無しさんNGNG
>>261
！　ありがとうございます！　なるほど、気づきませんでした。
0264デフォルトの名無しさんNGNG
>>1は糞だが良スレだな。
やっぱりスレの明暗をわかるのは>>2なんだな。
0265デフォルトの名無しさんNGNG
勉強しろよ
低脳
0266デフォルトの名無しさんNGNG
>>264＝>>2だろ？ｗ
全体を見ないと、良スレかどうかなんてわからない。
0267デフォルトの名無しさんNGNG
>>266
「低脳」は余計だよね
0268デフォルトの名無しさんNGNG
Fuckableだとおかしいかね？

Penisでも、おかしいときはおかしいわけで、
例えば、女もPenisを実装できてしまう。
やっぱりFackableかね？
そんでStateパターンのif文で男女判別。
0269デフォルトの名無しさんNGNG
>女もPenisを実装できてしまう。
ﾜﾗﾀ

亜乱・毛異がないてるぞ。
0270デフォルトの名無しさんNGNG
>例えば、女もPenisを実装できてしまう。

ふたなり(；´Д`)ﾊｧﾊｧ
0271デフォルトの名無しさんNGNG
PenisableだかFuckableインターフェース
ManクラスやWomanクラス、HomoSexual(Okama)クラス、
両性具有クラス、奇形児クラス、性別不明クラス
をpackage化して

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

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

コンポジション集約でhas-aの関係で人間クラスに生殖器フィールドを
設ければいいんじゃないかと。　
0272デフォルトの名無しさんNGNG
Penisを男性器として解釈するならば、interface名としては相応しくない。
だが、PenisをPenis形状の物として解釈するならば、問題は無い。
Fuckという言葉は性交するという意味合いで使われる事が一般的、
よって意味合いから言えば女性にも実装可能。よって相応しくない。
なにがなんでもableを使いたい人は、Insertableとするのが吉。
Insertableであればバイブにも大根にも実装可能。
0273デフォルトの名無しさんNGNG
>>271
HomoSexualとOkamaは同列に扱ってほしくない……
0274デフォルトの名無しさんNGNG
>>271
だからね、Penisableとか言う意味不明な言葉を
当たり前のように使うのは止めなさいね。
0275デフォルトの名無しさんNGNG
>>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;
}
0276デフォルトの名無しさんNGNG
>>275
同性愛者の総称がHomoSexual
・Gayが男性同性愛者
・Lesbianが女性同性愛者
（※Queerは蔑称として使われることがあるらしい）

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

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

以上、設計にあたっての用語定義ね。間違ってたら訂正歓迎よん。
0277デフォルトの名無しさんNGNG
interfaceを引数にとるclassを設計してみると、色々と見えてくる
ことがあると思うんだけどな。
0278デフォルトの名無しさんNGNG
なんでもかんでもinterfaceにすりゃいいってもんじゃないだろ？
0279デフォルトの名無しさんNGNG
なんでもかんでもinterfaceにしろとも言ってないわけだが。
0280デフォルトの名無しさんNGNG
両刀使いってのもあるだろ？BiSexual?
0281デフォルトの名無しさんNGNG
>>278
>>277はもっと知る事ができるって言いたいのでは？
0282278NGNG
277に対する文句じゃなかったが、場所が悪かったな。
0283デフォルトの名無しさんNGNG
interfaceの使いすぎはソースコードの健康を損なう恐れがあります。
使いすぎには注意しましょう
0284デフォルトの名無しさんNGNG
今気づいたが引数にとるクラスじゃなくて引数にとるメソッドだな。

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

この２つを学んだときはなるほどなと思ったよ。SwingのBorderクラス
とか見ていると面白い。自分でカスタムボーダー作って勉強してみる
のがいいと思う。
0285デフォルトの名無しさんNGNG
ソースコードの健康状態を知るにはどうすればいいのですか？
0286デフォルトの名無しさんNGNG
変化する可能性のある概念って何？
例えばどんなの？
いい例があったらおせーて。
0287デフォルトの名無しさんNGNG
>>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から継承して作れば、追加アルゴリズムだけを作れば
すむことになる。
0288デフォルトの名無しさんNGNG
>>286
static finalでないインスタンスフィールドのことをいっているんだと思う。
0289デフォルトの名無しさんNGNG
>>287
なるほど。抽象化の基本ですね。
0290デフォルトの名無しさんNGNG
ガーベッジコレクションってプログラマーは意識するんですか？
0291デフォルトの名無しさんNGNG
しない
0292デフォルトの名無しさんNGNG
ゴミ集めは無意識のうちに実行されます
0293デフォルトの名無しさんNGNG
ガーベッジコレクションを意識するというより、参照が無くなったこと(不可到達っていうんだっけ？)は
意識します。ただ、うっかりわすれても大抵かってに開放されちゃって問題はでにくい。
自作のコレクションとか作った時に死んだ参照をのこしたりしなきゃ大抵大丈夫。
0294デフォルトの名無しさんNGNG

　　　　　　　　　　　＿∧＿∧
　　　　　　　　／￣　（　・∀・）⌒＼ ｶﾞｯ!!
　　　__　 　　/　　＿|　　　　 |　　　|
　　 ヽヽ 　 /　　/　 ＼　　　 |　　　|　　　　　　　　　　 ,,,,,,,iiiiillllll!!!!!!!lllllliiiii,,,,,,,
　　　 ＼＼|　　|＿＿__|　　　.|　　 |　　　　　　 　 　 .,llllﾞﾞﾞﾞﾞ　　　　　　　　ﾞﾞﾞﾞﾞlllll,
　　　　 ＼/　　＼　　　　　　 |　　 |　　　　　　 　 　 .|!!!!,,,,,,,,　　　　　　 ,,,,,,,,,!!!!|
　　　　　| ヽ＿「＼　　　　　　|　　 |､　　　　　　　　　|　 ﾞﾞﾞﾞ!!!!llllliiiiiiiiiilllll!!!!ﾞﾞﾞﾞ　.|　
　　　　　|　　　 ＼ ＼――､. |　　 | ヽ　　　　　　 　 .|　　　　　.ﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞ　　　　　|
　　　　　|　　　/　＼ "-､,　 ｀|　　|　　ヽ　　　　　　　|　　　　　　　　　　　 　　 |
　　＿／　　　/　　　 "-, "' （_　　ヽ　　ヽ　　　　　　.|　　　　　　　　　　　 　　 |
／　　　 ＿_ノ　　　　　　"'ｍ__｀＼ヽ_,,,, ヽ 　　　　　|　　　　　　　　　　　 　　 |
｀ー―￣　　　　　　　　　 ヽ､__｀/ー_,,,, ﾞﾞﾞﾞ!!!!!!!lllllllliii|　　　　　　　　　　　　 　 |
　　　　　　　　　　　　　　　　　　　　＼ﾞﾞﾞﾞﾞﾞﾞ!!!!!lllllllliiiii|　　　　　　　　　　　 　　 |
　　　　　　　　　　　　　　　　　　　　　 ＼　　　ヽ　 　|　　　　　　　　　　　 　　 |
　　　　　　　　　　　　　　　　　　　　　　　ヽ　 　＼　 |　　　　　　　　　　　　 　 |
　　　　　　　　　　　　　　　　　　　　　　　　| 　 　 ＼.|　　　　　　　　　　　　 　 |
　　　　　　　　　　　　　　　　　　　　　　　　｀ヽ､,,＿ノ|　　　　　　　　　　　　 　 |
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ﾞﾞ!!!,,,,,,,,　　　　　　 ,,,,,,,,,!!!ﾞﾞ
　　　　　　　　　　　　　　　　　　　　　　 　 　 　 　 　 　 ﾞﾞﾞﾞ!!!!llllliiiiiiiiiilllll!!!!ﾞﾞﾞﾞ
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　／.// ･ｌ|∵ ヽ＼　　←>>1

0295コピペ天職NGNG

　　　　　　　　　　　＿∧＿∧
　　　　　　　　／￣　（　・∀・）⌒＼ ｶﾞｯ!!
　　　__　 　　/　　＿|　　　　 |　　　|
　　 ヽヽ 　 /　　/　 ＼　　　 |　　　|　　　　　　　　　　 ,,,,,,,iiiiillllll!!!!!!!lllllliiiii,,,,,,,
　　　 ＼＼|　　|＿＿__|　　　.|　　 |　　　　　　 　 　 .,llllﾞﾞﾞﾞﾞ　　　　　　　　ﾞﾞﾞﾞﾞlllll,
　　　　 ＼/　　＼　　　　　　 |　　 |　　　　　　 　 　 .|!!!!,,,,,,,,　　　　　　 ,,,,,,,,,!!!!|
　　　　　| ヽ＿「＼　　　　　　|　　 |､　　　　　　　　　|　 ﾞﾞﾞﾞ!!!!llllliiiiiiiiiilllll!!!!ﾞﾞﾞﾞ　.|　
　　　　　|　　　 ＼ ＼――､. |　　 | ヽ　　　　　　 　 .|　　　　　.ﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞ　　　　　|
　　　　　|　　　/　＼ "-､,　 ｀|　　|　　ヽ　　　　　　　|　　　　　　　　　　　 　　 |
　　＿／　　　/　　　 "-, "' （_　　ヽ　　ヽ　　　　　　.|　　　　　　　　　　　 　　 |
／　　　 ＿_ノ　　　　　　"'ｍ__｀＼ヽ_,,,, ヽ 　　　　　|　　　　　　　　　　　 　　 |
｀ー―￣　　　　　　　　　 ヽ､__｀/ー_,,,, ﾞﾞﾞﾞ!!!!!!!lllllllliii|　　　　　　　　　　　　 　 |
　　　　　　　　　　　　　　　　　　　　＼ﾞﾞﾞﾞﾞﾞﾞ!!!!!lllllllliiiii|　　　　　　　　　　　 　　 |
　　　　　　　　　　　　　　　　　　　　　 ＼　　　ヽ　 　|　　　　　　　　　　　 　　 |
　　　　　　　　　　　　　　　　　　　　　　　ヽ　 　＼　 |　　　　　　　　　　　　 　 |
　　　　　　　　　　　　　　　　　　　　　　　　| 　 　 ＼.|　　　　　　　　　　　　 　 |
　　　　　　　　　　　　　　　　　　　　　　　　｀ヽ､,,＿ノ|　　　　　　　　　　　　 　 |
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ﾞﾞ!!!,,,,,,,,　　　　　　 ,,,,,,,,,!!!ﾞﾞ
　　　　　　　　　　　　　　　　　　　　　　 　 　 　 　 　 　 ﾞﾞﾞﾞ!!!!llllliiiiiiiiiilllll!!!!ﾞﾞﾞﾞ
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　／.// ･ｌ|∵ ヽ＼　　←>>294
0296デフォルトの名無しさんNGNG
（　´Д｀）/＜ 先生！！こんなのを見つけました。
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
0297デフォルトの名無しさんNGNG
そと寒いね。
0298デフォルトの名無しさんNGNG
評議に時間制限は無い
0299デフォルトの名無しさんNGNG
オブジェクト指向型言語が威力を発揮するのはある程度複雑な
関連をもった構造を構築するときである。
私はオブジェクト間の関連を図に書くとき紙と鉛筆を使う。
正確には鉛筆ではなく、ペンテルのGraphGear1000という
シャープペンシルで0.3mmの芯を使っている。1000円である。
このシャープペンシルは先端がシャキーンと格納できるので
体感的にも良質な筆記用具といえよう。
私の筆箱には「ペンテル入ってる」状態で消しゴムとグラフギアが集約されている。

私はドキュメントの中に手書きの関連図をスキャナで取り込み、保存する。
ある程度美的感覚が要求される場合にはパソコン上で図を描くが、
比較的時間を取られる作業であるので、ほとんどの場合、手書きである。
設計の作業にはある意味での「試行錯誤」が伴う。
そこで図面上で思考実験を行うわけである。
同じ機能を実現する方法は数多くあるが、良い設計は実装の進化に対する
許容度が高く、時間と共に良いものが出来てくる。
設計で失敗すると、時間と共に実装がボロボロになってくる。
0300プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
オブジェクト指向はインチキ。
真の生産性の向上は粒度の小さいサブルーチン型モジュール指向によって成される。
0301デフォルトの名無しさんNGNG
ふーん、あっそ。で？
0302デフォルトの名無しさんNGNG
サブルーチン型モジュール指向はインチキ。
真の生産性の向上は可読度の小さいextern宣言外部変数指向によって成される。

0303デフォルトの名無しさんNGNG
>>299
UML使え。
クラス図くらいツールで描け。
0304デフォルトの名無しさんNGNG
馬鹿だな。ツールは清書用だろ？
ツールなんて使ってたら、思考の妨げになる。
コピーの裏紙に書きなぐるのが基本だろ。
0305デフォルトの名無しさんNGNG
ひとそれぞれ、最適な方法は人によって変わるということも
おまえたちは理解しないのですか？
0306デフォルトの名無しさんNGNG
しかし普通の人は紙とペンで勉強し続けてきたはずだ。
そんな人が急に禿げたらどうなると思う？結果は明白だ。
030750NGNG
紙をペンで黒く塗って、
それを頭に。。
0308デフォルトの名無しさんNGNG
紙に書くって
なんかいい感じだね。
0309Java太郎 ◆DMVtSSFzcg NGNG
オラ！オラ！オラ！オラ！！
0310デフォルトの名無しさんNGNG
最高ですか？
0311デフォルトの名無しさんNGNG
>>305
部品は黙ってろ
0312デフォルトの名無しさんNGNG
これからはウンコ指向だね。オブジェクトウンコ指向言語Cウンコ、Javaウンコ
C#ウンコ...etc.
0313デフォルトの名無しさんNGNG
だんだん真っ赤に燃えるんだ
0314デフォルトの名無しさんNGNG
これが本当のヤケクソ
0315デフォルトの名無しさんNGNG
コーダとはなにか？
0316デフォルトの名無しさんNGNG
ソフトウェア開発を設計工程と製造工程とを分けるとすれば、make 実行させている十数秒が製造工程で、それ以外は設計工程である。
0317デフォルトの名無しさんNGNG
はて？
0318デフォルトの名無しさんNGNG
●　　　これがオブジェクトだ

↓あとよろしく
0319デフォルトの名無しさんNGNG
>>315
ヨーダなら知ってる
0320デフォルトの名無しさんNGNG
★男はココを見るべし★女と金とサンプルムービー★
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
http://www.pink-angel.jp/betu/linkvp2/linkvp.html
0321デフォルトの名無しさんNGNG
★　これがメソッドだ
0322デフォルトの名無しさんNGNG
>>318
うんこみたい
0323デフォルトの名無しさんNGNG
発言がヤバイ
0324デフォルトの名無しさんNGNG
こんなスレがだらだら続いてしまう理由はいったい何でしょうか。
0325デフォルトの名無しさんNGNG
自分もオブジェクト指向の意味が
よく理解できてないんで質問したいんですが、
要するにオブジェクト指向ってのは同じ結果を生み出す
プログラムのソースをどれだけ簡略化できるかってことなのですか？
0326デフォルトの名無しさんNGNG
長い目で見て。
0327デフォルトの名無しさんNGNG
>>324
お前みたいな奴が書き込むからです。
0328デフォルトの名無しさんNGNG
>325
オレの中級レベルの中途半端な知識の範囲で答えると。。。
それは違うと思うｗ
0329デフォルトの名無しさんNGNG
>>325
拡張性、移植性、再利用性、堅牢性、コードの可読性を高めるためにもある。

ソースコードを修正せずにクラスを一つ追加するだけで拡張できる
手法と言うものがある、これができるのはオブジェクト指向以外にほかならない。
0330デフォルトの名無しさんNGNG
オブジェクト指向の利点は、プログラムをオブジェクトと呼ばれる
ブロックに分割して開発できることだ。
だから、分担しての多人数の開発もやりやすいし、改良する場合も
必要なオブジェクトだけ変更すれば良い。

もちろん、オブジェクト指向を使わなくてもルーチン毎、ソース毎
の分割はできるわけだが、オブジェクト指向を使えばもっと見通しが
良くなり、データを不正なアクセスから隠蔽できたりもする。
0331デフォルトの名無しさんNGNG
thisが曲者ですよね
0332デフォルトの名無しさんNGNG
>>329
という事はＪａｖａには明るい未来があると？
0333デフォルトの名無しさんNGNG
>325
ぶっちゃけて言っちゃうと。。。。
何かプログラムを作ろうとする時に
｢こういうクラスが必要だろう」って感じでクラスを設計していくと
全体の構想が浮かびやすいんだな。

で、細かいメリットは>329の言う通りなんだけど。
0334デフォルトの名無しさんNGNG
最近人生がおもしろくない。
そう思いのあなた！
http://www5e.biglobe.ne.jp/~rgxt5nl/index.htmlのページをお試しください！
100種類のタダで遊べるゲームに、
おもしろいパクリ物を集めたコーナーや、
管理人がすぐに素材にしてくれる素材掲示板
ほかにも、2ちゃん掲示板もありますよ！
自作フラッシュもあります。
とにかくいろんなコンテンツが豊富です！
常連になってくれる人大募集！
0335デフォルトの名無しさんNGNG
>>332
ブロックの組み合わせでプログラムを作るなら、より多くの強力な
ブロックが手に入りやすい環境の方が開発の手間が省けるわけで、
Javaはその辺、微妙というか中途半端というか。
0336デフォルトの名無しさんNGNG
>>332
なんでJavaが？
0337デフォルトの名無しさんNGNG
>>330
オブジェクトというブロック？
クラスじゃあないん？
0338デフォルトの名無しさんNGNG
>>325
違う。

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

他国で戦争が起こった為に、万一を考えて某レジャー施設の手荷物検査を
する何処かの国みたいなものだな。
0339デフォルトの名無しさんNGNG
>>338
なぜ安全性＆完全性が高まるのかわかりません
0340デフォルトの名無しさんNGNG
同じ結果を生み出すプログラムを、いかに単独で完結した部品にできるか。
0341デフォルトの名無しさんNGNG
構造化手法では関数同士の名前のバッティング、
関数の依存関係の影響
(依存される方を修正すると依存されるほうも修正しなければならないという地獄)
を最小限に抑えることができない。

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

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

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

そこでオブジェクト指向が生まれた。
0342デフォルトの名無しさんNGNG
それは名前空間と依存解決の説明であって、オブジェクト指向違う。
0343デフォルトの名無しさんNGNG
>>341
>そこでオブジェクト指向が生まれた。

オブジェクト指向が生まれたのはそういう理由じゃないんけど。
元々はSmalltalkのメッセージパッシングという手法
0344デフォルトの名無しさんNGNG
「在る物を、在るがままに」
0345デフォルトの名無しさんNGNG
オブジェクトとは、いくつかの状態を持ち、メッセージを受け付ける何かである。しかしいまではその定義は、神話の中にしか無い。
まず愚かにも実装効率を優先した者たちにより、オブジェクトはクラスとインスタンスとに分断された。
次にメッセージの送出は自身のポインタを渡す特殊な関数呼び出し、すなわちメソッド呼び出しに変わり、オブジェクト指向は汚されたのである。
0346デフォルトの名無しさんNGNG
>>345
そなの？メッセージを送るときって、
"単にメッセージを送る"んじゃなくて
"なにかして欲しいから、その意思表示としてメッセージを送る"んでしょ？
ってゆうことは、
"メッセージ送出とメソッド呼び出しは等価"なんじゃない？

オブジェクトがクラスとインスタンスに分断されていないことの
利点が思い付かないし。単純に想像してみても、
"その物が、何であるか(クラス)"と言うことと、
"その物が、そこにある(インスタンス)"と言うことは、全く別のことであると思うし、
つまり
"オブジェクトがクラスとインスタンスに分けられたことにより、オブジェクト指向はより美しくなった"....
とすら言えると思うのだけど。
0347デフォルトの名無しさんNGNG
>>342
そういば漏れの先輩の担当したコード、
どのクラスのメンバ関数みても static だったなぁ。
その先輩、今は違うプロジェクトに移ってC言語でコード書いてるみたいなんだけど、
「C++はいいなぁ、名前のバッティングがないもんな」とかゆってた。
0348デフォルトの名無しさんNGNG
>>346
彼は意味わからずに書いてんだから、いちいち相手しなくていいよ。
0349デフォルトの名無しさんNGNG
さっきから上げてるやつは同一人物か
0350デフォルトの名無しさんNGNG
>>346
>利点が思い付かないし。

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

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

それならば、（ちゃんと行えば）誰もが同じ結果を示せる。
話しはそれからだ。
0351デフォルトの名無しさんNGNG
おー中山！！オッスオッス！！
0352デフォルトの名無しさんNGNG
>>350
ふーん、自分の言葉ではインスタンスとクラスを分離しないことの利点を語れないんだ。
ま、そんな奴と話してもしょうがないね。
0353デフォルトの名無しさんNGNG
なるほど。なんだか人によってオブジェクト指向の捉え方が違うみたいですね。
とりあえず自分も教えて君ではいけないと思ってe-wordで調べてみました。

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

要するにユーザーにも開発者にも易しいプログラムの作り方ってことですか？
0354353NGNG
353は325です。ネーム入れるの忘れてました。
0355デフォルトの名無しさんNGNG
>>353
長いので全然読んでないけど、

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

と書いておきながら、

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

で締めるのはどうかと。
0356デフォルトの名無しさんNGNG
>>353
大体正しいけど、「ユーザー」ってのは「ユーザープログラマ」な。
0357デフォルトの名無しさんNGNG
>>353
なんか、「要するに」って言葉の使い方が
技術に明るくない管理職っぽい感じ。
0358デフォルトの名無しさんNGNG
>>353
分かったなら、ちょっとここで
「オブジェクト指向」と「構造化手法」の違いを
まとめてみれ。
0359353NGNG
>>355
そうですねｗ
でも
>個々の操作対象に対して固有の操作方法を設定することで、その内部動作の詳細を覆い隠し、利用しやすくしようとする考え方と言える。この考え方を応用したプログラミング技法が、オブジェクト指向プログラミング(OOP)である。
ってあるから、ユーザーが操作しやすいようにするってことですよね？
ということは、パソコンで例えると
ユーザーはアイコンをダブルクリックするだけでファイルを開けるけど、
開発者はその裏でfopenだとか色々練らなければいけない。
となりますよね？(多分)
こういう仕組みのことをオブジェクト指向というのでしょうか？
0360デフォルトの名無しさんNGNG
本に載ってる例題とかって基本的なことばかりだから
オブジェクト指向って素晴らしい！とは思えないなぁ・・・
0361デフォルトの名無しさんNGNG
>>359
それがほんとに例え話なら、まぁ正しい理解だ。
0362353NGNG
>>358
えっと、オブジェクト指向ってのは、さっきも書いたようにユーザー(プログラマ)が、
実際パソコンの中でどんなコトが起こっているのか意識しないでも使える手法？
構造化手法ってのは、ユーザー(プログラマ)がいちいちパソコンに直接指令を与えて
情報を引き出す手法？
全くのカンですｗ
0363デフォルトの名無しさんNGNG
>>360
デザインパターンの本とか読むといい。
ソースコードから、無様な部分がだいぶ減る。
( プログラミング技法としてのオブジェクト指向の
  能力と使い方が理解できるはずだ。)
0364デフォルトの名無しさんNGNG
>>359
>開発者はその裏でfopenだとか色々練らなければいけない。
それをやらなくてよい言語が作られたら、
それがＯＯＰか非ＯＯＰかに関係なく、
俺は今すぐその環境に移行するのだが・・・
0365デフォルトの名無しさんNGNG
>>362
ちがうぅ～
例えば、ファイルを開く関数 fopen() をコールした時、パソコン内部で
何がおこってるのかを知らなくても、プログラマはプログラムを書けるでしょ？
でも、fopen() は、オブジェクト指向的な関数じゃない。
0366362NGNG
>>365
そう言われてみればそうですねｗ
じゃあ、ライブラリのstdio.h(自分はＣですので)の中の
fopen()関数を定義した人が、本当のオブジェクト指向における開発者だと
言えるのでしょうか？
関数によってオブジェクト指向であるとかもあるんですか？
Ｃを勉強してる限りだとオブジェクト指向って言葉は耳にしません。
前にＣ＋＋がオブジェクト指向だとか聞いたような聞かなかったような・・・。
0367デフォルトの名無しさんNGNG
クラスツリーを変更したくなったとき困るとか、
複数クラスにまたがるようなアクセスが面倒くさい時とかいうのありますよね？
どうするのそこんとこ。
0368デフォルトの名無しさんNGNG
>>366
fopen()とか、stdio.hで定義されてる全てのものは、
オブジェクト指向的ではありません。というか、
C言語はオブジェクト指向をサポートしません。

オブジェクト指向はメッセージの受け渡しによって
記述するプログラミングパラダイムです。(続く)
0369デフォルトの名無しさんNGNG
>>367
リファクタリングだ。
0370368NGNG
続き
例えばファイル読み込みについて書くと、
非オブジェクト指向だと、
1. "ファイルを開く関数"を呼ぶ
2. "ファイルからデータを読み込む関数"を呼ぶ
3. "ファイルを閉じる関数"を呼ぶ

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

非オブジェクト指向のときは、どの関数の名前にも"ファイルを～"と付いてる。
オブジェクト指向のときは、どの操作も"そのオブジェクトにメッセージを送る"となってる。
0371367NGNG
あと、modern c++ designみたいなのって、自分じゃ作る気にならなくない？
また、使おうにもコンパイラがうまく対応してくれなくて面倒ってのない？
どうするのそこんとこ。
0372デフォルトの名無しさんNGNG
>>363
ありがとう、今度読んでみます
0373デフォルトの名無しさんNGNG
>>362
次は「オブジェクト指向」と「カプセル化」の
違いをまとめてみよう。

（一般には「カプセル化」と「オブジェクト指向」は
包含関係ではあるが同値関係ではないと言われているので・・・）
0374デフォルトの名無しさんNGNG
>>370
非オブジェクト指向とオブジェクト指向の違いはなんとなくわかるけど
それで？ってカンジになっちゃいます(・_・、) グスン
0375デフォルトの名無しさんNGNG
>>370
じゃあ、Ｃでfopen()を使っていても、それを
「"FILE *" に "fopen" メッセージを送る」
と呼びさえすれば、それでオブジェクト指向といえるのですか？（ｗ
0376デフォルトの名無しさんNGNG
プログラミング言語っぽく書くとこんな感じ
File f("filename"); // "filename" ファイルに対応するオブジェクトを作る。
f <- open; // そのファイルオブジェクトに"開く"メッセージを送る。
buf = f <- read; // ファイルオブジェクトに"データを読み込む"メッセージを送る(で、そのデータをバッファに置く)
f <- close; // ファイルオブジェクトに、"閉じる"メッセージを送る。
0377367NGNG
カプセル化って
#define private public
ってやられたとき困らない？
どうすんのそこんとこ。

やるやつがアホだし、class宣言のトップにprivateなやつならべりゃいいけどさ。
0378362NGNG
>>370
なるほど。「呼ぶ」と言う動作さえも非オブジェクト指向となるのですか。
自分はＣしか出来ないので、オブジェクト指向の言語を勉強するようになったら
より理解を深められると思います。
「オブジェクト指向」と「カプセル化」ですか？
全く分かりませんが、「カプセル化」ってのはモジュラプログラミングのことでしょうか？
0379デフォルトの名無しさんNGNG
>>378
なんで異なる言葉で呼ばれる概念を = で結ぼうとするのだろう。
0380デフォルトの名無しさんNGNG
>>377
#ifdef private
#undef private
#endif
か、
#ifdef private
#error ヴォケ！死ね！
#endif
0381デフォルトの名無しさんNGNG
>>370

Javaの本では普通に「メソッドを呼び出す」という言い回しを
使っているから、そういうのは誤解を招くぞ。
0382デフォルトの名無しさんNGNG
っていうか、メソッド呼び出しやめて、
すべてのインスタンスにメッセージキューを持たせよう。
0383デフォルトの名無しさんNGNG
>380
ソースコードを直接いじられたとき困らない？
どうすんのそこんとこ。
0384デフォルトの名無しさんNGNG
>>381
"メッセージを送ると、結果としてメソッドが呼ばれる"
ってふうには説明されていないのかなぁ。だとしたら鬱だ。
0385デフォルトの名無しさんNGNG
>>382
全部のメソッドがスレッド(プロセス？)を異にする？
0386362NGNG
>>379
ですよね。一緒のはずありませんよね。
ちょっとぐぐって調べてみます。
0387デフォルトの名無しさんNGNG
>>383
なんで困るの？
0388デフォルトの名無しさんNGNG
Java厨ｷﾀ━━━━━（ﾟ∀ﾟ）━━━━━!!!!!
0389デフォルトの名無しさんNGNG
和ジオ/AnimeComic-Name/7676/
0390デフォルトの名無しさんNGNG
>>380
ﾜﾗﾀ
こういう心温まるコードを見ると感動すら覚える。
0391デフォルトの名無しさんNGNG
"fopen"をメッセージを送ると捉えることもできる。
その際、メッセージを送る先は FILE** ではなくシステム。
0392デフォルトの名無しさんNGNG
>>384
C++やJavaの構文では、「送る」というより、
まさに「呼び出す」という雰囲気が当てはまるから、
言い回しをそれほど意識する必要はない。
0393362NGNG
調べてみました。
が、
これってそのまんまオブジェクト指向と同じじゃないですか？
違いがわかりません。
0394デフォルトの名無しさんNGNG
>>393
マメだねぇ。
カプセル化って言うのは「機能とデータをひとまとめにする」ってこと。
オブジェクト指向って言うのは「オブジェクト間のメッセージのやり取りでコードを書く」ってこと。

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

対立する概念じゃなくて、独立してるけど関連性の深い概念、だね。
0395OOﾓﾅｰNGNG
ったく。
おまいら、オブジェクト指向って何だか分かってんの？
これ以上、「OO=訳分かんない無気味なもの」という状態を
放置したくないので、マジレスする。

Objectを手もとの英和辞典で引いてみろ。
おそらく、
Object:モノ、対象、目的
などの意味が出ているはずだ。
日本の馬鹿な技術者がObject=モノと考えてしまったために、
OO技術の浸透はかなり遅れてしまったわけだ。
いまでもドキュソ入門書では、「モノ(Object)」などという
書き方をしているものが多いはず。
モノ？ふざけるな。そんな不明な定義でオブジェクト指向が
理解できるはずもない。「モノを指向する」とか言われて、
おまいらが混乱するもの無理はない。
だが、考えてみろ。Data Orientedは、扱うデータを中心に
分析設計を行うことである。Object Orientedとはなんぞや。
(続く)
0396OOﾓﾅｰNGNG
あえて批判を恐れずにいえば、オブジェクトのより理解しやすい
訳は、「対象」である。ソフトウェアに置ける対象とは、
システム化を行う対象のことである。
ゆえに、Object Orientedは「システム化対象指向」という
訳の方が適切である。つまり、システム化対象を中心に考える
ということである。
たとえば、いままで経理担当者が社員から領収書を受け取って、
帳簿に交際費を計算して記載し、帳尻を合わせた後、社員に
お金を支給していたところをシステム化したいと考えた場合、
オブジェクト指向ではまず、システム化対象を中心に考えるので、
「経理担当者」「社員」「領収書」「帳簿」「交際費」「お金」
など、現実の運用を行う上で、何らかの役割を担っている概念を
ピックアップすることから問題を考えていくのだ。
(気が向いたら続く)
0397デフォルトの名無しさんNGNG
>>395,396

そんな教科書をコピペしたような説明じゃ分からないから、
こんなスレがたつんだろ。
0398デフォルトの名無しさんNGNG
>>396
"Object"を”システム化対象”ととらえ直したのに、
システム化対象の例として"「経理担当者」「社員」"など、
"モノ"っぽいものばかり挙げたのでは、何のために
"モノ"という訳語を拒否したのか解りませぬ。
0399デフォルトの名無しさんNGNG
>>394
>オブジェクト指向って言うのは「オブジェクト間のメッセージのやり取りでコードを書く」ってこと。

goto >>375
0400デフォルトの名無しさんNGNG
>>396
"システム化対象"と訳したのでは、
もっと抽象的なオブジェクトを扱う段階に進む際の妨げとなるような気がします。
オブジェクト指向の本質とは関係ありませんが、
しかしOOPLを用いてプログラミングする際、
デザインパターンなどは必須な訳です。
その際、Object = システム化対象 という認識では不足です。
たとえば Mediater は、システム化される以前に存在しているシステム化対象ではありません。
旧来の Object = モノ と言う認識の方が優れていると思います。
0401362NGNG
>>394
そうなのですか。
なんとなく頭では理解できました。
でも、やっぱり実践経験がないのにどーのこーの言うのは良くないですね。
近いうちにオブジェクト指向の言語の勉強を始めようと思います。
それで、是非みなさんにオブジェクト指向を勉強するならこれ！ってな言語を教えて欲しいのですが・・・。
0402デフォルトの名無しさんNGNG
>>399

>>391
0403デフォルトの名無しさんNGNG
データ＋メソッド
0404デフォルトの名無しさんNGNG
>>401
Javaでもやっとけば？
0405401NGNG
Javaですか。じゃあ、ちょっとやってみようと思います。
自分はＣしか知らないのですが、そこから入ると考えても
やっぱりJavaが最適でしょうか？
0406デフォルトの名無しさんNGNG
>>402
∴Ｃ言語⊂オブジェクト指向言語

Q.E.D.

何か？
0407デフォルトの名無しさんNGNG
>>396
すんません、まず >>396 のいう「システム」とは
何かが分からないのですが。
0408デフォルトの名無しさんNGNG
情報＋手続き
0409デフォルトの名無しさんNGNG
>>406
ちょっと話を逸らすけど、
∴と⊂ってなんの記号ですの？

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

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

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

また、オブジェクト(システム化対象？)を軸としてモジュール分割したCのソースコードでは、
"他のモジュールの関数を呼び出す"ことを"他のモジュールにメッセージを送る"
と捉えた方が、理解しやすいかもしれない。
そのような場合であっても、それはそのコードがオブジェクト指向なのであって、
C言語自体がオブジェクト指向な訳ではない。
0412デフォルトの名無しさんNGNG
>>410
>OOの基本的な出発点は、「現実世界の事象を、できるだけ
>忠実にソフトウェア上にマッピングする」ってことだ。
それはＯＯの出発点ではなくて、システム構築の
出発点ではないかと・・・
0413デフォルトの名無しさんNGNG
>>410
そうか、初学者には「システム化対象」の方が分かりやすいのかもねぇ。
んでなれた頃に、システム化対象だけじゃなく、
もっと抽象的なモノもオブジェクトとして扱われることを教えていく、と。

企業とかで研修する際や学生向けにはいいかもね。
0414デフォルトの名無しさんNGNG
>>411
さて、そこらで一つ >>325 に

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

を教えてはくれないだろうか？
0415デフォルトの名無しさんNGNG
おまえら難しく考えすぎじゃねーの？

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

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

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

オブジェクト指向が理解したければ、自分自身で何度も設計を繰り返すのだ。
そうしてやっとオブジェクト指向の感覚が身についていく。
0416デフォルトの名無しさんNGNG
>>414

    な ん じ ゃ そ り ゃ 。
0417デフォルトの名無しさんNGNG
オブジェクトとは森羅万象なのだ。
Java/C#でいうObjectクラスに該当する。
全てのクラスのスーパークラスは森羅万象を構成するもの、
すなわちオブジェクトである。
0418デフォルトの名無しさんNGNG
>>409

∴ = 蕎麦畑 = 蕎麦 = 粋

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

要するに、

「(余計な機能をたくさん背負い込んだ)"Ｃ＋＋" は 粋な "Ｃ" に憧れている」
0419デフォルトの名無しさんNGNG
>>417
んじゃ、俺もObject?
0420デフォルトの名無しさんNGNG
>>415
>答えは実際に何度もこけて、自分で「自転車に乗る」という感覚を身をもって知るしかない。

言いたい事は分かった。

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

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

って指摘されたら萎えるだろ？
0421OOﾓﾅｰNGNG
構造化とオブジェクト指向について結合度の観点から考えてみるよ。

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

OOは、結合殿観点からいえば、総共通モジュール化を
狙ったものととらえることができる。時系列に依存する
部分をできるだけ内側に綴じ込め、いつでもどこからでも
処理を呼び出せるようにして、結合度を低く押さえるわけだ。
つまり、OOでは構造化のようなモジュール分割ではなく、
小さなモジュールの見通しの良さを生かしつつ、逆に
オブジェクトの内部に、そのオブジェクトをうまく使うための
初期化処理（これは通常コンストラクタが担う）
終了処理（デストラクタなどが担う）
を内包させ、初期化後は自由に使えるようにしたわけだ。
発想が逆なのがおもしろいね。
0422デフォルトの名無しさんNGNG
>>420
あーそのとおりだね。　すいませぬ。
0423デフォルトの名無しさんNGNG
>421
要するにトップダウンではなく
ボトムアップで設計すれば
「オブジェクト指向」になる、ってこと？
0424デフォルトの名無しさんNGNG
>>423
ならねぇ。
なんでトップダウンやボトムアップって言葉が出て来たんだ？
0425デフォルトの名無しさんNGNG
>>419
そーいうことになる。
この世に存在するもの全てがオブジェクト、地球も宇宙も生も死もすべてオブジェクト。

オブジェクト指向と似たような概念はプラトン哲学ですでに語られていたらしい。
0426OOﾓﾅｰNGNG
>>423
結合度の問題とはちょっとずれるけど、そういう側面はあるよ。
ボトムアップってのは、おそらくシステムの構成要素を
まず事前に洗い出して、それを組み合わせていくってことだろ。
こう書くと、何か難しいことのようだが、実はOOじゃなくても
システムの構成要素の洗い出しってのは、要件分析の初期段階で
やっているはずなんだよね。
構造化の場合は、その分析の結果、このシステムは
○○システムであると大きく捉えて、構造化手法によって
それを再構成しながら実現方式を考えていくけど、
OOの場合は、洗い出した個々の構成要素をできるだけ生かしつつ、
設計・実装まで持っていこうとする。
0427OOﾓﾅｰNGNG
>>425
プラトンのイデア論だろ。
クラスとインスタンスの関係を説明するには面白いが、
個人的には、そういうテツガク的な側面を強調する限り、
OOの理解は進まないだろうなと思う。
0428デフォルトの名無しさんNGNG
>>427
(　´∀｀)ｵﾏｴﾓﾅｰ
0429デフォルトの名無しさんNGNG
>>427
いや、あれは面白かった。
不変の「永遠の型」、イデアがクラスで、実体がオブジェクトやインスタンス
これは解りやすかった。

あの、小説「ソフィーの世界」にでてくる「ソフィーがいる」世界がクラスで
「ソフィーを小説の登場人物としてその小説を読んでいる側のヒルデと少佐の世界」
が現実世界でありオブジェクトやインスタンスという表現は面白かった。
0430デフォルトの名無しさんNGNG
恒例のOO派対非OO派のアプリ製作対決して
0431Java太郎 ◆DMVtSSFzcg NGNG
やい！やい！やい！やい！
テメェら！！
0432デフォルトの名無しさんNGNG
やいのやいの言うんじゃねぇよ
0433デフォルトの名無しさんNGNG
>>430
そんなもんどんなアプリ作るかで対決がどうこういってられる問題でなくなる。
0434デフォルトの名無しさんNGNG
>>430
よーし、それじゃ
「広島県庁の給与計算システム」でどうよ？
0435デフォルトの名無しさんNGNG
>>434
却下
0436デフォルトの名無しさんNGNG
んじゃぁ、「PRePで動くBeOS用のGeForce2のドライバ」でどう？
0437デフォルトの名無しさんNGNG
>>436
却下繚乱
0438Java太郎 ◆DMVtSSFzcg NGNG
お前ら、夢を作れ！！
0439デフォルトの名無しさんNGNG
クラスとインスタンスが分断されたことで、オブジェクトは柔軟性を失った。
かつて神話の時代、フィールドやメソッドは、実行時に追加や変更、削除が可能であった。
フィールドにnullなどを代入せずとも、フィールドそのものを「無」として扱えたのだ。
0440デフォルトの名無しさんNGNG
>434
出席簿に○付けて、学校に行った事にしてくれるプログラム。
0441デフォルトの名無しさんNGNG
あ、リンク間違った。
>>430ね
0442デフォルトの名無しさんNGNG
>>439
単なるMapじゃないの、それ。
0443デフォルトの名無しさんNGNG
>439
つーか、フィールドって何？
スロットの事？
0444デフォルトの名無しさんNGNG
最新の音楽情報満載。音楽ファン必見のサイト　
アンケートに答えると、もれなく音楽ギフト券！！
http://camellia16.fc2web.com/ongakudb.html
0445デフォルトの名無しさんNGNG
>>439
つーかJavaScriptでも使ってれば？
いやマジで
http://www.tokumaru.org/JavaScript/
0446デフォルトの名無しさんNGNG
キチガイが居るようですが、、
0447デフォルトの名無しさんNGNG
>>423
ボトムアップはXP (eXtreme Programming)じゃないか？
0448デフォルトの名無しさんNGNG
プログラムパラダイムとソフトウェア工学を混乱しているヤツが
とても多いようだ。
0449デフォルトの名無しさんNGNG
>>447
設計はトップダウンでしょ。
コーディングはユニットテストの助けがあるから好きにやれって感じ。
0450デフォルトの名無しさんNGNG
いや、こうか。
s/設計/分析/
s/コーディング/設計-コーディング/
0451Java太郎 ◆DMVtSSFzcg NGNG
>>448
解説願います
0452デフォルトの名無しさんNGNG
>>448
是非
0453OOﾓﾅｰNGNG
>>448はおそらく、OOは新しいパラダイムの提示であり、
ソフトウェア工学の範疇では捉えられないといいたいのでは
ないかと思う。
たとえるなら、天動説を信じてる香具師に地動説を示しても、
すぐには理解できないように、OOは新しい世界観の提示であり、
OO以前に固執する限り超えがたい壁があるといいたいのだろう。
いわゆるパラダイムシフトが必要だと。

よく聞く話だし、多少は考える視点を変える必要があるとも
思うが、俺は別な考え方を持っているよ。
OOは、ソフトウェア工学の成果を踏まえた延長上にある
技術だと思っている。その意味でこれまでのソフトウェア工学の
知識はOOを理解する上で、助けになることが多いと思う。
OOは決して特別なものじゃないし、ソフトウェア工学の
側面からOOを利点や欠点を捉えていくことも可能だと
思っている。
だから、いたずらに哲学的なベールをかぶせたり、
必要以上の壁を作るのにはあまり賛成したくない。
0454デフォルトの名無しさんNGNG
>>114
>implementsはextendsの代わりに使うものであり
Interfaceに対してプログラミングするんだろうがよ。
まぁ、やり方はいろいろあるが。
てめぇは言語仕様から引用してるだけ。実装したことある？
0455デフォルトの名無しさんNGNG
>>454
キツイね・・・
0456デフォルトの名無しさんNGNG
もうこんな時間かよ！！
0457448NGNG
おはよ。
トップダウンであろうがボトムアップであろうが、
どんな分析過程を経たとしても、
設計段階でOOを用いるのか、構造かプログラミング用いるのは任意。
あまつさえXPなんて言葉が出て来たしな。

0458デフォルトの名無しさんNGNG
任意ってあーた、分析→設計の連続性がOOの特徴だよ。
0459デフォルトの名無しさんNGNG
で？その時はボトムアップでアプローチしなきゃなんないわけ？


つか、分析・設計の連続なんて構造化プログラミングでも同じだろ？
何で問題解決プロセスとプログラミング技法をバインドしたがるんだよ。
藻まえらの脳をストラテジーパターンを使ってリファクタリングしろよと(w
0460デフォルトの名無しさんNGNG
OO と大雑把にいうと、 OOA や OOD も含まれるんでないかい。
0461459NGNG
>>460
で？
オブジェクト指向分析は、ボトムアップでアプローチしなきゃならないわけ？
0462デフォルトの名無しさんNGNG
いんや。
OO のプロセス技法なんて腐るほどあるし、
トップダウンでもボトムアップでもサンドイッチでも、
採用するプロセスや工程に応じてどれかになるだろうね。
このトップダウンとかって、プロセスがそう捉えられるってだけで、
そうしなければならないってものじゃないし。
0463459NGNG
ということだ。
>>OOﾓﾅｰ氏など
0464デフォルトの名無しさんNGNG
「オブジェクト指向」とは、あくまで考え方。
その考え方に基づいたプログラム手法がオブジェクト指向プログラミングであり
同様な設計手法がオブジェクト指向設計。同様に分析手法が（略

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

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

これが基本。
0465464NGNG
オブジェクトを単位に考えるにあたり、一つ一つを厳密に細部まで考えるのは人間の頭には無理。
だから、ある程度大雑把に考える。

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

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

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

これがクラスとインスタンスの関係。
0466464NGNG
「犬」「猫」に加えて「鼠」「牛」「虎」「兎」「馬」「羊」「猿」「猪」など
沢山、考えなければならない対象が増えてくる。

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

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

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

一般的にオブジェクト指向と言うのは前者。
0467デフォルトの名無しさんNGNG
だからさー
そんな教科書みたいな説明したって分かるわけないじゃん。。。。

一言
｢クラス使ってプログラミングすると楽なんだぞー」
でいいじゃん。
｢何で便利なの？」って聞かれたら。。。。
｢関数が100個あるよりクラスが10個ある方が分かりやすいでしょ？」
って答える。
一番大事なのはクラスの独立性であって
多態性とか継承とかは付録みたいなもんだから。。。
それが初心者には分かりやすいと思うけどね。
0468デフォルトの名無しさんNGNG
何の疑問ももたずにオブジェクト指向を身につけた人が
人に「オブジェクト指向とは」っていうのを教えると、決まって例え話を
持ち出すのは何故なんだろうか。

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

個人的には、ある特定のシステム（経理システムとか、在庫管理システムとか）について、
構造化手法とオブジェクト指向でそれぞれ作って、大きく異なる点と、ほとんど変わらない点を
図やコードで対比させて、異なる理由・変わらない理由を説明もらえると分かりやすいかも、と思う。
0469デフォルトの名無しさんNGNG
>>467
>｢関数が100個あるよりクラスが10個ある方が分かりやすいでしょ？」
何もわかって無い奴にそんな説明だけだと
「10個のクラスに10個のstaticメソッドをを実装しただけじゃん。
メソッド名の頭に暮らす名をつければ解決することじゃん。」
といわれるオチ
0470デフォルトの名無しさんNGNG
つーか、どう見ても467は分かって無いだろ

＞｢クラス使ってプログラミングすると楽なんだぞー」
＞｢関数が100個あるよりクラスが10個ある方が分かりやすいでしょ？」
＞一番大事なのはクラスの独立性であって
＞多態性とか継承とかは付録みたいなもんだから。。。
(ﾟДﾟ)ﾊｧ?
0471デフォルトの名無しさんNGNG
467の語るオブジェクト指向の利点は余りに小手先過ぎる。

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


比較的簡単で、非OOの人にも威力が分かりやすい、
ステートパターンのサンプルなど見せるといいかも。
0472464NGNG
えーとねぇ、あくまで俺が（途中まで）した説明は「オブジェクト指向」であり、
OOPでもOOAでもOODでもないし、ましてやOO言語でもないのよ。
基本の考えを理解しないうちに、設計なんかしたってダメダメなのができるのがオチ。

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

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

あと、OOに対する考えは世間では「難しい」という根本的な誤解があると思うんだけど
全然、難しくない。むしろ簡単。自然な人間の思考パターンなわけ。
だから、大上段に構える必要は全然ない。
0473デフォルトの名無しさんNGNG
哺乳類クラスから犬猫サル人クラスに～っていうのは典型的な
悪いOOの説明だよな。実際、そういう設計思想で作ると無駄だけ
増えてすっきりした実装にはならない。

つまるところ、より抽象的な機能を上位クラスに、より具象的な
機能を下位クラスに、汎用化できる部分はabstract classとか
interfaceを利用して、より少ないコード記述量で使いまわしが
きくように作ることだと思うんだが。
0474デフォルトの名無しさんNGNG
　オブジェクト指向というのは世界観でしょう。元々潜在的にオブジェクト指向という世界観を持って
ないとＪＡＶＡやってもオブジェクト指向にならないのでは？先にオブジェクト指向という世界観が
ありであってＪＡＶＡがありでないでしょう。ＪＡＶＡはオブジェクト指向という世界観に気づくきっかけ
を作ることはできても元々オブジェクト指向という世界観を持ってない人には理解不可能と思うが。

　結論、ＪＡＶＡを使うにはオブジェクト指向という世界観が事前に必要ということ？
オブジェクト指向という世界観が無い人はプログラマーに向かない人？
0475464NGNG
466までがis-a関係の説明。
で、今回がpart-of関係を説明してみる。

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

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

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

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

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

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

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

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

人間は、
「一度、まとまりとして認識したものは、まとまりのまま認識し続け、
　必要にならないかぎり詳細は考えない」
この考え方がオブジェクト指向。
0477デフォルトの名無しさんNGNG
>476

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

カプセル化
データとそれを操作する手続きを一体化して「オブジェクト」として定義し、
オブジェクト内の細かい仕様や構造を外部から隠蔽すること。
0478467NGNG
分かってる人には当然のことでも、
それを分かってない人に教えることが極めて難しい概念、
というのはどんな分野でもある。
プログラミングにおけるオブジェクト指向はまさにそれなんだよ。

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

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

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

オレは今までに、どんな初心者にでも分かるようなオブジェクト指向の説明を聞いたことがない。
まあ、世の中の大抵のことは自分で経験しなければ理解できないのだから、
初心者に分かる説明は元々不可能であるし、する必要も無いのかもしれないが。
0479デフォルトの名無しさんNGNG
★男はココを見るべし★女と金と？？？★
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
http://www.pink-angel.jp/betu/linkvp2/linkvp.html
0480デフォルトの名無しさん NGNG
すげーレベルだな。
おまいらの設計＆ソース見なくても想像つくわ。
今日中に辞表出しとけ。
以上
0481デフォルトの名無しさんNGNG
畑違いですまんが、仏教の教典によれば、悟りを得る初心者には
四種類あると解かれている。

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

仏様は、それぞれに合わせて別な説明のし方をするんだそうだ。
0482ＯザッパNGNG
レーザープリンタでもドットインパクトプリンタでもサーマルプリンタでも
インクジェットプリンタでもデイジープリンタでもプロッタプリンタでも
プログラム上からは全部プリンタとして扱うことができる。

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

レーザープリンタはプリンタとして汎用的に使うこともできるし
レーザープリンタとして特有の機能を使っても良い。
0483デフォルトの名無しさんNGNG
>>482
良いメタファですね。

# 「じゃぁ、プリンタやプリンタドライバはオブジェクト指向なんですね。」
# とかいう厨が出てきそうな気もするけど。
0484デフォルトの名無しさんNGNG
>>478
＞｢もし仮に、どんなプログラミングの初心者にでもオブジェクト指向の利点が分かるように
＞説明するとすれば」という意図から書いたものだ。

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

( ´,_ゝ｀)ﾌﾟｯ
0485デフォルトの名無しさんNGNG
？？
0486デフォルトの名無しさんNGNG
素朴な疑問ですが、OOってデバッグ大変じゃありませんか？
何がどう動いてるか調べるために追いかけて行くと
クラス階層まで入ってってしまってわけわかめになるんですけど。
0487デフォルトの名無しさんNGNG
>>486
非OOの方がデバッグが大変
OOはデバッグや保守、改良などをしやすくするために考えられ、洗練されてきた、と個人的に思う
0488デフォルトの名無しさんNGNG
>>486 設計が歪んでいると泥沼。正しいとパラダイス。
OOPはそこんとこ、重要。
0489デフォルトの名無しさんNGNG
>>486
言語による。
クラスを作らなくてもO.K.なオブジェクト指向もどきな言語はデバッグが大変だが、

グローバル関数など余計なものを使用禁止にしている
オブジェクト指向専用言語ではオブジェクト指向言語の方がデバッグが楽。
0490デフォルトの名無しさんNGNG
>>487
○ >488
× >489
0491デフォルトの名無しさんNGNG
>>488

漏れとしては歪んでてもなんでもとりあえず形だけでもいいから
らしくOOPしていただきたい。
0492デフォルトの名無しさんNGNG
なんだかんだ言って、みんなオブジェクト指向に興味あるんじゃない。
って言うか、みんな自分が思っているオブジェクト指向の理解度に自信が
無いからかな？まーここのスレ全部が正解かな？
この件に関して堂々と答えられる人間はどこのベンダーにもいないネ。
0493デフォルトの名無しさんNGNG
この件ってどの件？
0494デフォルトの名無しさんNGNG
>>493
馬鹿ﾆﾏｼﾞﾚｽ
0495デフォルトの名無しさんNGNG
>>494
ネタにマジレス
0496デフォルトの名無しさんNGNG
>>495
バカ登場
0497デフォルトの名無しさんNGNG
>>496
一番のバカ・・・
0498デフォルトの名無しさんNGNG
>>497
２番目にバカ？
0499デフォルトの名無しさんNGNG
なにを～　オレの方がバカだぞ！
0500デフォルトの名無しさんNGNG
犬とかネコとか山田さんとかそういうことは理解できるんだけど
それを実際のアプリ製作に当てはめようとするとどうもいまいちわからない。

作成するアプリを書いたら、どういうクラスが必要かをレスしてくれるスレはないかなあ
0501デフォルトの名無しさんNGNG
ない。以上。
0502デフォルトの名無しさんNGNG
>>500
それが一番楽しい作業じゃないのか？＞クラスの洗い出し
0503デフォルトの名無しさんNGNG
>>502
病気ですね。
0504デフォルトの名無しさんNGNG
>>478
しゃべればしゃべるほどわかってないのが、浮き彫りだね！
0505デフォルトの名無しさんNGNG
まぁ、許してやんなよ。
若い頃、小難しい本読んで、すべて理解出来た気になってたのが、
歳とって何度も読み返すたびに、奥の深さを知ってどんどんわからなくなる、そんな経験無い？
あの頃わかった気になってたのって、一体何だったんだろうって。
0506デフォルトの名無しさんNGNG
>>500
激しく同意。

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

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

粘り強くやっていけば、いつかはパライソにたどり着くという目論見だが、多分この辺の
要件分析からクラス設計までの話は、学術的・体系的に確立されたものがあるような気がする。
２ちゃんねるではあまり見かけない気がするけど。
0507デフォルトの名無しさんNGNG
>>505
それは、単純に内容を忘れていただけの場合もある
0508506補足NGNG
ただし、道筋に沿って最終目標へ近づけていくアプローチ自体は
むしろ構造化手法そのものなんじゃないかと悩み中。

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

そのときには、共通関数や共通モジュールのような「単なる共通系～」を
作らないように気をつけてる。「オブジェクトとして表現すべきものか」を考えてる。
言葉にするのが難しいので、「この辺はやってみて、体で覚えて」としか言えない
のが心苦しいんだけど。
0509デフォルトの名無しさんNGNG
>>507
内容を忘れてたら、誰だって忘れてることに気づくよ。
書いてある文章の意味を理解することと、本質を理解することの違いの話なんだけど。
0510デフォルトの名無しさんNGNG
>>508 10年くらい前入社したての頃に
同じ様なこと考えてたから気持ちはわかる
ただそんな処にいる人にオブジェクト指向の
なんたるかを語られてもなあ
0511デフォルトの名無しさんNGNG
http://www.agemasukudasai.com/bloom/
0512506NGNG
>>510
スマン、OOのなんたるかを語れるほどの者じゃないことを
冒頭で断った上でのレスだと理解してください。おながいします。

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

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

イイと思いますよ。

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

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

（そんな当たり前の権利も与えられてない漏れ）
0514506NGNG
>>513
> > 粘り強くやっていけば、いつかはパライソにたどり着くという目論見
>
> なんだけど、貴方のリファクタリングが認められてない開発プロセスが導入
> されていたなら、それも不可能になっちゃうのよね・・・。
そもそも実務で「粘り強く」設計するやり方自体があまりよろしくｎ（ｒ

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

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

とりあえず、「単なる比喩による説明」と「実務で使われるOO」とを結ぶ接点さえ>>500氏が
掴んでくれれば、私は満足です。
0515プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
あ、ひでー。
初心者洗脳してやんの。

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

そんなものよりちゃんと工学的な基礎を身につけることです。
・ＯＳやスレッドの仕組み
・ＢＩＯＳ
・フェイルセーフ
・割りこみ処理
・自動プログラミング
・システム工学
0516デフォルトの名無しさんNGNG
>>515 が煽りで釣りを楽しんでる香具師、と分かっていても、やはりこう言いたくなるな。

「OOは効率が上がる」
0517デフォルトの名無しさんNGNG
フツーにプログラミングしてりゃＯＯはどう考えても要ることが分かるぞ・・・。515 はひでぇなぁ。
0518デフォルトの名無しさんNGNG
>>48
抽象的な概念を導入することでなんで作業を一般化することになるの？
0519プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
>516と517はセンスの無い奴だろうな

まあ、ＯＯに教えられるまで再利用を知らなかったような程度の低いところなら
上がるかもね。
でも所詮底辺のレベルでとてもとてもトップの技術競争に勝てるようなレベルではない。
0520プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
ああ、最近来た人は知らないだろうけど、ＯＯと非ＯＯで効率を調べる為に
実証実験をこの板でやったんだけど、非ＯＯで三日で終わったオセロが
ＯＯだと３ヶ月たってもついに完成しなかった事を伝えておく。
ＯＯ本に書いて有る事を鵜呑みにするもんじゃあない。
それは洗脳だってえの。
0521デフォルトの名無しさんNGNG
>>520
それは、アンタのアンチの執念が3日で完成させただけかと…

やる気のあるなしと、方法論とは関係無いな。
0522プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
そりゃ言い逃れだつうの。
コードを比べた分析によっても、ＯＯオセロがうまく行かなかった原因は
コード量が多いのもあるが、
拡張性や再利用の予測が外れるとＯＯは途端に効率が落ち、それは容易に起こる事が判る。

ＯＯの宣伝本はその予測リスクについて全く触れていない酷い詐欺だ。
0523デフォルトの名無しさんNGNG
わらた。
面白い漫才スレをありがとう。
脳みその凝りがほぐれたよ。
0524デフォルトの名無しさんNGNG
>>523
こんなんで笑える脳味噌なら捨てちまえ！
0525わが持論NGNG
巷に馬鹿はたくさん居るが、

真実＝己の視界の範囲

と判断する奴は、もっとも有害な馬鹿。
0526デフォルトの名無し職人NGNG
>>525

「真実」はその人の視界の範囲以外に厳然とあって、そしてあんたはそれをわかるというわけだ。
0527デフォルトの名無しさんNGNG
>>525
これは再帰か？
0528デフォルトの名無しさんNGNG
>525

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

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

0529デフォルトの名無しさんNGNG
「人間、だれしも自分の経験の範囲内でしかモノを語れないわけで、
そんなことはあたりまえのことなわけですが、
世の中には、自分の経験の範囲内が世界の全てだ、
と勘違いしているおめでたい人間も沢山いて、
そういう勘違い人間には閉口してしまうことも多いです。」
0530Java太郎 ◆DMVtSSFzcg NGNG
愛だ！！愛！！！！（´д｀）ハァハァ
0531デフォルトの名無しさんNGNG
>>522

OO じゃないと予測うんぬん以前に修正さえできねーじゃんかよ
0532デフォルトの名無しさんNGNG
今の世の中のソフトウェアのほ必ずOOらしいことやってるだろ。負けを認めろ！
0533デフォルトの名無しさんNGNG
クラスで役割が定義されていて適切な名前がつけられているのがどれだけありがたいことか。

ただ関数一覧表がずらーっ・・・と並んでいるプロジェクト見たことある。
彼らと仕事するには神の認識力が必要だなと思った。
0534デフォルトの名無しさんNGNG
オブジェクト指向の理解度

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

なぜか、C はオブジェクト指向を説明するのに熱心なので、
ほとんどの人が B から C へいく。
0535デフォルトの名無しさんNGNG
漏れとしては形だけでも理解してなくてもいいからとりあえず OO を始めていただきたい。
0536デフォルトの名無しさんNGNG
案ずるより産むが易し。習うより慣れろ。

古人はいいこというね。
0537デフォルトの名無しさんNGNG
OO、OOといいながら、OOAもOODもしてないのに
製造にOOPだけ押し付けるのはやめてくれ。
0538デフォルトの名無しさんNGNG
とりあえず、構造化プログラミング＋そのとき必要になったクラスを
随時追加って感じで作り出しちゃってもいいですかね？
0539tanteiNGNG
★あなたのお悩み解決致します！！
●浮気素行調査
彼氏、彼女、妻、夫の浮気を調査致します！！
●盗聴器盗撮機発見
あなたの部屋に誰かが仕掛けているかも！！
●行方調査
行方不明になっている家族の消息を調査致します！！
●電話番号から住所割り出し
一般電話、携帯から住所を割り出し致します！！
●ストーカー対策
社会問題ともなっているストーカーを撃退致します！！
その他人生相談からどんなお悩みでも解決いたします！！
　直通　　０９０－８５０５－３０８６
ＵＲＬ　　http://www.h5.dion.ne.jp/~grobal/
メール　　[email protected]
　　　グローバル探偵事務局　

0540XPマンセーNGNG
「オブジェクト指向はこう使え！！」

設計の終焉?
http://objectclub.esm.co.jp/eXtremeProgramming/IsDesignDead.html
0541デフォルトの名無しさんNGNG
ＯＯに則ったコード設計は実に難しいと思う。
0542デフォルトの名無しさんNGNG
>>541

コード書き始めから完璧ってことは、どんなにOO設計大好き野郎でも不可能なんだし。

とにかく何らかの意図をもってクラス分けすりゃいいと思うよ。
0543デフォルトの名無しさんNGNG
ASPからC#に移行するメリットはオブジェクト指向で設計実装できることだけしか無いのだが、
会社のＰＧどもがそれを理解できない奴らばかりなので困ってる
0544デフォルトの名無しさんNGNG
>>542
禿胴。

1.最初は思いつきで大まかなクラス設計
2.推敲や実装作業のなかでよさげな構成に修正

というのは普通だよね？ウォーターフォールﾏﾝｾｰ馬鹿じゃなければ。
0545デフォルトの名無しさんNGNG
それではクラス設計しないで適当に実装するのとかわらん。
現実に無理とはわかっても、最初からカンペキなものを作る覚悟で設計しないと
0546544NGNG
>>545
分析レベルで完璧にしても、実装してみたらいろいろ不都合が起きるものですよ。
そういうことを言いたかったんだけど、誤解される文章でｽﾏｿ。
0547544NGNG
でもって、そういう不都合が全く発生しないような分析/設計フェーズの
実践が可能、などと思い込んでいる、現実しらずをさしてﾏﾝｾｰ馬鹿と
よんでみました。
0548デフォルトの名無しさんNGNG
つーか改造／改良にこそOOが威力を発揮すると思うのだが。
0549デフォルトの名無しさんNGNG
改良しようとしてもOOしてなきゃコードが読めん。
0550プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
ダメ過ぎ
0551デフォルトの名無しさんNGNG
>>550
貴方ほどじゃ…
0552デフォルトの名無しさんNGNG
(^Д^) オブジェクト思考でオブジェクト指向しようよ！
0553プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
ダメ過ぎ
0554デフォルトの名無しさんNGNG

　　　　　　　 　 ／´⌒´⌒＼
.　　　 　 　 　 / 〃　ハ　　ヾヽ　　　　　
　　　　　　　　|　ノ∠、ﾉ,ムヾ |　　　 ／￣￣￣￣￣￣￣￣￣
　　　　　　　　（|| ━｀ i　━ ||）　　＜　オブジェクツ！！
　　　　　　　∩｛ 　 ｒ ┘ 、　｝∩　　 ＼＿＿＿＿＿＿＿＿＿
　　　　 　 ＿|└９ ｋ='=ヶ} ６┘|＿
　 　 　 ／　 にニ｝､_￣´_/にニ｝　＼
　　　　|ヾ　　ﾄーｲ{≫又≪}ﾄ―ｲ　〃 |
0555デフォルトの名無しさんNGNG
>>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の中の人
0556デフォルトの名無しさんNGNG
プロの逝って良しの１ ってC++スレとかにも顔出してる
日本語の不自由なかわいそうな人ですか？
0557デフォルトの名無しさんNGNG

実務経験経験豊富な肩に質問！
J2EEの開発やっているものなのですが、オブジェクト指向分析って必要ですか？
とくにWeb系ではBCE出すのって、あんまりメリットないような気がするのですが。
（画面サンプルや画面遷移図書いたほうがよっぽどわかりやすい）

開発やってると、だいたい
　要件定義（ユースケース、画面、非機能要件、概念モデル作成）
→画面設計・コンポーネント設計・DB設計・アーキテクチャ設計
→クラスの詳細設計
→実装

という流れになることがおおいです。

それとも
オブジェクト指向分析＝エンティティモデル構築＋データ項目洗い出し
と理解すればいいのでしょうか

＃データベースアプリで無理にOOするなゴラァという話もあり・・・
0558デフォルトの名無しさんNGNG
>>557

画面遷移図とかあったほうが分かりやすいならそれを書くのがいい。


それは OO の本質とは違うところで、設計として OO を考えるタイミングとしては、
メソッド名が同じで機能が違う、みたいなものが見つかれば、抽象クラスする価値が
あるね、くらいのことで。

例えば、検索条件をプラグイン的に追加したいために、絞込み条件をクラス化することだったり、
予約タスクをクラス化することだったり。ログインしたユーザによって絞込み条件を変えるって
ことだったら、ユーザオプジェクトに絞込みオブジェクトをセットすることだったり。

税金の計算方法がちょくちょく変わるとかだったら、計算クラスでも作って、
利用者に選択できるようにするとか。

OO が要るところはそういうことで、ページをオブジェクトでマッピングするのもそれはそれで
便利だけど、それは設計ってわけじゃなくて、技術基盤として便利だねってことで、それは
分析、とはあまりいわないんじゃないかしら。
0559プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
いまさら提出して「二日でできました」つうのも、もう詐欺っぽさ満点だというのは
置いておくとしてもだ。

そのコード量じゃねえ。
再利用できない無意味なモデルだし。
0560プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
まあ、ＯＯは作り捨てに向いているってことかな。
パターンマニア向けでしかないね。
仕事では使えない。
0561デフォルトの名無しさんNGNG
>>560
どうやってその結論に到達したの？
飛躍し過ぎでサパーリ解らない。
0562プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
もう１０スレの費やしての説明で疲れました。

実証と理論的検証両面からＯＯはダメつう結論です。
必死に反対してる信者がいますが、現実を見ない者は滅ぶだけ。
0563プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
俺に抗議しても現実は変わらんよ。
0564デフォルトの名無しさんNGNG
ＯＯに興味が無いならのぞきに来なければいいだろうに。
0565デフォルトの名無しさんNGNG
業務だからOOなんでは？
OOは大人数、大規模プロジェクトで複数の人がコードを参照し
仕様変更による改良・改変しデバッグをしやすいというのが売りなんだから
リバーシのような個人が数日で作れるようなソフトではプロセスをそのまま
コーディングする非OOの方が慣れてる人が多い分、早くても自然だと思います。
コードの量が増えるにしたがってOOが有利になると思います。

改良・改変・デバッグに費やす時間（ソースの量Nの増加として）
非OO：OO　＝　N：Log N　って感じかと。
0566デフォルトの名無しさんNGNG
◎◎を使えねえやつはいりませぬ。文句を言っても◎◎を使えるやつは
貴重だな。
0567デフォルトの名無しさんNGNG
>現実を見ない者は滅ぶだけ

・・・どっちが？
0568プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
>>565
笑った。
しょーもな。
0569デフォルトの名無しさんNGNG
オレルールで開発するのが楽なのは当たり前。
OO だと既存の開発プロセスや設計手法が沢山あり、
それに従って開発するのが OO だと思われているので、
不適合なプロセスを選択すると不自由を感じながら開発することになる。
0570デフォルトの名無しさんNGNG
>>563
「現実」ってのは『非OOを支持してるのがお前だけ』だということを指してるわけか？
0571デフォルトの名無しさんNGNG
oo = 北朝指向
0572デフォルトの名無しさんNGNG
プ1はどういう経緯でOOに恨みを持ったのか…
よっぽどろくでもない生兵法馬鹿に粘着でもされたのかな。

コンサルだとか名乗って使いこなせてないOOを売り文句に
詐欺営業して大金を巻き上げるろくでもない連中が、確か
にいるからなあ…
0573プロの逝って良しの１ ◆MvRbZL6NeQ NGNG

「ＯＯはすぐに結果の出るものではありません。５年先、１０年先を見て行うものです」

と言ったコンサルが居たそうだ。
笑っちゃうね。
0574プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
洗脳されてる奴が周りにいると仕事やりづらいので世論を軌道修正すべく
日夜２ちゃんで広報活動に勤しんでいるだけで、別に恨みは無い。
0575デフォルトの名無しさんNGNG
>>573
おそらくそのコンサルは10年間寄生虫になることを目論んでいるロクデナシだった
んだと思うが、
アンタみたいな硬直した脳みそがイッパイいる企業を再教育するのには、確かに10
年みないといかんかもね。
0576プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
>>565なんか本に書いてある事そのまんまでしょうが。
オウムなんかに引きこまれたらさぞかし疑問を持たず、
教えられた教義をただ繰り返す人なんだろうなと思う。
0577デフォルトの名無しさんNGNG
OOだろうがコーディングの規約レベルだろうが流行のフレームワークだろ
うが、アンタ(あるいは俺)の俺様ﾏﾝｾｰスタイルに何らかの制約を掛けるの
は当たり前。
そのトレードオフは開発効率や保守性の向上。対企業システム開発なら
その実現は満たすべき重要な機能だと思われ。他人にとって見通しのよい
構造にしておくのは、単に動作するかどうかの次くらいに重要(なはずなん
だが、アマリにも実装能力の低い糞集団は、この機能を無視するんだよな)
だとおもわれ。

俺だっていつも俺様マンセーで開発したいとは思うが、人から与えられた
仕事をやる限りは、そうもいってられないでそ。
0578デフォルトの名無しさんNGNG
ooセミナーwとかして、信者候補生だまして
飯をくいてーなー。
信者はもっと普及活動しろよ。
オブジェクト指向って言うだけで金が
はいるんだもんな。
ｲｲ世の中だw
IT国家まっしぐらだw
0579プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
いやー、ＯＯ反対だと「硬直した脳みそ」ですか。

それもＯＯが宗教である証拠だ。
疑問を持つものをそうやって葬るシステムになっている。

ＯＯの本には
「従来は～でしたがＯＯになって～になりました」とでたらめが書いてあって、
「ソフトウエア産業ではかねてから生産性の向上が求められてきました・・
　ＯＯの導入は従来型の古い思考の持ち主には合わない面があります」

などと、疑問を持つものや反対者を「生産性を下げる人」とレッテルを貼るのと同じ
洗脳の手法によって、洗脳に対して免疫の無い若い人を中心に布教したんだ。
0580デフォルトの名無しさんNGNG
>>576
あいたたたたた
前に進むことも見ることもしなくなった、単なる古いオッサンじゃねーかよ
お前みたいなのがいるとこっちが仕事やりにくいだろ

年取ると新しいことは覚えずらいかもしれないけど学習しろよ
置いていかれるぞ？
0581プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
>>577
それもソフトウエア業界の問題の一つ。
集団による開発効率向上の手法は、しばしばその手法を正しく適用できる人がおらず、
単なる原理原則論の非実際的な適用によって返って効率を落としている。
その手の集団手法を好む会社は、例えばどうみても５人年で済む仕事に
３０人年投入してたりする。
0582575=577NGNG
おれもOOがカンペキでスバラシイなどとは一つも思ってないが、

・要件分析→設計までを一貫した成果物のスタイルに落とすことができ
て、他人が後からトレースするのが簡単
・クラスの分割、パッケージ分割などをきれいにしておくと、整理された
戸棚みたいに、特定機能の位置の把握がしやすい

あたりは便利だと思ってるな。
別に開発スタイルの一種だと思えば、それに従ってやるだけでしかな
いよ、折れは。仕事だし。

本読んだだけで分かった気になって、上司の攻撃に利用するマンセー
厨新入社員が大嫌いなのは、俺も同じだ(ﾜﾗ
0583プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
学習ときたか。
やれやれだ。
本人大真面目なんだもんな。
0584プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
以前ＯＯマンセーだったこの板の人達にコード出させたら、全然ＯＯじゃなかった
という話も付け加えておこう。
0585デフォルトの名無しさんNGNG
>>584
OOを完全否定か？　あんたは？
0586575=577NGNG
なんだかプ1って意外とまともな気がしてきたな。

>>581
ああ、あるべき論で現実離れした標準化プロセスを合議制で作ってる
馬鹿なプロジェクトがウチにもあったよ。関わっているやつは
高級管理職連中。現場を分かってない奴が作ったから、成果はみるも
無残。誰の現実も救っていない標準なんて、単なる無駄な稼動の原因
でしかないな。

で、OOもその類だというわけね、あんたは。
0587575=577NGNG
>>584
そりゃOOとは関係無いな。
そのマンセー野郎が馬鹿だっただけでしょ。
0588デフォルトの名無しさんNGNG
指向や思想を売ったり、押し付けたりするのは
どれに限らずおかしい事なんだよ。

だいたい指向ってなんだよ？指向ってよ？
新しいパラダイム？はぁ？
おまえらはさぞかしパラダイムシフトしたんだろうな？
オブジェクト指向のほかに何指向があるってんだよ。
俺は、ｱﾔﾔ指向だ。
0589575=577NGNG
>>584
ああ、OOマンセーといいながら使いこなせていない糞が
巷に腐るほどいて、現実問題のの解決に対して足を引っ張
っている=OOがダメっていうことか。

まあ、それはOOを別の概念にさしかえれば、どれにでも言え
る話だな。
0590デフォルトの名無しさんNGNG
「使いこなす」って表現が出る次点で
おかしいだろうがよ。
指向なんだろ？

マジで、洗脳ｯﾃｺﾜｲﾈ...
0591デフォルトの名無しさんNGNG
hoge指向
0592デフォルトの名無しさんNGNG
>>588
>オブジェクト指向のほかに何指向があるってんだよ。

お前にいい言葉を教えてあげよう。「教えてください、お願いします。」
この言葉を覚えるとそのうちいいことがあるぞ。
0593デフォルトの名無しさんNGNG
>>588
オブジェクト指向というけど、実際にこの単語を使うときは
「(狭義の)オブジェクト指向という思想に基づく数々の手法」
の総称をオブジェクト指向と呼ぶほうがおおいようなきがする
な。

アスペクト指向==AspectJとか、そういう人多いよ。
0594デフォルトの名無しさんNGNG
>>592
偉そうに・・・
ｷｼｮｲんだよ。
お前、金八指向な。
0595デフォルトの名無しさんNGNG
なんか、活発に議論してますねー

ＯＯは駄目ですか、では僕は何を勉強するべきなのでしょうか？
すいません。道を示してください。
0596デフォルトの名無しさんNGNG
>>594
>金八指向
いかん、ツボにはまった。激藁
0597デフォルトの名無しさんNGNG
「プロの逝って良しの１ 」氏の言は、漏れにとっては新鮮だ。
「オブジェクト指向は素敵」と聞いて、漏れはあっさり信じちゃったからな。
確かに、疑いの目を向けてみることは必要かも。科学的にね。

ただまぁ、実感としてオブジェクト指向は素敵だと感じてる。
「問題を分析する際に、その問題を構成してる『モノ』達と、
そのモノたちの間で交わされる『メッセージ』を基盤とする」
と言うことよりも優れた分析方法ってのを知らないから、
漏れは当分オブジェクト指向にしがみつくしかないけど。
モノを基盤とせず、操作(？)を基準とした問題分析って、難しいんだよなー。
0598デフォルトの名無しさんNGNG
>>593
アリが㌧
0599575=577NGNG
俺はOOがダメなんていってないよ。
詐欺コンサルや提灯記事に安易に流されて、理解していない
ことを「手持ちの道具」扱いするなといっているだけ。
0600デフォルトの名無しさんNGNG
まともな奴が使えば効果が上がり、馬鹿が使えば悲惨なことになる？
んなの、何だってそうだろが、ボケェが！
0601575=577NGNG
>>600
そのとおり。だが、一方で「どんな物事でも一様に悲惨にする」
馬鹿が業界には大勢いて、でも多くのまともな人間が、そいつら
と仕事せにゃならん現実もあるわけで。
0602プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
>>595
勘を磨くとか、対人関係スキル上げるとか。
0603デフォルトの名無しさんNGNG
>>603
とりあえず、歯を磨くことにしまつ。
0604575=577NGNG
いっとくけど、おれはOOを分かってないよ。
OOで作られたシステムとそのプロセスにかかわり、それを通じて
観察したことがあるだけ。見えなかったことは知らんので、あて
にせんでくれ。
0605デフォルトの名無しさんNGNG
>>602
いえいえいえいえ、そのようなことではなくて、それが大切なことはわかりますが
とりあえず、設計方法のほうをお願いします。
0606デフォルトの名無しさんNGNG
>>605
きびしいなぁ。ｱﾝﾁOOなだけの人に、
まともな設計方法の提示ができるわけ無いじゃないですか。
敵の退路は立ってはいけません．それは、予想外の事態を生みます．
まったりちゅらさんでも見るﾖﾛｼ．
0607デフォルトの名無しさんNGNG
プログラミングしてたら、OOは自然と身につくもんだから。

設計をあらたまって勉強するとか、もう止そうぜ。

クソセミナーやクソコンサルに騙されちゃいかん。
0608607NGNG
プログラミングを学習する上でOOを意識するのは極めて有効なのは確かだ。
0609デフォルトの名無しさんNGNG
エンジニアなら技術で勝負しろっつーの。
OOがスキルだと思うな。良いのや悪いのや詐欺やらを
判断しながら、自分なりに取捨選択して
取り入れていけばいいんだよ。要はセンス。技術者なんだから。
そこにある要求定義に対して自分のセンスをぶつければいいんだよ。
小泉風に言えば、柔軟かつ冷静に対応。
0610デフォルトの名無しさんNGNG
>>606
おーい、「まったりちゅらさん」ってなんだよ！
ぐぐッたけど、なんもでてこねーよ！
0611デフォルトの名無しさんNGNG
>>610
その場合の「まったり」は形容詞だ。
本体とは分離しなければ望む結果は得られないだろう。
オブジェクトの切り出しを誤ってはいけない。
0612575=577 NGNG
OOだろうがなんだろうが、現実にその手法で設計を行い、後で評価して
フィードバックする作業を繰り返すことナシに、ガッコのオベンキョだ
けですばらしい設計手法が身につくと思っているアホは、しんで欲しい。
0613デフォルトの名無しさんNGNG
>>610
読点なくてスマソ．ことえりよりアホだとは想定しなかったので．
「まったり」は「見る」にかかる福祉で、
つまり、
「まったり、『ちゅらさん』を見なさい」といういみでつ。
0614プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
>>609
「柔軟かつ大胆に対応する」だろ

>>605
手続き型で書こう
0615デフォルトの名無しさんNGNG
プ1が考えてることっていうのは、上流とか下流とかあって
設計する人とコーディングする人が分かれてるとうまくいかねーって
ことではなかろうか。

ここらへんの議論は開発方法論（XPの話題とか）でいろいろ言われてる。
（どう考えたって、プログラマが設計しなきゃいけない）


OOを悪用してヒエラルキーを作りたがる勢力がいて、
ここらへんの利権がらみの解決を行うのは、不可能に近い。
0616デフォルトの名無しさんNGNG
>>615
> プ1が考えてることっていうのは、上流とか下流とかあって
> 設計する人とコーディングする人が分かれてるとうまくいかねーって
> ことではなかろうか。

どこがそんな風に読めたんだろう．
0617615NGNG
>>616

>>573 あたりで
0618デフォルトの名無しさんNGNG
俺指向でいけ
0619デフォルトの名無しさんNGNG
>>614
すいません、手続き型＋αしたものがオブジェクト指向というものではないのですか？

>手続き型プログラミングでは、5つの基本的な考え方があります。それは「連接」「繰返し」「判断」「部品化」「再帰」です。

今見たページにこう書いてあったのですが、オブジェクト指向も同じことするのでは？
勘違い指摘してください。
0620デフォルトの名無しさんNGNG
>>617
573>>「ＯＯはすぐに結果の出るものではありません。５年先、１０年先を見て行うものです」
573>>と言ったコンサルが居たそうだ。
573>>笑っちゃうね。
と、
615>>プ1が考えてることっていうのは、上流とか下流とかあって
615>>設計する人とコーディングする人が分かれてるとうまくいかねーって
615>>ことではなかろうか。
の間にミッシングリンクがある気がする,,,,
0621デフォルトの名無しさんNGNG
>>619
手続き型であれば、そこに無条件分岐とか、
構造化されてないのものも含まれるはず。

たぶんあなたはDQNサイト観てる。
ﾁﾊﾞﾐｿｰﾘﾖｰ
0622デフォルトの名無しさんNGNG
>>621
無条件分岐？　gotoのことですね。

構造化されてないものも含むって・・・え？　
手続き型を学ぶとはそういうものを駆使しろということですか？
0623デフォルトの名無しさんNGNG
>>619

勘違いしてるとこなんてございません。

+α の部分を言うならば、OOすると複雑な分岐を省略することができます。
0624デフォルトの名無しさんNGNG
>>622
gotoなどを駆使しろ、と言うのではなく、
「『手続き型』と『構造化』を混同してるんじゃないの」って突っ込み．
0625デフォルトの名無しさんNGNG
OOは手続き型を含めてOO。とか言ってるｶｷｺを前にみたなぁ。
まあそうだと思いこんだとしても、
それでどこがパラダイムシフトなのかと小一時間(ry
0626デフォルトの名無しさんNGNG
C→C++、Pascal→Delphi、Perl→Perl5
と手続き型をベースに OO の機能を乗っける言語が多いからねえ。
0627デフォルトの名無しさんNGNG
>>625
もう、訳わからないのです。　パラダイムシフトかどうかはどうでもいいんです。
なぜＯＯは否定されたのですか？　

手続き型はオブジェクト指向の土台ではないのですか？
何で土台に家を建てたら駄目なのか、ヒントをください。
0628デフォルトの名無しさんNGNG
>>623
OOじゃなきゃ、複雑な分岐を省略できないわけでも、
手続き型だと、複雑な分岐になるわけでもない。
お前の発言には、何の意味もない。
0629デフォルトの名無しさんNGNG
>>626
だ　か　ら　な　に？
0630「メッセージのやり取り」厨NGNG
>>627
オブジェクト指向は、問題の分析とか設計とかを、
「オブジェクトと、その間のメッセージのやり取り」
と、捉えること．

手続き型は、俺はよく知らないけど、
「その問題の中で行われる操作」を中心に問題を分析すること、だろ。
コンテキストフルに．

全く異なる概念だね．
どっちかがどっちかの土台であるわけでは無い．
0631623NGNG
Perlでもくだらねーif文の嵐を回避するテクは存在するがな
0632デフォルトの名無しさんNGNG
>>630
ところが、JavaだのC++だのは、メッセージのやり取りを操作とやら？
で表現するんですよ。
0633デフォルトの名無しさんNGNG
>>627

まあ一緒か別かはこの際どうでもよくてさ、
プロジェクトが成功しないっていう統計や、
ｿｰｽコードの再利用性とか、保守性とか、
可読性とか、べつに上がるわけじゃないって
統計でてるんだって。
ｵｾﾛ合戦とかやってた時期に散々言われてたよ。
統計のｿｰｽはプ1がもってるんじゃないかな？

OOを好んで作ったっていいんだけど、素人には
おすすめできないってことだろう。プロならなおさら
慎重になれって。
0634デフォルトの名無しさんNGNG
>>630
なるへそ！
ちょっとわかった気がします。

で結論、ＯＯも手続き型も知ってても損はしないだろうから
どっちも勉強して実際に設計、コーディングしてみようと思います。

ありがとうございました。
0635デフォルトの名無しさんNGNG
>>632
いや、「(メソッドの起動に限定された)メッセージのやり取り」で表現されてるはずだ。
非OO的な、メッセージのやり取りとして判断するのが困難な、
「その問題に置ける操作をいきなり抽出する」って方法は、あまりとられないはず。
0636デフォルトの名無しさんNGNG
>>635
現実には、そういうコーディングを注意深くすれば、そうなるという
レベルなんだけどね。
0637デフォルトの名無しさんNGNG
つうか、>>600- で、「手続き型」って語が不用意に使われてるが、
「手続き型」ってのは「順序に意味がある」ってこと。
これの対義語は「関数型」であって
「順序がどうであっても、結果は同じ」ってことなのです。

この分類でいくと、普通のオブジェクト指向言語とかは、
各オブジェクトが状態を持つことを許すので、
「手続き型」のサブカテゴリーとも捉え得ます．

0638デフォルトの名無しさんNGNG
>>637
あ、調べてる途中、なんかそう感じました。
やっぱり手続き型とOOは仲間ですか？
0639デフォルトの名無しさんNGNG
>>636
意味が分かんない．　例えば、Javaで普通に設計すると
「全部のメソッドをpublic staticにしたクラスが林立する」
ってことも、あなたの主張に含まれますか？
0640デフォルトの名無しさんNGNG
>>638
いえ、全く関係のない概念です。
依存し合うわけではないし、排他的なわけでもありません。

「手続き的なオブジェクト指向」
「手続き的な非オブジェクト指向」
「関数的なオブジェクト指向」
「関数的な非オブジェクト指向」
の、どれもがあり得ます．
ただ、世の中でもてはやされてるのは「手続き的なオブジェクト指向」。

0641デフォルトの名無しさんNGNG
非ＯＯで新規開発するのと、ＯＯで新規開発するのは、若干ながらＯＯで
開発するほうが工数がかかると思う。ただ、ＯＯで最初から開発しておけば
後々の拡張を考えたとき、非ＯＯよりは工数が少なくなると思う。

非ＯＯ、ＯＯとも、まともに設計されていれば、だけど。
ただ両者の差がどれくらいになるかはつまるところ開発要員によるわけで。
あまりどっちがどうのと優劣をつける問題でもないような気がする。人的な
問題のほうが手法的問題よりはるかに大きい。

優劣を論じたり、ＯＯは使えないとか非ＯＯは古いとかっていう二元論に
持ち込もうとする人間が最大のガンなんだろうと思う。
0642デフォルトの名無しさんNGNG
>>641
禿胴！
0643デフォルトの名無しさんNGNG
プ逝１はオブジェクト指向を理解していないので反論は無意味です。
0644デフォルトの名無しさんNGNG
> 非ＯＯで新規開発するのと、ＯＯで新規開発するのは、若干ながらＯＯで
> 開発するほうが工数がかかると思う。ただ、ＯＯで最初から開発しておけば
> 後々の拡張を考えたとき、非ＯＯよりは工数が少なくなると思う。
幻想です。優劣を論じたいのは貴方ですね。


0645デフォルトの名無しさんNGNG
オブジェクト指向を使いたくない人は使わなければ済む話なのに…
0646デフォルトの名無しさんNGNG
>>645
個人開発ばっかりやってる人ですか？
0647デフォルトの名無しさんNGNG
OOな言語で開発したいけど
マイコンとかだとそうもいかないんだよな。
ROM32k RAM4k だとなかなかC++使う気にはならない
しょうがないから、考え方だけOOを使って
アセンブラやCで組んだりするわけだ。
設計にはOOの概念使った方がいい意味で手抜きできるし
0648デフォルトの名無しさんNGNG
★プロの逝って良しの１のパターン★

間違ったオブジェクト指向の定義に基づいて批判する
　　　　　　　　　　　　　↓
オブジェクト指向の定義が間違っていることを指摘される
　　　　　　　　　　　　　↓
オブジェクト指向の定義が間違っているという指摘を無視する
　　　　　　　　　　　　　↓
間違ったオブジェクト指向の定義に基づいて批判する
　　　　　　　　　　　　　↓
オブジェクト指向の定義が間違っていることを指摘される
　　　　　　　　　　　　　↓
オブジェクト指向の定義が間違っているという指摘を無視する
　　　　　　　　　　　　　↓
間違ったオブジェクト指向の定義に基づいて批判する
　　　　　　　　　　　　　↓
オブジェクト指向の定義が間違っていることを指摘される
　　　　　　　　　　　　　↓
オブジェクト指向の定義が間違っているという指摘を無視する
　　　　　　　　　　　　　↓


間違ったオブジェクト指向の定義に基づいて、オブジェクト指向を
批判するというプ逝１の詐欺行為はいつまで続くのだろう…
0649デフォルトの名無しさんNGNG
>>627
アンチOOな江戸幕府と、開国を迫る先進技術を誇るOOなアメリカ。
アンチOOはOOを妬んでいるのです。

OOを否定する連中はクラスを作るとコードが余分にふえて面倒くさいから、
重くなるから使いたくないとか不平ばかりいう連中なのです。
0650デフォルトの名無しさんNGNG
OOが単純にヨイと言い切れないのは、似非ＳＥ、似非コン猿がマッチポンプだからだ。
0651デフォルトの名無しさんNGNG
>>649
何のたとえ話ですか？
江戸幕府は、アメリカを妬んでいたのですか？
0652Java太郎 ◆DMVtSSFzcg NGNG
ヤイ！ヤイ！ヤイ！ヤイ！
0653デフォルトの名無しさんNGNG
>649 クラスを作るとコードが余分にふえて面倒くさい

確かにJavaのソースを見てるとアクセサばかりで
中身のないクラスとか結構多いからね。。。。

で、｢Delphiはプロパティがあって便利だぞ！」
というDelphi厨の話になるんだがｗ
0654デフォルトの名無しさんNGNG
>>653
VB（ﾓｺﾞﾓｺﾞ
0655デフォルトの名無しさんNGNG
>>647
ってか，重要なのは考え方じゃない？Javaでもひとつのクラスに全部機能を実装
するヤシも実在するらしいし
0656 ◆2X.Isr1tR. NGNG
トリップテスト
0657 ◆2X.Isr1tR. NGNG
第二のテスト
0658デフォルトの名無しさんNGNG
>>655
Utils系は漏れもそうしてるぞ
0659デフォルトの名無しさんNGNG
>>655
あるCOBOLerが初めてJavaを使ったときに
すべての処理を一つのクラス、main()メソッド内
に書いてしまってオブジェクト指向言語の特長を
全く生かしていなかったという話があった。
有名な話らしい。
0660プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
おまいら釣られてるんじゃない
http://java-house.jp/ml/archive/j-h-b/021822.html#body
0661プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
>>659
ある会社はコーディング規則でそう決まっているのだ。
コボラーのせいではないのだ。
0662デフォルトの名無しさんNGNG
なんかJava＝OOと思い込んでるアフォがいませんか。
0663デフォルトの名無しさんNGNG
>>661
確かに子簿ラーのせいではないね。　
オブジェクト指向を理解しようとしないやつのせいだね
0664デフォルトの名無しさんNGNG
それは>>662だけです。
0665641NGNG
>>644
話のごく一部だけの揚げ足を取って「優劣をつけたいのはあなた」とか
言われても説得力ゼロなわけですが。
つーか>>641の内容を全部読んで、それで優劣を比較するという結論
に達した時点でアフォですか？としか・・・
あたしゃ非ＯＯの開発も否定してないですよ。ていうか、現実的には
非ＯＯがまだまだ主流じゃないですかね。ただ、ＯＯによる再設計とか
をうまく使うことができれば（あくまで「使うことができれば」ね）工数は
減りますよ。JDKのコンポーネントの設計を見ていると、うまく再利用
とか拡張ができるように工夫されてるのがよくわかります。
0666デフォルトの名無しさんNGNG
オブジェクト指向型言語の不得意な分野も指摘しておこう。
顕著な例はメモリマネージメント機能を持たず
メモリの少ない組み込みマイコンである。
ダイナミックなインスタンスの生成および消滅が困難である。
また同時に存在するインスタンスがどれだけになるか予測がつかない場合、
しばしばメモリがオーバーフローする。
このような場合手続き型言語のほうが便利であるし、オブジェクト指向言語を
手続きのグルーピングとして使用する程度の意味合いしかないのは事実である。
携帯ゲームのプログラマはＣ++をあまり好まない。

オブジェクト指向型言語は抽象化によるメリットが高い場合に
利用効果が上がる。一方で具体的なハードウェアを直接操作する場合、
汎用化を行うことは出来ても抽象化はあまり意味がない。

オブジェクト指向型言語の習得は修行ではない。
便利なら使えば良いし、不便なら使ってはいけないのである。
そしてこの判断が出来るかどうかは
悲しいことであるが設計者の知性のレベルに依存するのである。
0667デフォルトの名無しさんNGNG
>>665-666
ﾊﾞｶの長文氏ね　Σ(´Д｀lll)
0668デフォルトの名無しさんNGNG
以上、オブジェクト指向＝Javaという前提でお送りしました。
======================ここまで======================
0669デフォルトの名無しさんNGNG
>>666の上司は賢明なので勘違いOO信者の言うことをすべて却下しました
0670デフォルトの名無しさんNGNG
>>648
ﾜﾗﾀ
0671デフォルトの名無しさんNGNG
インスタンス変数をpublicで直接いじるのでは
なく、privateにして、setter、getterメソッドで
アクセスさせる方法が定石なのはなぜなのか、
違い（というか、できたらからくりも）
お前ら教えてください。
0672デフォルトの名無しさんNGNG
>>667
　長さを支えるだけの構成力があれば、長文もバカに出来ないゾ。
　長文＝バカと言いきってしまうのはどうか。

　とマジになってみるテスト。
0673デフォルトの名無しさんNGNG
>>671
そうしておくと、そのオブジェクトの変数を変更しようとする人は、
必ずメソッドコールしてることになるでしょ。

そうすると、誰がいつ変更しようとしたかが分かるわけさ。
ﾜｹﾜｶﾗﾝとんでもない値入れようとしたら拒否してみたり、変更の履歴
を取ったり、そういう仕事をメソッド内部に追加できるわけさ。
でもって、そういうものを追加しても、(メソッドシグネチャは変わ
らんので)ユーザに迷惑掛けないわけさ。

誰がいつどのように変更して、整合性の取れない状態変数の集合に
なっても全然かまわないクラスなら、全部変数publicでもかまわない
けど、普通クラスに複数の変数を宣言するときって、それぞれの変数
が全部"なんでもいい"って事は、ないことが多いでしょ？
0674デフォルトの名無しさんNGNG
>>671
publicな変数を１つ使って実現していた機能が、変数２つに変更したいとする。
外部から直接変数を操作していると、操作する個所すべてに修正を入れる
必要がある。１箇所２箇所ならいいが、数百箇所もあったらバグるのは目に
見えている。

setter/getterメソッドを使って実現していると、メソッドの呼び出し形式が変更
されない限り、変数の操作はクラス内部に隠蔽される。よって、変更箇所も
クラス内部だけですみ、修正工数もバグも激減することになる。
0675デフォルトの名無しさんNGNG
なんか必死に書いてるのがいるけど、
オブジェクトのインタフェースは、その実装方法に依存してはならない
っていう原則があるからなんだよ。

メンバ変数を公開してしまうと、何かの都合でオブジェクトに変更が入ったとき、
それを利用している他のオブジェクトも一緒に修正しなきゃならなくなるでしょ。

JavaわからんからC++で書くけど、悪い例で言うと
class Foo {
public:
double double_data;
} foo;
void examine(double &d);
みたいなのを作ってたとして、 exsamine(foo.double_data); みたいなコードが
どっかに一カ所でもあると、これをdouble->floatやmona::bignum とかに
置き換えようとしたとき、このクラスを使ってるとこ全部見なおさなきゃ逝けないわけ。

せっかくオブジェクトとして分離、隠蔽してるのに、メンバ変数を一個公開しただけで
そのクラスも、そのクラスを利用する他のクラスも、メンバ変数の実装方法に
依存した設計・実装をしなきゃ逝けなくなるの。
0676デフォルトの名無しさんNGNG
相手に見せる仕様は最小限に、とか、どっかの本に書いてなかった？

setter/getterは、コード量が増えて面倒に思えるけど、実装方法を
隠蔽したまま、相手に最小限のインタフェースを提供することが出来るわけ。

まあ、集約だけしたコンテナクラスなんかつくってると、いちいち書くのが
面倒とか、委譲できない言語は駄目とか思ったりするわけだけど、
オブジェクトのあり方をしっかり考えながらを繰り返し設計・実装していけば
setter/getterがなんで必要なのか体感できるようになるかも。

外からいじるため（だけ）に作る集約オブジェクトは、setter/getter
いらない場合もあると思うよ。
0677デフォルトの名無しさんNGNG
>>671
隠蔽しないと個々のオブジェクトとして設計していく意味がないから。

この辺りのことは入門書でも詳しく触れられているんじゃないすか。
読めよ。
0678プロの逝って良しの１ ◆MvRbZL6NeQ NGNG

>>640に洗脳されたアフォはこの先見こみが無いので転業しなさいね。
0679デフォルトの名無しさんNGNG
>>676
getter/setter 方式のメリットは、今は本当にメンバ変数を return したりそれに
代入したりするだけの処理をしていたとしても、クラスを修正したり、それを
継承した子クラスで処理が予想と変わり、get や set する際に何かしら演算を
してからメンバ変数に代入したり、メンバ変数の値を演算したものを返したり
することになることがあるとき。

リファクタリングで言う引数オブジェクトなんかは、とりあえず public な
メンバ変数でもいいのだろうけど。
0680デフォルトの名無しさんNGNG
＞＞６７９ 微妙にsetter/getterの意味を読み違えてるやつ
0681デフォルトの名無しさんNGNG
>>672
どう考えても、「ﾊﾞｶは長文書くな」って意味だと思うよ。
0682671NGNG
どうも、みなさんありがとうございました。
カプセル化（隠蔽）の必要性は本等で
読んでいます。
なので、公開する必要性のあるデータ
のみの話です。

1行のア/サクセサをつらつら書いておくのも
実際には今後の保守や拡張の為の保険って
いうのが主な理由なのですね。
0683デフォルトの名無しさんNGNG
>>678
おまえも非ＯＯの布教活動に躍起になってますね。　
どうですかＯＯから非ＯＯへの洗脳はうまくいきますか？
0684デフォルトの名無しさんNGNG
手続き型も関数型も同じじゃん。procedure か function でしょ。
要するに、void かそれ以外の型を返すか。
0685デフォルトの名無しさんNGNG
>>684
エイプリルフールは終わりましたよ・・・
0686デフォルトの名無しさんNGNG
OOって、データのクラスとそれらを使って何かやる人のクラスと
あると思うんだけど、正式な名称って何？
UMLとか勉強すれば書いてあるのかな
アクターってやつがそうなの？ アクトレスは？
きまぐれオレンジロードの主題歌って誰が歌ってたんだっけ？
0687デフォルトの名無しさんNGNG
>>686
ユースケース図とクラス図を行動しているなおまいは
0688デフォルトの名無しさんNGNG
>>682
違った面から見た理由をいうと
予めアクセサをつらつら書いておく必要があるのは、
メンバ変数のアクセスとメンバ関数呼び出しとで書き方が違うから。
同じ書き方であれば、必要になってからアクセサを書くで充分だったりする。

アクセサはせっかく隠蔽してあるものを透かしてしまう働きがあるとかで
多用すべきではないという話を聞いたことがある。
0689デフォルトの名無しさんNGNG
>671-679
Delphiにはプロパティがあって・・・（以下略
0690デフォルトの名無しさんNGNG
>>682
Beanにしたい　ってこともあるんじゃないですか。
0691デフォルトの名無しさんNGNG
>>684
そのネタ飽きた。
0692デフォルトの名無しさんNGNG
>>686
エンティティ、コントロール、バウンダリ
ロバストネス図を調べてみ。
0693デフォルトの名無しさんNGNG
>>692

なんか、こういう技巧を凝らした用語がOOに対する偏見とか
批判対象を作ってしまうような気がしてる。
0694デフォルトの名無しさんNGNG
全部読んだ。ココ、本当にスゲー！！！
会社で、ここにいるＳＥ程レベルの高い人間が居る？って思っちゃう位。

プロ・アマ含めて相当なスキルある人間集まってると思う。

誰か箇条書きで挙げてくれる人います？

たとえば．．

・絶対継承外すのは、譲れないね！理由は．．．
・多重継承は許さんね！名背なら．．．

みたいな達人達！
0695デフォルトの名無しさんNGNG
オブジェクト指向のオブジェクトとは物体ではなく、対象・目的という意味合いが強い。
解説書には「物として扱う」などとかかれているが、それは微妙にニュアンスが異なる。
「対象として扱う」と記述したほうがより理解が進むであろう。

漏れはオブジェクト指向は目的思考とでも言ったほうが良かった気がする。
objectとまったく同じニュアンスを持つ日本語が存在しないために
苦肉の策としてオブジェクトというカタカナを使ったのだとは思うが、
物体思考だと勘違いする香具師がいかんせん多すぎはしないか。
0696プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
ＯＯマンセーやってた会社はどんどん潰れてるから、昔よりＯＯ派の声が小さい。
0697デフォルトの名無しさんNGNG
>>696
> ＯＯマンセーやってた会社はどんどん潰れてる
ｿｰｽｷﾎﾞﾝ
0698プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
>>695
そんなネタしか無いのか？
0699デフォルトの名無しさんNGNG
>>696
OOコンサルなんかやってた詐欺師連中は、新しいネタ探しにいってるだろな。
IT関連のベンチャーなんて、開発なんか本心ではﾄﾞｳﾃﾞﾓｲｲと思ってる山師ﾊﾞ
ｯｶﾘだからナー。

普通に使える人がイッパイいる会社では、普通に使ってるんじゃないのかね。
0700プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
でも、その調子で、「ＯＯだ、ＯＯだ」と言いながら
巧いこと騙して手続き型に導くのも手だな。
0701プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
>>697
仮定法
0702プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
４月。
新入社員の中には「ＯＯやります」という会社の説明を受けて入ってみたら
クラス名が番号だったり、mainメソッドに全部書くキマリの会社だったり
するのが居るだろう。
0703デフォルトの名無しさんNGNG
>>700

漏れは非OOと見せかけてOOするステルスOOやってますた
0704デフォルトの名無しさんNGNG
>>702
そういうダメダメな会社はＯＯ以前につぶれる罠。
0705デフォルトの名無しさんNGNG
適度に荒れているなぁ
>695
『プログラマがやりたいことをオブジェクトにやらせる』
つうのが基本でしょうなぁ．

そういや，オブジェクト指向の説明で『車．走る』なんて
説明していたのもあったなぁ．こんな説明したら初心者は
混乱するのに……

本当は『車．走らせる（プログラマが）』つうのが正解ですな
0706デフォルトの名無しさんNGNG
オブジェクト指向の本質は必要な時にオブジェクトが生成できて、
メソッドの実行結果をオブジェクトに格納させられることだと思う。

Ｃ言語（非オブジェクト指向）なら、
メソッドの実行結果を構造体に格納する場合があると思うけど、
オブジェクト指向言語なら、オブジェクトのメソッドを実行して、
その結果をオブジェクトに持たせることができる。

■Ｃ言語（非オブジェクト指向）
int ret;
KOUZOUTAI *kekka;
ret = methodA(param,kekka);

■ＪＡＶＡ（オブジェクト指向）
int ret;
OBJECT_SAMPLE obj = new OBJECT_SAMPLE
ret = obj.methodA(param) ←　結果はobjに格納


0707デフォルトの名無しさんNGNG
オブジェクト指向の本質はポリモーフィズムだよね。

>>706 のことは、メソッド名は同じでも返り値が違うってのもポリモーフィズム、、、と言っていいのかどうか。
0708デフォルトの名無しさんNGNG
OO厨はオブジェクト指向の本質１つ
　　　　　　　意見がまとめられないのかよ・・・
0709デフォルトの名無しさんNGNG
>>705
> 本当は『車．走らせる（プログラマが）』つうのが正解ですな

車.走れ();

だろう。
0710デフォルトの名無しさんNGNG
>>706
> int ret;
> KOUZOUTAI *kekka;
> ret = methodA(param,kekka);

int ret;
KOUZOUTAI kekka;
ret = methodA(param,&kekka);

の間違いか？
0711デフォルトの名無しさんNGNG
>>708
ほとんどのOO厨がちゃんとしたOOPの定義を知らないで
OOPとはこんなものだろうと推測してOOPの定義を勝手に
つくっているので統一されることはありません。
0712デフォルトの名無しさんNGNG
理系もおちたな
0713デフォルトの名無しさんNGNG
あいかわらずアフォばっかりだな
0714デフォルトの名無しさんNGNG
>>705
>>709
つーか現実世界の物体に投射しようとするところがそもそも間違いだと
思うのよ。プログラムで扱いたいことってそういう「物体の表現」ではない
わけでさ。そういう意味では>>695の説明が実に的確だと思うんだが。
0715デフォルトの名無しさんNGNG
まあそれにしても

＞オブジェクト指向の本質は必要な時にオブジェクトが生成できて、
＞メソッドの実行結果をオブジェクトに格納させられることだと思う。

こんなこと正気で考えているなら、今すぐ業界から足洗ったほうがいいよ。
きっと上司も冷たいだろう。
0716デフォルトの名無しさんNGNG
指向のオブジェクトがあるなら究極のオブジェクトもあるんですか？
0717デフォルトの名無しさんNGNG
>>715

面白くない煽りは要らない。


漏れはOO大好き野郎だが、OOはいろんな側面がある。教科書的には
１）カプセル化（encapsulation）
２）継承（inheritance）
３）多様性（polymorphism）
４）均一性（uniformity）

基本要素はこれ。その中でも多様性がブッチギリで重要かつ便利な機能であることは確かだ。
0718デフォルトの名無しさんNGNG
>>714
オブジェクト指向の object は、物体の意味じゃなくて、subject に対する object でしょ。
だから、subject（プログラマ）が、object（対象）に命令する形が自然。
だからメソッド名は命令形なんだよ。

car.run(); // 「車よ、走れ」とこっちが相手に命令

0719デフォルトの名無しさんNGNG
subject は、主体、相手を服従させるという意味、つまりすべての権限を握っている者、
つまりプログラマのこと。
object は写真撮影の被写体とかいうけど、ようするにいじくり回されるものの意味。
つまり、A Programmer subjects objects. （プログラマがオブジェクトを支配する、
思い通りにいじくり回す）という発想。
オブジェクト指向を「物指向」と訳した人は、この語感がわからなかったんだろうね。

つまり、OO では、object が独立してあるわけじゃなくて、そこには subject に
支配されることが前提という語感がある。
｢物指向｣と訳しちゃった人は、object が自律的に動く、現実世界の｢物｣に対応
させたけれど、それは誤り。
0720デフォルトの名無しさんNGNG
>>718-719
サブジェクトがメソッドを使ってオブジェクトをいじくり回すということね。

おれはむかし、'90 年頃、オブジェクト指向の話を聞いて、とりあえず .c を
みんな .obj にしておいて、そこからどうにかするとリンクからだから速く作れて
便利なものだと勝手に理解していた。

0721プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
>>719
死ね
0722デフォルトの名無しさんNGNG
>>719
ということはエージェント指向は、subjectの意識に逆らって
objectが自立しって動く指向なのですね？
0723デフォルトの名無しさんNGNG
誤った定義でも批判出来なかったのですね？
0724デフォルトの名無しさんNGNG
>>722
そう。
0725デフォルトの名無しさんNGNG
非ＯＯが入力プロンプトで人間が動くソフトウェアドリブンな方式
ＯＯがマウスクリックなどのイベントでソフトウェアが動くイベントドリブンな方式

のような印象があるな。
0726デフォルトの名無しさんNGNG
>>722
自立はしませんね。自律はするけど。
でもまあ、いままで subject - object という枠組みだったから、agent な
object がある程度の裁量権を持つというのはそれなりに画期的だったから、
それがわかる人には注目されてきたわけだ。
0727デフォルトの名無しさんNGNG
>>725
OO とイベント・ドリブンとは関係がない。ただ、イベント・ドリブンなフレームワークに
OO はなじみやすいというのは確か。
0728デフォルトの名無しさんNGNG
>>721
知らなかったからって、まあ、怒るな。マターリいきませう。
0729デフォルトの名無しさんNGNG
>>722
別の環境でいろいろといじくり回されるということ。
こっちからどっかに転送されてしまったエージェントは、どっかで
どうメソッドを呼ばれるのかわからない。
やられたい放題。
だから、セキュリティを確保するために、どこにいっちゃっても、
本当にめちゃくちゃにいじりまわされないような合意が必要。
0730デフォルトの名無しさんNGNG
>>716
究極のオブジェクト＝ぶろぶ

COBOLerなんかが作ってくれるらしいよ。
0731デフォルトの名無しさんNGNG
>>717

違います。ポリモーフィズムが重要なのは
設計以下であり、全般的にわたって重要かつ基本なのは
メッセージパッシングとカプセル化です。

これがわかってないとクラスの責務の重要性
が理解できない。



0732デフォルトの名無しさんNGNG
宗方指向
0733デフォルトの名無しさんNGNG
>>717
> ４）均一性（uniformity）

基本要素にこれが入るってあまり聞いたことがない。
少し調べてみたけど、多様性との違いがわからなかった。
0734デフォルトの名無しさんNGNG
で、１は理解できたのか？
0735デフォルトの名無しさんNGNG
自分で考えようとしない奴には誰が教えたって同じさ。
0736デフォルトの名無しさんNGNG
ここはやはりアプリを作ってだな・・・
0737デフォルトの名無しさんNGNG
>>731
細かい役割担当者の組み合わせで大きな仕組みを実現する、っていう
構造が再帰するような構造にしとくと、馬鹿なオイラにも分かりやす
い。

OOはヘンな宗教じゃなくて、物覚えの悪い馬鹿に優しい仕組みだと、
おいらは思うじょ。
0738デフォルトの名無しさんNGNG
>>731

>細かい役割担当者の組み合わせで大きな仕組みを実現する

731がいいことゆうた。
0739デフォルトの名無しさんNGNG
>>738

737のまちがえ。
0740デフォルトの名無しさんNGNG
>OOはヘンな宗教じゃなくて、物覚えの悪い馬鹿に優しい仕組みだと、
>おいらは思うじょ。

まったくもって同感。
オブジェクト指向は難しいものだと思い込んでる人に、そう説いた経験がある。
現在はその相手もそう思ってると聞きました。
0741737NGNG
いや～、今日、死ぬほどたくさんのプリミティブ値の配列を準備して、全てその
配列への操作と大量のスイッチ文でプログラムを実現する、「根性の賜物」ソー
スを追う羽目になりまして、「ああ、ｺﾚ作った奴がOOをちょっとでも知ってたら、
オイラも楽だし、作った奴も楽だっただろうにな～…何がなんだか分からんよ　つд`)」
と思ったのデス。

根性なしのオイラからみると、作者はある意味えらいとおもうんだけど、その根性
をすこしでも情報収集に向けてくれてれば…
0742705NGNG
>709
確かに命令形の方がわかりやすいけど，あえて使役の形にしたのは
「車を走らせるためにプログラマがお膳立てをしている」
というニュアンスを含めたかったから．
……まあ，大した意味は無いけどね

>714
オブジェクト指向の良いところは，（生まれてきてから何度となく繰り返して
きている）現実世界での行動との相似性を利用できるところだから，
『現実世界の物体に投射しようとする』のはそんなに的外れじゃないよ．
＃方向は逆だけどさ

>717
要素ではあるけれど，本質じゃないよ．
結局，『繰返し習得して身につけた現実世界のメタファをプログラムに利用する』
つうのがオブジェクト指向の良いところじゃないのかな？

>719
英語で"object"が『物体』『目的』『対象』という意味を持つように，向こうさん
にとっては，このあたりの概念はかなり混然としたものなんじゃないのかな？
抽象的な概念を『物体』のように扱ったり……ただのヨタです．外国人のこと
良く知らないし．

>737
人間３つ以上のことは同時に憶えていられないから……
良くできたライブラリがあれば，かなり乱暴なプログラムをしてもマトモに
動作するからねぇ


0743デフォルトの名無しさんNGNG
> オブジェクト指向の良いところは，（生まれてきてから何度となく繰り返して
> きている）現実世界での行動との相似性を利用できるところだから，
あと、パラメータを追加した時に外部の変更を最小限に抑えられる
とか、実行フローからの独立性が高くなるとか。
0744Java太郎 ◆DMVtSSFzcg NGNG
>>734
いいえ。
最近、さぼってました。
マルチスレッドの所で疲れました(プログラミングレッスン下巻）
しばらく、休みます・・・ゴホッゴホッ。
0745デフォルトの名無しさんNGNG
>>743
その引用部分は笑うところだと思うんだが。
0746デフォルトの名無しさんNGNG
現実世界の物体に自律して動くものがどれだけあるつうの？
殆どは受動的だよ。
0747デフォルトの名無しさんNGNG
>>1
ついでに、

「貴様ら！エージェント指向を教えろ！」
「貴様ら！アスペクト指向を教えろ！」

スレも立ててくれ
0748ヽ(´ー｀)ノNGNG
あー aspect 指向興味あるんだよな。関連スレ立ってなかったけ？
0749名無し＠沢村NGNG
>>746
＞現実世界の物体に自律して動くものがどれだけあるつうの？
殆どは受動的だよ。

ヌヒよ、すべての物体は自立して動いてるよ。わかるか？
ヌヒよ、すべての物体は原子からなっており、原子核の周りを電子が回ってるよ。能動的にな。
ヌヒよ、すべての物体は能動的なんだよ。わかるかな？
0750デフォルトの名無しさんNGNG
>>746
ネコ。
0751デフォルトの名無しさんNGNG
くされ、だな。現実世界で、お金がもらえなければみっともねーだろう。
0752デフォルトの名無しさんNGNG
>すべての物体は原子からなっており、原子核の周りを電子が回ってるよ。能動的にな。
本気で言ってるのか？
0753デフォルトの名無しさんNGNG
電子は自らの意思で原子核の周り、つかず離れずの位置を保っている。
この電子の意図は神すらも計りえない。これをハイゼンベルグの不確定性原理という。
0754705NGNG
>753
そこまでいくと受動も能動もクソもミソも無いだろうに。
疑似問題で言葉遊びされてもなぁ。
0755デフォルトの名無しさんNGNG
モノが能動的に動いていようがそうでなかろうが、モノを観察する人、
使用する人にとっては、モノに対するどんなアクションにどんなリア
クションがかえってくるかということ以外に、興味はないですの。
0756デフォルトの名無しさんNGNG
>>753
電子に聞いたのか？　おまえは電子の何がわかる？　おまえは電子の何なんだ！
電子が本当にそういったんだな？　電子がいったのだったら謝るが、それが何？
0757デフォルトの名無しさんNGNG
>>756
おまえは聞いたことないのか？　おまえはわからないのか？　おまえは知らないのか！
当然そういったんだよ！　早く謝れよ！　だから何？　
0758デフォルトの名無しさんNGNG
（プッ
0759デフォルトの名無しさんNGNG
>>757
ごめんなさい。
0760デフォルトの名無しさんNGNG
>>753
> これをハイゼンベルグの不確定性原理という。

言わないって。
0761デフォルトの名無しさんNGNG
× ハイゼンベルグ
○ ハイゼンベルク
0762デフォルトの名無しさんNGNG
>>745
>その引用部分は笑うところだと思うんだが。
同意。
0763デフォルトの名無しさんNGNG
>>742
クラスは抽象データ型の雛型です。
現実世界の雛型という定義は本質からズレてる。
0764デフォルトの名無しさんNGNG
液晶テレビ「AQUOS」が当たるチャンス
http://camellia16.fc2web.com/gpoint.html
0765デフォルトの名無しさんNGNG
死死死死死死死死死死死死死死死死死死死死
0766プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
受動的なオブジェクトを支配下においてメインは手続き型で書く。
部品化可能なモジュールは見とおしが良いからすぐ思いつく。
逆に無理やり部品化したようなのは破綻しやすい。
上位層は構造化。
ＵＭＬ図は無用の長物。
これがあるべきプログラミングの最終結論。
0767デフォルトの名無しさんNGNG
すいません。
オブジェクト指向って、情報隠蔽、継承、多態性が柱だそうなんですが、
多態性って柱とまで言うほとのものなんですか？
だって結局のところ同じメッセージ受け付けるかどうかってだけですよね？
0768デフォルトの名無しさんNGNG
>>767

例えば COM とか UDDI とかのインタフェイス抽象のことを考えると
多態性ってのの実用性もわかると思うけど。

あとテンプレートとかメソッド名での late binding な Smalltalk みたいな
言語とかを使うと、「同じメッセージ受け付けるだけ」ってのが案外便利な
技法だってことに気付くと思う。
0769デフォルトの名無しさんNGNG
>>767
ダイナミックバインディングの便利さを知っているか？
0770デフォルトの名無しさんNGNG
ここは実装ヲタばっかりだな。継承やポリモが
重要というやつの実装は概念モデルがめちゃくちゃ
で他人には容易に理解できないという罠。
0771dNGNG
最新情報です。
甘く見てると痛い目にあう典型みたいなヤツだな。ｗ

http://www.deai-navi.net/linkrank/linkrank.cgi?mode=in&id=fdeai
0772デフォルトの名無しさんNGNG
オブジェクト指向、Strict-XHTMLと極右思想
http://tmp.2ch.net/test/read.cgi/sisou/1049523041/l50
0773デフォルトの名無しさんNGNG
ｵﾌﾞｼﾞｪｸﾄ指向とは・・・
簡単に言うと、「ｽﾎﾟｰﾂ」って言葉がある。
このｽﾎﾟｰﾂに属する物に「ｻｯｶｰ」とか、「野球」とかってあって、それが・・・

　　　　　　　　　　　　　（中略3379文字）

・・・いてはいけないよ！って言ってお茶を飲んだ。
0774デフォルトの名無しさんNGNG
>>766
perlのこと？
0775デフォルトの名無しさんNGNG
金・銀パール
プレゼント！
0776プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
>>774
めまいがする言語はカンベンして
0777デフォルトの名無しさんNGNG
>>776
じゃあおまえはどの言語ならめまいがしないんだよ
0778プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
パール以外
0779デフォルトの名無しさんNGNG
>>778
オブジェクト指向言語は別にいいのか？
0780デフォルトの名無しさんNGNG
>>778
関数型言語は？
0781デフォルトの名無しさんNGNG
関数型言語はメンテしやすいよ。
副作用が表に出てくる言語なんかより保守性はずっと上だし、
リファクタリングも掛けやすい。
副作用をストリームに隠蔽したりする考え方は、他の言語で
書くときも応用できる。
0782プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
普通に仕事で使う言語以外しらんな。
0783あぼーんNGNG
　　　______________
　／:＼.＿＿＿_＼
　|:￣＼(∩´∀｀)　＼　　＜先生！こんなのがありました！
　|:在　 |:￣￣ U￣:|
http://saitama.gasuki.com/aomori/
0784佐々木健介NGNG
　　　　　＿＿＿＿_＿
　　　 ／＿　　　　　　|
　 　 /.　＼￣￣￣￣|
　　/　　／　 ―　― |
　　|　 /　　 　-　　- |
　 ||| (5　　　　　　>　|
　| | |　　　　 ┏━┓|　　 ／￣￣￣￣￣￣￣￣￣￣
| | | | 　　　　┃─┃|　 ＜　こんなサイトを見つけた
|| | | | 　＼　┃　 ┃/　 　 ＼　　正直、スマンカッタ
| || |　|　　　￣　　　　　　　　　＼＿＿＿＿＿＿＿＿＿
http://saitama.gasuki.com/hiroyuki/
0785あぼーんNGNG
　（　・∀・）＜　こんなのみつけたっち♪　
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
0786あぼーんNGNG
　　　　　　　　　　　　　∩
　　　 　 　 ∧＿∧ 　　| |　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　 　 （　 ´Д｀）／/　　＜　先生！こんなのを発見シマスタ！
　　　　　 ／ 　 　 　 /　　　　｜
　　　　 / /|　　　　/　　　　　　＼ 　http://saitama.gasuki.com/koumuin/
　 ＿＿| | .|　　　　| 　　　　　　　 ＼
　 ＼　 ￣￣￣￣￣￣￣＼ 　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　||＼　　　　　　　　　　 　 ＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　 　 .||　 　 　 　 　 　 　 ||
0787あぼーんNGNG
　　 ,.´ / Vヽヽ
　　　 ! i iﾉﾉﾘ）) 〉
　　　 i l l.´ヮ｀ﾉﾘ　＜先生！こんなのがありました！
　　　 l く/_只ヽ 　　　
　　|￣￣￣￣￣|
http://muryou.gasuki.com/sinagawa/
0788デフォルトの名無しさんNGNG
>>782
勉強しろよ
0789デフォルトの名無しさんNGNG
無知が癇癪を起こしている
0790767NGNG
結局多態性ってのは単に「同じメッセージを受け取れる」ってことに名前を付けただけなんですね。
dynamic bindingが便利かどうかなんてこのさいどうでもいいんでしょ？
0791デフォルトの名無しさんNGNG
うん
0792デフォルトの名無しさんNGNG
>>790
話に参加したかったら基礎的な用語ぐらい勉強してからにしようね。
0793デフォルトの名無しさんNGNG
大した物じゃないけど、いざ実装してみると色々便利だったりする。
OOにシフトする際になんかめりっとあるかって言われたとき、
実装レベルの便利さを立ててあげてもいいんでないかなあ。
0794デフォルトの名無しさんNGNG
プログラミングに大した物なんてない。
その中で最高の物の一つが多態性。
0795デフォルトの名無しさんNGNG
>>794
手続き（関数）をスッキリ構造化する手段として、便利ですが。

JavaDocとか、最近はやりのUMLベースIDEみたいな、クラス構造に関するドキュメントを
自動生成してくれるフレームワークがあると、仕様の後追いがすごい楽でつ。
0796デフォルトの名無しさんNGNG
メンバ変数をprivateにしてメンバ関数からアクセスさせて壊れにくくさせると
いいますが、けっきょくクラス内部で条件指定などをしてあげないと
壊れにくくならないので、それって普通の関数でも同じじゃんと思ってしまうのは
漏れだけでしょうか？
0797bloomNGNG
http://www.agemasukudasai.com/bloom/
0798デフォルトの名無しさんNGNG
>>796
そのメンバ変数はそのクラスのメンバ関数以外からは変更されない

普通の関数と同じじゃないだろ
0799767NGNG
>>792
こういう何か言ってそうで何も言ってない(言えない。言うだけの頭がない)人間との話になんて参加したくもありませんよ。
0800デフォルトの名無しさんNGNG
その 「だけ」 のことが便利だから柱の一つと呼ばれてるんだが。
このスレを 1 から読むなりデザパタでも調べろ。
0801デフォルトの名無しさんNGNG
>>799
はあ、そうですか。　だから？　何？
0802デフォルトの名無しさんNGNG
>>799
参加したくない場合に取るべき行動は何かわかるか？
ここに来るなってことだよ。

さっさと消えな。
0803705NGNG
>多態性
多態性というよりも、グルーピングといったほうがピンと来そうだけど……

せっかくオブジェクトとしてそれぞれ独立させたんだったら、相手の
オブジェクトのことは（必要最低限のこと以外は）知らなくても良いように
したくない？

多態性があると、『このオブジェクト群には、こう命令すれば動いてくれる』
といった感じに何種類かのオブジェクトをひとまとめにして取り扱うことが
できるので、そのオブジェクト群を使うオブジェクトが、そのオブジェクト群を
個別に扱う必要が無くなる->オブジェクトがシンプルになる。という訳。
wigetなんかの設計をするときに多態性がなかったら死んでますな………

＃さらにこの考えを推し進めると、もっと便利になるよ。
＃Rubyだと、そもそも同じ名前のメソッドだったら、継承関係の無い
＃オブジェクトでさえも同じように扱える。

このへんは現実世界でも良くあることで、例えば
・テレビ用のリモコン
・AVコンポ用のリモコン
・エアコン用のリモコン
なんかは、とりあえずpowerボタンを押せば、それぞれの装置のことを
あまり詳しく知らなくてもスイッチを入れることができるよね。
多態性って、そのあたりのメタファーなんじゃない？
0804デフォルトの名無しさんNGNG
つーかさ、VBでも多態性簡単に実装できるんだけど･･･。
なんか勘違いしてない？
0805デフォルトの名無しさんNGNG
どっから VB の話が？
0806デフォルトの名無しさんNGNG
Cでも多態性実装できますね。
アセンブラでも実装できますね。
0807705NGNG
つづき
次に逆の方向になるけど、次のようなケースも多態性が必要になるケースですな。
すでにできあがっている／作りかけのシステムに機能（仕組み）を追加したくなった。
その機能は全く新しい機能なので、既存のオブジェクトを調整するだけでは
実現できないけど、機能を実現するための仕組みは従来のオブジェクトを
操作する方法を利用できそうだ。
（実際うまく設計できれば、様々な機能を同じ仕組みの上で実現することができる）

そこで、『このオブジェクト群と同じ命令を受け付ける様にする』すなわち多態性を
利用することによって、既存のシステムの仕組みを変更することなく新しい機能を
追加することができる。
こっちのほうがいわゆる『多態性』になるのかな？

このへんも現実世界で良くあることで、タイプライターとコンピュータのキーボード
なんかは良い例ですな。

つまり、多態性によって『機能』と『仕組み／操作方法』を分離することができるつうのが
『多態性』を重要なものにしている要因だと思うんだけど、どう？
0808デフォルトの名無しさんNGNG
>>806
VBと違って専用の命令ないけどね。
0809デフォルトの名無しさんNGNG
>>808
VB は命令で多態性を指示するのか。
悔しかったら VB で Template Method パターンをやてみろ。
0810デフォルトの名無しさんNGNG
>>806
昔、オブジェクト指向言語が簡単に手に入らなかったときに、
前向きにやろうということでそういうのを掛け声にすることは
あったけど、何が悲しくていまさらそんなことを。
0811デフォルトの名無しさんNGNG
ポータビリティのため。
0812デフォルトの名無しさんNGNG
>>811
厳しい環境だね。ご苦労さん。
0813プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
多態デムパが暴れてるスレはココですか？
0814デフォルトの名無しさんNGNG
>>808
VBって、どんな命令でかくの？
0815デフォルトの名無しさんNGNG
>>770

いいことゆうた。ここみてるとオブジェクト指向って
実装レベルでしか浸透してないなーとおもふ。
0816デフォルトの名無しさんNGNG
>>809
へぇ～ 継承が出来ないから、Template Method"は" できないの知ってるみたいだね。
でも継承を使わないパターンは実装できるんだよ。
もちろん多態性が必要なパターンもね。

>>814
多態性といえばimplementsでしょ。Javaと同じ。
0817デフォルトの名無しさんNGNG
>>816
質問っす。
最近Implements (VB)知ったんだけど，べつにこれ使わなくても多態はできるん
だよね。ただ、他の強制力が多少はたらくっつーか、コードが書きやすくなる
っていうくらいで。
0818デフォルトの名無しさんNGNG
VB.NETがでたんだから、VBのクラスはもういいじゃん。
0819デフォルトの名無しさんNGNG
>>817
アーリーバインドとレイトバインドの違いもある。
オレとしてはコードのカキ易さ(+読みやすさ)も重視したいところだが。
0820デフォルトの名無しさんNGNG
実装(少なくとも定義)忘れが無くなるのはかなり便利だと思う。
0821デフォルトの名無しさんNGNG
>>816
インターフェースの継承しかできないじゃん。
「できる」っていえばできるけど、両足を縛られて 100 m 走をやれって
ゆうようなもんだよ。
0822デフォルトの名無しさんNGNG
VB6 までで、まともなオブジェクト指向設計しようとすると、
やってみればわかるけど、インターフェースの継承しかできないばっかりに、
かなりひねくれた設計になるぞ。
たとえば、メソッドの引き上げは不可能だから、別のクラスにして、すべての
子クラスからそれを呼ぶようにするとか。
かなりひずんだ設計になる。
0823デフォルトの名無しさんNGNG
> たとえば、メソッドの引き上げは不可能だから、別のクラスにして、すべての
> 子クラスからそれを呼ぶようにするとか。
要するに委譲のことですね。委譲は別に歪んだ設計じゃありませんよ。
0824デフォルトの名無しさんNGNG
>>821
始めっからインターフェースの継承の話しかしてないじゃん。
なに一人であつくなってんの？
0825ヽ(´ー｀)ノNGNG
委譲自体は歪んだ設計じゃないけど、委譲だけの設計ってのも異常だよなぁ…。
…あ、いや、シャレじゃなく。
0826デフォルトの名無しさんNGNG
>>823
委譲というか、オブジェクト・コンポジション。
オブジェクト・コンポジションはひずんだ設計じゃないが、メソッドの
引き上げをする場面でオブジェクト・コンポジションを使うと言うのは
ひずんだ設計だよ。
0827デフォルトの名無しさんNGNG
委譲っていうのは、自分自身のインスタンスをどれか別のクラスに渡すこと。
0828デフォルトの名無しさんNGNG
なんでメソッドの引き上げってリファクタリングの話してんだ？
設計の話だろ。VBなんだからVB用の設計をするだけの話だろ。
0829デフォルトの名無しさんNGNG
>>824
> 始めっからインターフェースの継承の話しかしてないじゃん。

ちがうねえ。VB で多態性ができるという話が始まったんだねえ。
インターフェースの継承も多態性のひとつだけど、抽象クラスの継承も
多態性なんだね。
0830デフォルトの名無しさんNGNG
>>828
リファクタリングは設計です。
0831デフォルトの名無しさんNGNG
VBでオブジェクト指向の話をすると
かならずメソッドの引き上げとtemplate methodの話で対抗する
奴がいますねぇ（ｗ
0832デフォルトの名無しさんNGNG
>>829
> インターフェースの継承も多態性のひとつだけど、
結論。VBで多態性は実装できる。
0833デフォルトの名無しさんNGNG
>>831
OO の定石だからね。できないとすごく不便。まともなクラス設計はできない。
すごくひずんだ設計になる。
って、OO のクラス設計をやったことがないとわからないか……
0834デフォルトの名無しさんNGNG
>>830
残念ながら違います。そんなアフォな事言っているのは貴方だけです。
0835デフォルトの名無しさんNGNG
>>832
VB で多態性は中途半端に実装できる。
0836デフォルトの名無しさんNGNG
>>835
中途半端ではないですね。ちゃんと多態性になっているのですから。
0837デフォルトの名無しさんNGNG
>>833
あなたはCでOOやったことありませんね。
0838デフォルトの名無しさんNGNG
CでOO出来るって言っておきながらVBでは出来ないって言っている
奴もいるくらいだからねぇ。
まぁ、認めたくないものは認められないって強い信念を持っている奴は
人間的に認められないね。
0839デフォルトの名無しさんNGNG
>>834
それは、古い｢計画的設計｣の頃のお話。
http://objectclub.esm.co.jp/eXtremeProgramming/IsDesignDead.html
進化的設計ではふつうの話。

>>836
クラスの継承で多態性ができないのは、中途半端。

>>387
C で OO はできるけれど、昔、OO 言語で納品できなかった頃の、前向きな
掛け声。できるできないといったらできる。でもひずんでいる。コードも増える。
0840デフォルトの名無しさんNGNG
>>815
実装しないで何すんの？
0841デフォルトの名無しさんNGNG
>>388
VB でも OO はできるが、とてもひずんだ設計になってしまう。
0842デフォルトの名無しさんNGNG
じゃー VB でも多態性の実現はできるけど、C で OO やってるぐらいに
歪んでいる、というのでファイナルアンサー？
0843デフォルトの名無しさんNGNG
C や VB で OO なんて、環境が整ったいまとなっては、わざわざやる意義はない。

0844デフォルトの名無しさんNGNG
>>842
C よりはマシでファイナルアンサー。
0845デフォルトの名無しさんNGNG
>>842
Cよりは歪んでないね。多態性が中途半端にできるのだから。

で、ファイナルアンサー。
0846デフォルトの名無しさんNGNG
要するに、VBで多態をやりたきゃ VB.NET を使ってろってこった。
// 俺は使ったことないから実体はしらんが。
0847デフォルトの名無しさんNGNG
>>846
その方が賢明。
0848デフォルトの名無しさんNGNG
>>846
× 要するに、VBで多態をやりたきゃ
○ 要するに、VBで継承をやりたきゃ

0849デフォルトの名無しさんNGNG
>>848
多態をやると、多くの場合どうしてもメソッドの引き上げがでてくる
（でないと｢ただ一度｣の原則が守れず、バグが散在する）から、訂正する
必要はないです。
0850デフォルトの名無しさんNGNG
中途半端中途半端いっておきながら、
実際自分がVBで作ると多態性やっている罠。
0851デフォルトの名無しさんNGNG
> 多態をやると、多くの場合どうしてもメソッドの引き上げがでてくる
ただ設計が悪いだけだろ（藁
0852デフォルトの名無しさんNGNG
>>851
違うね。
同じ継承ツリーにあるってことは、どの子クラスにも共通した
処理って言うのがあるんだよ。多くの場合。やってみればわかるけど。
何の関係もないクラスを同じ親から継承しているんなら別だけど。
0853デフォルトの名無しさんNGNG
>>851
VCL や Java SDK の継承ツリーを見てみろ。
0854デフォルトの名無しさんNGNG
オブジェクト指向のやりやすさ
Java・C#・VB.NET > C++・Delphi > VB > C > アセンブラ
0855デフォルトの名無しさんNGNG
>>854
そんな感じだろうね。
0856デフォルトの名無しさんNGNG
どうせオブジェクト指向で継承使いまくるのって
GUIの部分ぐらいじゃん。
他は一段くらい継承して終わりでしょ。
GUIがコンポーネントとしてまとめられている場合、
継承なんかほとんど使わないよ。
0857デフォルトの名無しさんNGNG
>>856
VCL や Java SDK のソースの GUI じゃない所を見てから家。
0858デフォルトの名無しさんNGNG
>>857
へぇ～。具体的にどこかなぁ～。ｗ
0859デフォルトの名無しさんNGNG
>>856
1 段でも、同じ親から継承した子クラスで同じ処理が出てきたときは、
1 つのメソッドにまとめて親クラスに持っていくんだよ。
OO したことがない人が想像で言っているんだろうけど、
「どうせ」も何もない。
そんな場面は、たくさん出てくる。
0860デフォルトの名無しさんNGNG
>>858
TBDEDataSet とか、よく読んでみろよ。
0861デフォルトの名無しさんNGNG
http://yahooo.s2.x-beat.com/linkvp/linkvp.html
0862デフォルトの名無しさんNGNG
↑死にさらせ
0863デフォルトの名無しさんNGNG
>>858
Java やったら java.io のストリーム系、たとえば java.io.BufferedOutputStream あたり
おもしろいよ。
0864デフォルトの名無しさんNGNG
>>856
え、コンテナクラスはGUIでない継承を使いまくった例だが、
お前は使ったこと無いんだろうな。
0865デフォルトの名無しさんNGNG
>>856>>858
C++ なら std::iterator とその派生クラスとか楽しいよね。
0866デフォルトの名無しさんNGNG
>>864
そうか、そういう人が多いからメソッドの引き上げなんてできなくてもいいなんて
変なことを堂々と言えちゃう人がいるわけだ。
0867デフォルトの名無しさんNGNG
論破され無知を暴露する馬鹿な>>856でしたとさ。
0868デフォルトの名無しさんNGNG
結局継承使って実装することってなさそうだな。
使用すべきところはライブラリの範囲ばかりだ。
0869デフォルトの名無しさんNGNG
>>868
じゃあ、オリジナルの処理は OO で書かないんですね。
0870デフォルトの名無しさんNGNG
>>869
まだうまく自前の処理を OO で書けないから、そういった例がライブラリだけの
ことだと思い込んでるのでは。
0871デフォルトの名無しさんNGNG
やっと話が落ち着いてきたな。
俺的にはVBでも多態ができることが分かって勉強になったよ。
0872デフォルトの名無しさんNGNG
>>868
君には必要ないよ。だってCOBOLerでしょ？
0873デフォルトの名無しさんNGNG
>>870
でも実際ないしね。
0874デフォルトの名無しさんNGNG
>>870
それか、ものすごく規模の小さいプログラムとか。たとえば、フォームに
部品を貼り付けて、イベント・ハンドラに数行書く程度の。
0875デフォルトの名無しさんNGNG
>>873>>874
それなら、メソッドの引き上げもないね。
0876デフォルトの名無しさんNGNG
>>873
設計のうちに入らんな。お勉強サンプルぐらいか。
0877デフォルトの名無しさんNGNG
いや、OOはいるけど継承はいらないよ。
0878デフォルトの名無しさんNGNG
Hello,Worldを書くためにはOOは必要ないな。
0879デフォルトの名無しさんNGNG
VB や Delphi でメモ帳もどきを作るのにも OO も継承もいらないね。
0880デフォルトの名無しさんNGNG
要らないケースしか知らないから、要らないと言い張ってるのか。
0881デフォルトの名無しさんNGNG
>>871
そのおかげで、VBUnit なんかがかろうじて作れたりする。
けど、完全に OO してないから、コア部分は VC++ 製の DLL にして逃れているけどね。
0882デフォルトの名無しさんNGNG
データベースから値ひっぱってきてHTML吐くだけでもいらないね。
0883デフォルトの名無しさんNGNG
>>881
> コア部分は VC++ 製の DLL にして逃れているけどね
うそつけ。
0884デフォルトの名無しさんNGNG
OO必要ないプログラムしか作ってない人が、OOなんて無意味っていうのって
電車で会社と家の往復だけの生活してる人が、高速道路なんて必要ないから無意味っていってるのと同じ感じですね。
0885デフォルトの名無しさんNGNG
うんうん。地球で生活している人が宇宙船なんかいらないと言っているのと同じだ。
0886デフォルトの名無しさんNGNG
vbUnitのコアはVBソースつきなんだけどなぁ。
Dependancy Walker使ったらちゃんとMSVBVM60.DLLリンクされてるし。
0887デフォルトの名無しさんNGNG
>>883
嘘でした。
0888デフォルトの名無しさんNGNG
うんうん。家に包丁がない人が砥石なんていらないと言っているのと同じだ。
0889デフォルトの名無しさんNGNG
うんうん、手が使えない人がペンなんて不要だと言っているのと同じだ。
0890デフォルトの名無しさんNGNG
結局実生活じゃいらないんじゃん。
0891デフォルトの名無しさんNGNG
うんうん。頭が使えない人が理論なんて不要だと言っているのと同じだ。

0892デフォルトの名無しさんNGNG
うんうん、OO で設計しない人が OO なんていらないといってるのと同じだ。
0893デフォルトの名無しさんNGNG
でもOO設計できる人がいらないって言ってんだから間違いないだろうね。
0894デフォルトの名無しさんNGNG
>>893
s/OO設計できる人/OO設計できると思っている人/
0895デフォルトの名無しさんNGNG
>>893 は、同じ処理があっちこっちにあって、バグもあっちこっちにあって、
汚いプログラムを書いているか、>>874 のようなのしか作ったことないか、
だろう。
0896デフォルトの名無しさんNGNG
OOいるって言っている人がOO設計できると思い込んでるんだからたち悪いね。
0897デフォルトの名無しさんNGNG
まあいらないと思う人は使わなければいいだけでしょ。俺は必要だから
使う。それだけ。
0898デフォルトの名無しさんNGNG
うんうん。OO で設計できると思い込んでいる人が、OO がいらないと言っているのと同じだ。
0899デフォルトの名無しさんNGNG
うんうん。OO で設計できると思い込んでいる人が、OO がいると言っているのと同じだ。
0900デフォルトの名無しさんNGNG
.
0901デフォルトの名無しさんNGNG
なんも無いんかい…
0902デフォルトの名無しさんNGNG
うんうん。OO のライブラリしか見たことがない人が、OO の設計はライブラリだけのものだと言っているのと同じだ。
0903デフォルトの名無しさんNGNG
うんうん。OO のライブラリ _すら_ 見たことがない人が、OO の設計はライブラリだけのものだと言っているのと同じだ。
0904デフォルトの名無しさんNGNG
でも真実はOO使いこなしている人がOOいらないといってるんだから間違いないでしょ。
0905デフォルトの名無しさんNGNG
でも真実はOO使いこなしていると思い込んでいる人がOOのライブラリをのぞいたこともないといってるんだから間違いないでしょ。
0906デフォルトの名無しさんNGNG
OO使いこなしてる人って誰さ
0907デフォルトの名無しさんNGNG
まっそういうデマを信じちゃう奴には何をいってもダメなわけで。
0908デフォルトの名無しさんNGNG
>>904
メソッドの引き上げって、C マガとかの初心者向けの記事にも出てくるよな。
επιστημηさんよりすごいのかい。君は。
0909デフォルトの名無しさんNGNG
>>906
OOいるって言っている人にとって都合のいい架空の人物。
0910デフォルトの名無しさんNGNG
>>908
その通り。
0911デフォルトの名無しさんNGNG
>>904
そこまでいうなら、
http://www.freeml.com/ctrl/html/MLInfoForm/[email protected]
で、επιστημη氏はじめたくさんのエンジニアの前で論破してみろ。
cppll ML で待っている。
0912デフォルトの名無しさんNGNG
>>911
匿名じゃなくなるので却下。
0913デフォルトの名無しさんNGNG
>>912
Hotmail でもいいんだよ。匿名メールの制限は設けられていないから。
0914デフォルトの名無しさんNGNG
結局>>868のような奴が一番OOの恩恵を受けてるわけですね。
0915デフォルトの名無しさんNGNG
>>914
そういうやつのための OO でもあるからね。
知らないうちに OO を使っている。そのうち自分でも OO の設計ができるようになる。
向上心があれば。
0916デフォルトの名無しさんNGNG
うんうん～系の１行レスには反論する価値さえないわけだが。
まあリファクタリングもしない奴には継承の有用性もわからんのだろう。
0917デフォルトの名無しさんNGNG
継承が有用と思えない奴はリファクタリングしても継承しないと思いますが何か？
0918デフォルトの名無しさんNGNG
>>917
思えないんだったらもう仕方ないね。
0919デフォルトの名無しさんNGNG
>>917
きみの OO 技術がいかに優れているのか、匿名メールでもいいから cppll ML で
紹介して、人類文化の発展に寄与してくれたまへ。
0920デフォルトの名無しさんNGNG
うんうん系　うんうん系　継承は
うんうん系　うんうん系　いらないよ
そんな　運動
0921デフォルトの名無しさんNGNG
続きが思いつかなかった……
0922デフォルトの名無しさんNGNG
じゃあ取りあえず、OOでOS作ってくれ。
OOでないOSならばいくつかあるんで、OSを作れたらOOは素晴らしいと認めよう。
0923デフォルトの名無しさんNGNG
OO のライブラリを見たこともない人が OO で作ったものの評価ができるわけがない。
0924デフォルトの名無しさんNGNG
姉さん、OO で設計できない人が OO で作ったものの評価ができるわけもなく……
0925デフォルトの名無しさんNGNG
あれあれ、OSという複雑なものこそOOで作る価値が無いかい？
OSが出来ないならコンパイラでもいいよ。
0926デフォルトの名無しさんNGNG
>>922
もうある。評価しろ。
http://www.csl.sony.co.jp/project/Apertos/

0927デフォルトの名無しさんNGNG
BeOSとかいってみよう。
少なくともWindowsでさえもOOしていると思うんだけどな
(程度の問題はおいといて)
0928デフォルトの名無しさんNGNG
OO もわからないしライブラリの継承ツリーも調べたことがないやつに、
分散オブジェクトとか言っても「はあ？ぼくちゃんわからない」でせう。
0929デフォルトの名無しさんNGNG
>>926
ソースがねーぞ。論文だけじゃねーか。言語は何で作ったんだ？
>>927
BeOSって「コンパイル時に存在しないクラス」を使えるようになったんだっけ？
> 少なくともWindowsでさえもOOしていると思うんだけどな
MFCがOOしていると主張するなら、まぁOOしてますね。
0930デフォルトの名無しさんNGNG
>>929
http://www.ipsj.or.jp/members/Magazine/Jpn/3608/article014.html
の論文からたどれる。
0931デフォルトの名無しさんNGNG
>>920
うんうん系は、なくてもいいけどあったらいいこともあるよ、っていってるん
ですが
0932デフォルトの名無しさんNGNG
>>930
本文のリンクをクリックするとユーザ名とパスワードを求められるんですが、
やっぱり会員登録しなくちゃ駄目ですか？
0933デフォルトの名無しさんNGNG
浅海さんがゆうてるように継承はOOの主要な
要素ではない。
0934デフォルトの名無しさんNGNG
>>933
なんだ、人の受け売りか。
0935デフォルトの名無しさんNGNG
>>934
おまえこそ、お前の持ってる99.99%の知識は人の受け売りだろう？
それを馬鹿にしてもしょうがないぞ？
0936デフォルトの名無しさんNGNG
別に主要な要素かどうかを問題にしているわけではないでしょ。
ここまでの流れでは、必要と思う人には必要という結論がすでに。
いらないよねーといってる人は、本当にいらないか、意味がなにも
わかってないか、どっちかなんでしょう。
0937デフォルトの名無しさんNGNG
OOは、手続き型、データ＆構造中心の設計を許容する。
オブジェクト内でどんなコードが動いてようと、オブジェクトの
切り分けとメッセージのやりとりさえ決まっていれば、それで十分だろ？
0938デフォルトの名無しさんNGNG
許容したら糞コードといいますよ。
0939デフォルトの名無しさんNGNG
>>929
＞コンパイル時に存在しないクラスを使えるようになったんだっけ
ってなんだ？
コンパイル時に存在しないクラス？使えるに決まってるじゃんか。
おまえ、非OOでも、プログラム書けない...書いたこと無いだろ。
0940プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
正しいプログラムはオブジェクトを手続きの中に封じ込めたもの。
分散オブジェクトは失敗したでしょうが。
0941デフォルトの名無しさんNGNG
>>940
RPCは成功したの？
0942デフォルトの名無しさんNGNG
>>941
RPCってリモートオブジェクト？
0943デフォルトの名無しさんNGNG
DCOMやらRMIやらは、とりあえず一定の成果をあげたといえる。
0944デフォルトの名無しさんNGNG
>>940
ﾊｧ？EJBは分散オブジェクトそのまんまですが。
0945デフォルトの名無しさんNGNG
分散システムが協調処理行うときに、分散オブジェクト以外に何が有力というのだろうか。。。
0946デフォルトの名無しさんNGNG
俺もマジでわからん、オブジェクト指向ってやつが。
かろうじてDelphiで実体験したのが"継承"。
その他にどういった要素が揃えばオブジェクト指向プログラミング足り得るのだろうか。

10数年前、勉強会に参加したCobolerの中には、いまだに
"オブジェクト指向=細かいルーチン化"と思ってるオッサンもいるぞ。

本当に頭のいいヤツは、バカでもわかる比喩をこなせる筈、
>>22がいい線行ってると思ったが、実際どうなんだよ。
どういう概念でもってソースを組めば、誰にも恥じる事のないオブジェクト指向による組み方になるのだろう。

0947デフォルトの名無しさんNGNG
>>946
>>210付近を読め
0948デフォルトの名無しさんNGNG
>>946
＞その他にどういった要素が揃えばオブジェクト指向プログラミング足り得るのだろうか。

ということを厳密にやろうとすると、上で繰り広げられてることが起きるので、漏れはパス。
どういった要素が揃えばJazz足り得るのだろうか、という問いに似て、厳密には難しい。

結局はJazzを勉強したミュージシャンが演奏すればそれはJazzになる、
ということが言えるとすれば
オブジェクト指向を勉強したプログラマが組めばそれはオブジェクト指向プログラムになる
といえるかもしれない。
0949sageNGNG
今までのやり方の延長で試してみても、上っ面だけになりがち。
一度頭を空白にして、「今まで君が読み飛ばしてきた」数多くの
オブジェクト指向に関する文献を、読み直してみるといいよ。

キーボードのないところで、出来ればコーヒーでも飲みながら、
まったりと。
0950デフォルトの名無しさんNGNG
やりなおし。

Jazzを勉強したミュージシャンがその技術を生かして演奏すれば
それはJazzになる、ということが言えるとすれば
オブジェクト指向を勉強したプログラマがその技術を生かして組めば
それはオブジェクト指向プログラムになるといえるかもしれない。
0951946NGNG
なるほど。弁当屋の例えはわかりやすかったです。
Fuckable から読む気無くしました。根気ないですね、おれ。
ちなみにDelphiでやってた"継承"というのは、
画面フォームの提示様式とボタンの機能を統一するため、
最小限の基本機能（画面の見た目、パネル分け、PFキー、確認ボタン類）をクラス定義して、
各アプリはそのクラスを利用して造り込んでいく、というものです。

この時問題になったのは、クラス内部の（結果的に）冗長的な一機能が、派生先の仕様によっては足枷になる場合が開発末期に生じたという事です。
また関数一つとっても、各プログラマが"俺の部品こそ効率的"と、みんな互いに譲らず独自に別個の関数をダラダラ書きやがったという問題もありました。
（俺も書きやがった一人ですが）　…まあ、その程度の経験しかないす。

オブジェクト指向って、決して同一ではないが似たような手続きを複数箇所にダラダラ書くのはダサイから、
一つにまとめて能率よく処理できるよう工夫を凝らそうといったものになるんでしょうか。
ある種ゲージツ的センスで意見が分かれそうで集団開発にどこまで向いているのかちと疑問にも思ったりします。
ちゅーか、それこそ"指向"に左右されるのだなぁなんてね。


0952デフォルトの名無しさんNGNG
>>951
そういう観点で言うなら、いかにプログラムを分割して
関連のあるものを近いところに、関連のないものを遠くにおくか、とか
まとめて変更する可能性のあるものをいかにまとめるか、とか。

だから、集団開発、という点でいえば、おおきなプログラムを
集団で作るときに、ある機能を担当している人が作るプログラムが
他の機能を担当している人のプログラムの影響を受けない・影響を与えない
ようにという方向で設計ができる、という点でオブジェクト指向が良い。
0953952NGNG
コードが似ている・似ていないが判断基準になるのではなく
概念的に似ている・似ていないが判断基準になる。
結果的には、コードが似ている・似ていないでまとめることになる場合が多い
のだけど、それは結果論。

ある時点でコードが似ているからという理由でまとめると、あとで泣く。
0954デフォルトの名無しさんNGNG
「OOは必要か」という質問には答えがない。
答えがない質問は、質問自身が間違っているからである。
正しい質問は「OOは便利か」である。便利である。
OOの最大の利点は「差し替え可能」であることと言っても過言ではない。
同じインターフェースあるいは同じ起源をもつオブジェクトは
差し替え可能であり、LEGOのように組換え可能である。
スライムをマンドリルに差し替えたところで、
剣と魔法のインターフェースを備えていれば、同様に扱うことが出来る。
IF文やSWITCH文で振り分ける必要がない。
便利である。

それにしてもこのスレは良く伸びている。良いことである。
0955デフォルトの名無しさんNGNG
>>954
なんとなくあんた良いこといった！
0956952NGNG
>>951
> 足枷になる場合が開発末期に生じたという事です。

という部分だけど、開発ライフサイクルを考えると、開発末期には
開発をコントロールすることが難しくなるのは、どのような技術を
使っても起こり得る。
いまのところオブジェクト指向を取り入れた開発が、その飛距離が長い。
0957デフォルトの名無しさんNGNG
ＯＯを採用したプロジェクトがなかなか成功しない
と言われる原因は何ですか？
0958デフォルトの名無しさんNGNG
>>957
全体的にプロジェクト自体の規模が大きくなり、予算・納期は縮小する傾向が
あるので、プロジェクトが成功しにくくなっているというのがある。
だから、OOを採用してなければ成功していたかというと、難しい。

また、新技術にはやはりリスクがあるので、OOを採用したからといって
最初からその利点の恩恵にあずかれるものでもない。

ただ言えるのは、最近の開発で成功しているプロジェクトは
OOを採用している割合が高くなっている。
0959デフォルトの名無しさんNGNG
現実社会だってインターフェースに満ち溢れているわけで、
それはつまりそれが人間にとって楽なわけだよね。携帯電話の
中の実装知らないと電話できないんじゃ、話にならんよね。
各社ごとにキーボードが違ったら、つらいよね。
だから、プログラムだってインターフェース指向の方が楽なはず。
OOってオブジェクトのコラボレーション云々ってよく言われるけど、
そんなことよりインターフェースをどう切るか、ってところの方が
重要だと俺は思う。また、インターフェースによる切り分けと差し替え
が出来るところが、OOの良さっていうか楽な所だと思う。どうかな？
0960デフォルトの名無しさんNGNG
インターフェースだけなら、オブジェクト指向使う必要ないじゃん。
インターフェースと継承ぐらいあればいいんじゃないの？
オブジェクトなんて出てくる必要ない。
0961デフォルトの名無しさんNGNG
オブジェクト指向が特に便利というわけじゃなく、
その周辺に用意されたものが、たまたまニーズに
合ってるだけかもしれない。
オブジェクト指向は「狼の皮を被った羊」なんじゃないのか、と。
0962デフォルトの名無しさんNGNG
>>961
オブジェクト指向は、羊に狼の皮を提供する。
0963デフォルトの名無しさんNGNG
>>962
文盲は黙ってろ。
0964デフォルトの名無しさんNGNG
>>963
じゃあ、おまえが黙ってろ。
0965デフォルトの名無しさんNGNG
何か言い返さないと気がすまないのですね、そんな性格じゃ損するだけだよ
0966デフォルトの名無しさんNGNG
>>963
突拍子なく来るな
0967デフォルトの名無しさんNGNG
>>961
なるほど。
多態や継承とかは、別にオブジェクト指向でなくてもできるよな。
純なオブジェクト指向つーと、メッセージ受け渡し程度だから、
まあ無くてもいいわな。
0968962NGNG
へんなちゃちゃが入ってるようだけど、オブジェクト指向のおかげで
プログラムをあまり勉強しなくても、ある程度部品を組み合わせれば
ある程度のものができるようになっている。

あと、>>961の言うような「周辺に用意されたもの」の多くは
オブジェクト指向を核に研究開発されている。
それは情報処理学会誌なんかを読んだ感想。
0969デフォルトの名無しさんNGNG
おまえら「オブジェクト指向」に騙されてるぞ。
「オブジェクト指向」と一括りにされて、うやむやにされた技術は、
実はほとんどが「オブジェクト指向」とは全く関係ないものばかりだ。
俺達は「オブジェクト指向」という言葉に踊らされているのさ。
0970デフォルトの名無しさんNGNG
>>968
>オブジェクト指向のおかげで
オブジェクト指向のおかげじゃない。
オブジェクト指向の周辺技術のおかげだ。
0971デフォルトの名無しさんNGNG
言われてみるとそんな気もするな。
0972デフォルトの名無しさんNGNG
>>968
>部品を組み合わせればある程度のものができる
これはオブジェクト指向とは何の関係も無いな。
0973962NGNG
>>970
そのオブジェクト指向の周辺技術はオブジェクト指向のおかげではない？
0974デフォルトの名無しさんNGNG
>>969
なんかこれ、真理を突いてるっぽい。
初心者がプログラムするときなんか、メッセージなんて概念は
頭に出てこないだろうし。最近の言語の傾向見てると、
純粋な「オブジェクト指向」という意味自体も消えかかってる。
0975959NGNG
>>960
確かに、インターフェースと継承があるだけでよいかも。
メッセージングの重要性、ってのをあんまり感じたことないし。
それよかインターフェース合わせるとか、多態で楽するとかの方が重要だ。
>>967のニーズにあっているというのは、なんとなく理解できる。

>>969
となると、純なオブジェクト指向＝メッセージング程度という>>967の意見と、
オブジェクト指向の周辺技術がニーズにあっているという感覚からすると、
少なくとも俺はオブジェクト指向の派生物を便利便利と言っているわけで、
そうなると俺は何指向だ？オブジェクトデリバティブ指向とかか？
0976デフォルトの名無しさんNGNG
庶民はとくに指向でなくてよい。
0977デフォルトの名無しさんNGNG
>>973
それは老人の戯言と同じ。
使う側からすれば知る価値はない。
0978959NGNG
>>976
まあ、確かにそうかもしれん。
でもやっぱりプログラムするときはいつもインターフェース
意識するから、しいて言うなら俺はインターフェース指向かな。
オブジェクト指向ではないことは、>>961の発言で確定したし。
0979デフォルトの名無しさんNGNG
まあ、最近の「オブジェクト指向」という言葉の使われ方は、
あいまいな表現の部類に入るな。
「オブジェクト指向」だけでは密な会話が成立する事なんて少ないし。
0980デフォルトの名無しさんNGNG
>>977
ふーん。じゃあいいや。

そうやってオブジェクト指向をもとにした周辺技術だからこそ
核となるオブジェクト指向を知る必要がないものになるわけだけど。
そして>>968に続くわけだ。
0981デフォルトの名無しさんNGNG
>>980
その研究者達も「オブジェクト指向」という言葉の語呂がいいから使うだけで、
純な意味のオブジェクト指向原理主義な人なんていないと思うよ。
いたとしても、自分のやってることが良くわかってない盲信者だろうね。
0982959NGNG
>>979
学術用途で抽象度の高かったオブジェクト指向が、実装レベルが
近くなるにつれ実用上有用な技術がどんどん引っ付いてしまい、
学者が言うオブジェクト指向と実装者が思うオブジェクト指向が
乖離している。学者は核が、実装者は周辺技術がテリトリーであるため、
一向にオブジェクト指向の利点、特徴が一意に語られないため、
「オブジェクト指向」という言葉があいまいで、踊らされている。
こんなところかな？となるとさ、周辺技術をカテゴライズして
やれば、見通しよくなりそうだよね。
0983プロの逝って良しの１ ◆MvRbZL6NeQ NGNG
メソッド呼び出しもメッセージだなどと言ってる人が居ますが全然違います。
あれは制御。
呼んだら戻さなきゃいけないところがメッセージと根本的に違う。
メッセージ送って自分は消滅とか出来ないんでジャヴァで往生した。
0984デフォルトの名無しさんNGNG
>>982
そんなとこだと思う。
オブジェクト指向だけが全面に出てくる今の状況はおかしい。
理系の考え方じゃない。
0985980NGNG
>>981
まぁ、研究分野でも、オブジェクト指向は当たり前の技術みたいな感じになっている
ようなので、専門に研究してる人は少ないかも。
ソフトウェアシンポジウムのレジュメなんかでも97年あたりからオブジェクト指向
のセッションが少なくなってる。
そのあとの流行は「プロセス」だったけど、最近はどうなんだろう。。。
0986デフォルトの名無しさんNGNG
逝って良しが来たのでそろそろ退散するとしよう。
0987デフォルトの名無しさんNGNG
>>984
エンジニアリングは理系じゃないからね。
0988デフォルトの名無しさんNGNG
>>984
同意。
オブジェクト指向の本はあんなに分厚い必要はない。
なんつーか、うまく分離できないものかね。
0989959NGNG
>>985
Java界だと、「フレームワーク」とかになるのかな？
フレームワークって、やっぱりインターフェース指向だよ。

>>987
深いね。
0990980NGNG
>>989
そういえば、オブジェクト指向の次にはパターンが流行った。
0991デフォルトの名無しさんNGNG
>>951
> また関数一つとっても、各プログラマが"俺の部品こそ効率的"と、みんな互いに譲らず

ちゃんと測定して裏を取ればよかったんだよ。
0992980NGNG
核という言葉はまずかったな。前提、だな。
0993デフォルトの名無しさんNGNG
>>983
Smalltalk-80も本質的にはサブルーチン・コールに過ぎないわけで、
これもオブジェクト指向のベースモデルのアクター理論が実装で
歪められた例の一つですね。
0994デフォルトの名無しさんNGNG
なんかスレの最後でまともっぽい話になったな。
0995959NGNG
>>993
実装で歪められた、って所はおもしろいね。
htmlのタグも実用ではだいぶ歪んだ使われ方がされていて、
あまつさえそれがテクニックとして世に出回ったり
しているから、OOにもこうゆう要素が少なからずあるということ
だよね？
0996デフォルトの名無しさんNGNG
　　 ／⌒＼
　　（　　　　）
　　｜　　 ｜
　　｜　　 ｜
　　（　・∀・）　　　1000ﾊ
　　 ）　　　ﾉ
　　（＿⌒ヽ
　　　 )ノ ｀J

　　 ／⌒＼
　　（　　　　）
　　｜　　 ｜
　　｜　　 ｜
　　（　・∀・）　　　ﾜﾀｻﾅｲﾖ
　　 ）　　　ﾉつ
　 ／ __　 /
∠　'´　)ノ
0997デフォルトの名無しさんNGNG
　　　　∧＿∧ 　 　∧＿∧
　　　 （　__　__） 　 （　__　__）
　　　（6　・ ｣・）. 　（6　・ ｣・）　　ﾎﾞｸﾀﾁﾀﾞｯﾃ
　　　 （　　∀） 　　（　　∀）
　　　／　　 　＼　／　　 　＼
　　⊂　） 　 ﾉ＼つ　）　　ﾉ＼つ
　　　　（＿⌒ヽ　　（＿⌒ヽ
　　　　　ヽ　ﾍ　}　 　ヽ　ﾍ　}
　　　 　　ﾉノ ｀J　　　ﾉノ ｀J

　 　　　∧＿∧ 　 　 ∧＿∧
　 　　 （　__　__）　　 （　__　__）
　 　　（6　・ ｣・）. 　 （6　・ ｣・）　　ﾏｹﾅｲﾖ
　 　　 （　　∀） 　 　（　　∀）
　 　　／　　 　＼　 ／　　 　＼
　 　⊂　） 　　ﾉ＼つ　） 　　ﾉ＼つ
　 　 ／　__　<　　　／　__　<
　 ／　 '´ ヽ　）　／　 '´ ヽ　）
∠／　　　 ﾉノ∠／　　　 ﾉノ
0998デフォルトの名無しさんNGNG
　　　　∧＿∧ 　 　∧＿∧
　　　 （　__　__） 　 （　__　__） 　　　 ／⌒＼
　　　（6　・ ｣・）. 　（6　・ ｣・） 　　 （　　　　）
　　　 （　　∀） 　　（　　∀） 　　　｜　　 ｜
　　　／　　 　＼　／　　 　＼ 　　｜　　 ｜
　 ⊂ 　） 　 ﾉ＼つ　）　　ﾉ＼つ　 （　・∀・）
　　　　（＿⌒ヽ　　（＿⌒ヽ　　　　 ）　　　ﾉ　 （　・∀・）　　ｼｮｳﾌﾞﾉ
　　　　　ヽ　ﾍ　}　 　ヽ　ﾍ　}　　　（＿⌒ヽ 　 （＿⌒ヽ
　　　 　　ﾉノ ｀J　　　ﾉノ ｀J　　　　 )ノ ｀J　　　 )ノ ｀J

　 　　　∧＿∧ 　 　 ∧＿∧
　 　　 （　__　__）　　 （　__　__） 　　 ／⌒＼
　 　　（6　・ ｣・）. 　 （6　・ ｣・） 　　（　　　　）
　 　　 （　　∀） 　 　（　　∀） 　　 ｜　　 ｜
　 　　／　　 　＼　 ／　　 　＼ 　 ｜　　 ｜
　　⊂ 　） 　　ﾉ＼つ　） 　　ﾉ＼つ （　・∀・）
　 　 ／　__　<　　　／　__　< 　　 　 ）　　　ﾉつ （　・∀・）　 ﾊｼﾞﾏﾘﾀﾞﾈ
　 ／　 '´ ヽ　）　／　 '´ ヽ　）　 　／ __　 /　　／ __　 /
∠／　　　 ﾉノ∠／　　　 ﾉノ　 ∠　'´　)ノ　∠　'´　)ノ
0999９９９NGNG
９９９
1000デフォルトの名無しさんNGNG
ははは
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。