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

理解してるんだったら、教えやがれ！！

勉強しろよ
低脳

お尻の穴が少し広がった

誤爆ｽﾏｿ

そろそろコタツのしまいどきですね

T>>1=class(T2chaneller)
public
property Hikikomori defaut True;
procedure CreateKusoThread;
procedure Jisakujien;
end;

つくしの子が恥ずかしげに顔を出す頃なんだなぁ

VB太郎の間違いじゃないの？

キャベツ太郎

>>3
どの板の誤爆か大体予想つくｗ

>>1
Javaができるなら自分でクラス作りながら勉強しろ
コンパイルエラーがお前にオブジェクト指向を教えてくれるぞ

オレはコンパイルエラーが大嫌いだ！！
オレが間違っているのではない！マシンが悪いのだ！！！

なんかの罰ゲームですか？

>>11
クラス!=オブジェクト指向
いくらクラスを作ってもオブジェクト指向は理解できない

　　　　　　　　　　　　　　　　　　　　　　　　　　'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´　　ﾞ'-,｣　　　　　　　　°　　　　　.”
　　　　　　　　　　　　　　　 ―---┘

>>15
激しく同意

オブジェクト＝インスタンスってのがわからねぇぜ！！

>>12
そんなこといってる奴には、
いつまでたっても、オブジェクト指向どころか
プログラミングを極めることができない。

>>18
極める？バカじゃないの？
そんなことできるはず無いじゃん
居るんだよね〜少しプログラミングできるからって、「極めた」って言う奴が。
そういう発言は慎め！

>>18
お前のせいで名前を入れ忘れたじゃねぇか！！
チｯ・・・お前が居ると調子狂うぜ、まったくよｗ

>>19-20
いいからよく本を読んで勉強しろ
がんがれ

スライムから、バブルスライムやメタルスライムを派生させる。
これで継承は完璧。

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

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

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

>>21
お前、いい奴だな・・・
オレの一番の下僕にしてやるぞ♪

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

>>22
さらにいうならデータの保存はMementoパターンだろ

個人スレたてんなボケ

>>24
java.io.Serializableを調べよ

>>25
そ、そうだ！！それだ・・・
（なんだよそれ・・・((((；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ）

>>27
はい！先輩！！

個人スレたてんなボケ

ごめんなさいもうしません削除依頼出してきます
このスレは終了しますた。
-----------------------------------------------
冬

昨日のperl馬鹿か？

>>31
偽者ｷﾀ━━━━━━＼(T▽T)／━━━━━━ !!!!!
それだけ、オレが人気者って証拠だな♪

倉庫に落ちました。。。

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

甚だ不本意だが、トリップつけてやるぜ！！
人気を奪われちゃー金を手に入れれねぇからな！！

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

はぁ？

　　　　　　　　　　,,―‐．　　　　　　　　　　　　　　　　　 r-、　　　　＿,--,、
　　　　　,―-、　.| ./''i､│　　r-,,,,,,,,,,,,,,,,,,,,,,,,―ｰ．　　　 ﾞl, ｀"ﾞﾞﾞﾞﾞ￣＾　　　＼
　　　 ／　　　＼ ヽ,ﾞ'ﾞ_,/　　 .ﾞl、　　　　　　　　　`i､　　　＼ _,,―ｰ'''/　　.,ｒ'"　　　　　
.,,,、.,,i´　.,/＾'i､　｀'i､｀｀　　　　 ｀--‐'''''''''''''''"'''''''''''ﾞ　　　　 ｀゛　　 .丿　 .,　　　　　　　
｛ ""　 ,/｀　　ヽ、 ｀'i､　　　　　　　　　　　　　　　　　　　　　　　 丿　 .,/｀ 　　　　
.ヽ、　丿　　　　＼　 .＼　　　　　　　　　　　　　　　　　　　　　 ,/′ 、ヽ,,、 　　　　　
　 ﾞ'ｰ'"　　　　　　ﾞ'i､　 ‘i､.r-、　　　　　 ＿_,,,,,,,,--、　　　　 ／　.,／＼　`'-,、 　　
　　　　　　　　　　　ヽ　　.]ﾞl ｀ﾞﾞﾞﾞ"ﾞﾞﾞﾞ￣￣　　　　　｀'i､　　,／ .,,／　　 .ヽ　　＼
　　　　　　　　　　　　ﾞヽ_/ .ヽ_.,,,,--―――――ｰ-ノ_,／ﾞ,,／′　　　　 ﾞl　　 ,"
　　　　　　　　　　　　　　　　 ｀　　　　　　　　　　　　 ﾞ‐''"｀　　　　　　　　ﾞ'ｰ'"

>>37
そういう事なのか！？！？
あとほんの少しだけ、勉強してやる。
兄貴！待ってろよ

>>36>>39
かってに騙るなボケ。トリップまでつけて厚かましいんだよ、もう来るな。

// 手続き型
function("hoge");
// オブジェクト指向
class instance i = new class();
i.method("hoge");

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

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

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

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

はぁ・・・なんだか色々難しいぜ！！（ウソ）
しょうがない、殺るか！

>>42
Java言語プログラミングレッスンの下を読みはじめたよ
ふぅ・・・だるくてやる気が出ないのが本音（ウソ）

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

>>45
（一応、反応するか・・・(　´Д｀)）
スゴイ！涙が出ちゃう話だね・・・
最近、涙もろくてｗ
ハハもう年かな？

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

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

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

>>１の妹の花穂ですっ★
お兄ちゃま、お元気ですか？　花穂は自作自演を毎日一生懸命がんばってます！
早くお兄ちゃまのクソスレを1000まで行かせたくって、もう待ちきれないくらい!!
お兄ちゃまに「花穂のおかげでこのスレが1000まで行ったよ」って言ってもらうのが、
花穂のちっちゃい頃からの夢なんだぁ……★
お兄ちゃま、花穂の自作自演、楽しみにしててね！

>>47
（コイツもか・・・）
妹、居ないけど、(　´Д｀)なにか?
・・・２ちゃん風に決めたぜ！よっしゃ！！

>>１の妹の可憐です。
大好きなお兄ちゃん。この前お兄ちゃんが立てたスレ、とっても大切にしています。
どうしたって毎日１回はスレを見てしまうの。１の書き込みを見ているとお兄ちゃんの
声が聞こえるみたいな気がする不思議なスレ……。
でもみんなはこのスレをクソスレって言うの。とってもすてきなスレなのに･･･｡
でも、可憐だけはお兄ちゃんの味方だよ･･･｡お兄ちゃん……大好き。

>>48
すごい！！当たってるｗ
知識と経験が全然足りないよ・・・
初心者Javaのスレに行っても、話がわからないし。

1の妹の沙織です。
このたびはお兄ちゃんがごめいわくおかけして
どうもごめんなさい。（ペコリ）
はぁ……なんでこんなことになっちゃったんだろ。
昔のお兄ちゃんは、優しくて、家族思いで、頭だってテスト１００点
ばっかりだったし、お友達に囲まれていっつも楽しそうだった。
でも、あの日の後、もうお兄ちゃんはお兄ちゃんじゃなくなっちゃった。

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

１の妹シリーズって読んでると疲れるし、面白くないね。
しかも、コピペでしょ〜
はぁ・・・それでも読んでるオレってピュアだ！！

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

>>51
やさしいね、ありがとう(　´Д｀)

>>1の妹の咲耶です。うちのお兄様が皆さんに迷惑をかけてしまった
みたい、お兄様にかわってお詫びするわね。

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

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

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

>>53
近親相姦に興味ない(　´Д｀)

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

>>55
まだ死なない(　´Д｀)

>>1の妹の千影だ…
兄くん…駄スレは立てないでくれと…いつも言っているだろう･･･
そうでないと…きっと…兄くんの身に…不幸な災いが…ふりかかる…
ホラ…見てみろ…。兄くんのせいで…こんなにも多くの…愚者が…稚拙なレスを……。
兄くん…、いいかい？もう…こんなスレ立てないと…約束してくれ
でないと…兄くんの命が…危ないことになる…
それでは兄くん…また…来世…

>>57
他人とお風呂入るの嫌なの知ってるじゃん(　´Д｀)

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

>>1の妹の春歌ともうします。

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

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

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

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

>>59
なんでスレを立てたぐらいで、命がどうのこうのって話になるんだよ(　´Д｀)
どこから仕入れたんだろ・・・妹シリーズ。

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

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

１の妹シリーズへ
もう似たようなネタしかないね・・・
やめよう(　´Д｀)

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

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

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

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

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

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

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

妹レスも読みつかれた。しつこすぎ。
マンネリには飽きた。他板でやれ。

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

>>72
オブジェクト指向なんて算数でいえば九九みたいなもん。
器もなにもない。
確かに九九が出来ない小学生もいるだろうが。

あえて言うなら「九九ではなく微分みたいなもの」としておこう。
意味のない微分と同様に、意味のないオブジェクト化をする人間もいる。
困ったものだ。

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

>>72
人には器というものがある
↑これって荒らしに対して？

>>74
九九ならできる！！ヽ(´∇｀)ノ

>>75
オブジェクト化する必要が無いものまでしてると
ちょっと読みづらくなる・・・

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

>>72
図星みたいだね
１の妹シリーズが止まったよｗ

昔Ｄｅｌスレだかで観た「ギコ猫オブジェクト」が非常におもしろかった。

>>82
え？なにそれ〜
独り占め？
ズルイぞ！ズルイぞ！．．．(´З｀)ﾁｭｯ

静かだ・・・

おい、J太郎出て来い

>>85
Ｊ太郎って、オレの弟か？
どうなんだよ！？隠すんじゃねーよ！！
コンチクショー

オ・バ・ケの･･･

>>87
Q太郎か？
お前、年いくつだよ？
オヤジスレにするつもりかよ！！

何も書き込むことが無い

オブジェクト定食

ここ、本当にプログラム組める奴、何人ぐらい居るんだろう？

>>89
書き込んでるじゃーん！！
ビックリ人間だな・・・オマエ

>>90
名前だけじゃ、どんなものが出されるのかわからないな・・・
み、味噌汁はついてるのかなぁ？ぐへへ・・・

>>91
それは愚問だ！
一応、答える
Ａ．オレしか居ないぜ！！（素

>>Java太郎
ひまそうですね。

>>94
何言語だよ

オブジェクト指向の概念において、（私の父：公務員）が
“私の父は公務員”というインスタンスとクラスの関係を意味する
としたとき、同じ関係となるものはどれか。


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

　ウ　（私の父：私の母）　　　　　エ　（私の部屋：私の家）

何このスレ・・・・・・・？
　　　　　　 　　　　　　/ヽ　　　　　　 /ヽ
　　　　　　　　　　　　/　ヽ　　　　　 /　ヽ
　　＿＿＿＿＿＿ /U　ヽ＿＿＿/　　ヽ
　　|　＿＿＿＿　／　　　U　　　　:::::::::::U:＼
　　| |　　　　　　 /／ ＿__　　　＼　　::::::::::::::|
　　| |　　　　　　 |　　|　　 |　　　　　U :::::::::::::|
　　| |　　　　　　.|U　|　　　|　　　　　　::::::U::::|
　　| |　　　　　　 |　├―-┤　U.....:::::::::::::::::::/
　　| |＿＿＿＿　ヽ　　　　　.....:::::::::::::::::::::::<
　 └＿＿＿／￣￣　　　　　　:::::::::::::::::::::::::|
　　|＼　　　 |　　　　　　　　　　　:::::::::::::::::::::::|
　　＼ ＼　 ＼＿＿＿　　　　　 ::::::

>>97

オ（ウホッ：いい男）

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

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

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

>>100
間違い

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

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

知性はフツーで十分です。

俺はＪａｖａの
インターフェースとインプリメンツの違いが
よくわかんねーよ。

かたまり、かたまり
カプセル、カプセル

>>105
引退しろ

>>107
あはっ、Ｊａｖａは趣味でやってまつから。
関りたくネーヨ＞Ｊａｖａ。

protectedに何を置けばいいのか分からない…(Delphi)

　　　　　　　　　　　　☆ ﾁﾝ
　　　 　 　 ☆　ﾁﾝ　　〃　 Λ＿Λ　　　／￣￣￣￣￣￣￣￣￣￣￣
　 　 　 　 　　ヽ　＿＿_＼（＼・∀・）　＜　鞠絵ﾏﾀﾞ〜？
　　 　 　 　 　 　 ＼＿／⊂　⊂＿ )　　 ＼＿＿＿＿＿＿＿＿＿＿＿
　　 　 　 　 　 ／￣￣￣￣￣￣ ／|
　　　　　　　　|￣￣￣￣￣￣￣|　 |
　　　　　　　　| .　　　　　　　　　 |／
　　　　　　　　￣￣￣￣￣￣￣

インターフェースは抽象的なメソッドの定義である。
インプリメンツは具体的な実装プログラム記述である。

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

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

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

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

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

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

ＯＯの前に正しいサブルーチンの作り方を会得しろ。
まあ才能のある奴はそうは居ないけどな。
ＯＯはその次だ。
正しいサブルーチン作れない奴にＯＯは無謀。

>>105
implementsはinterfaceを実装するときに記述するものだ。
>>111の説明は誤解を招く部分がある。
>>105はまず実際にinterfaceを実装したクラスを作って
プログラミングしてみろ。

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

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

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

interfaceをimplementsする。
とても解り易いと思うんだがな。

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

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

同意

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

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

　　　Ｃ
　　　｜
　Ａ←Ｂ

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

Ａ0 A1 ・・・・　Ａn

で、この時Ａ1〜Ａnまでを利用するが、Ｃで定義された変数はＡ1〜Ａnまで
すべて共通の値を持つということでよい？。

俺は、基本的にinterfaceってのは
プログラマに実装上の留意を促し、
実装ミスを防ぐ為にあるのが50％、
C++と比べてClassの多重継承ができない事に
対する代用策としてが50%と考えてる。

ぬるぽをいかに抽象化するかってことだな

>>119

不正解。

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

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

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

(*1)ーＤ

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

Ａ0 A1 ・・・・　Ａn

で、この時Ａ1〜Ａnまでを利用するが、Ｃで定義された変数はＡ1〜Ａnまで
すべて共通の値を持つということでよい？。

インターフェースが威力を発揮するのは、
同一のインターフェースが複数のクラスでインプリメントされる場合である。

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

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

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

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

>>121
不正解と3文字だけ書くことなら
馬鹿にでもできる

>>105
念のため確認したいんだけど、
Polymorphismの事くらいは知ってて書いてるんだよな。

>>122
＞クラスＢ、Ｃが親クラスでクラスＡに継承し
JAVAでclassの多重継承はできまへん

>>125
＞Polymorphism
知らない。

>>126
ああっそうだった。
やべっ混乱してきた。

>>127
じゃ、知っとけ。

>>122
> えっと少し変更。
> クラスＡ、クラスＢ、クラスＣ、インターフェースＤがあって、
> クラスＢ、Ｃが親クラスでクラスＡに継承し、
Javaではそのような実装の多重継承を許さない。

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

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

(ﾟ∀ﾟ;)

オブジェクト指向やJavaのinterfaceは全然分からんが
>>105が何も分かっていないことだけは分かる。

>>121
いや、不正解と言われても。。。
あくまで俺なりの解釈なんで、
正解も不正解もないんだが。

>>122 での矢印の使い方から、105は馬鹿ってことに決定。

>>Cが親クラスでクラスAに継承し
このアタリもまずいような気がする。

馬鹿馬鹿言わんと教えてやれや

ゲッツ！

>>123
ラーメンクラスと、interfaceと、その他の追加するクラス関係が分かれば
納得すると思う。できれば図ｷﾎﾞﾝﾇ。

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

interfaceAにBというメソッドがあるとすれば
interfaceAをインプリメントしたクラスはＢメソッドが実装されていることが保証される。

「持つ」といったらこういう意味だからな。

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(){
　　//ここに実装
　}
}

>>133

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

>>140
class B {
は
class B interface C{
だよね？

>142
それ、何言語？

やべ、142でまた変な事書いてしまったかな？
はぁ。Ｊａｖａの本を探しに逝ってくる。

>>144
ダメ！行かないで！！
ヽ(´Д｀ヽ)(/´Д｀)/イヤァ〜ン

>>142
お前はちゃんとプログラミングしているのか？

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

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

それは机上の空論か？

机上の空論というよりも論にすらなってない。

なんかキモイやつらばかりだね、ここは。

そうだな。とくに>>149とか

implementsとinterfaceを混同してしまっているんだろう。

>>150
わかってないな！おまえ・・・
一番キモイのはオレだ！！
ポリモルフィズムの利点がよくわからない、今日この頃ヾ(´ー｀ )ノ

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

＞ラーメンクラスと、interfaceと、その他の追加するクラス関係が分かれば
＞納得すると思う。できれば図ｷﾎﾞﾝﾇ。

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

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

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

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

ダメポ銀行のA嬢

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

>>153
初心者にスレの話しても混乱するだけと思われ

コンストラクタに自分の上位インタフェース渡すパターンって何？

天気いいなぁ・・・

なんですかラーメンタイマーって。
じゃあ俺もぽりもーひずむの利点を麺にちなんで例えてみる。

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

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

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

つづく

> 製麺ボタン()を定義したのみ。
> 製麺interface自体は空っぽ

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

>>159の続き

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

つづく

定義して空っぽって
抽象メソッドみたいだね。

HAS-A関係（？）を使って
擬似的に多重継承できないのかな？

>>161の続き

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

つづく

>>163のつづき

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

話をややこしくするだけの人ってたまにいるね。
プロジェクトに入ってくるととても迷惑。

いいたいことはわかるのだけどね。

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

＞不親切な誤りを

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

>>106 で指摘したけれど、

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

それは機械として中身は空っぽという事を言ったつもりなんだけど。
機械に例えたりプログラムに例えたりと
曖昧な例え方がいけなかったかな？

機械として中身が空っぽであるなら、ボタンなんてものも無い、と
読むのが普通ではないかい？

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

まあこのスレの趣向から言って
ポリィモーフィズムの雰囲気さえ
掴めれば問題ないんでない？
JAVAの話が主体じゃないんだし

>>170
悪かったよ。
もう余計な口は出さん事にするよ。

>>172

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

>173
ご満悦そうだな（ｗ

>>162
そういうのは多重継承とはいわんよ。
単に集約してるといえばいいのさ

>>175
あなた頭いいでしょ？
わかる！！わかるんだよ・・・オレには。

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

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

C++と比べてJAVAはクラスの
多重継承ができない代わりか
どうか知らんけど、
implemetsというキーワード
を提供しているが、それによって
良くなった点と悪くなった点を
誰か挙げてくれないか？

>>177
implementsはクラスへのinterface実装専用。

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

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

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

でも綿密に管理されたコードだったとして、
バッティングの心配とかを抜きにすれば、
多重継承できない事でコーディング量が増えたり
不便になったという事は考えられるんでない？

ATLとか見るとな

＞良くなった点と悪くなった点を誰か挙げてくれないか？

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

>>179
実装の多重継承の危険性はソフトウェア工学の研究で実証済み

>>182
だから、危険か危険じゃないかは人によって違うだろ。
使う人間によっては便利にもなるし、危険にもなる。
そもそも、お前のように自分の観点でしか物を見れない
奴がいるから危険なんだよ、バーカ。

独りで書いて使うぶんにゃとても便利だろうな。
多人数が同時に書いたり使ったりだと大変だろう。

そもそも多重継承できない事で代替の方法でコーディング量が増えることは少ないわけだが。
逆に減ることもあるわけでな

CPPの多重継承の機能はJAVAの
interfaceでは完全に代替できない。
コードの再利用という観点からすれば
実装を継承できるのとできないとでは
やっぱ色々と違うでしょ

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

よくできたサブルーチン集と、それが内部で使うデータを一塊にする

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

>>187
コードの再利用とか不必要な情報の隠蔽とか利点はいろいろあると思う。
まあ特に必要を感じないんだったら従来どおりにやればいいと思うよ。

>>188
低能な突っ込みやめれ。
言いたいことは解るだろう？

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

＞いわゆる勘違いによる間違いが減る。それだけである。

それだけじゃないと思うが（ｗ

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

>>187
生産性。

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

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

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

>>193
短絡的な意見ありがとうございます。

オブジェクト指向によるコードが再利用できる程度が知れてます。

struct 男;
struct 女;

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

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

人間.絶頂()

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

>>187
構造化手法だけではカプセル化という概念を導入できない。

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

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

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

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

ときに、人間クラスがあったとして、そこから男・女クラスが
派生しているとして、sex() はＯＯ的にどこに実装されるのが
妥当ですか？

>>199
sexは名詞というの分かっているか？

ああ、では fuck (w でもいいですが。

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

なるほどなるほど、至極納得であります>>202

男ばかりがエントリされたときはstart時にアブノーマル例外を送出

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;
　}
}

お前ら熱いね

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() );

中の人も大変だな

Man implements Penis は余計だった

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

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

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

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

（つづく）

しかし、弁当屋は海苔弁ばかり置いてあるわけではなく、
唐揚げ弁当や焼き肉弁当もある。

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

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

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

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

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

（つづく）

頭の冴えているヤシは、さらに「弁当屋」と「おもちゃ屋」にも
共通点があることに気がつく。いわゆる「商店」であり、
なんらかの「商品」を売って、「お金」をもらうのであると。

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

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

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

（つづく）

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

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

（つづく）

さて、このヤシはたまに友達からレアものビデオなんかも買うのである。

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

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

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

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

みなさん食い物に例えすぎ（ｗ
別にいいけど。。。
どんどん書いてくれ

C++では普通に多重継承してて、JAVAでは出来ないので正直設計がしにくい言語だと思った。
もう慣れたが。

正直>>207はわかりやすい

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() );

良スレ認定

sexを属性(フィールド)にする手法とどっちがいい？

僕の部屋はクラスがないので
グローバル変数だらけです

>>221
どういう喩えでつか？　　

>>222
要は本棚とか無いんじゃないの？

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

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を分離することのメリットである。

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

>>224
抽象化のセンス無し

>>226
いやーわかりやすい。（ｗ

>>226
public abstract class Man implements Penis{}
はどういう意味、働きをもってくるの？

あっ却下
>>218

>>218
これって多重継承に似ているね。
引数でクラス名を渡しているところが異なるだけで、
クラスを隠蔽化する為に、Ｊａｖａ開発者が無理やりinterfaceやabstractを
とってつけたみたいだ。
なぜなら、Ｊａｖａは全てクラスで表現するという制約を自ら課しているから。

public class Woman {
　　public void sex( Penis p ) { System.out.println( "あなたの ちんこ" + p.getPenisSize() + "のね" ); }
}
は、Penisを引数の型に使っても起こられない？

>>229
Manという言葉があっても、それは単に概念とか分類であって
実際にManという"物"が存在する訳ではない。
TakeshiやHiroshiは"物"として存在するが、Manは存在しないという事。
でも後々、TakeshiやHiroshiを個人の単位ではなく、
Manという分類で扱いたくなるかもしれない。

>>232
言葉の意味から考えれば、
public void sex( Man m )
が相応しい。
或いは、
public void insert( Penis p )
など。

>>225 >>218
そもそもhas-aの関係にあるものをそうやってimplementsする
形式にすべきかも疑問。
それじゃis-aの関係になってしまう。
"He is a penis."

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

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

別に問題ないんじゃない
PenisはHourseにだってimplementsできる。
woman.sex( new Hourse )とか、、
そんな獣姦ビデオとかあるし。

知識は沢山持ってても抽象化のセンスが乏しい奴はいる。
そういうSEは結構いたな。
抽象化ってのは別部分の能力なんだろうか。
要は分類だよな。

>>235
＞abstract同様
抽象クラスと純化相関数入りのクラスにどれほどの違いがあるんですか？

>>238
抽象クラスにも実装済みで継承可能なメソッドを入れることができるでしょう。
抽象クラスは中に少しでもabstractなメソッドがあればクラスも抽象(abstract)と見なされる。
抽象クラスは継承した具象クラスがないと使えない。
抽象クラスはインスタンスを作れない。

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

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

>要は分類だよな。
Ｓヨ板がいまだに学問・理系カテにありますから・・・。

>>239
C++も知らないくせにC++との差別化とかほざいてるわけか。浅いな。そこが。

>純仮想関数
純粋仮想関数の typo だと思われ

>>241
Javaも知らないくせにJavaを批判しているわけか。浅いな。そこが。

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

>>243
言語機能とオブジェクト指向用語とごっちゃになってない？

純粋仮想関数ってJavaでいうabstractメソッドのことか。

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

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

ちょっと奇怪に見え

低能な奴ほど言葉の問題にやたらこだわろうとするな。
もちろん言葉は大切、慎重に選んで使わなきゃならないが、
ここで重要なのは指向または志向または思考なわけで、
大体のニュアンスが伝わればなんら問題ない。

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

>virtual void doMethod() = 0;
>
>ちょっと奇怪に見え
確かに。
vtable へのポインタを 0 で初期化するという意味らしい。

>235
じゃあ「interface Penisable」だったらいいのか？

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());

>>249
>>225や>>226や>>236を読みなさい。
俺は変える必要は何も無いと思う。
そもそもPenisableって意味わからん。

>>251
陰根可能

fuckableのほうがいいよ

>>246
人にわかりやすく説明するならクラスやメソッドなどのネーミングにこだわることは重要。
ネーミングが変な名前だと混乱するだろう。

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

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

>>254
普通ableは動詞につけるもんだと思うが。
なんでもかんでもableつければいいってもんじゃないですよ。

>>255
ableに詳しい人発見！！　質問させてください
ときどきcompatibleのように単純にable追加したら駄目なのがありますよね
なにか規則でもあるのですか？

>>256
コンパチはダメな英語ですか？

>>257
すいません。意味が良く輪からないのですが
駄目なのは自分の英語力です

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

>>255
それで>>253「ファッカボー」に改名？

>>258
もし間違っていたらあとでリファクタリング

>>258
「〜する　+ 〜できる」だから
動詞にくっつけるぶんには外人さんにも意味は通るんじゃない？
不安なら作った言葉をgoogleとかで検索してみるといいよ。

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

>>261
！　ありがとうございます！　なるほど、気づきませんでした。

>>1は糞だが良スレだな。
やっぱりスレの明暗をわかるのは>>2なんだな。

勉強しろよ
低脳

>>264＝>>2だろ？ｗ
全体を見ないと、良スレかどうかなんてわからない。

>>266
「低脳」は余計だよね

Fuckableだとおかしいかね？

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

>女もPenisを実装できてしまう。
ﾜﾗﾀ

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

>例えば、女もPenisを実装できてしまう。

ふたなり(；´Д`)ﾊｧﾊｧ

PenisableだかFuckableインターフェース
ManクラスやWomanクラス、HomoSexual(Okama)クラス、
両性具有クラス、奇形児クラス、性別不明クラス
をpackage化して

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

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

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

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

>>271
HomoSexualとOkamaは同列に扱ってほしくない……

>>271
だからね、Penisableとか言う意味不明な言葉を
当たり前のように使うのは止めなさいね。

>>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;
}

>>275
同性愛者の総称がHomoSexual
・Gayが男性同性愛者
・Lesbianが女性同性愛者
（※Queerは蔑称として使われることがあるらしい）

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

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

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

interfaceを引数にとるclassを設計してみると、色々と見えてくる
ことがあると思うんだけどな。

なんでもかんでもinterfaceにすりゃいいってもんじゃないだろ？

なんでもかんでもinterfaceにしろとも言ってないわけだが。

両刀使いってのもあるだろ？BiSexual?

>>278
>>277はもっと知る事ができるって言いたいのでは？

277に対する文句じゃなかったが、場所が悪かったな。

interfaceの使いすぎはソースコードの健康を損なう恐れがあります。
使いすぎには注意しましょう

今気づいたが引数にとるクラスじゃなくて引数にとるメソッドだな。

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

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

ソースコードの健康状態を知るにはどうすればいいのですか？

変化する可能性のある概念って何？
例えばどんなの？
いい例があったらおせーて。

>>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から継承して作れば、追加アルゴリズムだけを作れば
すむことになる。

>>286
static finalでないインスタンスフィールドのことをいっているんだと思う。

>>287
なるほど。抽象化の基本ですね。

ガーベッジコレクションってプログラマーは意識するんですか？

しない

ゴミ集めは無意識のうちに実行されます

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

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

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

（　´Д｀）/＜ 先生！！こんなのを見つけました。
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

そと寒いね。

評議に時間制限は無い

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

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

オブジェクト指向はインチキ。
真の生産性の向上は粒度の小さいサブルーチン型モジュール指向によって成される。

ふーん、あっそ。で？

サブルーチン型モジュール指向はインチキ。
真の生産性の向上は可読度の小さいextern宣言外部変数指向によって成される。

>>299
UML使え。
クラス図くらいツールで描け。

馬鹿だな。ツールは清書用だろ？
ツールなんて使ってたら、思考の妨げになる。
コピーの裏紙に書きなぐるのが基本だろ。

ひとそれぞれ、最適な方法は人によって変わるということも
おまえたちは理解しないのですか？

しかし普通の人は紙とペンで勉強し続けてきたはずだ。
そんな人が急に禿げたらどうなると思う？結果は明白だ。

紙をペンで黒く塗って、
それを頭に。。

紙に書くって
なんかいい感じだね。

オラ！オラ！オラ！オラ！！

最高ですか？

>>305
部品は黙ってろ

これからはウンコ指向だね。オブジェクトウンコ指向言語Cウンコ、Javaウンコ
C#ウンコ...etc.

だんだん真っ赤に燃えるんだ

これが本当のヤケクソ

コーダとはなにか？

ソフトウェア開発を設計工程と製造工程とを分けるとすれば、make 実行させている十数秒が製造工程で、それ以外は設計工程である。

はて？

●　　　これがオブジェクトだ

↓あとよろしく

>>315
ヨーダなら知ってる

★男はココを見るべし★女と金とサンプルムービー★
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
http://www.pink-angel.jp/betu/linkvp2/linkvp.html

★　これがメソッドだ

>>318
うんこみたい

発言がヤバイ

こんなスレがだらだら続いてしまう理由はいったい何でしょうか。

自分もオブジェクト指向の意味が
よく理解できてないんで質問したいんですが、
要するにオブジェクト指向ってのは同じ結果を生み出す
プログラムのソースをどれだけ簡略化できるかってことなのですか？

長い目で見て。

>>324
お前みたいな奴が書き込むからです。

>325
オレの中級レベルの中途半端な知識の範囲で答えると。。。
それは違うと思うｗ

>>325
拡張性、移植性、再利用性、堅牢性、コードの可読性を高めるためにもある。

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

オブジェクト指向の利点は、プログラムをオブジェクトと呼ばれる
ブロックに分割して開発できることだ。
だから、分担しての多人数の開発もやりやすいし、改良する場合も
必要なオブジェクトだけ変更すれば良い。

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

thisが曲者ですよね

>>329
という事はＪａｖａには明るい未来があると？

>325
ぶっちゃけて言っちゃうと。。。。
何かプログラムを作ろうとする時に
｢こういうクラスが必要だろう」って感じでクラスを設計していくと
全体の構想が浮かびやすいんだな。

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

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

>>332
ブロックの組み合わせでプログラムを作るなら、より多くの強力な
ブロックが手に入りやすい環境の方が開発の手間が省けるわけで、
Javaはその辺、微妙というか中途半端というか。

>>332
なんでJavaが？

>>330
オブジェクトというブロック？
クラスじゃあないん？

>>325
違う。

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

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

>>338
なぜ安全性＆完全性が高まるのかわかりません

同じ結果を生み出すプログラムを、いかに単独で完結した部品にできるか。

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

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

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

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

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

それは名前空間と依存解決の説明であって、オブジェクト指向違う。

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

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

「在る物を、在るがままに」

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

>>345
そなの？メッセージを送るときって、
"単にメッセージを送る"んじゃなくて
"なにかして欲しいから、その意思表示としてメッセージを送る"んでしょ？
ってゆうことは、
"メッセージ送出とメソッド呼び出しは等価"なんじゃない？

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

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

>>346
彼は意味わからずに書いてんだから、いちいち相手しなくていいよ。

さっきから上げてるやつは同一人物か

>>346
>利点が思い付かないし。

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

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

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

おー中山！！オッスオッス！！

>>350
ふーん、自分の言葉ではインスタンスとクラスを分離しないことの利点を語れないんだ。
ま、そんな奴と話してもしょうがないね。

なるほど。なんだか人によってオブジェクト指向の捉え方が違うみたいですね。
とりあえず自分も教えて君ではいけないと思ってe-wordで調べてみました。

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

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

353は325です。ネーム入れるの忘れてました。

>>353
長いので全然読んでないけど、

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

と書いておきながら、

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

で締めるのはどうかと。

>>353
大体正しいけど、「ユーザー」ってのは「ユーザープログラマ」な。

>>353
なんか、「要するに」って言葉の使い方が
技術に明るくない管理職っぽい感じ。

>>353
分かったなら、ちょっとここで
「オブジェクト指向」と「構造化手法」の違いを
まとめてみれ。

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

本に載ってる例題とかって基本的なことばかりだから
オブジェクト指向って素晴らしい！とは思えないなぁ・・・

>>359
それがほんとに例え話なら、まぁ正しい理解だ。

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

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

>>359
>開発者はその裏でfopenだとか色々練らなければいけない。
それをやらなくてよい言語が作られたら、
それがＯＯＰか非ＯＯＰかに関係なく、
俺は今すぐその環境に移行するのだが・・・

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

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

クラスツリーを変更したくなったとき困るとか、
複数クラスにまたがるようなアクセスが面倒くさい時とかいうのありますよね？
どうするのそこんとこ。

>>366
fopen()とか、stdio.hで定義されてる全てのものは、
オブジェクト指向的ではありません。というか、
C言語はオブジェクト指向をサポートしません。

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

>>367
リファクタリングだ。

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

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

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

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

>>363
ありがとう、今度読んでみます

>>362
次は「オブジェクト指向」と「カプセル化」の
違いをまとめてみよう。

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

>>370
非オブジェクト指向とオブジェクト指向の違いはなんとなくわかるけど
それで？ってカンジになっちゃいます(・_・、) グスン

>>370
じゃあ、Ｃでfopen()を使っていても、それを
「"FILE *" に "fopen" メッセージを送る」
と呼びさえすれば、それでオブジェクト指向といえるのですか？（ｗ

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

カプセル化って
#define private public
ってやられたとき困らない？
どうすんのそこんとこ。

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

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

>>378
なんで異なる言葉で呼ばれる概念を = で結ぼうとするのだろう。

>>377
#ifdef private
#undef private
#endif
か、
#ifdef private
#error ヴォケ！死ね！
#endif

>>370

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

っていうか、メソッド呼び出しやめて、
すべてのインスタンスにメッセージキューを持たせよう。

>380
ソースコードを直接いじられたとき困らない？
どうすんのそこんとこ。

>>381
"メッセージを送ると、結果としてメソッドが呼ばれる"
ってふうには説明されていないのかなぁ。だとしたら鬱だ。

>>382
全部のメソッドがスレッド(プロセス？)を異にする？

>>379
ですよね。一緒のはずありませんよね。
ちょっとぐぐって調べてみます。

>>383
なんで困るの？

Java厨ｷﾀ━━━━━（ﾟ∀ﾟ）━━━━━!!!!!

和ジオ/AnimeComic-Name/7676/

>>380
ﾜﾗﾀ
こういう心温まるコードを見ると感動すら覚える。

"fopen"をメッセージを送ると捉えることもできる。
その際、メッセージを送る先は FILE** ではなくシステム。

>>384
C++やJavaの構文では、「送る」というより、
まさに「呼び出す」という雰囲気が当てはまるから、
言い回しをそれほど意識する必要はない。

調べてみました。
が、
これってそのまんまオブジェクト指向と同じじゃないですか？
違いがわかりません。

>>393
マメだねぇ。
カプセル化って言うのは「機能とデータをひとまとめにする」ってこと。
オブジェクト指向って言うのは「オブジェクト間のメッセージのやり取りでコードを書く」ってこと。

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

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

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

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

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

>>395,396

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

>>396
"Object"を”システム化対象”ととらえ直したのに、
システム化対象の例として"「経理担当者」「社員」"など、
"モノ"っぽいものばかり挙げたのでは、何のために
"モノ"という訳語を拒否したのか解りませぬ。

>>394
>オブジェクト指向って言うのは「オブジェクト間のメッセージのやり取りでコードを書く」ってこと。

goto >>375

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

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

>>399

>>391

データ＋メソッド

>>401
Javaでもやっとけば？

Javaですか。じゃあ、ちょっとやってみようと思います。
自分はＣしか知らないのですが、そこから入ると考えても
やっぱりJavaが最適でしょうか？

>>402
∴Ｃ言語⊂オブジェクト指向言語

Q.E.D.

何か？

>>396
すんません、まず >>396 のいう「システム」とは
何かが分からないのですが。

情報＋手続き

>>406
ちょっと話を逸らすけど、
∴と⊂ってなんの記号ですの？

　　MM
　⊂ﾟДﾟつ∴ｽﾝﾏｿﾝ
　　UU

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

>>402
Cはオブジェクト指向言語ではない。
オブジェクト指向をサポートするような機能がないから。

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

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

>>410
>OOの基本的な出発点は、「現実世界の事象を、できるだけ
>忠実にソフトウェア上にマッピングする」ってことだ。
それはＯＯの出発点ではなくて、システム構築の
出発点ではないかと・・・

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

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

>>411
さて、そこらで一つ >>325 に

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

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

おまえら難しく考えすぎじゃねーの？

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

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

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

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

>>414

    な ん じ ゃ そ り ゃ 。

オブジェクトとは森羅万象なのだ。
Java/C#でいうObjectクラスに該当する。
全てのクラスのスーパークラスは森羅万象を構成するもの、
すなわちオブジェクトである。

>>409

∴ = 蕎麦畑 = 蕎麦 = 粋

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

要するに、

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

>>417
んじゃ、俺もObject?

>>415
>答えは実際に何度もこけて、自分で「自転車に乗る」という感覚を身をもって知るしかない。

言いたい事は分かった。

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

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

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

構造化とオブジェクト指向について結合度の観点から考えてみるよ。

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

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

>>420
あーそのとおりだね。　すいませぬ。

>421
要するにトップダウンではなく
ボトムアップで設計すれば
「オブジェクト指向」になる、ってこと？

>>423
ならねぇ。
なんでトップダウンやボトムアップって言葉が出て来たんだ？

>>419
そーいうことになる。
この世に存在するもの全てがオブジェクト、地球も宇宙も生も死もすべてオブジェクト。

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

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

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

>>427
(　´∀｀)ｵﾏｴﾓﾅｰ

>>427
いや、あれは面白かった。
不変の「永遠の型」、イデアがクラスで、実体がオブジェクトやインスタンス
これは解りやすかった。

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

恒例のOO派対非OO派のアプリ製作対決して

やい！やい！やい！やい！
テメェら！！

やいのやいの言うんじゃねぇよ

>>430
そんなもんどんなアプリ作るかで対決がどうこういってられる問題でなくなる。

>>430
よーし、それじゃ
「広島県庁の給与計算システム」でどうよ？

>>434
却下

んじゃぁ、「PRePで動くBeOS用のGeForce2のドライバ」でどう？

>>436
却下繚乱

お前ら、夢を作れ！！

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

>434
出席簿に○付けて、学校に行った事にしてくれるプログラム。

あ、リンク間違った。
>>430ね

>>439
単なるMapじゃないの、それ。

>439
つーか、フィールドって何？
スロットの事？

最新の音楽情報満載。音楽ファン必見のサイト　
アンケートに答えると、もれなく音楽ギフト券！！
http://camellia16.fc2web.com/ongakudb.html

>>439
つーかJavaScriptでも使ってれば？
いやマジで
http://www.tokumaru.org/JavaScript/

キチガイが居るようですが、、

>>423
ボトムアップはXP (eXtreme Programming)じゃないか？

プログラムパラダイムとソフトウェア工学を混乱しているヤツが
とても多いようだ。

>>447
設計はトップダウンでしょ。
コーディングはユニットテストの助けがあるから好きにやれって感じ。

いや、こうか。
s/設計/分析/
s/コーディング/設計-コーディング/

>>448
解説願います

>>448
是非

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

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

>>114
>implementsはextendsの代わりに使うものであり
Interfaceに対してプログラミングするんだろうがよ。
まぁ、やり方はいろいろあるが。
てめぇは言語仕様から引用してるだけ。実装したことある？

>>454
キツイね・・・

もうこんな時間かよ！！

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

任意ってあーた、分析→設計の連続性がOOの特徴だよ。

で？その時はボトムアップでアプローチしなきゃなんないわけ？


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

OO と大雑把にいうと、 OOA や OOD も含まれるんでないかい。

>>460
で？
オブジェクト指向分析は、ボトムアップでアプローチしなきゃならないわけ？

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

ということだ。
>>OOﾓﾅｰ氏など

「オブジェクト指向」とは、あくまで考え方。
その考え方に基づいたプログラム手法がオブジェクト指向プログラミングであり
同様な設計手法がオブジェクト指向設計。同様に分析手法が（略

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

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

これが基本。

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

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

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

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

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

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

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

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

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

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

だからさー
そんな教科書みたいな説明したって分かるわけないじゃん。。。。

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

何の疑問ももたずにオブジェクト指向を身につけた人が
人に「オブジェクト指向とは」っていうのを教えると、決まって例え話を
持ち出すのは何故なんだろうか。

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

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

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

つーか、どう見ても467は分かって無いだろ

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

467の語るオブジェクト指向の利点は余りに小手先過ぎる。

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


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

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

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

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

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

哺乳類クラスから犬猫サル人クラスに〜っていうのは典型的な
悪いOOの説明だよな。実際、そういう設計思想で作ると無駄だけ
増えてすっきりした実装にはならない。

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

　オブジェクト指向というのは世界観でしょう。元々潜在的にオブジェクト指向という世界観を持って
ないとＪＡＶＡやってもオブジェクト指向にならないのでは？先にオブジェクト指向という世界観が
ありであってＪＡＶＡがありでないでしょう。ＪＡＶＡはオブジェクト指向という世界観に気づくきっかけ
を作ることはできても元々オブジェクト指向という世界観を持ってない人には理解不可能と思うが。

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

466までがis-a関係の説明。
で、今回がpart-of関係を説明してみる。

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

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

カプセル化と情報隠蔽について

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

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

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

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

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

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

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

>476

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

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

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

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

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

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

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

★男はココを見るべし★女と金と？？？★
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
http://www.pink-angel.jp/betu/linkvp2/linkvp.html

すげーレベルだな。
おまいらの設計＆ソース見なくても想像つくわ。
今日中に辞表出しとけ。
以上

畑違いですまんが、仏教の教典によれば、悟りを得る初心者には
四種類あると解かれている。

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

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

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

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

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

>>482
良いメタファですね。

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

>>478
＞｢もし仮に、どんなプログラミングの初心者にでもオブジェクト指向の利点が分かるように
＞説明するとすれば」という意図から書いたものだ。

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

( ´,_ゝ｀)ﾌﾟｯ

？？

素朴な疑問ですが、OOってデバッグ大変じゃありませんか？
何がどう動いてるか調べるために追いかけて行くと
クラス階層まで入ってってしまってわけわかめになるんですけど。

>>486
非OOの方がデバッグが大変
OOはデバッグや保守、改良などをしやすくするために考えられ、洗練されてきた、と個人的に思う

>>486 設計が歪んでいると泥沼。正しいとパラダイス。
OOPはそこんとこ、重要。

>>486
言語による。
クラスを作らなくてもO.K.なオブジェクト指向もどきな言語はデバッグが大変だが、

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

>>487
○ >488
× >489

>>488

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

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

この件ってどの件？

>>493
馬鹿ﾆﾏｼﾞﾚｽ

>>494
ネタにマジレス

>>495
バカ登場

>>496
一番のバカ・・・

>>497
２番目にバカ？

なにを〜　オレの方がバカだぞ！

犬とかネコとか山田さんとかそういうことは理解できるんだけど
それを実際のアプリ製作に当てはめようとするとどうもいまいちわからない。

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

ない。以上。

>>500
それが一番楽しい作業じゃないのか？＞クラスの洗い出し

>>502
病気ですね。

>>478
しゃべればしゃべるほどわかってないのが、浮き彫りだね！

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

>>500
激しく同意。

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

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

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

>>505
それは、単純に内容を忘れていただけの場合もある

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

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

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

>>507
内容を忘れてたら、誰だって忘れてることに気づくよ。
書いてある文章の意味を理解することと、本質を理解することの違いの話なんだけど。

>>508 10年くらい前入社したての頃に
同じ様なこと考えてたから気持ちはわかる
ただそんな処にいる人にオブジェクト指向の
なんたるかを語られてもなあ

http://www.agemasukudasai.com/bloom/

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

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

>>505

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

イイと思いますよ。

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

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

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

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

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

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

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

あ、ひでー。
初心者洗脳してやんの。

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

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

>>515 が煽りで釣りを楽しんでる香具師、と分かっていても、やはりこう言いたくなるな。

「OOは効率が上がる」

フツーにプログラミングしてりゃＯＯはどう考えても要ることが分かるぞ・・・。515 はひでぇなぁ。

>>48
抽象的な概念を導入することでなんで作業を一般化することになるの？

>516と517はセンスの無い奴だろうな

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

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

>>520
それは、アンタのアンチの執念が3日で完成させただけかと…

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

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

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

わらた。
面白い漫才スレをありがとう。
脳みその凝りがほぐれたよ。

>>523
こんなんで笑える脳味噌なら捨てちまえ！

巷に馬鹿はたくさん居るが、

真実＝己の視界の範囲

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

>>525

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

>>525
これは再帰か？

>525

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

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

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

愛だ！！愛！！！！（´д｀）ハァハァ

>>522

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

今の世の中のソフトウェアのほ必ずOOらしいことやってるだろ。負けを認めろ！

クラスで役割が定義されていて適切な名前がつけられているのがどれだけありがたいことか。

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

オブジェクト指向の理解度

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

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

漏れとしては形だけでも理解してなくてもいいからとりあえず OO を始めていただきたい。

案ずるより産むが易し。習うより慣れろ。

古人はいいこというね。

OO、OOといいながら、OOAもOODもしてないのに
製造にOOPだけ押し付けるのはやめてくれ。

とりあえず、構造化プログラミング＋そのとき必要になったクラスを
随時追加って感じで作り出しちゃってもいいですかね？

★あなたのお悩み解決致します！！
●浮気素行調査
彼氏、彼女、妻、夫の浮気を調査致します！！
●盗聴器盗撮機発見
あなたの部屋に誰かが仕掛けているかも！！
●行方調査
行方不明になっている家族の消息を調査致します！！
●電話番号から住所割り出し
一般電話、携帯から住所を割り出し致します！！
●ストーカー対策
社会問題ともなっているストーカーを撃退致します！！
その他人生相談からどんなお悩みでも解決いたします！！
　直通　　０９０−８５０５−３０８６
ＵＲＬ　　http://www.h5.dion.ne.jp/~grobal/
メール　　[email protected]
　　　グローバル探偵事務局　

「オブジェクト指向はこう使え！！」

設計の終焉?
http://objectclub.esm.co.jp/eXtremeProgramming/IsDesignDead.html

ＯＯに則ったコード設計は実に難しいと思う。

>>541

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

とにかく何らかの意図をもってクラス分けすりゃいいと思うよ。

ASPからC#に移行するメリットはオブジェクト指向で設計実装できることだけしか無いのだが、
会社のＰＧどもがそれを理解できない奴らばかりなので困ってる

>>542
禿胴。

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

というのは普通だよね？ウォーターフォールﾏﾝｾｰ馬鹿じゃなければ。

それではクラス設計しないで適当に実装するのとかわらん。
現実に無理とはわかっても、最初からカンペキなものを作る覚悟で設計しないと

>>545
分析レベルで完璧にしても、実装してみたらいろいろ不都合が起きるものですよ。
そういうことを言いたかったんだけど、誤解される文章でｽﾏｿ。

でもって、そういう不都合が全く発生しないような分析/設計フェーズの
実践が可能、などと思い込んでいる、現実しらずをさしてﾏﾝｾｰ馬鹿と
よんでみました。

つーか改造／改良にこそOOが威力を発揮すると思うのだが。

改良しようとしてもOOしてなきゃコードが読めん。

ダメ過ぎ

>>550
貴方ほどじゃ…

(^Д^) オブジェクト思考でオブジェクト指向しようよ！

ダメ過ぎ

　　　　　　　 　 ／´⌒´⌒＼
.　　　 　 　 　 / 〃　ハ　　ヾヽ　　　　　
　　　　　　　　|　ノ∠、ﾉ,ムヾ |　　　 ／￣￣￣￣￣￣￣￣￣
　　　　　　　　（|| ━｀ i　━ ||）　　＜　オブジェクツ！！
　　　　　　　∩｛ 　 ｒ ┘ 、　｝∩　　 ＼＿＿＿＿＿＿＿＿＿
　　　　 　 ＿|└９ ｋ='=ヶ} ６┘|＿
　 　 　 ／　 にニ｝､_￣´_/にニ｝　＼
　　　　|ヾ　　ﾄーｲ{≫又≪}ﾄ―ｲ　〃 |

>>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の中の人

プロの逝って良しの１ ってC++スレとかにも顔出してる
日本語の不自由なかわいそうな人ですか？

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

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

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

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

＃データベースアプリで無理にOOするなゴラァという話もあり・・・

>>557

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


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

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

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

OO が要るところはそういうことで、ページをオブジェクトでマッピングするのもそれはそれで
便利だけど、それは設計ってわけじゃなくて、技術基盤として便利だねってことで、それは
分析、とはあまりいわないんじゃないかしら。

いまさら提出して「二日でできました」つうのも、もう詐欺っぽさ満点だというのは
置いておくとしてもだ。

そのコード量じゃねえ。
再利用できない無意味なモデルだし。

まあ、ＯＯは作り捨てに向いているってことかな。
パターンマニア向けでしかないね。
仕事では使えない。

>>560
どうやってその結論に到達したの？
飛躍し過ぎでサパーリ解らない。

もう１０スレの費やしての説明で疲れました。

実証と理論的検証両面からＯＯはダメつう結論です。
必死に反対してる信者がいますが、現実を見ない者は滅ぶだけ。

俺に抗議しても現実は変わらんよ。

ＯＯに興味が無いならのぞきに来なければいいだろうに。

業務だからOOなんでは？
OOは大人数、大規模プロジェクトで複数の人がコードを参照し
仕様変更による改良・改変しデバッグをしやすいというのが売りなんだから
リバーシのような個人が数日で作れるようなソフトではプロセスをそのまま
コーディングする非OOの方が慣れてる人が多い分、早くても自然だと思います。
コードの量が増えるにしたがってOOが有利になると思います。

改良・改変・デバッグに費やす時間（ソースの量Nの増加として）
非OO：OO　＝　N：Log N　って感じかと。

◎◎を使えねえやつはいりませぬ。文句を言っても◎◎を使えるやつは
貴重だな。

>現実を見ない者は滅ぶだけ

・・・どっちが？

>>565
笑った。
しょーもな。

オレルールで開発するのが楽なのは当たり前。
OO だと既存の開発プロセスや設計手法が沢山あり、
それに従って開発するのが OO だと思われているので、
不適合なプロセスを選択すると不自由を感じながら開発することになる。

>>563
「現実」ってのは『非OOを支持してるのがお前だけ』だということを指してるわけか？

oo = 北朝指向

プ1はどういう経緯でOOに恨みを持ったのか…
よっぽどろくでもない生兵法馬鹿に粘着でもされたのかな。

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

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

と言ったコンサルが居たそうだ。
笑っちゃうね。

洗脳されてる奴が周りにいると仕事やりづらいので世論を軌道修正すべく
日夜２ちゃんで広報活動に勤しんでいるだけで、別に恨みは無い。

>>573
おそらくそのコンサルは10年間寄生虫になることを目論んでいるロクデナシだった
んだと思うが、
アンタみたいな硬直した脳みそがイッパイいる企業を再教育するのには、確かに10
年みないといかんかもね。

>>565なんか本に書いてある事そのまんまでしょうが。
オウムなんかに引きこまれたらさぞかし疑問を持たず、
教えられた教義をただ繰り返す人なんだろうなと思う。

OOだろうがコーディングの規約レベルだろうが流行のフレームワークだろ
うが、アンタ(あるいは俺)の俺様ﾏﾝｾｰスタイルに何らかの制約を掛けるの
は当たり前。
そのトレードオフは開発効率や保守性の向上。対企業システム開発なら
その実現は満たすべき重要な機能だと思われ。他人にとって見通しのよい
構造にしておくのは、単に動作するかどうかの次くらいに重要(なはずなん
だが、アマリにも実装能力の低い糞集団は、この機能を無視するんだよな)
だとおもわれ。

俺だっていつも俺様マンセーで開発したいとは思うが、人から与えられた
仕事をやる限りは、そうもいってられないでそ。

ooセミナーwとかして、信者候補生だまして
飯をくいてーなー。
信者はもっと普及活動しろよ。
オブジェクト指向って言うだけで金が
はいるんだもんな。
ｲｲ世の中だw
IT国家まっしぐらだw

いやー、ＯＯ反対だと「硬直した脳みそ」ですか。

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

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

などと、疑問を持つものや反対者を「生産性を下げる人」とレッテルを貼るのと同じ
洗脳の手法によって、洗脳に対して免疫の無い若い人を中心に布教したんだ。

>>576
あいたたたたた
前に進むことも見ることもしなくなった、単なる古いオッサンじゃねーかよ
お前みたいなのがいるとこっちが仕事やりにくいだろ

年取ると新しいことは覚えずらいかもしれないけど学習しろよ
置いていかれるぞ？

>>577
それもソフトウエア業界の問題の一つ。
集団による開発効率向上の手法は、しばしばその手法を正しく適用できる人がおらず、
単なる原理原則論の非実際的な適用によって返って効率を落としている。
その手の集団手法を好む会社は、例えばどうみても５人年で済む仕事に
３０人年投入してたりする。

おれもOOがカンペキでスバラシイなどとは一つも思ってないが、

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

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

本読んだだけで分かった気になって、上司の攻撃に利用するマンセー
厨新入社員が大嫌いなのは、俺も同じだ(ﾜﾗ

学習ときたか。
やれやれだ。
本人大真面目なんだもんな。

以前ＯＯマンセーだったこの板の人達にコード出させたら、全然ＯＯじゃなかった
という話も付け加えておこう。

>>584
OOを完全否定か？　あんたは？

なんだかプ1って意外とまともな気がしてきたな。

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

で、OOもその類だというわけね、あんたは。

>>584
そりゃOOとは関係無いな。
そのマンセー野郎が馬鹿だっただけでしょ。

指向や思想を売ったり、押し付けたりするのは
どれに限らずおかしい事なんだよ。

だいたい指向ってなんだよ？指向ってよ？
新しいパラダイム？はぁ？
おまえらはさぞかしパラダイムシフトしたんだろうな？
オブジェクト指向のほかに何指向があるってんだよ。
俺は、ｱﾔﾔ指向だ。

>>584
ああ、OOマンセーといいながら使いこなせていない糞が
巷に腐るほどいて、現実問題のの解決に対して足を引っ張
っている=OOがダメっていうことか。

まあ、それはOOを別の概念にさしかえれば、どれにでも言え
る話だな。

「使いこなす」って表現が出る次点で
おかしいだろうがよ。
指向なんだろ？

マジで、洗脳ｯﾃｺﾜｲﾈ...

hoge指向

>>588
>オブジェクト指向のほかに何指向があるってんだよ。

お前にいい言葉を教えてあげよう。「教えてください、お願いします。」
この言葉を覚えるとそのうちいいことがあるぞ。

>>588
オブジェクト指向というけど、実際にこの単語を使うときは
「(狭義の)オブジェクト指向という思想に基づく数々の手法」
の総称をオブジェクト指向と呼ぶほうがおおいようなきがする
な。

アスペクト指向==AspectJとか、そういう人多いよ。

>>592
偉そうに・・・
ｷｼｮｲんだよ。
お前、金八指向な。

なんか、活発に議論してますねー

ＯＯは駄目ですか、では僕は何を勉強するべきなのでしょうか？
すいません。道を示してください。

>>594
>金八指向
いかん、ツボにはまった。激藁

「プロの逝って良しの１ 」氏の言は、漏れにとっては新鮮だ。
「オブジェクト指向は素敵」と聞いて、漏れはあっさり信じちゃったからな。
確かに、疑いの目を向けてみることは必要かも。科学的にね。

ただまぁ、実感としてオブジェクト指向は素敵だと感じてる。
「問題を分析する際に、その問題を構成してる『モノ』達と、
そのモノたちの間で交わされる『メッセージ』を基盤とする」
と言うことよりも優れた分析方法ってのを知らないから、
漏れは当分オブジェクト指向にしがみつくしかないけど。
モノを基盤とせず、操作(？)を基準とした問題分析って、難しいんだよなー。

>>593
アリが�d

俺はOOがダメなんていってないよ。
詐欺コンサルや提灯記事に安易に流されて、理解していない
ことを「手持ちの道具」扱いするなといっているだけ。

まともな奴が使えば効果が上がり、馬鹿が使えば悲惨なことになる？
んなの、何だってそうだろが、ボケェが！

>>600
そのとおり。だが、一方で「どんな物事でも一様に悲惨にする」
馬鹿が業界には大勢いて、でも多くのまともな人間が、そいつら
と仕事せにゃならん現実もあるわけで。

>>595
勘を磨くとか、対人関係スキル上げるとか。

>>603
とりあえず、歯を磨くことにしまつ。

いっとくけど、おれはOOを分かってないよ。
OOで作られたシステムとそのプロセスにかかわり、それを通じて
観察したことがあるだけ。見えなかったことは知らんので、あて
にせんでくれ。

>>602
いえいえいえいえ、そのようなことではなくて、それが大切なことはわかりますが
とりあえず、設計方法のほうをお願いします。

>>605
きびしいなぁ。ｱﾝﾁOOなだけの人に、
まともな設計方法の提示ができるわけ無いじゃないですか。
敵の退路は立ってはいけません．それは、予想外の事態を生みます．
まったりちゅらさんでも見るﾖﾛｼ．

プログラミングしてたら、OOは自然と身につくもんだから。

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

クソセミナーやクソコンサルに騙されちゃいかん。

プログラミングを学習する上でOOを意識するのは極めて有効なのは確かだ。

エンジニアなら技術で勝負しろっつーの。
OOがスキルだと思うな。良いのや悪いのや詐欺やらを
判断しながら、自分なりに取捨選択して
取り入れていけばいいんだよ。要はセンス。技術者なんだから。
そこにある要求定義に対して自分のセンスをぶつければいいんだよ。
小泉風に言えば、柔軟かつ冷静に対応。

>>606
おーい、「まったりちゅらさん」ってなんだよ！
ぐぐッたけど、なんもでてこねーよ！

>>610
その場合の「まったり」は形容詞だ。
本体とは分離しなければ望む結果は得られないだろう。
オブジェクトの切り出しを誤ってはいけない。

OOだろうがなんだろうが、現実にその手法で設計を行い、後で評価して
フィードバックする作業を繰り返すことナシに、ガッコのオベンキョだ
けですばらしい設計手法が身につくと思っているアホは、しんで欲しい。

>>610
読点なくてスマソ．ことえりよりアホだとは想定しなかったので．
「まったり」は「見る」にかかる福祉で、
つまり、
「まったり、『ちゅらさん』を見なさい」といういみでつ。

>>609
「柔軟かつ大胆に対応する」だろ

>>605
手続き型で書こう

プ1が考えてることっていうのは、上流とか下流とかあって
設計する人とコーディングする人が分かれてるとうまくいかねーって
ことではなかろうか。

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


OOを悪用してヒエラルキーを作りたがる勢力がいて、
ここらへんの利権がらみの解決を行うのは、不可能に近い。

>>615
> プ1が考えてることっていうのは、上流とか下流とかあって
> 設計する人とコーディングする人が分かれてるとうまくいかねーって
> ことではなかろうか。

どこがそんな風に読めたんだろう．

>>616

>>573 あたりで

俺指向でいけ

>>614
すいません、手続き型＋αしたものがオブジェクト指向というものではないのですか？

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

今見たページにこう書いてあったのですが、オブジェクト指向も同じことするのでは？
勘違い指摘してください。

>>617
573>>「ＯＯはすぐに結果の出るものではありません。５年先、１０年先を見て行うものです」
573>>と言ったコンサルが居たそうだ。
573>>笑っちゃうね。
と、
615>>プ1が考えてることっていうのは、上流とか下流とかあって
615>>設計する人とコーディングする人が分かれてるとうまくいかねーって
615>>ことではなかろうか。
の間にミッシングリンクがある気がする,,,,

>>619
手続き型であれば、そこに無条件分岐とか、
構造化されてないのものも含まれるはず。

たぶんあなたはDQNサイト観てる。
ﾁﾊﾞﾐｿｰﾘﾖｰ

>>621
無条件分岐？　gotoのことですね。

構造化されてないものも含むって・・・え？　
手続き型を学ぶとはそういうものを駆使しろということですか？

>>619

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

+α の部分を言うならば、OOすると複雑な分岐を省略することができます。

>>622
gotoなどを駆使しろ、と言うのではなく、
「『手続き型』と『構造化』を混同してるんじゃないの」って突っ込み．

OOは手続き型を含めてOO。とか言ってるｶｷｺを前にみたなぁ。
まあそうだと思いこんだとしても、
それでどこがパラダイムシフトなのかと小一時間(ry

C→C++、Pascal→Delphi、Perl→Perl5
と手続き型をベースに OO の機能を乗っける言語が多いからねえ。

>>625
もう、訳わからないのです。　パラダイムシフトかどうかはどうでもいいんです。
なぜＯＯは否定されたのですか？　

手続き型はオブジェクト指向の土台ではないのですか？
何で土台に家を建てたら駄目なのか、ヒントをください。

>>623
OOじゃなきゃ、複雑な分岐を省略できないわけでも、
手続き型だと、複雑な分岐になるわけでもない。
お前の発言には、何の意味もない。

>>626
だ　か　ら　な　に？

>>627
オブジェクト指向は、問題の分析とか設計とかを、
「オブジェクトと、その間のメッセージのやり取り」
と、捉えること．

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

全く異なる概念だね．
どっちかがどっちかの土台であるわけでは無い．

Perlでもくだらねーif文の嵐を回避するテクは存在するがな

>>630
ところが、JavaだのC++だのは、メッセージのやり取りを操作とやら？
で表現するんですよ。

>>627

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

OOを好んで作ったっていいんだけど、素人には
おすすめできないってことだろう。プロならなおさら
慎重になれって。

>>630
なるへそ！
ちょっとわかった気がします。

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

ありがとうございました。

>>632
いや、「(メソッドの起動に限定された)メッセージのやり取り」で表現されてるはずだ。
非OO的な、メッセージのやり取りとして判断するのが困難な、
「その問題に置ける操作をいきなり抽出する」って方法は、あまりとられないはず。

>>635
現実には、そういうコーディングを注意深くすれば、そうなるという
レベルなんだけどね。

つうか、>>600- で、「手続き型」って語が不用意に使われてるが、
「手続き型」ってのは「順序に意味がある」ってこと。
これの対義語は「関数型」であって
「順序がどうであっても、結果は同じ」ってことなのです。

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

>>637
あ、調べてる途中、なんかそう感じました。
やっぱり手続き型とOOは仲間ですか？

>>636
意味が分かんない．　例えば、Javaで普通に設計すると
「全部のメソッドをpublic staticにしたクラスが林立する」
ってことも、あなたの主張に含まれますか？

>>638
いえ、全く関係のない概念です。
依存し合うわけではないし、排他的なわけでもありません。

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

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

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

優劣を論じたり、ＯＯは使えないとか非ＯＯは古いとかっていう二元論に
持ち込もうとする人間が最大のガンなんだろうと思う。

>>641
禿胴！

プ逝１はオブジェクト指向を理解していないので反論は無意味です。

> 非ＯＯで新規開発するのと、ＯＯで新規開発するのは、若干ながらＯＯで
> 開発するほうが工数がかかると思う。ただ、ＯＯで最初から開発しておけば
> 後々の拡張を考えたとき、非ＯＯよりは工数が少なくなると思う。
幻想です。優劣を論じたいのは貴方ですね。

オブジェクト指向を使いたくない人は使わなければ済む話なのに…

>>645
個人開発ばっかりやってる人ですか？

OOな言語で開発したいけど
マイコンとかだとそうもいかないんだよな。
ROM32k RAM4k だとなかなかC++使う気にはならない
しょうがないから、考え方だけOOを使って
アセンブラやCで組んだりするわけだ。
設計にはOOの概念使った方がいい意味で手抜きできるし

★プロの逝って良しの１のパターン★

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


間違ったオブジェクト指向の定義に基づいて、オブジェクト指向を
批判するというプ逝１の詐欺行為はいつまで続くのだろう…

>>627
アンチOOな江戸幕府と、開国を迫る先進技術を誇るOOなアメリカ。
アンチOOはOOを妬んでいるのです。

OOを否定する連中はクラスを作るとコードが余分にふえて面倒くさいから、
重くなるから使いたくないとか不平ばかりいう連中なのです。

OOが単純にヨイと言い切れないのは、似非ＳＥ、似非コン猿がマッチポンプだからだ。

>>649
何のたとえ話ですか？
江戸幕府は、アメリカを妬んでいたのですか？

ヤイ！ヤイ！ヤイ！ヤイ！

>649 クラスを作るとコードが余分にふえて面倒くさい

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

で、｢Delphiはプロパティがあって便利だぞ！」
というDelphi厨の話になるんだがｗ

>>653
VB（ﾓｺﾞﾓｺﾞ

>>647
ってか，重要なのは考え方じゃない？Javaでもひとつのクラスに全部機能を実装
するヤシも実在するらしいし

トリップテスト

第二のテスト

>>655
Utils系は漏れもそうしてるぞ

>>655
あるCOBOLerが初めてJavaを使ったときに
すべての処理を一つのクラス、main()メソッド内
に書いてしまってオブジェクト指向言語の特長を
全く生かしていなかったという話があった。
有名な話らしい。

おまいら釣られてるんじゃない
http://java-house.jp/ml/archive/j-h-b/021822.html#body

>>659
ある会社はコーディング規則でそう決まっているのだ。
コボラーのせいではないのだ。

なんかJava＝OOと思い込んでるアフォがいませんか。

>>661
確かに子簿ラーのせいではないね。　
オブジェクト指向を理解しようとしないやつのせいだね

それは>>662だけです。

>>644
話のごく一部だけの揚げ足を取って「優劣をつけたいのはあなた」とか
言われても説得力ゼロなわけですが。
つーか>>641の内容を全部読んで、それで優劣を比較するという結論
に達した時点でアフォですか？としか・・・
あたしゃ非ＯＯの開発も否定してないですよ。ていうか、現実的には
非ＯＯがまだまだ主流じゃないですかね。ただ、ＯＯによる再設計とか
をうまく使うことができれば（あくまで「使うことができれば」ね）工数は
減りますよ。JDKのコンポーネントの設計を見ていると、うまく再利用
とか拡張ができるように工夫されてるのがよくわかります。

オブジェクト指向型言語の不得意な分野も指摘しておこう。
顕著な例はメモリマネージメント機能を持たず
メモリの少ない組み込みマイコンである。
ダイナミックなインスタンスの生成および消滅が困難である。
また同時に存在するインスタンスがどれだけになるか予測がつかない場合、
しばしばメモリがオーバーフローする。
このような場合手続き型言語のほうが便利であるし、オブジェクト指向言語を
手続きのグルーピングとして使用する程度の意味合いしかないのは事実である。
携帯ゲームのプログラマはＣ++をあまり好まない。

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

オブジェクト指向型言語の習得は修行ではない。
便利なら使えば良いし、不便なら使ってはいけないのである。
そしてこの判断が出来るかどうかは
悲しいことであるが設計者の知性のレベルに依存するのである。

>>665-666
ﾊﾞｶの長文氏ね　Σ(´Д｀lll)

以上、オブジェクト指向＝Javaという前提でお送りしました。
======================ここまで======================

>>666の上司は賢明なので勘違いOO信者の言うことをすべて却下しました

>>648
ﾜﾗﾀ

インスタンス変数をpublicで直接いじるのでは
なく、privateにして、setter、getterメソッドで
アクセスさせる方法が定石なのはなぜなのか、
違い（というか、できたらからくりも）
お前ら教えてください。

>>667
　長さを支えるだけの構成力があれば、長文もバカに出来ないゾ。
　長文＝バカと言いきってしまうのはどうか。

　とマジになってみるテスト。

>>671
そうしておくと、そのオブジェクトの変数を変更しようとする人は、
必ずメソッドコールしてることになるでしょ。

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

誰がいつどのように変更して、整合性の取れない状態変数の集合に
なっても全然かまわないクラスなら、全部変数publicでもかまわない
けど、普通クラスに複数の変数を宣言するときって、それぞれの変数
が全部"なんでもいい"って事は、ないことが多いでしょ？

>>671
publicな変数を１つ使って実現していた機能が、変数２つに変更したいとする。
外部から直接変数を操作していると、操作する個所すべてに修正を入れる
必要がある。１箇所２箇所ならいいが、数百箇所もあったらバグるのは目に
見えている。

setter/getterメソッドを使って実現していると、メソッドの呼び出し形式が変更
されない限り、変数の操作はクラス内部に隠蔽される。よって、変更箇所も
クラス内部だけですみ、修正工数もバグも激減することになる。

なんか必死に書いてるのがいるけど、
オブジェクトのインタフェースは、その実装方法に依存してはならない
っていう原則があるからなんだよ。

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

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

せっかくオブジェクトとして分離、隠蔽してるのに、メンバ変数を一個公開しただけで
そのクラスも、そのクラスを利用する他のクラスも、メンバ変数の実装方法に
依存した設計・実装をしなきゃ逝けなくなるの。

相手に見せる仕様は最小限に、とか、どっかの本に書いてなかった？

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

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

外からいじるため（だけ）に作る集約オブジェクトは、setter/getter
いらない場合もあると思うよ。

>>671
隠蔽しないと個々のオブジェクトとして設計していく意味がないから。

この辺りのことは入門書でも詳しく触れられているんじゃないすか。
読めよ。

>>640に洗脳されたアフォはこの先見こみが無いので転業しなさいね。

>>676
getter/setter 方式のメリットは、今は本当にメンバ変数を return したりそれに
代入したりするだけの処理をしていたとしても、クラスを修正したり、それを
継承した子クラスで処理が予想と変わり、get や set する際に何かしら演算を
してからメンバ変数に代入したり、メンバ変数の値を演算したものを返したり
することになることがあるとき。

リファクタリングで言う引数オブジェクトなんかは、とりあえず public な
メンバ変数でもいいのだろうけど。

＞＞６７９ 微妙にsetter/getterの意味を読み違えてるやつ

>>672
どう考えても、「ﾊﾞｶは長文書くな」って意味だと思うよ。

どうも、みなさんありがとうございました。
カプセル化（隠蔽）の必要性は本等で
読んでいます。
なので、公開する必要性のあるデータ
のみの話です。

1行のア/サクセサをつらつら書いておくのも
実際には今後の保守や拡張の為の保険って
いうのが主な理由なのですね。

>>678
おまえも非ＯＯの布教活動に躍起になってますね。　
どうですかＯＯから非ＯＯへの洗脳はうまくいきますか？

手続き型も関数型も同じじゃん。procedure か function でしょ。
要するに、void かそれ以外の型を返すか。

>>684
エイプリルフールは終わりましたよ・・・

OOって、データのクラスとそれらを使って何かやる人のクラスと
あると思うんだけど、正式な名称って何？
UMLとか勉強すれば書いてあるのかな
アクターってやつがそうなの？ アクトレスは？
きまぐれオレンジロードの主題歌って誰が歌ってたんだっけ？

>>686
ユースケース図とクラス図を行動しているなおまいは

>>682
違った面から見た理由をいうと
予めアクセサをつらつら書いておく必要があるのは、
メンバ変数のアクセスとメンバ関数呼び出しとで書き方が違うから。
同じ書き方であれば、必要になってからアクセサを書くで充分だったりする。

アクセサはせっかく隠蔽してあるものを透かしてしまう働きがあるとかで
多用すべきではないという話を聞いたことがある。

>671-679
Delphiにはプロパティがあって・・・（以下略

>>682
Beanにしたい　ってこともあるんじゃないですか。

>>684
そのネタ飽きた。

>>686
エンティティ、コントロール、バウンダリ
ロバストネス図を調べてみ。

>>692

なんか、こういう技巧を凝らした用語がOOに対する偏見とか
批判対象を作ってしまうような気がしてる。

全部読んだ。ココ、本当にスゲー！！！
会社で、ここにいるＳＥ程レベルの高い人間が居る？って思っちゃう位。

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

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

たとえば．．

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

みたいな達人達！

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

漏れはオブジェクト指向は目的思考とでも言ったほうが良かった気がする。
objectとまったく同じニュアンスを持つ日本語が存在しないために
苦肉の策としてオブジェクトというカタカナを使ったのだとは思うが、
物体思考だと勘違いする香具師がいかんせん多すぎはしないか。

ＯＯマンセーやってた会社はどんどん潰れてるから、昔よりＯＯ派の声が小さい。

>>696
> ＯＯマンセーやってた会社はどんどん潰れてる
ｿｰｽｷﾎﾞﾝ

>>695
そんなネタしか無いのか？

>>696
OOコンサルなんかやってた詐欺師連中は、新しいネタ探しにいってるだろな。
IT関連のベンチャーなんて、開発なんか本心ではﾄﾞｳﾃﾞﾓｲｲと思ってる山師ﾊﾞ
ｯｶﾘだからナー。

普通に使える人がイッパイいる会社では、普通に使ってるんじゃないのかね。

でも、その調子で、「ＯＯだ、ＯＯだ」と言いながら
巧いこと騙して手続き型に導くのも手だな。

>>697
仮定法

４月。
新入社員の中には「ＯＯやります」という会社の説明を受けて入ってみたら
クラス名が番号だったり、mainメソッドに全部書くキマリの会社だったり
するのが居るだろう。

>>700

漏れは非OOと見せかけてOOするステルスOOやってますた

>>702
そういうダメダメな会社はＯＯ以前につぶれる罠。

適度に荒れているなぁ
>695
『プログラマがやりたいことをオブジェクトにやらせる』
つうのが基本でしょうなぁ．

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

本当は『車．走らせる（プログラマが）』つうのが正解ですな

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

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

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

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

オブジェクト指向の本質はポリモーフィズムだよね。

>>706 のことは、メソッド名は同じでも返り値が違うってのもポリモーフィズム、、、と言っていいのかどうか。

OO厨はオブジェクト指向の本質１つ
　　　　　　　意見がまとめられないのかよ・・・

>>705
> 本当は『車．走らせる（プログラマが）』つうのが正解ですな

車.走れ();

だろう。

>>706
> int ret;
> KOUZOUTAI *kekka;
> ret = methodA(param,kekka);

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

の間違いか？

>>708
ほとんどのOO厨がちゃんとしたOOPの定義を知らないで
OOPとはこんなものだろうと推測してOOPの定義を勝手に
つくっているので統一されることはありません。

理系もおちたな

あいかわらずアフォばっかりだな

>>705
>>709
つーか現実世界の物体に投射しようとするところがそもそも間違いだと
思うのよ。プログラムで扱いたいことってそういう「物体の表現」ではない
わけでさ。そういう意味では>>695の説明が実に的確だと思うんだが。

まあそれにしても

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

こんなこと正気で考えているなら、今すぐ業界から足洗ったほうがいいよ。
きっと上司も冷たいだろう。

指向のオブジェクトがあるなら究極のオブジェクトもあるんですか？

>>715

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


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

基本要素はこれ。その中でも多様性がブッチギリで重要かつ便利な機能であることは確かだ。

>>714
オブジェクト指向の object は、物体の意味じゃなくて、subject に対する object でしょ。
だから、subject（プログラマ）が、object（対象）に命令する形が自然。
だからメソッド名は命令形なんだよ。

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

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

つまり、OO では、object が独立してあるわけじゃなくて、そこには subject に
支配されることが前提という語感がある。
｢物指向｣と訳しちゃった人は、object が自律的に動く、現実世界の｢物｣に対応
させたけれど、それは誤り。

>>718-719
サブジェクトがメソッドを使ってオブジェクトをいじくり回すということね。

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

>>719
死ね

>>719
ということはエージェント指向は、subjectの意識に逆らって
objectが自立しって動く指向なのですね？

誤った定義でも批判出来なかったのですね？

>>722
そう。

非ＯＯが入力プロンプトで人間が動くソフトウェアドリブンな方式
ＯＯがマウスクリックなどのイベントでソフトウェアが動くイベントドリブンな方式

のような印象があるな。

>>722
自立はしませんね。自律はするけど。
でもまあ、いままで subject - object という枠組みだったから、agent な
object がある程度の裁量権を持つというのはそれなりに画期的だったから、
それがわかる人には注目されてきたわけだ。

>>725
OO とイベント・ドリブンとは関係がない。ただ、イベント・ドリブンなフレームワークに
OO はなじみやすいというのは確か。

>>721
知らなかったからって、まあ、怒るな。マターリいきませう。

>>722
別の環境でいろいろといじくり回されるということ。
こっちからどっかに転送されてしまったエージェントは、どっかで
どうメソッドを呼ばれるのかわからない。
やられたい放題。
だから、セキュリティを確保するために、どこにいっちゃっても、
本当にめちゃくちゃにいじりまわされないような合意が必要。

>>716
究極のオブジェクト＝ぶろぶ

COBOLerなんかが作ってくれるらしいよ。

>>717

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

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

宗方指向

>>717
> ４）均一性（uniformity）

基本要素にこれが入るってあまり聞いたことがない。
少し調べてみたけど、多様性との違いがわからなかった。

で、１は理解できたのか？

自分で考えようとしない奴には誰が教えたって同じさ。

ここはやはりアプリを作ってだな・・・

>>731
細かい役割担当者の組み合わせで大きな仕組みを実現する、っていう
構造が再帰するような構造にしとくと、馬鹿なオイラにも分かりやす
い。

OOはヘンな宗教じゃなくて、物覚えの悪い馬鹿に優しい仕組みだと、
おいらは思うじょ。

>>731

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

731がいいことゆうた。

>>738

737のまちがえ。

>OOはヘンな宗教じゃなくて、物覚えの悪い馬鹿に優しい仕組みだと、
>おいらは思うじょ。

まったくもって同感。
オブジェクト指向は難しいものだと思い込んでる人に、そう説いた経験がある。
現在はその相手もそう思ってると聞きました。

いや〜、今日、死ぬほどたくさんのプリミティブ値の配列を準備して、全てその
配列への操作と大量のスイッチ文でプログラムを実現する、「根性の賜物」ソー
スを追う羽目になりまして、「ああ、ｺﾚ作った奴がOOをちょっとでも知ってたら、
オイラも楽だし、作った奴も楽だっただろうにな〜…何がなんだか分からんよ　つд`)」
と思ったのデス。

根性なしのオイラからみると、作者はある意味えらいとおもうんだけど、その根性
をすこしでも情報収集に向けてくれてれば…

>709
確かに命令形の方がわかりやすいけど，あえて使役の形にしたのは
「車を走らせるためにプログラマがお膳立てをしている」
というニュアンスを含めたかったから．
……まあ，大した意味は無いけどね

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

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

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

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

> オブジェクト指向の良いところは，（生まれてきてから何度となく繰り返して
> きている）現実世界での行動との相似性を利用できるところだから，
あと、パラメータを追加した時に外部の変更を最小限に抑えられる
とか、実行フローからの独立性が高くなるとか。

>>734
いいえ。
最近、さぼってました。
マルチスレッドの所で疲れました(プログラミングレッスン下巻）
しばらく、休みます・・・ゴホッゴホッ。

>>743
その引用部分は笑うところだと思うんだが。

現実世界の物体に自律して動くものがどれだけあるつうの？
殆どは受動的だよ。

>>1
ついでに、

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

スレも立ててくれ

あー aspect 指向興味あるんだよな。関連スレ立ってなかったけ？

>>746
＞現実世界の物体に自律して動くものがどれだけあるつうの？
殆どは受動的だよ。

ヌヒよ、すべての物体は自立して動いてるよ。わかるか？
ヌヒよ、すべての物体は原子からなっており、原子核の周りを電子が回ってるよ。能動的にな。
ヌヒよ、すべての物体は能動的なんだよ。わかるかな？

>>746
ネコ。

くされ、だな。現実世界で、お金がもらえなければみっともねーだろう。

>すべての物体は原子からなっており、原子核の周りを電子が回ってるよ。能動的にな。
本気で言ってるのか？

電子は自らの意思で原子核の周り、つかず離れずの位置を保っている。
この電子の意図は神すらも計りえない。これをハイゼンベルグの不確定性原理という。

>753
そこまでいくと受動も能動もクソもミソも無いだろうに。
疑似問題で言葉遊びされてもなぁ。

モノが能動的に動いていようがそうでなかろうが、モノを観察する人、
使用する人にとっては、モノに対するどんなアクションにどんなリア
クションがかえってくるかということ以外に、興味はないですの。

>>753
電子に聞いたのか？　おまえは電子の何がわかる？　おまえは電子の何なんだ！
電子が本当にそういったんだな？　電子がいったのだったら謝るが、それが何？

>>756
おまえは聞いたことないのか？　おまえはわからないのか？　おまえは知らないのか！
当然そういったんだよ！　早く謝れよ！　だから何？　

（プッ

>>757
ごめんなさい。

>>753
> これをハイゼンベルグの不確定性原理という。

言わないって。

× ハイゼンベルグ
○ ハイゼンベルク

>>745
>その引用部分は笑うところだと思うんだが。
同意。

>>742
クラスは抽象データ型の雛型です。
現実世界の雛型という定義は本質からズレてる。

液晶テレビ「AQUOS」が当たるチャンス
http://camellia16.fc2web.com/gpoint.html

死死死死死死死死死死死死死死死死死死死死

受動的なオブジェクトを支配下においてメインは手続き型で書く。
部品化可能なモジュールは見とおしが良いからすぐ思いつく。
逆に無理やり部品化したようなのは破綻しやすい。
上位層は構造化。
ＵＭＬ図は無用の長物。
これがあるべきプログラミングの最終結論。

すいません。
オブジェクト指向って、情報隠蔽、継承、多態性が柱だそうなんですが、
多態性って柱とまで言うほとのものなんですか？
だって結局のところ同じメッセージ受け付けるかどうかってだけですよね？

>>767

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

あとテンプレートとかメソッド名での late binding な Smalltalk みたいな
言語とかを使うと、「同じメッセージ受け付けるだけ」ってのが案外便利な
技法だってことに気付くと思う。

>>767
ダイナミックバインディングの便利さを知っているか？

ここは実装ヲタばっかりだな。継承やポリモが
重要というやつの実装は概念モデルがめちゃくちゃ
で他人には容易に理解できないという罠。

最新情報です。
甘く見てると痛い目にあう典型みたいなヤツだな。ｗ

http://www.deai-navi.net/linkrank/linkrank.cgi?mode=in&id=fdeai

オブジェクト指向、Strict-XHTMLと極右思想
http://tmp.2ch.net/test/read.cgi/sisou/1049523041/l50

ｵﾌﾞｼﾞｪｸﾄ指向とは・・・
簡単に言うと、「ｽﾎﾟｰﾂ」って言葉がある。
このｽﾎﾟｰﾂに属する物に「ｻｯｶｰ」とか、「野球」とかってあって、それが・・・

　　　　　　　　　　　　　（中略3379文字）

・・・いてはいけないよ！って言ってお茶を飲んだ。

>>766
perlのこと？

金・銀パール
プレゼント！

>>774
めまいがする言語はカンベンして

>>776
じゃあおまえはどの言語ならめまいがしないんだよ

パール以外

>>778
オブジェクト指向言語は別にいいのか？

>>778
関数型言語は？

関数型言語はメンテしやすいよ。
副作用が表に出てくる言語なんかより保守性はずっと上だし、
リファクタリングも掛けやすい。
副作用をストリームに隠蔽したりする考え方は、他の言語で
書くときも応用できる。

普通に仕事で使う言語以外しらんな。

　　　______________
　／:＼.＿＿＿_＼
　|:￣＼(∩´∀｀)　＼　　＜先生！こんなのがありました！
　|:在　 |:￣￣ U￣:|
http://saitama.gasuki.com/aomori/

　　　　　＿＿＿＿_＿
　　　 ／＿　　　　　　|
　 　 /.　＼￣￣￣￣|
　　/　　／　 ―　― |
　　|　 /　　 　-　　- |
　 ||| (5　　　　　　>　|
　| | |　　　　 ┏━┓|　　 ／￣￣￣￣￣￣￣￣￣￣
| | | | 　　　　┃─┃|　 ＜　こんなサイトを見つけた
|| | | | 　＼　┃　 ┃/　 　 ＼　　正直、スマンカッタ
| || |　|　　　￣　　　　　　　　　＼＿＿＿＿＿＿＿＿＿
http://saitama.gasuki.com/hiroyuki/

　（　・∀・）＜　こんなのみつけたっち♪　
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

　　　　　　　　　　　　　∩
　　　 　 　 ∧＿∧ 　　| |　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　 　 （　 ´Д｀）／/　　＜　先生！こんなのを発見シマスタ！
　　　　　 ／ 　 　 　 /　　　　｜
　　　　 / /|　　　　/　　　　　　＼ 　http://saitama.gasuki.com/koumuin/
　 ＿＿| | .|　　　　| 　　　　　　　 ＼
　 ＼　 ￣￣￣￣￣￣￣＼ 　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　||＼　　　　　　　　　　 　 ＼
　　||＼||￣￣￣￣￣￣￣||￣
　　||　 ||￣￣￣￣￣￣￣||
　　 　 .||　 　 　 　 　 　 　 ||

　　 ,.´ / Vヽヽ
　　　 ! i iﾉﾉﾘ）) 〉
　　　 i l l.´ヮ｀ﾉﾘ　＜先生！こんなのがありました！
　　　 l く/_只ヽ 　　　
　　|￣￣￣￣￣|
http://muryou.gasuki.com/sinagawa/

>>782
勉強しろよ

無知が癇癪を起こしている

結局多態性ってのは単に「同じメッセージを受け取れる」ってことに名前を付けただけなんですね。
dynamic bindingが便利かどうかなんてこのさいどうでもいいんでしょ？

うん

>>790
話に参加したかったら基礎的な用語ぐらい勉強してからにしようね。

大した物じゃないけど、いざ実装してみると色々便利だったりする。
OOにシフトする際になんかめりっとあるかって言われたとき、
実装レベルの便利さを立ててあげてもいいんでないかなあ。

プログラミングに大した物なんてない。
その中で最高の物の一つが多態性。

>>794
手続き（関数）をスッキリ構造化する手段として、便利ですが。

JavaDocとか、最近はやりのUMLベースIDEみたいな、クラス構造に関するドキュメントを
自動生成してくれるフレームワークがあると、仕様の後追いがすごい楽でつ。

メンバ変数をprivateにしてメンバ関数からアクセスさせて壊れにくくさせると
いいますが、けっきょくクラス内部で条件指定などをしてあげないと
壊れにくくならないので、それって普通の関数でも同じじゃんと思ってしまうのは
漏れだけでしょうか？

http://www.agemasukudasai.com/bloom/

>>796
そのメンバ変数はそのクラスのメンバ関数以外からは変更されない

普通の関数と同じじゃないだろ

>>792
こういう何か言ってそうで何も言ってない(言えない。言うだけの頭がない)人間との話になんて参加したくもありませんよ。

その 「だけ」 のことが便利だから柱の一つと呼ばれてるんだが。
このスレを 1 から読むなりデザパタでも調べろ。

>>799
はあ、そうですか。　だから？　何？

>>799
参加したくない場合に取るべき行動は何かわかるか？
ここに来るなってことだよ。

さっさと消えな。

>多態性
多態性というよりも、グルーピングといったほうがピンと来そうだけど……

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

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

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

このへんは現実世界でも良くあることで、例えば
・テレビ用のリモコン
・AVコンポ用のリモコン
・エアコン用のリモコン
なんかは、とりあえずpowerボタンを押せば、それぞれの装置のことを
あまり詳しく知らなくてもスイッチを入れることができるよね。
多態性って、そのあたりのメタファーなんじゃない？

つーかさ、VBでも多態性簡単に実装できるんだけど･･･。
なんか勘違いしてない？

どっから VB の話が？

Cでも多態性実装できますね。
アセンブラでも実装できますね。

つづき
次に逆の方向になるけど、次のようなケースも多態性が必要になるケースですな。
すでにできあがっている／作りかけのシステムに機能（仕組み）を追加したくなった。
その機能は全く新しい機能なので、既存のオブジェクトを調整するだけでは
実現できないけど、機能を実現するための仕組みは従来のオブジェクトを
操作する方法を利用できそうだ。
（実際うまく設計できれば、様々な機能を同じ仕組みの上で実現することができる）

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

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

つまり、多態性によって『機能』と『仕組み／操作方法』を分離することができるつうのが
『多態性』を重要なものにしている要因だと思うんだけど、どう？

>>806
VBと違って専用の命令ないけどね。

>>808
VB は命令で多態性を指示するのか。
悔しかったら VB で Template Method パターンをやてみろ。

>>806
昔、オブジェクト指向言語が簡単に手に入らなかったときに、
前向きにやろうということでそういうのを掛け声にすることは
あったけど、何が悲しくていまさらそんなことを。

ポータビリティのため。

>>811
厳しい環境だね。ご苦労さん。

多態デムパが暴れてるスレはココですか？

>>808
VBって、どんな命令でかくの？

>>770

いいことゆうた。ここみてるとオブジェクト指向って
実装レベルでしか浸透してないなーとおもふ。

>>809
へぇ〜 継承が出来ないから、Template Method"は" できないの知ってるみたいだね。
でも継承を使わないパターンは実装できるんだよ。
もちろん多態性が必要なパターンもね。

>>814
多態性といえばimplementsでしょ。Javaと同じ。

>>816
質問っす。
最近Implements (VB)知ったんだけど，べつにこれ使わなくても多態はできるん
だよね。ただ、他の強制力が多少はたらくっつーか、コードが書きやすくなる
っていうくらいで。

VB.NETがでたんだから、VBのクラスはもういいじゃん。

>>817
アーリーバインドとレイトバインドの違いもある。
オレとしてはコードのカキ易さ(+読みやすさ)も重視したいところだが。

実装(少なくとも定義)忘れが無くなるのはかなり便利だと思う。

>>816
インターフェースの継承しかできないじゃん。
「できる」っていえばできるけど、両足を縛られて 100 m 走をやれって
ゆうようなもんだよ。

VB6 までで、まともなオブジェクト指向設計しようとすると、
やってみればわかるけど、インターフェースの継承しかできないばっかりに、
かなりひねくれた設計になるぞ。
たとえば、メソッドの引き上げは不可能だから、別のクラスにして、すべての
子クラスからそれを呼ぶようにするとか。
かなりひずんだ設計になる。

> たとえば、メソッドの引き上げは不可能だから、別のクラスにして、すべての
> 子クラスからそれを呼ぶようにするとか。
要するに委譲のことですね。委譲は別に歪んだ設計じゃありませんよ。

>>821
始めっからインターフェースの継承の話しかしてないじゃん。
なに一人であつくなってんの？

委譲自体は歪んだ設計じゃないけど、委譲だけの設計ってのも異常だよなぁ…。
…あ、いや、シャレじゃなく。

>>823
委譲というか、オブジェクト・コンポジション。
オブジェクト・コンポジションはひずんだ設計じゃないが、メソッドの
引き上げをする場面でオブジェクト・コンポジションを使うと言うのは
ひずんだ設計だよ。

委譲っていうのは、自分自身のインスタンスをどれか別のクラスに渡すこと。

なんでメソッドの引き上げってリファクタリングの話してんだ？
設計の話だろ。VBなんだからVB用の設計をするだけの話だろ。

>>824
> 始めっからインターフェースの継承の話しかしてないじゃん。

ちがうねえ。VB で多態性ができるという話が始まったんだねえ。
インターフェースの継承も多態性のひとつだけど、抽象クラスの継承も
多態性なんだね。

>>828
リファクタリングは設計です。

VBでオブジェクト指向の話をすると
かならずメソッドの引き上げとtemplate methodの話で対抗する
奴がいますねぇ（ｗ

>>829
> インターフェースの継承も多態性のひとつだけど、
結論。VBで多態性は実装できる。

>>831
OO の定石だからね。できないとすごく不便。まともなクラス設計はできない。
すごくひずんだ設計になる。
って、OO のクラス設計をやったことがないとわからないか……

>>830
残念ながら違います。そんなアフォな事言っているのは貴方だけです。

>>832
VB で多態性は中途半端に実装できる。

>>835
中途半端ではないですね。ちゃんと多態性になっているのですから。

>>833
あなたはCでOOやったことありませんね。

CでOO出来るって言っておきながらVBでは出来ないって言っている
奴もいるくらいだからねぇ。
まぁ、認めたくないものは認められないって強い信念を持っている奴は
人間的に認められないね。

>>834
それは、古い｢計画的設計｣の頃のお話。
http://objectclub.esm.co.jp/eXtremeProgramming/IsDesignDead.html
進化的設計ではふつうの話。

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

>>387
C で OO はできるけれど、昔、OO 言語で納品できなかった頃の、前向きな
掛け声。できるできないといったらできる。でもひずんでいる。コードも増える。

>>815
実装しないで何すんの？

>>388
VB でも OO はできるが、とてもひずんだ設計になってしまう。

じゃー VB でも多態性の実現はできるけど、C で OO やってるぐらいに
歪んでいる、というのでファイナルアンサー？

C や VB で OO なんて、環境が整ったいまとなっては、わざわざやる意義はない。

>>842
C よりはマシでファイナルアンサー。

>>842
Cよりは歪んでないね。多態性が中途半端にできるのだから。

で、ファイナルアンサー。

要するに、VBで多態をやりたきゃ VB.NET を使ってろってこった。
// 俺は使ったことないから実体はしらんが。