お前ら俺にオブジェクト指向を教えろや　２周目

教えたがり屋の貴様らに今一度チャンスをやる。
俺に教えろ。

前スレ　http://pc8.2ch.net/test/read.cgi/prog/1114768433/

2げと

>>1
乙

また建てたのか

クソスレ２週目おめ。

= 絶対に負けられない戦いが、そこにはある - VIP =

悪質手法で金を巻き上げる「ワンクリ詐欺」
　　　　　　　　　　　　　　VS
　　　　　　 その悪行を全力で阻止する「ワンクリメン」

さあ、勇者よ、報道ステーションに向けて･･･
　　　　　　　　　ワンクリック詐欺サイトを撲　滅　せ　よ！！！！

http://sagamioriginal.yh.land.to/

☆ワンクリ業者を思う存分煽ってみよう！！ｗｗｗｗ
☆メールボム撃ち放題！！憂さ晴らしにもおｋ！！！
☆業者からの返信メールｷﾞｶﾞﾜﾛｽｗｗお返しメールﾃﾗﾜﾛｽｗｗｗ
☆VIPPER、いや２ちゃんねるの強さを見せ付けろ！！
※金土日夜９～１２時に田代祭り開催中　友達も呼んで盛り上がれｗｗｗｗｗｗｗｗ
（注：祭り中はhttp://tmp5.2ch.net/test/read.cgi/kova/1121693467/へ
　　なければhttp://tmp5.2ch.net/kova/に行けばいいとおもうよ。

http://ocbyebye.tripod.com/index.htm ←　四連田代砲でワンクリ詐欺サイト砲撃中
　　　　　　　　　　　　　　　　　　　　　　　　　　　マシンスペック･回線に自信があれば踏んでみ？


【重要】【重要】【重要】【重要】【重要】【重要】【重要】【重要】【重要】【重要】【重要】
昼間はおもに業者から口座聞き出し、口座凍結、各種通報機関に通報をします。

ご協力お願いしますm(_ _)m

オブジェクト指向って要するになに？

仕事が・・・ほしい（ウェブアプリ-ケーション）
http://yum.hippy.jp/pum/

ていうか何が嬉しいの？

仕事が・・・ほしい（ウェブアプリ-ケーション）
http://yum.hippy.jp/pum/

俺の認識では、

C言語　printf(); //ヘッダの内容をインクルードすることで使用
JAVA　 System.out.print();　//Systemクラスのout変数が参照するprintメソッドを指定

ｺﾚﾀﾞ!!!

俺JAVAよく知らないけどoutは変数なのか？

>>1
教えて君には教えてやらないよ。
努力もせずチャンスをやるなんて偉そうなこと言ってる奴には
苦労して得たアーキテクチャパターンのノウハウを教えてやらないよ。

>>11-12
outは変数ともいえるが
厳密は解釈では
Systemクラスのpublic staticなPrintStream型のフィールド。

変数という表現は正確ではないが
意味合い的には正しいよ
静的に標準出力ストリームオブジェクトの参照を保持している変数。

Systemクラスの静的な変数であるという意味では定数という言い方もできるし、
printメソッドから見ればオブジェクトであるとも言える。

難しそうに説明してみるテスト。

>>11
> 俺の認識では、
>
> C言語　printf(); //ヘッダの内容をインクルードすることで使用
> JAVA　 System.out.print();　//Systemクラスのout変数が参照するprintメソッドを指定

本来ならば
JavaのCのincludeのように以下のようなimport宣言をしないとSystemクラスってなんだ？
というコンパイルエラーが出るはずだが、

import java.lang.System;

Javaではすべてのクラスは暗黙のうちにデフォルトでimport java.lang.*;が宣言されており
これを省略することができる。なお、*はワイルドカードであり、java.langパッケージ内にあるすべてのクラスをimport
するという意味である。ただし、注意しなければならないことは、JavaのimportはCのincludeとは
違うものだという意識を持つ必要があることだ。import宣言は比較的自由に扱えるもののCのinclude宣言は
一度宣言すると、それを呼び出す関数があるコードにもまったく同じinclude宣言をすると重複になってしまう。
importでは違う。そのクラスで必要なものはとにかくすべてimportしなければならないのだ。
それからJavaではimport宣言をするときに上記に示したようなワイルドカード*を使用することは
おすすめしない。なぜなら、*を使われては、どのクラスを呼び出しているのか即座に見分けにくい問題があることと、
クラス名は同じだがパッケージ名がことなるクラス(たとえば、java.util.Date, java.sql.Date)をimportした
とき*を使うと異なるパッケージだが中に全く同じ名前のクラスが使われているとコンパイラは、どっち
のクラスを使えばよいかわからずコンパイルエラーをはき出す。
Javaでは継承を宣言していないすべてのくらすにおいて
暗黙のうちに java.lang.Objectクラスを継承している。

たとえば 以下のようなクラスを宣言したとき
class Test {}
と書くが、
これは暗黙のうちに
class Test extends Object {}
のようにObjectクラスを継承しているのである。

Systemクラスのoutはフィールドというが
C++でいうところのメンバ変数に相当する。UMLでいうところの属性に相当するともいえる。
ちなみにJavaでいうところのメソッドとはC++でいうところのメンバ関数に相当する。
UMLでいうところの操作に相当するともいえる。

ちなみに、Cにはあったグローバル変数、グローバル関数はJavaでは当然の如く
汚いものとして排除された。
オブジェクト指向に必要ないものはJavaではほとんど徹底的に排除されている。

>>17
グローバル変数が無い場合
何かのクラスは必ず何かに属するという上下関係が出来るんだよね？
オブジェクト指向において対等にメッセージを交換し合うということはないのかな？

>17
public static 変数は、グローバル変数じゃないの？
static メソッドはCの関数と同じじゃないの？

オブジェクト指向がわからないC厨哀れｗ

単に言語のイディオムをOOと表現するほうが憐れｗ

>>19
早い話、そのとおりです。

オブジェクト指向がわからないPGなんて食っていけないね

オブジェクト指向とは、「プログラムよくわかんないから、現実世界の例を使って単純に考えましょ」
っていう感じの 『考え方の指針』 で、それを使ってプログラミングするとオブジェクト指向プログラミングになる

ついでに言うと、カプセル化とか情報隠蔽とか再利用性とかは、『現実世界に既に存在していた性質』 を
プログラムの世界に移植しただけなので、オブジェクト指向の機能などではないし、少なくとも機能と呼んではいけない


オブジェクト指向は、あくまで 『考え方の指針』 を提示しただけ
んで、初心者が戸惑うのは、それにくっついた数多の付属品、というわけだ

>24
逆だろ、「現実世界にないから説明しにくい」んだろ。
だから動物の話や、ドラ○もん製造機の話になって、訳分からなくなるんだろ。

オブジェクト指向がわからないPGなんて食っていけないね

ああ五月蝿いな

まだこのスレ続いてたのか
延々ループスレ認定

じゃ、こういうのはどうだ？
オブジェクト指向をマスターした人が、自分のマスターした経緯を書くってのは。
これなら、参考になるんじゃね？

オブジェクト指向はメタファーだ！

>>29
ＵＭＬで設計したらわかるよ。
ああ、明らかに構造化設計とは違うんだなって。

>>13
お前が教えてくれるまで、俺は帰らない

オブジェクト指向がわからないPGなんて食っていけないね

大丈夫、すぐに慣れるさ。

オブジェクト指向は他人から教えてもらうものではなく
自分で習得するものだと思っているのだが。

C++の機能一通り使って中規模のシステム組んでみたらわかるんじゃね
それでも素直に頭に入ってこないのは頭が固いんだよ

オブジェクト指向がわからないPGなんて食っていけないね

>31
UMLってただの落書きにしか見えないんだけど、何の図を言ってる？
クラス図？シーケンス図？

>36
昔、Javaで中規模のシステム組んでるの見たことあるんだけど、
仕様変更の連続で無茶苦茶になって行くのを見て、「これはオブジェクト指向じゃないな」
ってのは分かったんだけど。

>>39
それは開発プロセスの問題で、開発方法論の問題ではない希ガス

ハガレンの映画見に行きたいんだけど

いけばぁ～？

おれはsmalltalkで遊んでオブジェクト指向プログラミングを初めて理解したな。

それはよかったですね。

smalltinkoでしょ

俺はJavaで、構造化プログラミングで組んだが、すごいプログラムになったな。
throw使わないために先にifで判定したり、細かくtryで囲ったり。
クラスの分け方が分からなかったから、メソッドを処理の種類毎にクラスに入れてたから、
仕様変更のたびにいくつものクラスに修正が入っていたな。
数回の仕様変更で破綻して作り直したが。

>>46
いいお勉強ができたみたいで
おれはこれから独習だよ

＞throw使わないために先にifで判定したり、細かくtryで囲ったり。
＞クラスの分け方が分からなかったから、メソッドを処理の種類毎にクラスに入れてた
ここら辺が構造化プログラミングと関係ないやんっつーのがツッコミどころですか？

何このオナニースレ

>48
ジャンプしないのと、機能で分割するのが構造化だろ。
オブジェクト言う前に構造化を勉強して来い。ボケ

>>50
この子はコーダ止まりで会社辞めて警備員のバイトってコースだね

>>50
順次・反復・分岐の構造化プログラミングと、データやデータの流れに着目した
オブジェクト指向以前の設計手法である構造化分析/設計技法がごっちゃに
なってないか？

>51
俺の将来の心配する前に、自分の将来を心配しろや、ボケ！！

>52
「順次・反復・分岐の構造化プログラミング」って何だ？
確かに俺の言ってるのは、
「オブジェクト指向以前の設計手法である構造化分析/設計技法」だが、
それが構造化プログラミングだろう。

>>53
違うと思う。多分うちの大学では前者を教えた。

オブジェクト指向がわからないPGなんて食っていけないね

>54
前者の、「順次・反復・分岐の構造化プログラミング」って意味がわからん。
順次、反復、分岐を使うのが構造化プログラミングだって言いたいのか？
それはプログラム言語の3大要素だ。その論理だとプログラムは全部構造化だぞ。
つーか、学校でそんな間違いはしないだろうから、お前の理解が間違ってるんだよ。

結局構造化さえ誰も理解できて無いってことね。

理解してなくてもプログラムが動くなら良いじゃんｗ

>>58
なまじ動いてデータ壊されたりするぐらいなら
動かないほうがまだいいと思う。心底そう思う。

>58
仕様変更繰り返しても動くならいいよ。
最初に作って変更無しなら、はっきりいって適当に作っても動くんだよ。

>57
俺は理解出来ているし、このスレの半分ぐらいの奴も理解出来てるよ。
そのうちのほとんどが、オブジェクト指向も理解しているように思える。
怪しいのは構造化を知らずにオブジェクト指向語る奴だな。

何度も使用する処理をサブルーチンにするんだよ。
一度しか使わない処理をサブルーチンにすることは無いだろ。
















と言う人が最近でもいる。

まじで俺はわかんなくなってきたぞw
構造化ってなんだ？？

構造化。それはあなたの青春の思い出。

>>56
＞順次、反復、分岐を使うのが構造化プログラミングだって言いたいのか

クラスを定義するのがオブジェクト指向プログラミングだって言いたいのか？
そうじゃないだろう。

>65
要素と手法は違うって言いたいのか？
それは俺の言っている事だろう。だからその要素を使ってどうやって組むのかが問題なんだろう。
構造化の手法を説明してみろや。俺は出来るぞ。

無知なスレが続くのでマジレス。

構造化＝手続き抽象
クラスベースＯＯＰ＝データ抽象＋手続き抽象

抽象＝．．．

という感じで言葉を正しく理解しる！

オブジェクト指向がわからないPGなんて食っていけないね

>>66
悪い。なんとなく混乱している理由がわかった。
「順次・反復・分岐の構造化プログラミング」の意味を脳内解釈してましたですよ orz

>67
言いたいことは分かるが、明らかに説明不足だ。
それに構造化すると結果的に処理の抽象化（分かりにくく言うな、ただの共通関数だろう）が進むが、
それ＝構造化ではない。

思想的な話はいくら言っても分からない人には分からないんで、実装的な観点で言おう。
1.「関数の入り口と出口はそれぞれ1つとする」
　つまりgotoの禁止と、途中returnの禁止。
2.「グローバル変数を使わない」
　グローバル変数使用の禁止。（中断処理のフラグを除く）
3.「機能毎に関数を作成する」
　変数のスコープ（有効範囲）に着目し、他のブロックと最も干渉の少ない単位で機能毎に関数化する。
　1関数どのぐらいにするかは意見の分かれる所だが、機能毎が判断出来ない初心者は1関数50行を
　目安にするといい。

以上だ。

50行？・・・長いなぁ

最大50行ってことじゃねぇか？
俺には50行すらも完全に把握する脳みそがねぇからなぁ・・・。
困ったもんだ。

>>71
だな。漏れの目安は30行弱ってとこかな。

コメント入れまくれば何とか５０行くらいは……やっぱ無理か

>>73
素晴らしい目安だ。

構造化プログラミング
http://ja.wikipedia.org/wiki/%E6%A7%8B%E9%80%A0%E5%8C%96%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0

オブジェクト指向プログラミング
http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0

構造化プログラミングは
徹底するには訓練が必要であるものの
現在では常識的すぎる（であるべき）内容な気がする。

構造化プログラミングとオブジェクト指向プログラミングは
歴史的に連続していて、構造化プログラミングで苦労していれば
むしろ受け入れられるはず。

俺の話はいつでも長い。

>72
すまんその通りだ、最大50行って事だ。
フォロー感謝する。

自分はいきなりオブジェクト指向から入った若い人間で構造化なんたらってのが
よく分からんのだがこういう奴のことか？
http://www.vest.co.jp/Shoseki/saving/saving_sasd1.html

　　　　　　　　　　※日中友好の同志を募集しています※
　　　　　　　　　　~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
現在の日中間は最悪な局面を迎えています。
中国サイトからのサイバーテロが相次ぎ、日本のサイトは危機を迎えています。
こんな状況下で我々は日々民間日中交流を行っています。

反日系中国ウエッブサイトへの友好交流をしてくださる方！
お持ちの知識・技術を活用してくださる方！
三度の飯よりお祭りが好きな方！
今の自分を変えてみたい方！
ちょっと暇だと思ってる方！
夏休みの思い出を作りたい方！
田代砲に興味がある方！
もちろん愛国心に燃えてる方も大歓迎！！！！

どんな志願理由でもおｋ！みんなの参加を待ってるお！


　　　　　　　　　「友　好」は「謝罪と賠償」じゃないです（´･ω･｀）

　　　　　　　　　8/6土 20:00 集合 21:00 集団訪問開始予定です。
　　　　　　　　　~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
★拠点
【友好交流】ハ´;）BAKKER　VS　VIPPER(´･ω【+盆祭+】112
http://ex11.2ch.net/test/read.cgi/news4vip/1122907493/
2chan専用プラウザをお勧めいたします。

なお、砲撃や投票に参加する人は必ずCCCにも参加してください。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
＊CCCに参加の際は板名などでもおｋですので必ずお名前を付けてください。

うんばぼ!うんばぼ!

>76
リンク先の説明は分かりにくい。誤解してた人がいた訳がやっと分かった。
オブジェクト指向の方はもっとひどい。分かってる人でも混乱するぞ。
素人が読んだらオブジェクトはメッセージングだと言い出しかねない。

構造化は常識だが、新人もいる訳だから常識で済ませる訳にもいかないだろう。
それに「基本情報処理」持っていても実践していない奴は多い。
話を聞いてみると原理は勉強したが、実装方法が分からないし習ってないと言っていた。

オブジェクト指向は構造化を習得すれば受け入れやすいと言う意見だが、
それは構造化をマスターしていて、さらにそれを捨てれば受け入れやすいとは思う。
オブジェクト指向と構造化の実装は全く違う。いわば90度違うと言う所だ。
なんせ、構造化原則の「入り口と出口が1つ」と言う時点で違う。

今のオブジェクト指向は最小単位を手続きで記述しなければいけないから
構造化プログラミングから逃げられないんだと思う

>78
違う、ここで言う構造化とは構造化プログラミングを指す。

>81
最小単位においてはその通りだ。

>>80
>オブジェクト指向と構造化の実装は全く違う。いわば90度違うと言う所だ。
まぁそこはよしとして。

>なんせ、構造化原則の「入り口と出口が1つ」と言う時点で違う。
「入り口と出口が１つ」なオブジェクト指向プログラミングはありえないと？
例外機構を使わなくてもOOPは十分可能だが？

OOPとは「データに振る舞いを持たせ、それら（オブジェクト）に仕事をさせる」手法のことだ。
従来の構造化＋カプセル化をさらに発展させた物がその正体だ。

「構造化 対 オブジェクト指向」で考えるからおかしくなるんであって、
「オブジェクト指向前 対 オブジェクト指向」で一度考えてみたらどうかな？

まあ手続き抽象 = 構造化って話は論外。
手続き抽象の歴史は構造化の歴史よりずっと長い。こんなのは歴史をしらなくても
ちょっと頭を働かせれば誰でもわかる。

フォンノイマンみたいな奴ならともかく、普通の人間は「意味のラベル」を貼ることができる
機能ブロックに分割できず、全てが有機的につながった様なプログラムは書けないし読めないから。

構造化ってのはその「手続き」の内部の設計を、受験勉強みたいに
パターン認識で解くことによってプログラムを書くことと読むことの両方を
効率化しようって話だよ。

ハイここは定数回ループする「パターン」、ハイここは値によって処理を選択する「パターン」、
ハイここは多分岐「パターン」って具合に。

ダメダメ！！
変な説明は初心者を混乱させるだけだ。
結局、構造化プログラミングは70で説明した通りな訳だから、もうそれでいいだろう。

次はオブジェクト指向の説明に移ってくれ。
それも思想的な事じゃなくて、実際にコーディングするイメージで頼む。

>84
オブジェクト指向の説明は正しいし、言いたいことは分かる。
ただその説明ではどうやってオブジェクト指向的にプログラミングするのか分からない。
ちなみに俺も構造化ほど明確に説明出来ない。
誰か「オブジェクト指向でコーディングする手順」を説明する勇者はいないか。

>>86
頭大丈夫だろうかこの人。
だから、>>70に書いてあるようなことは構造化とは何の関係もない、
少なくとも構造化のテーマではないと言っているのだが。。

オブジェクト指向で開発するととても楽で楽しくなった。
でも実行速度が遅くなったorz

よくできたコードを読んでまねするのが一番いいよ。

現在集団訪問中です

【友好交流】ハ´;）BAKKER　VS　VIPPER(´･ω【+盆祭+】112
http://ex11.2ch.net/test/read.cgi/news4vip/1122907493/
2chan専用プラウザをお勧めいたします。

民間の反日系中国ウエッブサイトへの抗議をしてくださる、お持ちの知識・技術を活用してくださる　等

・　・　・　・
日　中　友　好　　目的　での、ご参加をお待ちしております。



　　　　　　　　　「友　好」は「謝罪と賠償」じゃないです（´･ω･｀）

オブジェクト指向がわからないPGなんて食っていけないね

オブジェクト指向がわかる食い物を教えてくれ

ピザでも食ってろ

ピザ嫌いのため却下

その好き嫌いで拒絶する態度でオブジェクト指向すらも拒絶しているようですな
喰わずに死ね

そういえばまだ委譲について聞いてないな
誰かまともに教えられるやついねーのかよ。お前らゲスだなホント。
俺も時間ねーんだからもたもたすんな
自分で調べろだと？　ﾏﾝﾄﾞｸｾ

今の時世にＯＯ解らない奴なんているのか？

オブジェクト指向がわからないPGなんて食っていけないね

>>97
前スレで話したよ
下請け会社を取り込んで作業の丸投げ(委譲)をすること。
リスクのある吸収合併（継承）や新部署設立(仕様変更/機能追加)よりイージーかつ柔軟に必要な仕事をこなせる。

class Kogaisha{
//ものすごく便利な機能
}

class Oyagaisha{
Kogaisha k；
//気に入らなくなったら
//別の会社に替えたっていい
}

これで親会社は子会社の機能を使える。

むつかしくないだろ？

プログラムの見通しや再利用性を高め
継承、多態性、カプセル化を用いたもの

久石譲とどこが違うのか良くわからないな。

久石譲の名前の由来はクインシー・ジョーンズから。
よって全然違うよ！

103様
ご教授いただきまことにありがとうございました。
今までそんなこともわからなかった自分が恥ずかしいと感じております。
ご教授いただいたことは我が家の家訓とし、
末代まで103様のことは語り継ぐ所存でございます。

オブジェクト指向がわからないPGなんて食っていけないね

大きなものを分割する訓練をつめばよろしいかと。
オブジェクト指向言語ではない場合でもこの訓練は有効かと。

まぁ、最初は50-100 行程度のクラスを何個も作っていったらどうでしょうか？
訓練にもなるし、資産にもなる。

＞まぁ、最初は50-100 行程度のクラスを何個も作っていったらどうでしょうか？

はぁ？馬鹿ですか？

関数ならともかくクラスでそんな量はつかいもんにならん

>>107
行数で分けるのはおかしな話ですね。
オブジェクト指向をあまり理解せずに、行数の多いでかいクラスを作ろうとしていると、
ただ class 内にいろいろぶち込んだだけの「塊」が出来上がってしまう、
そう懸念したので、具体的な行数を出しただけですよ。
まぁ、50-100行 に無理矢理押さえ込もうとする方が苦痛になることもあるでしょうがね。

最初は、と書いたと反論されそうだな。
無理矢理行数制限付けて実装するなら継承乱発かなぁ。

>>110
こんなところで「俺の方がオブジェクト指向理解しているぜぇーー」、
なんていう幼稚な喧嘩をするつもりはありませんよ。どうせレベル低そうですし。ｗ

日本語よめんのかい？　被害妄想はげしすぎんか？
これぐらいしか手がないねとしか言ってないんだが。

>>109
全体の設計を視野に入れて
クラス間の関係を考えないと
伸びない気がするねえ

最初はビットマップとかの画像クラス作るべきだと思う
カプセル化、再利用のありがたみがよくわかる

オブジェクト指向がわからないPGなんて食っていけないね

クラスライブラリにおんぶに抱っこでいいじゃん。

アペオスのOOPっぷりには脱帽だね！
あれには舌を巻きますよね、ね！？
・・・・・・・・・・・・・・
どんでん返しですよね！！？！
どんでんは反さんよ、な？
どんでんは反さんでしょうｗｗｗｗ

わっはっはっは・・・・・

>88
頭おかしいのはてめーだ。
ぐたぐたぬかす前に、お前が説明して見ろ。リンクじゃなくてな。

>>118
文句言うの遅すぎ

プログラミングの前に日本語勉強しとけ。

ＯＯＰで一番大事な要素は「分類」ね。
小学生の頃やらされた知能指数測定テストにあったでしょ、
あるオブジェクトを数種類見せられて、好きなようにチーム分けしないさいってやつ。
あれですよ。

>>118
10秒ほど君のレスを見させて貰ったけど>>88氏の言うとおりだ。
君、頭大丈夫？
自分で気付いてないのなら致命傷だよ。

classify ってくらいだしね

OOは大体分かった。
でもポインタがわからねぇ…

>>124
たぶんＯＯもわかってないぞｗ

>>124
ポインタがわからないと仮想関数が使えないから、
ほとんどOOの利点がいかせない．．．

C++でOOするのは大変だろうな。

頭悪いなりに思ってるのは変数の集合体が肉体だとして
その肉体を動かすための思考回路が肉体自身に備わっているって所だろうか

なにか間違ってる？

リンクモジュールがどうロードされて実行されるかイメージがわかないから
から同じところで悩み続けるんだろうなぁ
しかもインタプリタだったりするからなぁ

>>128
当たらずとも遠からずと言ったところか

１であるこの俺が自ら

　 　＿＿＿.　　　　　　　 　 　 　 　 　 　　 ∩゛ 　　　　∧空∧　　　　（（（　））） ／＼
　　/. ――┤.　-=・=-　　　　-=・=-　　　　| |　 ∧ ∧｛´ ◎ `｝__＿＿（　´∀｀）＼ う ＼
　./(. 　= ,= | 　　　　 ∧∧　　　 ∧＿∧　 | |　( ´ー｀) ）:::／´∀｀ ;:::: ＼ヽ(`Д´)ﾉ゛＼ ま＼
　|||＼┏┓/∫ 　　　(=ﾟωﾟ)ノ~　（　´Д｀）／/　　＼　< .∧|∧　　　/::::::::::| .¶＿¶.　　　 ＼い＼
　V/　∧,,∧ ∬ 　～（　　x） 　／ 　 　 　 /　　　,一-、(´ー｀)　　/:::::|::::::| (ΦдΦ)／~　　　＼棒＼
　 ||　ミ,,ﾟДﾟノ,っ━~~　U U 　 / /|　　　　/　　　/￣　l⊂ヽ　＼/|:::::::::|::::::| 　γ＿＿　　∧w∧ 旦∬
　人 ﾐ ,,,　 ~,,,ﾉ　　.ｎ　　THANK YOU　2ｃｈ　■■-っ ┌───────┐　　＼ （ ﾟДﾟ　）∩゛
( ﾟーﾟ)と..ﾐ,,,/~),ヽ（凸）ﾉ~　　　　　and..　　　　 ´∀｀/.　｜ ●　　　 　 　 ●　| 　　　　ヽ 　　　ノ
　　／￣￣し'J＼［Y］ GOOD-BYE ２ｃｈ WORLD！ ／|　.┌▽▽▽▽┐.　|____|__||_| ））
　/　　　　 ●　　●､ヽ　　　　　　　　　　　 　 　　 　（.　┤ .｜　 　 　 　 ｜.　|□━□ ）　(ﾟДﾟ)?
　|Y　　Y　　　　　　　＼　　またどこかで会おうね..　＼.　 └△△△△┘.　|　 J　　|）∧＿∧
　|.| 　 ｜　　　 　 　.▼ |∀ﾟ)　　　　　　　　　　　　　　　｜＼あ＼　　　　　　 |　∀　ﾉ　" ,　 、　ﾐ
　| ＼ ／■＼　 ＿人　|∧∧∩゛∧＿∧∩゛∧＿∧　　| 　 ＼り.＼　　　　　| - Å′　ゝ∀　く
　|　　（　´∀｀）_＿＿／( ﾟДﾟ.)'/ （ ´∀｀ ）/ （・∀・　）,.　|.　　　 ＼が＼.　 　 |　 ）. ＼　 Λ＿Λ
　＼　（ Ｏ 　 ）　　冫、 U　　/　 （　　 　 / ⊂　　⊂.）ヽ(´ー｀)ﾉ゛　＼と.. ∧_∧/(´Д｀;)<丶｀∀´>
　　｜││ │ 　 `　　 |　　 | 　　∪　|　 |　　（　（　（　　(　 へ (ﾟдﾟ)～⌒(ﾟーﾟ*) (-＿-) (･ω･` )
　　（_（__（＿_）（・∀・） ∪~∪　　（＿（＿_）　（＿（＿）　く ⊂⌒~⊃｡Д｡）⊃⊃⊃（∩∩）（∩ ∩）







このスレはここまでです。ご愛顧ありがとうございました

ﾇﾙ(･ω･)ﾎﾟﾘｰﾝ

プログラミングの前に日本語勉強しとけ。

遅レスするけど>>70に書いてあることはおおむねあっていると思うけど。
ジャンプ命令に関してはあってるでしょ。
入り口と出口が１つで同じ結果をえられるようにするにはとりあえず
グローバル変数廃止は必須だし。
機能毎に関数を作成するってのもおおむねはずれてはいないっしょ？
何が駄目なの？マジレスキボン。

実はみんなわかってないんだよ

オブジェクト指向がわからないPGなんて食っていけないね

>>134

＞つまりgotoの禁止と、途中returnの禁止。
＞グローバル変数使用の禁止。（中断処理のフラグを除く）
＞変数のスコープ（有効範囲）に着目し、他のブロックと最も干渉の少ない単位で機能毎に関数化する。

内容はともかく、単なるプログラミング・ガイダンスというなら解る。
これらのどこら辺が"オブジェクト指向"なの？

>>137
>>70は構造化に対する説明だろ。

まだ続けるんかい、このスレｗ

議論厨がわくかぎり永遠に。

機能毎に部品分けするのがオブジェクト指向。
それでわからない奴や特定言語のコードの講釈たれてる奴は馬鹿。

>>141
ちがう。機能別に部品分けする一つの流派がオブジェクト指向
『機能別に部品分け』 では構造化手法も含んでしまう

中断処理のフラグ　だけがグローバル変数化可能な理由が判らんなぁ

>>143
複数の関数に渡っての処理を一気に抜けるための中断フラグは、グローバル変数にした方が便利だって言う事じゃない？

>>143
俺もそれは疑問だった。スルーしたけど。
実は中断処理フラグでも俺は駄目だと思うな。
>>70の勝手な付けたしだと思う。

じゃあ俺も。
途中returnって何でいけないの？
全く解らん。
保守性の高い実装もすることができるし、普通に多用されてる手法だと思うんだけど。

>>146
いけなくない。
「入り口と出口は各一個なら全てのロジックは構造化して記述できる」
と証明した定理が存在していて、それを逆に考えているだけ。
つまり「構造化するなら出口は一個であるべきだ」と。

>>146
ぶっちゃけ、構造化定理の立場では 『順接』 『条件分岐』 『反復』 以外の流れは全部 goto つまりイクナイなんですよ

>>146
まあ、あんまり長い関数書く馬鹿がそこらへんにいたから
禁止してんだろうなって予想できる俺の環境ｗ

１０００行ぐらい続く関数眺めてると、途中returnとgotoは死ねる。
switch caseのbreakとcontinueに恐怖を抱くことができるソースを俺はもっているｗ

俺、どうやっても千行の関数を作れないんだけど、コレってマズいの？

改行1000行いれときゃいいだろうがボケ

switch caseなんてあんまり分岐多いようならテーブル化した方がスマートだからなぁ。

今日、ハガレン見てきたよ。
いやー面白かったね。

>>153
ハガレンは、言ってみればオブジェクト指向を映画化したようなもんだからな。

ループの中のswitch caseで状態遷移させるようなコードはよくあるけど
goto使ってるのと同じだしな。

>>155
遷移先でさらに遷移、なんてことが続いてると
ちょっと読む気無くすよね。

>122
122=137なら、答えは138だ。
122はオブジェクト指向を知ってそうな様子なんで、実装観点の説明はできんか？

>143-145
中断処理のフラグってのはインタラブト（Ctrl+Cなど）がかかった時の処理だ。
Cだとシグナル使ったりするだろう。その時に後処理（リソースの解放）などをやるが、
リソースを確保する前かどうかを判定するのに使うフラグを、中断処理のフラグとした。
グローバル変数以外に使えるいい物がないんで、しかたなく使うことになるだろう。
外にいい手があるか？

>146
リターンがだめってのは、リソース解放のためだ。
つまり極端な例で言うと、10個のファイルオープンがあった場合、リターンしている箇所が
10箇所あれば、それぞれのリターンの前に10個のクローズが必要になる。
たとえそれを書いたとしても、保守になって次の担当に変わり変更が入った場合に忘れることが多い。

よかったなオマエラ、構造化プログラミングが理解できて。
次はオブジェクト指向に行くから、疑問点は解消しとけよ。

>>157
めちゃめちゃ狭い視野でプログラミングを語るなよ。

>>157
ﾈﾀ？

＞リターンがだめってのは、リソース解放のためだ。
＞つまり極端な例で言うと、10個のファイルオープンがあった場合、リターンしている箇所が
＞10箇所あれば、それぞれのリターンの前に10個のクローズが必要になる。

こんな事言ってんだもの。程度が知れるわな。
10箇所があった場合に10個のクローズが必要になるのは
君の処理分割の方法が効率的でないからだよ。

ポリモーフィズム

うちの子を馬鹿にしないでちょうだい。

>>19
> >17
> public static 変数は、グローバル変数じゃないの？
パッケージ名にドメイン名を織り交ぜてクラスを呼び出しかつ、
クラス名.staticフィールド名とアクセスするからCでよく起こるグローバル変数のような弊害
はほぼ起きない。下手な乱用は混乱の元だが、
大抵、public staticにするときはさらにfinalにして定数として使うものだ。
定数でないpublic staticな変数は特別な理由が無い限り不用意に作るではない。




> static メソッドはCの関数と同じじゃないの？
それに近い

>>32
> >>13
> お前が教えてくれるまで、俺は帰らない
ﾌﾟ　こいつ餓鬼だなw

>>163
＞クラス名.staticフィールド名とアクセスするからCでよく起こるグローバル変数のような弊害はほぼ起きない
丁度ネームスペース内のグローバル変数にアクセスしている感じですな
名前の競合は起きないけど、それ以外の弊害は起きますぜ

弊害が起きるから
＞大抵、public staticにするときはさらにfinalにして定数として使うものだ
という習慣があるんだろうに

おまいらはまず日本語を勉強しろ

あぁ。きっと「どこで変更／更新しているかがわからない」という弊害かな。
#「検索すればイイ」という人は明示されていないという事実自体が弊害であるとは思っていない事が多いね

>>167
副作用

>160
じゃあ、その効率的な例ってのを見せてくれ。
下のを修正してな。

int func(){
FILE *fp1;
FILE *fp2;
char buff1[100];
char buff2[100];

if(NULL == (fp1 = fopen("file1", "rb")){
return -1;
}
if(NULL == (fp2 = fopen("file2", "rb")){
fclose(fp1);
return -1;
}
if(1 > fread(buff1, sizeof(buff1), 1, fp1){
fclose(fp2);
fclose(fp1);
return -1;
}
if(1 > fread(buff2, sizeof(buff2), 1, fp2){
fclose(fp2);
fclose(fp1);
return -1;
}
fclose(fp2);
fclose(fp1);
retrun 0;
}

>158
中断フラグにグローバル変数が必要な訳と、途中リターンがダメな訳を書いたんだよ。
途中リターンがダメなのは他にも理由があるが、一番分かりやすくて重要なのを書いたんだ。
どっかの学者の宗教論みたいなのよりは、分かりやすいだろう。

試しにお前の広い視野で書いて見ろよ。

オブジェクト指向COBOL

つーか、このスレ、小学生がたてたんだな・・・
こんなところで議論して悲しくなってこないか？
俺は、一抜けたっとｗ

>>157
>つまり極端な例で言うと、10個のファイルオープンがあった場合、リターンしている箇所が
>10箇所あれば、それぞれのリターンの前に10個のクローズが必要になる。

ファイル処理は呼び出し前後でやればいいじゃない
効率的に組めばそんな風には絶対ならないよ

>>169
160じゃないけど書いてみたｗ。俺も暇人だなｗ
サンプルが悪いね。file1とfile2のデータに依存関係がある例でないと
現在の話題に沿わないのじゃないか？
int func1( char *fn, char *buf, int size ){
FILE *fp;
int ret;
if ( ( fp = fopen( fn, "rb" ) ) == NULL ) return -1;
ret = ( fread( buf, size, 1, fp ) < 1 ) ? -1: 0;
fclose( fp );
return ret;
}

int func(){
char buff1[100];
char buff2[100];
return ( func1( "file1", buff1, sizeof(buff1) ) && func1( "file2", buff2, sizeof(buff2) ) ) ? 0 : -1;
}

>>169
まあオープンが１０回あったとしたらそんなコードの書き方はありえないが
サブ関数作らずにそれを途中リターンさせるならこうなるんじゃない？
int func(){
FILE *fp1=NULL; FILE *fp2=NULL;
char buff1[100]; char buff2[100];
int retcode = 0;
if(NULL == (fp1 = fopen("file1", "rb")){ retcode = -1; }
else if(NULL == (fp2 = fopen("file2", "rb")){ retcode = -1; }
if(retcode == 0){
if(1 > fread(buff1, sizeof(buff1), 1, fp1){
retcode = -1;
}
if(retcode == 0){
if(1 > fread(buff2, sizeof(buff2), 1, fp2){
retcode = -1;
}
}
}
if(retcode != 0){
if(fp2){
fclose(fp2);
}
if(fp1){
fclose(fp1);
}
return retcode;
}
fclose(fp2);
fclose(fp1);
retrun retcode;
}

見ずらいので少し整理してみた。
ちなみに漏れも>>160ではないでつ。
int func(){
FILE *fp1=NULL; FILE *fp2=NULL;
char buff1[100]; char buff2[100];
int retcode = 0;

if(NULL == (fp1 = fopen("file1", "rb"))){ retcode = -1; }
else if(NULL == (fp2 = fopen("file2", "rb"))){ retcode = -1; }

if(retcode == 0){
if(1 > fread(buff1, sizeof(buff1), 1, fp1)){ retcode = -1; }
if(retcode == 0 && (1 > fread(buff2, sizeof(buff2), 1, fp2))){ retcode = -1; }
}

if(retcode != 0){
if(fp2){ fclose(fp2); }
if(fp1){ fclose(fp1); }
return retcode;
}

fclose(fp2);
fclose(fp1);
retrun retcode;
}

>>174のが一番無駄な処理が無く、簡潔で見やすい。

動作的に微妙な違いがあるけどな。

サンプルからしてコンパイルエラーなわけだが

>>174って
return ( func1( "file1", buff1, sizeof(buff1) ) || func1( "file2", buff2, sizeof(buff2) ) ) ? -1 : 0;
じゃないの？
最近javaしかやっとらんので、C忘れちゃった。エヘ。

>>174
１つのファイルのオープン～データの読み込み→ファイルクローズまでが
連続して行われるのならそういう形になるだろうね。
>>169の場合だと
file1オープン→file2オープン→file1読み込み→file2読み込み
→各ファイルクローズになってるけど。

>>180
だな。

>>175
サブルーチン使わなかったら構造化プログラミングにならないじゃない。
要するに>>169ってのは本来ならサブ化すべきところをサブ化しない為、
結果としてclose１０回書くようなコードになっちゃうって事だと思うんだけど。

>>183
>>174でサブ関数使ったコードは書かれてるしね。
ポインタやフラグでリソースの状態管理をしていれば、
一連の処理後に一回close＆リターンすればいいから、
毎回一つずつcloseするなんて事はなくなる。

>>169が
＞リターンがだめってのは、リソース解放のためだ。
の証明になるサンプルではないって事が言いたいだけ。

>172,173
おいおい、コーディング出来ないからって逃げなくていいぞ。
いい機会だから勉強していったらどうだ。夏休みで暇だろう。

>174
依存関係がある物として見て欲しかったな。
本来ならreadの所に処理が入るし、write用のファイルを使ったりする。
fp2をwriteにしておけばよかったかな。
しかし酷いソースだな。短いだけで、可読性も保守性も無視してないか。
マクロ以外で三項演算子使うのはあまり良くないぞ。
あとifには{}付けろ、今は1行でも。

>175,176
それは途中リターンをしない構造化の書き方だな。
最後だけ無理にreturnを2箇所にしただけじゃ、途中リターンすると言うことにはならんだろう。
最初のリターンをifの外に出すと、リターンが1箇所になるぞ。
if(retcode != 0){
if(fp2){ fclose(fp2); }
if(fp1){ fclose(fp1); }
}
return retcode;

>184
つまり途中リターンありにすると、最後ってのが数カ所になるため、
「最後に1回やればいいだけ」ってのが出来なくなるって事だ。
わかったかな？

＞わかったかな？

なんでそんなに偉そうなんだ？

>>186
叩かれまくりなんで、自尊心保護の為に攻撃モードに入ってんでしょ。

>>185
ファイル処理が１０箇所あると仮定するなら、>>169のような所で
途中リターンを使用するという事自体がありえない。

なので、>>169のサンプルが出来損ないなだけの話で、そのコードでは
＞リターンがだめってのは、リソース解放のためだ。
という論の証明にはなっていない。

＞最初のリターンをifの外に出すと、リターンが1箇所になるぞ。
そうした場合、正常に処理された場合にファイルがcloseされませんがなにか？
それでいいんだったら>>169での最後のfclose()もいらないという事になる。
てっきり最後に行われるfclose()の手前になんらかの処理を入れる事が前提で
ああ書かれているのかと思ってたけど違うのか。
もっとも、>>169が元々途中リターンが使えるようなコードではないから、
無理に入れたと言うのは否定しないけど。

まあ、的確なサンプルコード書けるようになってから出直した方がいいかと思うよ。

＞まあ、的確なサンプルコード書けるようになってから出直した方がいいかと思うよ。
それはお前さん自身にもあてはまるんではないかと思うんだが。

>>189
煽り入れる暇があるならまともなサンプルコードを提示してね＾＾；
まあ否定はしない。

>>70=>>185

遊んでやるからトリップつけろ。

>190
残念ながらとりあえず口はさんだだけの別人だ。
その位気付いてくれよな。

void func() {
    using(StreamReader sr01 = new StreamReader("file1"), sr02 = new StreamReader("file1")) {
        String text01 = sr01.ReadToEnd();
        String text02 = sr02.ReadToEnd();
    }
}

ん？ まあ良いか別に

>188
まず途中リターンする事がありえないと言うのはおかしいだろう。
エラー発生で処理を中断することは充分あり得るのではないかな？

サンプルが出来損ないと言うのはどういう事だ？問題の意図は188自身でも読み取っているのではないか？
だから174ではなく、175のサンプルを書いたんだろう。
しかしそれが途中リターンではなく、構造化の組み方だし、自分でもそれは否定しないんだろう。

途中リターンで適切な組み方は提供出来ないが、途中リターンはOKだと言いたいのか？
それとも途中リターンはNGだが、リソース解放が目的ではないと言いたいのか？

まともな神経を持ったプログラマが構造化を意識してコーディングをした場合、
最終的な結果として>>169のようなコードになる事はまずあり得ないわな。
169のは使えん奴の書くコードだよ。まあたまにそういう奴居るけど。

要するに、ちゃんと構造化されてない出来損ないのコードじゃ、
途中returnの弊害を検証できるようなサンプルにはならない
って事なんじゃないの？

途中リターンがリソース未解放のbugになるようなら、
「途中リターンが駄目」なのではなくて「プログラム構造が駄目」なのではないのか

リソース未開放になるような所で途中リターンなんて使わないから、
途中リターン自体が駄目という理由にリソースうんぬんは関係ないな。

>>198
リソースの開放なんて必要のなかった関数で途中リターンしてました
そのうちその関数でBeginTran()とEndTran()するように変更しました
案の定リリースしてからバグりました
それ以来C++のデストラクタは神だと思うようになっています。10年前の夏でした･･･

浅い経験と狭い視野で物事を語る奴が多くてかなわんな。

そろそろOOに話を戻さないか？

>>200
深い経験と広い視野で、OOを語ってくれないか？

>196
なるほど言いたい事は分かったが、それは誤解だ。
俺は構造化では途中リターンはダメだと言いたくて、途中リターンはいいのではないかと言う意見に対して、
「途中リターンしている構造化ではないプログラム」を提示して、途中リターンを残したまま、
構造化になるように修正してくれと言った訳だ。
結果的に175が途中リターンを廃した（無理にreturnが残っているが不要にできる）コードを提供して
くれたわけだから、途中リターンはダメだと言うのは分かっただろう。

一応、構造化されたコードを提供しておこう。
int func(){
int ret = 0;
FILE *fp1;
FILE *fp2;
char buff1[100];
char buff2[100];

if(NULL == (fp1 = fopen("file1", "rb")){
ret = -1;
}else{
if(NULL == (fp2 = fopen("file2", "rb")){
ret = -1;
}else{
if(1 > fread(buff1, sizeof(buff1), 1, fp1){
ret = -1;
}else{
if(1 > fread(buff2, sizeof(buff2), 1, fp2){
ret = -1;
}
}
fclose(fp2);
}
fclose(fp1);
}
retrun ret;
}

俺は201ではないが、201と同意見だ。
200にはOOを語ってもらおうでなないか。
できれば、どこかへのリンクではなく、自分の経験と視野で語ってくれるとありがたい。

構造化の意味わかってんのかな

>>202
まともなプログラマならリソースにからむような所で
途中リターンなんて使わないんだから、
使いもしない所で途中リターンを使えと言われても無理な話だ。

元々使わないんだから、途中リターンがダメな理由に
リソース開放うんぬんは関係ないだろ？

>>203
コンパイルエラー
括弧の数も数えられないのかい？

>>1
　おれは教えたがり屋だー！
　だから、おしえてやるー！
　けど、教えたいことが多すぎて、とても書ききれないー！

　だから、>>1は、Ｃ＋＋どのぐらいやってるのか、そして、
　今までどういう本を読んだか？　不明な点はどうやって調べてきたか？
　　（　例えば.NETのオンラインヘルプでいつも調べてる、とか、）
　得意な学問など教えてくれれば、多分、とっても詳しく、
　しかも的確に教えてやれると思うぞ？
　特に数学に関してはどのぐらいのレベルか書いてくれるとよろしいぞ。
　どうだ？

　まあ、「どうしてオブジェクト指向と数学が関係あるだよ！」
　というようなら、おれの教える相手ではないな。
　がはは！

>>203
１０個のファイルオープンがあったとするなら
そんなコードの組み方ではとんでもない事になるぞ。

Javaメインだから後処理はfinallyに任せて途中リターンしまくりだなあ。
C++はあんなに機能一杯なのにfinallyが無いのが信じられない。

そろそろ終了か

>>206
今だから言うが、別に俺に教える必要は無い。
俺は俺で勉強してるし、聞く必要があったら上長に聞く。
このスレはつりなのだよ。わかるかね？
わからんか？！　ああ？　死ねよｗ

オブジェクト指向とは死ぬこととみつけたりぃ!!!

>>209
＞このスレはつりなのだよ
大半の厨達は当然気づいている。無視しろ。

>>209　×
>>210　○

ハガレンを全巻読み直して、強気になった1がきたなｗ

まともな反論もなくなって来たようなので、構造化プログラミングは完了って事でいいだろう。
そろそろ本題のオブジェクト指向に移るとするか。

まあ実際俺もオブジェクト指向を、構造化のように簡潔に説明しろと言われても、できない訳だ。
つーわけでオブジェクト指向を簡潔に、いやこの言い方は悪いな。
オブジェクト指向型のプログラムを組む方法を、具体的に説明出来る勇者求む。

200はどうした？早く出て来い。
204でもいいぞ。
205だと、まともなプログラマはオブジェクト指向できるから説明いらないとか言いそうだな。

オブジェクト指向まわりの愚痴はこのスレでいいのかな？

俺はオブジェクト指向や設計の話をするときに、ソースコードを要求する奴がウザクてかなわない。
お前はなんでそんなに馬鹿なのかと、頭ひっぱたきたくなる。
てゆうか、ホントそいつが馬鹿なことについて小１時間問い詰めたくなる。
なんでソースがいるのかと？
お前はどこの時代からやってきたのかと？
設計の話でなんでソースを出さなきゃわからないのかと？

根本的に想像力が足りないっつーか、そんなんじゃ一生オブジェクト指向なんて理解できねぇよっつーか、
人としてその程度で終わってて満足なのかっつーか、もうホント救えない。

あーすっきりした。じゃあね。

釣りか・・・。
なーんだ。

ベタだけどやっぱソースより醤油だよな。

>>215
「誰に何をやらせるかを考えて設計する」でどう?

設計で一番大切なのはアプリケーションの抽象モデルを正しく理解する
あるいはおおむね正しく理解することだと思う

その点で入門書的なOOは非常に問題がある。
人と犬は哺乳類から派生して･･･というやつだ

人と犬のBaseクラスを作るべきかどうか、作るとして哺乳類かどうかはアプリケーションによる
アプリケーション内の現実をどうやってモデル化するか？という問題のはずだ
これをリアル世界で人も犬も哺乳類だからといういう理由で哺乳類Baseを作るのは設計の基本が
なっていないと思うがどうよ

正直設計に王道はないし、確立された方法もないと思う。OOが有効なのはOOPってのが俺の結論

設計ならCRCカードとか結構使えると思うぞ。
ほんとにカード使うとふざけてると思われるので
ホワイトボードとかにエッセンスだけ使うとOO知らない人でも
結構通じるみたいだぞ。

>>215
で、君はファイル１０個オープンという前提なのに>>203のような
コードを書くのかい？

>>221
CRCは悪くないと思うが箇条書きやホワイトボードやUMLと比べて
特に優位性はないと思う。
設計はいろんな手法を織り交ぜて、さまざまなレベルで繰り返し考えて
完成させるものだと思うので特定の技法が支配的にはならないと思う

>>222
if～elseの多用はアホグラマーの常套手段だからしょうがない

「ネストの上限は5とする」という規約を決めたい

>>223
まあ確かにね。

>222,224
一応RESしとこうかな。他の人は分かってると思うので読み飛ばしてくれ。
もし10個のファイルの同時使用が必要ならば、10段のネストにするよ。
しかし実際に同時に必要なのは3段ぐらいに収まるはずだから、3段のぐらいのネストにして、
その中は関数にするよな。
すまん、本気で疑問に思ってるとは思わなかったんで無視してた。

>220
俺もそう思う。
大昔に読んだオブジェクト指向の入門書もそんな感じだった。
「ドラ○ちゃん」は「ドラ○もん」の派生であるとか、ドラ○もん製造機がどうのとかの内容だった。
その頃はCの全盛期だったんで、Cとの違いを調査していたのだが、継承の説明が簡略されてて意味不明だった。
そのため、その本を読んだだけでは、
「外部変数を撤廃して関数をカプセル化すればオブジェクト指向と同じ」
と言う無茶苦茶な結論に達した。
ただ、そんな訳はないだろうとの事で、
「きっとほとんど説明されていない継承がすごいんだろう」
と言うことになってその時は保留になった。

つまり入門書にドラ○もんや哺乳類が出て来たら、捨てた方がいい。

>206
俺は1じゃなくて、オブジェクト指向マスター済みだが、みんなのために教えてくれ。
対象は、
・C++は未経験だが、Cは3年の経験。構造化マスター済み。
・読んだ本はオブジェクト指向の入門書で、哺乳類の事が書かれてるやつ。
・検索はグーグル。趣味は自作とアニメ。
・数学は小学生レベルで、四則演算マスター済み。
以上で、よろしく。

ちょっと聞きたいんだが、貴様らの中でruby厨の奴、
もしいたら手上げろ。市場調査したい。
別にここに聞く必要は無いが、なんとなくだ。別にｗ

こないだ宇宙戦争見たんだけどよ、50年前の映画をまあまあ忠実に再現してると思うぞ。
収拾のつけ方はたぶんあれしかないし、主人公が科学者という矛盾もなくなってよかったじゃねーかよ。
この映画の落ちがだめだとか言ってるヤローはたぶんオリジナル知らない奴だな。ＤＶＤ借りて情報仕入れとけよ。糞が。
矢口マリ、テメーだよ。

rubyは興味あるが今のところ使用する用途がない。

宇宙戦争ってたしかH.G.ウェルズのSF小説が原作じゃなかったっけか？
100年前だぞ。

映画は50年前にやってたんだよ。

>>220
モデルの理解と入門書的OOの批判とモデリングの方法論不在を同時に語っていて
論点が不明瞭だな
>どうやってモデル化するか？という問題のはずだ
ここだけ同意

>>230
ヤグチマリが糞かどうかわ知らんが，オリジナルを知らんと面白さがわからんような映画は糞だろ

落ちが糞といってたからな。映画は普通だが、矢口は間違いなく馬鹿だ。

矢口が馬鹿だということは誰もが認めるところだろ。
映画通ぶってるけど、ほとんど何も知らないみたいだし。
宇宙戦争って言うのはほとんどのエイリアンものの元になった映画。インディペンデンスデイでは落ちをパクってるくらいだし。

問題は矢口にどうやってOOの真髄を教えるかだな。

今日の勉強の成果を発表する。

ドラえもんとガンダムは、
どちらもロボットクラスから派生したものである。

public class ドラえもん extends ロボット {
　　public 道具 ポケット();
}

public class ガンダム extends ロボット {
　　public ビーム 鉄砲();
}

ってことは明日はロボットクラスの実装に入るんだな！

>>227
１０段のネストだろうが関数だろうが同じ事だろｗ

>>229
まずは参考にオブジェクト指向マスター済みのあなたの講釈が聞きたいな。
ぜひ、ご教授いただきたい。よろしく。

無駄な関数で溢れ返るなら、ためらい無くネストを深くするなぁ俺は

括弧の数も数えられないのにオブジェクト指向マスターとか言われてもなぁ（汗

ネストを深くすると見ずらい上に拡張性の希薄なコードになるからな。
無駄に階層増やすより、できるところは一本道で組めるように心がけてる。

「自称○○の専門家」 ほど怪しげな職業は無いです

「～をマスターしてます！」とかって採用面接でよく言う奴いるけど
実際テストしてみるといろはのいの字も知らない奴ばかり。

プログラマは常に創意工夫の上に成り立っている職業なので、
マスターしたと思う事は途中で投げ出すのと同義だと思ってる。

>>246
＞マスターしたと思う事は途中で投げ出すのと同義だと思ってる

同感。途中で投げたか、あるいは飽きたか

>>238
リスコフの置換原則を守ってない。
安易な継承はいけません！

>>248
悪いが、>>238 は守っていると思う

>リスコフの置換原則について

このスレ初のためになる議論を頼む

>>250
SubClass extends SuperClass の時、SubClass は SuperClass と置換可能であることが望ましい
掻い摘んで言うと、SubClass は SuperClass と同じように振舞う事が理想だということ

ガンダムってロボットと同じように振舞えるんじゃないの？

ごめん文章が微妙に変だ

SuperClass は SubClass と置換可能である事が望ましい
要は SubClass は最低限 SuperClass と同じ仕事をこなせることが理想と

>240
何がｗなのか分からん。ネストを深くするのに抵抗がある人なのかな？
見にくいって言う人もいるけど慣れの問題だよ。拡張性が希薄ってのも何を指してるのかわからんな。
まあしかし、Javaとかではネストが浅くなるし、finallyもあるから途中リターンOKだから、
現代向きと言えば言えるな。
さてそろそろオブジェクト指向の説明に移るとするか。

ではお待ちかねのオブジェクト指向プログラミングの説明だ。
まず最初に言っておくが、これは俺のやり方なので、誰でも出来るかは分からない。
さらに完全版ではない。また他にいい方法もあるかもしれないので、自分で研究して開発してくれ。

まずオブジェクト指向プログラミングには、経験とセンスが必要だ。
多少の訓練をすれば誰でも出来る構造化プログラミングとはちょっと違う。
新人で出来ない人でも気にする必要は無い。3年ぐらいの実務経験を積んでからチャレンジすれば良い。
5年の実務経験があって、半年勉強しても分からない人は諦めた方がいい。
それはセンスの無いためだが、センスが無くても普通の業務ぐらいはこなせるから、
無理して覚える必要は無い。
まあ、俺の経験ではプログラマの中で30%ぐらいは、頑張ってもオブジェクト指向を理解出来ない人がいる。

終始センスかよ

オブジェクト指向型プログラミングの方法には2種類ある。
1.構造化プログラミングで作成した後に、作成された構造体をクラスにして、
　それに関連する関数を作成したクラスのメソッドとして追加する。
2.使用するデータをDB設計の手法を用いてテーブルとして作成し、それをクラスとする。
　その後にそのデータに関連する処理をメソッドとして作成する。

1の方法は非常に困難である。まず構造化手法で脳内で作成して、分解、分類を行うため、
相当の熟練者でなければ不可能である。また一度に作成出来る量も少なくなる。
そのため、1の方法は推奨しない。長年構造化をやってきた人がオブジェクト指向に移るために
最初に行うのはいいかもしれない。

次に2の方法だが、まずDB設計が出来るのが前提である。
DB設計と言うのは非常に高度な作業で、経験と学習が必要である。
経験というのは設計から保守までを言う。
最初に設計しただけではだめで、多くの仕様変更に耐えたDBを設計運用した経験が必要である。
また経験だけでもだめで、学習が必要である。最低でも正規化ぐらいはマスターしておいて欲しい。
では2の方法で説明しよう。今日はここまで、また次回。

>>254,256
他の書き込みを完全に無視した長文お疲れ

>>256
OOPとRDBは仮面夫婦。

本質的に仲が悪いのに世間体のために同居している。
そんなことも知らんのか。

オブジェクト指向をマスターしたのに完全版ではないとはこれいかに

そう言っておく事で突っ込みの言い訳する逃げ道を作ってるんだろｗ

>>256
ＤＢ設計手法はオブジェクト指向型プログラミングに適したものではないな。
根本的に違うものだから。

>258
そうかな？
オブジェクト指向と仲の悪いのは、DB自体でなく「SQL」だろ。
そんな事もしらんのか？とは言わないが、ちょっと考えてみてくれ。

>259,260
分かった分かった。
突っ込まれたら「完全ではないで逃げない」事にするから、ちょっとは内容に突っ込んで見たらどうだ？

>261
根本的に違うのは承知の上だが、データ分けする部分などの正規化の部分が利用出来ると思う。
DB設計の知識の方が膨大だが、その一部をオブジェクト指向に利用する物だと考えてくれ。
また、反論の時は具体的な理由も書いて欲しいな。
こっちが反論する時に対象が曖昧になるからな。
「～するときに、～が問題になる」形式だと助かる。

>241
ほらおまえの番だぞ。

>>249
おわー賑わってる。遅レスすまんです。
痴漢原則に則ると、これが望ましいと思われます。

public class ドラえもん extends ロボット {
　　public 出るもの 出す(){
　　　return new 道具;
　　};
}

public class ガンダム extends ロボット {
　　public 出るもの 出す(){
　　　return new ビーム;
　　};
}

もちろん、道具とビームは出るものの子クラス。
せっかく同じロボットクラスを継承した兄弟なんだから
インタフェースは極力一緒にしたい。
そうすれば、コンテキスト側を変える事無く
ドラもガンムも使える事になる。

ただ、メソッド名が汎用的すぎて不明瞭てのはあるかも。
そこは思案のしどころだね。

おっと失敬、セミコロン消し忘れがあった。

あと、ロボットクラスはどうせならインタフェースにしたい。

public interface ロボット {
　　public 出るもの 出す();
}

>250
こんなんでためになる？
なんか皆さんには釈迦に説法みたいで恐縮なんですが。

>>262
＞2.使用するデータをDB設計の手法を用いてテーブルとして作成し、それをクラスとする。
＞　その後にそのデータに関連する処理をメソッドとして作成する。
DB設計的に良い分割がOO的には役に立たないと思う
OOの基本のひとつに隠蔽、データ抽象があるけど、これとDBの正規化は真逆の概念でしょ

ただ現実世界ではObjectを永続化する必要があるわけで、そのときにRDBを使うならORマッピング
は避けて通れない。ORマッピングを苦労するくらいならOO的な美しさを捨ててDB基本主義で作る
っていうのは賛成する
でもそれはOOの敗北であって、決してOOとRDBが仲がいいということではない

俺も白いものがある部位から出てくるので

public class 俺 extends ロボット {
　　public 出るもの 出す(){
　　　return new 白いもの;
　　}
}

でOKか？

>>263
２の方法での説明とやらはどうしたんだい？

>>267
オーケーオーケー。
ただロボットはinterfaceにしたいから
implementsだとありがたいです。

これじゃ多態性ってより、多態・性ですね。

いったんまじめな話に戻ると
>>252
に書いてある事だと継承はただの差分プログラムになっちゃう。

ロボット型変数でガンダムのインスタンスを受けた時、
鉄砲メソッドを使おうとするとガンダムにキャストしなきゃいけない。
だから置換原則に反してると思った訳です。
出すメソッドをオーバーライドする形ならキャストは要りません。

簡単に白いものも飛ばせるようになった事でも
interfaceへのプログラミングの柔軟性が判りますね。

まあやりすぎはソースが読みにくくなっていやんだけど。
出すメソッドって名前じゃ抽象的すぎるし。

こんなんでどうでしょう。

ロボットクラスの例って設計時の手順のヒントにもなってるね。

1. ドラえもんクラスとガンダムクラスをつくろうとした。
2. ドラえもんクラスはポケットメソッド、ガンダムクラスは鉄砲メソッドを持つ
3. ポケットメソッドと鉄砲メソッドを出すメソッドで抽象化できることに気づいた
4. ロボットインターフェースで出すメソッドを定義しドラえもんクラスとガンダムクラスで、
出すメソッドを実装した
5. 俺クラスもロボットインターフェースをインプリメントできることに気づいた

こういう流れでクラス設計してくのって結構ありがちじゃない？

>>256
ぐぐるだけでどこにでも書いてあるような事を
自論であるかのように得意げに語られても困るわ。

ホリエモン無所属かよ

まあ小泉の独裁政治に加担するよりましだな

ｽﾏﾝごばくったorz

>>273
いやいや、無所属だが小泉自民のバックアップつきだぞ

で、ホリエモンクラスは何を出すんだ？

>>271
そうですねえ。
オブジェクトは現実世界のなんちゃらとかゆうよりも
だんぜん現実的。

このスレ初のためになる議論になったかな。
そうでもないか。

>272
本当にどこかに書いてあるなら、俺の考えと同じ考えの人がいるって事で、
俺の正当性が増したってことだな。
さらに272自身が内容自体に文句を言ってないって事は、272も内容に異存はないって事で、
さらに正当性が増したって事だな。
おつかれ。

ロボット説明はドラ○もん説明や哺乳類説明と同じで、オブジェクト指向を知っている人にしか分からない。
で、オブジェクト指向知っている人が、分かりやすい説明だとか言うから、
知らない人に「キ○ガイが集まるスレはここですか」と言われる。

>>271
お世辞にもいいサンプルとはいえないな
共通のベースクラスを作るのに【ポケットメソッドと鉄砲メソッドを出すメソッドで抽象化できることに気づいた】
が理由というのはOO覚えたての初心者によくある「なんでもいいからOO使いたい病」にしか見えん

>>271
俺だったら、

class Robot
{
public:
　　virtual void gun() = 0;
　　//または virtual void gun(){} か？
　　virtual void pocket() = 0;
　　//または virtual void pocket(){} か？
};

class Doraemon : public Robot{};
class Gandom : public Robot{};

のようにするな。gun や pocket でいったい何をするのか
さっぱりわからんがｗ
C++ですまん。

>>281はCからの転向組。

「オブジェクト指向で開発をする」
と言いつつ、結局最後には昔ながらの開発スタイルになってやがる。
そして残ったのは、開発を始めた頃に書かれた誰も読まなくなったUMLの各種設計書・・・

>>283
それほどまでに「オブジェクト指向開発」は難しいものなのだよ。さて、ここでオブジェクト指向
開発を最後まで持続できる方法に関するヒントをあげよう。

ヒント：「適度な忍耐力」と「割り切り」と「切り捨て」

>>284
割り切ってオブジェクト指向を切り捨てよう
すると忍耐もいらない。

オブジェクト指向なんて子供のおもちゃですよ。
それで給料が上がるわけじゃない。

>>278
別に否定するつもりは元からないから。ただつまらんだけだ。
３流サイトの丸写しで満足かい？
君にしかできない身のある説明をしてくれ。

>>287
俺は278ではないが、君は批判しかしていないだろ。
君こそ、君にしかできない身のある説明をしてくれよ。

自演乙

>>288
そういう君こそ、君にしかできない（ｒｙ

結局のところ、ここには身のある説明ができる人は一人もいないって事でＦＡ？
いたら説明してくれ。マジで。

結局、糞の集まりだな。

そろそろこのスレ終了かな。
ためになる事一つもないからもういいよ。

といいつつage

オブジェクト指向やってるとこあります？
やっぱ専用の開発ツール必要ですよね？

こりゃまたすごい質問がきたな

緊急告知！

今ＶＩＰと韓国サイバーテロ集団が火花をあげて戦っています！
この夏の思い出作りに是非貴方達ももこの祭りに参加しませんか？

↓↓↓詳しくはは↓↓↓

http://ex11.2ch.net/test/read.cgi/news4vip/1124442853/


ご協力、よろしくお願いします。



【VIP】抗議文を考えてくれ
http://academy3.2ch.net/test/read.cgi/english/1124431469/

犬＝オブジェクト

犬．尻尾を追っかけてクルクル回る
犬．俺に前足を掛けて腰を振る

まっ、そういうことだ。

>>280
元がネタだしな。

- ロボットを戦わせるゲームをつくる
- ロボットのみを後からリリース可能で、ゲームに追加できる
という前提をつけてみたら?

今日は、ファクトリーパターンというものを教えてもらった。

public class ４本足Factory {
　　public ４本足 factory(String 特徴) {
　　　　if (特徴.equals("背もたれ")) {
　　　　　　return new 椅子();
　　　　}
　　　　if (特徴.equals("ぬれた鼻")) {
　　　　　　return new 犬();
　　　　}
　　}
}

戦争だ。援軍頼む。

http://ex11.2ch.net/test/read.cgi/news4vip/1124460460/

>>299
それでは椅子が食えないから中国人が文句たらたらだろ。

>300
チョンと同レベルの阿呆は(･∀･)ｶｴﾚ!

はいはいワロスワロス

2chでまじめな話するのはいやだが、
しょうがないから業務システムでありそうな例考えてみた。

- なんちゃら申請書が何種類もある
- 申請書は上司の承認が必要である
- 申請書の入力項目はまちまちである。
- 申請書は書きかけでもシステムに保存できる
- ほとんどの申請書は上司に提出する前なら書いた本人が削除できる。
ただし、タクシー代清算申請書は金額が低ければ、上司に提出後
上司が削除できる。
- 削除できない場合は画面上に削除ボタンは表示しない。
- 今の開発は第一フェーズで第二フェーズで申請書の種類が増えるが
仕様は全く決まっていない。

こんな感じのときお前らどう作る?

素直に助けてくださいって言えよ。

>>304
助けてください。









なーんて、実は昔作ったのとほぼ一緒の内容。

俺は単純に
申請書ベースクラスで表示可か不可を返すメソッドを実装してディフォルト動作とし、
タクシー代清算申請書で上書きした。
二次フェーズで削除可不可のロジックがまたいろいろ出てきそうだったしね。

もちろんOOしなくても書けるし、OOでも他にやりかたあんだろうね。
他人がどうするか見てみたい。

レス番を間違えるあたり、>>306の必死さが覗える

>>307
せっかくまじめな例出してやったのにそんないいかたするなよ。

で、お前はどうするよ。

夏休みの宿題は自分でやろう

おいおい。
つまらん連中だな。

>287
本当にあるようなので、そのサイトのアドレス教えてくれないか？
いや287への攻撃って意味じゃなくて、そのサイトでどういう説明しているのか見てみたい。
大体、コピペかどうかは本人がよく知っている訳だから、俺にコピペだって批判されても、
そうじゃないとしか言えないな。大体、長文で本当のコピなら見れば分かるだろう。

>266
266に反論するつもりだったんだが、304で面白いのが出て来たのまた今度。

>304
やっとホネのありそうな奴が出て来たので、解答を考えて見る事にする。
是非ともロボットマニアの方々の設計も見せて頂きたい。
大口叩いた連中は、クラス分けぐらいでも見せてみろよ。
（俺が一番大口というのは別棚）

はいはいワロスワロス

いい反論が思いつかないから先延ばしって事なんだろうねー

>>304
漏れもそんな感じの設計１週間で完了しろって言われたよ。

お、頼むよ。
期待してるよ！

>>304
申請書の規定クラス作って、そこにそれぞれの種類の申請書クラスをぶら下げるだけだろ？

全体的に実装すべきことは、大別して、
・申請書の登録、更新、削除
・申請フロー制御
・各ユーザごとの権限制御
だな。

どの申請フローを通るかは、申請書ごとに決定するわけだから、
申請書には、申請フロー情報がぶら下がる。
ただ、出した人間の部署によって、各所属の部課長の承認が必要な可能性があるな。
そうすると、申請フロー図の各ノードに乗る承認者は、１ユーザであったり、役職であったりする可能性があるな。

あと、承認者不在時の代行処理や、申請迂回も考慮した方がいいかもな。
誰か一人いないせいで、処理が止まってしまっては、使えないから。

あと、一つの承認レベルに複数の承認者がいる可能性もあるな。
3人が承認して、初めて次のレベルの承認者に書類が回されるけど、
この3人のレベルは同じで、下位のレベルで承認された場合は、3人同時に書類が届かないといけない、みたいな。
逆に、一つのレベルに複数の承認者がいて、誰か一人承認すればよい、みたいのもありうる。
ないならないで、いいが、全く考慮しないのはあぶないな。
この辺を考慮して申請書フローのクラス構造を考えないと、あとで直しが大変だな。

申請書はDBに保存するんだろ?
ならBaseクラスはLoadとSaveのメソッドを持たなくてはいけないな
後必要そうなのは
・申請(Person 提出者)
・承認(Person 承認者)
・却下(Person 承認者)

そして振る舞いをオーバーライドしたいから
・virtual On申請されたとき()
・virtual On承認されたとき()
・virtual On却下されたとき()

プロパティとしてその報告書特有のフィールドがあるだろう。そしてそれはDBの各カラムと対応しなければならない
俺なら定義書ファイルからDBのTable作成のためのSQLとソースコードを同時に作成するスクリプトを作る
そのほかに全ての報告書に共通のプロパティとして
・承認フローのタイプ
・申請者
・承認状態
・申請時間
などがあるかな

>319,320
おれはO-Rマッピングツール、ワークフローは出来合いのものを使ったのでその辺は楽ちんだった。
その辺自分で作るとなると結構大変だよな。

ちょっと待てｺﾞﾗｧ！

オブジェクト指向プログラミングではグローバル変数が存在しないって本当ですか？

>>169
超効率悪いな。
わざと言ってるだろ

オブジェクト指向ならこんなにスッキリ！
#include <string>
#include <cstdio>
class FileReader
{
  std::string fname;
  FILE *fp;
  char buf[100];
public:
  FileReader(const char *pfname, const char *mode) : fname(std::string(pfname)), fp(NULL)
  { if( NULL == (fp = fopen(fname.c_str(), mode))) throw "fopen error : " + fname; }
  ~FileReader() { if( fp ) fclose(fp); }
  char *read_byte()
  { if( 1 > fread(buf, sizeof(buf),  1, fp)) throw "fread error : " + fname;
    return buf;
  }
};

int func(){
  try{
    FileReader fr1("file1", "rb");
    FileReader fr2("file1", "rb");
    char ch1 = *fr1.read_byte();
    char ch2 = *fr2.read_byte();
  }catch(...){
    return -1;
  }
  return 0;
}

>>325
try catch があればこんなにスッキリ
なら理解できるけど
どのへんがOOかをもっと詳しくお願いしたい

>>326
見るところはtry-catchじゃなくてﾃﾞｽﾄﾗｸﾀでのｸﾛｰｽﾞだろ？

>>169
import java.io.file;

//(ry
public class FileIoDemo{
　private File file;

　public FileIoDemo(File file){
　　this.file = file;
　　this.file.createNewFile();
　}

　public int func(){
　　PrintWriter writer = null;
　　try{
　　　writer = new PrintWriter(
　　　　new PrintWriter(
　　　　　new OutputStreamWriter(
　　　　　　new FileOutputStream(fp1), encode
　　　　　)
　　　　)
　　　);
　　　while(何か処理){
　　　　writer.write(何か書き込む);
　　 }

　　} catch(IOException e) {
　　　e.printStackTrace();
　　} catch(FileNotFoundException e) {
　　　e.printStackTrace();
　　} catch(Exception e) {
　　　e.printStackTrace();
　　} finally {
　　　try {
　　　　if(writer != null){
　　　　　writer.close();
　　　　}
　　　} catch(IOException e) {
　　　　e.printStackTrace();
　　　} catch(Exception e) {
　　　　e.printStackTrace();
　　　} finally {
　　}

publise UsingDemoClass{
　public static final void main(final String[] args){
　　File directory = new File("/usr/local/apps/examples/io/");
　　if(!directory.exists()){
　　　directory.mkdirs();
　　}
　　File fp1 = new File(directory, "file1");
　　File fp2 = new File(directory, "file2");
　　List<FileIoDemo> fileIoDemoList = new ArrayList<FileIoDemo>();

　　FileIoDemo fileIoDemo1 = new FileIoDemo(fp1);
　　FileIoDemo fileIoDemo2 = new FileIoDemo(fp2);

　}
}
これはどう？

もともとのお題が良くないから別になんともって感じだね。
サブルーチンがメンバメソッドに変わった程度じゃね、、
ＯＯって程のもんじゃないでしょ。

なにを書やりたいのか意味不明なお題だよな

なにを書やりたいのか意味不明なレスだよな

>>332
サブルーチンなんて死語を今どき使うお爺さんがいるとは

>>332のような分からず屋のために
>>328を改良したほうがよさそうだ。

改良型FileIoDemoの実装としては

フィールドにWriterを追加だ。
そしてFileIoDemoにclose()メソッドを委譲させる。

そして、Listオブジェクトをwhile()で回して
close()メソッドの記述を一回で済ませる。

それとimport文を忘れている。
import java.io.PrintWriter;
import java.io.BufferedWriter;
import java.io.Writer;
import java.nio.charset.Charset.;
import java.io.FileWriter;
import java.io.OutputStreamWriter;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.FileNotFoundException ;






あとはまかせた、

ささ、抽象クラスを作ってあげたから継承しなさい！

public abstract class 改良型FileIoDemoAbstract {
　private Writer writer;

　public 改良型FileIoDemo(Writer writer){
　　this.writer = writer;
　}

　public abstract void close() throws IOException {
　}

　//あとは任せた
}

こうやって絶えずリファクタリングするんだよ

こうやって、前に進んでいるようで進んでいない
予算ばかりかかるプロジェクトは破綻していくんだよ

専門学校生が学習中の中途半端な知識をひけらかして悦に入るスレはここですか？

お前らさ、何を得意げに無意味なゴミコード晒してんの？

そういやこの前しゃべり場でスキルを身につけるために
大学よりもコンピュータ専門学生に行く事を選んだとかいってた
馬鹿がいたな。

そういう奴らが集まって恥部を晒すスレか

>>339-340
あんたらネガティブだねえ

>>340
思うんだが、専門学校卒業した香具師が
バイト先にいるんだがオブジェクト指向なんて全然しらないのが
不思議でしょうがないんだけどなあ。
ちなみに漏れは大学院生ね

>>341
オブジェクト指向教育は専門学校ですらやらないところが多そうだがなあ。

とりあえず、デザインパターンの本でも読んでみなよ。
専門学校なんて行かなくても
オブジェクト指向スキルが身に付くから。

スーパークラスに

　publiv Writer getWriter(){
　　return this.writer;
　}
を追加しないといけないね。

public class 改良型FileIoDemo　extends 改良型FileIoDemoAbstract {

　public 改良型FileIoDemo(Writer writer){
　　super(writer);
　}

　public void close() throws IOException {
　　this.getWriter().close();
　}

　//さらにあとは任せた。
　public void write() throws IOException {
　　//任せた。自分で実装してくれ
　}
　
}
ついでにスーパークラスにこいつも追加ね

　/**
　 * 書き込み.
　public abstract void write() throws IOException;

>>270
亀だがすまぬ。なんか返信したつもりでしてなかったみたいで

リスコフの置換原則ってのは具体例を挙げて言うと、
『ガンダムはロボットを継承している。ならばロボットにできることはガンダムにもできてしかるべきだ』
って言うこと。
この原則に反する設計は、スーパークラスの振る舞いをキャンセルするような設計だ。

んで >>238 はその原則をとりあえず守ってるみたいなんだな。
ついでに言うと、

＞ロボット型変数でガンダムのインスタンスを受けた時、
＞鉄砲メソッドを使おうとするとガンダムにキャストしなきゃいけない。

ロボットにできない筈の事をしようとしているんだから、ある意味キャストは自然だよな。
こんなの置換原則でもなんでもない。

>>344
レスありがとう。
でも原則の定義がちょっと違うと思います。
それだと差分プログラムでしかないでしょう？

『派生型は基本型と置換可能でなければならない。』

これが要約。つまり、コンテキスト側で

ガンダム.出す()

と書いてある所を、

ロボット.出す()

って置換しても振る舞いが変わらないようにしなきゃいけない。
これがLSPだと、俺はずっと思ってたんだけど、違うのかな？
少なくともR.マーチンの文章からはそう読んだんですが。

もちろん原則は原則であって、やぶったら絶対にいけないって訳じゃないから
キャストくらいする局面は幾らでもあるでしょう。
でも、なるたけそれは避けようぜ、って話ですね。

あわわ間違えた。

＞置換しても振る舞いが変わらないようにしなきゃいけない

振る舞いは変わるんだよ！バカだなー。すまそ。

>>270
あれ？と思って調べてみたら

＞派生型はその基本型と置換可能でなければならない
＞基本クラス型を派生クラス型に置き換えても正常に動作しなくてはならない

の両方を見つけたよ
ttp://www.atmarkit.co.jp/fdotnet/designptn/designptn07/designptn07_01.html

俺は下の方をリスコフの置換原則だと思ってたけど原書ではどうなんだろ
けど、２個目の文の直ぐ下にも

＞そのためには派生クラスは基本クラスの振る舞いの妥当性を維持する必要がある。
＞基本クラス以下の機能しか持たない派生クラスは、基本クラスと置き換えることはできない

って書いてあるし

良くわからんが、リスコフの置換原則は負の可変性をできる限り無くしましょうって話じゃないのか？
親クラスの振る舞いをキャンセルする子クラスが無いようにしましょうって

>>347
継承はis aの関係でなくてはいけないってのが
そもそもだから、上と下両方でしょうね。

俺はリスコフの原書じゃなくて
R.マーチンの『アジャイルソフトウェア開発の奥義』で
初めて知ったんだけど
兎に角親クラスだろうと派生クラスだろうと
何が来ても正常に動作するように設計するのが
よろしいって話でした。

「派生 is a 基本」はいいけど、「基本 is a 派生」はなりたたないんでね？

んなこたわかってるね。失礼しました。

>>349
上と下と両方なのか。了解でし

最初の例に戻るけど、「ロボット」に「鉄砲を撃つ」メソッドを付けることはできないんだから、
このメソッドは、たとえ置換原則に反してでも「ガンダム」に付けるのが正しい設計なんじゃないかな
無理してトリッキーな事するよりも、よほど自然な設計だと思うけど

ロボット::指を動かす();

ガンダム::ビームライフルを撃つ()
{
　if( ビームライフル != NULL )
{
　 指を動かす();
;
}
}

>>352
そうですねー。ドラえもんも道具をポケットから出すし、
それで「出す」メソッドに抽象化してみたんですけど、
やっぱり直感的じゃないですな。

まあ俺の考えるLSPにのっとった設計の例、って事で許して下され。
元々のロボットクラスの例がネタだし。

俺はメイヤー先生の本で最初に知った
メイヤー先生はAssertion大好きなのでBaseクラスのメソッドのAssertionをパスする入力は
派生クラスのAssertionも通らなくてはいけない。
同じようにBaseクラスのメソッドが約束する振る舞いは派生クラスのメソッドも満たさなくてはいけない
という原則をうたってたなぁ

これは数学的だなとおもったよ

専門学校で本格的なOO教えるとこ
なんかあんのか？
OOに限った事じゃないけど、独学ばっかりで
なんのために学校通ってたのかわかんなく
なってたよ。

あらゆるジャンルの専門学校で役に立つとこってほんとにあんのか

>>357
学ぶ人間の資質が一番重要だが、
スペシャリストを輩出する専門学校はそれなりにあるよ。
でも殆どはゴミ生産工場。特ににコンピュータ関連は酷いね。

俺は現役専門学校生だけど俺が通ってる学校は
せっかく2年間もあるのに内容を薄く薄く伸ばした授業しかないよ
そんな授業にもついていけてない連中がSE、プログラマーとして内定取ってたりするの見てて
プログラマーになるの怖くなったよ。趣味が一番なのかな？

書いてから気づいたが思いっきりスレ違いだな…スマン

>>359
まあ大抵は実務をこなしながらスキルアップしていく訳だけど、
人間性も含めプログラマとしての最低限の資質を兼ね備えてない奴は
デスマ引き起こしたり精神患ったりしてるわな。

スキル不足だけが原因の長時間残業は、デスマとは呼ばないけどね

派生　基本という用語がでているが
UML命名規則に従って統一しないか

派生する, 継承, 拡張 -> 汎化
派生 -> サブクラス
基本 -> スーパークラス
メンバ変数, フィールド, プロパティ -> 属性( 注 : C#の属性と間違えないように !)
メンバ関数, メソッド, サブルーチン -> 操作

>>363
どうでもいい

どうでもよくない！　ｶﾞｼｬﾝ！

>>363
お断りだ。

とりあえず
オブジェクト -> おっぱい
でいいんじゃない

もうこのスレ終わりか。
8なんたらも講義の続きができないみたいだからな。

>>363
「派生する, 継承, 拡張」は、「汎化」の逆の方を言うんじゃなかったっけ？

派生・継承は「特化」。たしかに汎化とは逆の筈

お前ら愚鈍どもに聞きたい
最高ですかーーー？

>>362
いや、デスマの原因は営業の交渉能力に依存する。
営業がバカであればデスマは簡単に起こる。うちのバイト先がもろにそうだ。

バイト先を見て思ったが
バカに営業はやらせないほうがええな。
バカに営業やらせるとできないこともすぐできると大嘘ばかりつく。
バカな営業をクビにしたいところだが、そいつ、会社役員なので
それができない。しかも威張ってる。最悪だ。

そのとき思ったよ、
技術がろくに解ってない奴なんかに営業なんて絶対やらせるべきじゃないと悟ったね。
技術が解ってない奴は中身が見えてないから
どんなものでも魔法のようにすぐに簡単にできると勘違いしている。
顧客がバカでも営業が賢ければ多少は救いようがあるのに
営業がバカで威張ってるからこの会社はいつもデスマで土日も休みがない。
しかも残業代は一切無いし(嘲笑


ああ、こんな会社の社員じゃなくてよかったw

>>366
UMLに逆らう奴は氏ね

UML命名規則が嫌ならJavaキーワードに従おう

拡張, 派生　-> 継承
子クラス, 派生クラス ->サブクラス
基本クラス、親クラス -> スーパークラス
純粋仮想関数 -> 抽象メソッド またはabstractを使って表現
メンバ関数、操作　-> メソッド
メンバ変数、プロパティ、属性 -> フィールド
C#の属性、Javaのアノテーション　-> アノテーション または@を使って表現

不変クラスの作り方
setterメソッドは使用禁止。
インスタンスフィールドはすべてfinal宣言し
コンストラクタを呼び出した時点で
すべてのインスタンスフィールドへの代入を直ちに完了させる。
getterメソッドを用意する。
メソッドの操作によってオブジェクトの中身が変更されることはあってはならない。
一度生成したオブジェクトは、その後、いかなるメソッドを呼び出しても
メソッド呼び出し後、呼び出し前とでは全く同じオブジェクトになり
Object#equals()を呼び出しても必ずtrueになるようにする。
クラスはfinal宣言する。

委譲の話が異常に盛り上がったので、以上で終了します。

>>376
頼むから死んでくれ

>>377
ブ・ラジャー！！

>>376
だめだ。許さん！　ﾋﾞｼｯ! ｶﾞｶﾞｯ!

委譲 -> Delegation
集約 -> Aggregation
コンポジション集約 -> Compisition
継承 -> Generalization, Extension, Inheritance

>>379
100万円差し上げますのでどうか許してください

100万円？
匿名掲示板でそんなこといっても信じねぇぞｺﾞﾙｧ


100万円に相当する情報を匿名掲示板に無料でばらまいてみろ。
マスコミに目が届くほど100万円に相当する力を発揮してみろ。

子供銀行券の100万円に決まってんだろうが
何あつくなってんのﾁﾐ

なぁ…つまらない奴の存在ってのは罪だと思うんだが、どうだろう。

「あぁ、お前のことか」と言う

>>385
ちょっと長いよ

がっかりだぜ

お前らは今までに食ったパンの枚数を覚えているのか？

時は今！
場所はここだ！

時は宇宙、所は未来

時間と空間は等価ってヤツですね！

いや、上手くないし。
なんだその得意げな顔は。

やれやれだぜ

　

緊急アンケート開始

あなたは
１、クンニ派？　
２、指派？

３，ちんこ派

４．おもちゃ派

オブジェクト指向の講義の続きまだー？

５．貝合わせ派

６、はぐれ刑事、童貞派

７．貧乳支持派

それは「微乳」と呼ぶのだ

8. あなたの尻の穴を舐めさせてください派

毎度毎度、迷惑メールはフィルタリングでゴミ箱逝きのメール環境だが、
なんとなくゴミ箱の迷惑メールを見てみたら笑えるのが来たので報告します。

≪日本人以外の女性も多数在籍中≫
※日本在住の女性中心です。
http://1191.jp/kensaku/index.html
逆援・エッチなチャットや電話、メール交換・1-対-1 のセックス・秘密の関係・SM調教・女装や男装・・・・・・・から選んでピッタシの女性をお探し下さい。
http://1191.jp/kensaku/index.html
お試し登録の方に完全10000万円分差し上げます。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
●NO.I don't veceive your mail●
sweet_as_candy_700@yahoo.fr
●今後、受信を拒否する場合は●
sweet_as_candy_700@yahoo.fr


ちなみに、クリックしてしまうとどうなるか分からないので自己責任乙。

> お試し登録の方に完全10000万円分差し上げます。

この部分が意味不明で凄過ぎです。1億円もらえるっぽいです。

この前はじめてオブジェクト指向のプログラムの作り方教わったけど
ハッキリ言ってオブジェクト指向ってショボイね。
もっと凄いもんかと思ってた。

>>405
いやいや、作るのは大変なんですって。

作るの大変だしメンテもそれほど楽とは言えない。

開発者のオナニーの塊がオブジェクト指向ということで結論は出ている。

イメージの出来てない人間のやるオブジェクト指向は似非だ
似非オブジェクト指向は本当にひどいプログラムを生み出す

>>405
>この前はじめてオブジェクト指向のプログラムの作り方教わったけど
OO を知らずに OOP だけ教わったんじゃあ、話になりませんね。

OOPSは教わった

＞ OO を知らずに OOP だけ教わったんじゃあ、話になりませんね。

実際には、OOPを習って自分で書いてみて初めてOOが理解できるという構図が一般的。
なぜならOOだけ勉強してもあまりにも概念的過ぎるから。
とりあえずOOPでOOしないで組んでみて、それをOOに直していくっていうのがいまフィリピンで大ブーム。
できる奴ならOOAとOODをやって、OOPはほかにまわす。これが南アでひそかなブーム。

まあ、OOだけ知ってるってやつよりはOOPだけ知ってる、ってやつのほうが仕事しやすいけど。

「OOP だけ知ってる」 ってやつは大抵 「とにかくクラスを１つでも作れば OOP」 って思ってる奴だと思う

んなこたあないだろう。
OOP知ってる、って言う場合、
大抵Javaや.netのプロジェクトにPGとして参加したことがあるやつだろ。

む、実は学生だからその辺良くわかんない

何というか、俺はみたことあるのよ
クラス１つ作って input, process, output の３つの引数なしメソッドを追加して 「これが OOP だ」 って言っちゃった人を

しかもその人、java の継承については差分プログラミングの部分しか説明して無いし
あれじゃ講義に出た人は、絶対に曲解しただろうに

OOだけ知ってる奴→「みかんは果物の継承でだなぁ…」とかいう受け売りを得意げにばらまく。プログラムは組まない。
OOPだけ知ってる奴→C++をベターCとして使う。Javaを関数型言語として使う。

>>416
＞OOPだけ知ってる奴→C++をベターCとして使う。Javaを関数型言語として使う。
ごめんよくわかんない

OOPってOOも含むんじゃないの？

>>416
>OOPだけ知ってる奴→C++をベターCとして使う。
これは出来るが・・・

>Javaを関数型言語として使う。
これは無理。原理的に。

DelphiをVisual Pascalとして使う
って言い回しがあったなあ（涙）。

>>418
OO を使ってプログラミングすることを OOP と言うんだ

OO　－継承→　OOP

継承じゃないだろ

集約？
やっぱ継承じゃね？

OOP is OO …… なのか？

OO は概念、OOP はプログラミングテクニックだから、俺は継承じゃないとは思ったが

プログラムの側から見れば
プログラム　→　OO
オブジェクト指向の側から見れば
OO　→　OOP
切り口をどちらに取るかによって関係が変わるけど
オブジェクト指向は抽象クラスであって
OOPという具体的な形にしないと使えないと思われ

＞プログラム　→　OO
プログラム　→　OOP
に訂正

切り口の意味がわかんないっす

クラス分けするときの見方のこと
どういった側面から物事を見るかで
クラスの分け方が変わってくると思う
>>426の例でいえば
プログラムを元に考えるかオブジェクト指向を元に考えるかで
どちらが基本クラスになるかが変わってくる

この辺の考え方はこれで合ってるよね？

ごめん。俺の考えと異なるからうまくわかんないわ (-∀-)
俺は最初の段階でプログラムの完成図を OO でマッピングしちゃうから

俺も我流だから自信ないんだよね・・・
パス。

OOとは～とか、OOが分かったとか、漠然としすぎだよな。
デザパタで無理やりJavaってみて初めてCと違うと気づく。これでいいんじゃね？

そだね

結局必然性が感じられないから、いつまでたっても理論家の一人よがりに見えるんだろうな。
実際に使ってみれば、本当に綺麗なプログラムってやつが記述できるんだが。
いかんせん、規模がでかくて、構造が複雑で、変更や拡張を前提としているプログラムでないと、
ひたすら「余計な手間」に見えてしまうというのは、確かに効果が見えにくいかも知れない。

見えやすい効果としては、今までライブラリの中に漫然と並んでいた関数郡が、
階層化された構造の中にある、ってだけでも恩恵あると思うんだが。
でもそれで魅力を語ろうとすると、「いや、それはOOの本質じゃない」とか言われるんだろうなｗ

＞でもそれで魅力を語ろうとすると、「いや、それはOOの本質じゃない」とか言われるんだろうなｗ

俺はそれが本質だと思う
どんな手法も結局整理整頓の方法の一つだと思う

>>434-435

そういう議論になっても、「本質」という言葉の定義が各自バラバラだから
議論がかみ合わないｗ

http://pc8.2ch.net/test/read.cgi/tech/1129156338/5-7

初心者です。
オブジェクト指向って皆さんはどのようにして勉強されたのですか？
やはり何か書籍とか読んだのですか？

何年も掛けて慣れた

C++やJAVAを使っているだけでオブジェクト指向と言ってる人もいれば、
ちゃんと考え方まで取り入れて設計している人までさまざまですね。
実際はどちらが多いのでしょうね？

絶対に前者

>>440
８０：２０の法則に乗っ取ってるかも。かも。

UML描ける人はオブジェクト指向してると思っていいのかな？
今、勉強中だけど。。。

ゆるさん

どゆこと？

指向って言葉の意味を考えれば
厳密な定義があろうはずもないじゃないか

厳密な定義が無くても、それなりの概念はあると思うのだが。
でなきゃ、OOP言語やら書籍など巷にあふれないもんな。
オブジェクト指向に挫折した人って、
そう言い訳していつも逃げてるのかしら？？？
煽ってんじゃないのよ。
避けてる人、挫折した人の本音が知りたいのよ。

いまさらだが、上がってたのでロボットクラスに関してレス

結局目的が定義されずに分類だけ進んでる事が問題。

public 出るもの 出す()　メソッドが、
ロボットたるもの、何かを出せてしかるべきだ。
というコンセプトで設計されているなら、出てくるものが道具でもビームでも置換原則は守れている。

しかし、
ドラえもん：便利な道具を出してマスターを助ける。
ガンダム：宇宙空間で敵と戦う。

のようなコンセプトであるならば、出す()メソッドを抽象化する必要性があまりない。
どちらかというと継承ではなく、ロボットクラスをハードウェアとして、委譲して持っているべきではないか。

実際のOO開発では、現実世界で考えられる振る舞いを全て実装する事はなく、
プロジェクトにあった必要最小限なものだけを実装するわけだが、ここで現実世界とのギャップが出てくる。

たとえば、上の例でロボットを新しく追加したいが、出す()メソッドが必要ない。（出すものがない）といった仕様変更が来た場合どうだろう。
現行のプログラミングでは全てロボットは何かを出せる。として設計してあった場合に困った事になる。

つまり、OO設計とは、現実世界の「一部」を抽出する行為であり、
その一部の範囲に含まれない仕様変更があった場合に破綻をきたす。
しかし大きなプロジェクトほど、ありえない仕様変更が多い。

現実世界を完全に投影できれば最強だが、一部しか実装しない場合は破綻する可能性がある。
ならば変なルールなど作らずに、修正の容易な（影響範囲が少なくてすむ）設計でもいいのではないか？
という意見もなくなくなくなくなくない？と思ったりもする。

どこのスレでロボットが出てきたのかと思えば、このスレだったのか。忘れてたな。


＞ロボットたるもの、何かを出せてしかるべきだ。
＞というコンセプトで設計されているなら、出てくるものが道具でもビームでも置換原則は守れている。

『何も出さないロボット』 が登場し、親クラスが想定していない動作……
例えば null を出す場合や、例外を搬出する等を行った時には、リスコフ置換原則は守られていない。

逆に、親クラスで 『何も出さないときには例外を出す』 とか定義しているなら、
実は置換原則は守られていたりする。

# ちなみに、親クラスに 『出す』 が無い場合には、置換原則はそもそも関係ない。


意外と親クラスがどこまで物を考えているかに関係しちゃったりするんだよなぁ。
けど、親クラスの変更は子クラスまで伝播するから、親クラスを改変しないことを第一に考えるべきかと思ったり。

>>414
ハッタリC言語厨は>>413に挙げられる例を醸し出す香具師が多いのも事実なわけで

ていうか、オブジェクト指向を理解もして無いﾔｼが、
挫折した腹いせに「OOPは無駄」とか必死に言ってるのがｱﾜﾚｿｽ。

>>452
…と、ﾏﾙﾁしてる君の方が必死に見える。

まあ、ダメな人間ってのは、何をやらせても自分のせいではなく、周りのせいだと思うものだし。
自分の置かれている状況と、チーム内の人間と、開発体制と仕様書にけちつけて自己弁しつづけるよな。

オブジェクト指向プログラミングの場合、
マスターファイルをトランザクションファイルで更新するというプログラムは
どうやって組むんですか？

仕様による。

あんなにクリスマス～って騒いでても、
一瞬の出来事だったね。
今度は大晦日～って盛り上がるんだろうけど、
来週の今頃って、もう来年だよ。
それも、既に元旦過ぎてる。

『オブジェクト指向でなぜつくるのか』
つー本読んだが・・・やっぱ理解できない

このシリーズの中でこの本だけ判り難いとおもた
今日

とりあえず、このスレ見ててオブジェクト指向が理解できて無い奴は
憂鬱本は読んだ上で言ってるんだよな？

つーか、次回から最低でも憂鬱本の紹介はテンプレに入れろ。

憂鬱本って？

ぐぐったら１・２・３番目に出てくるじゃないか

>>461
http://tito.fc2web.com/2ch/tech/index.html
http://tito.fc2web.com/2ch/tech/index.html#d0e2176

憂鬱なプログラマのためのオブジェクト指向開発講座 ― C++による実践的ソフトウェア構築入門
Tucker (著)
翔泳社(1998) ISBN:4-8813-5619-4

デザパタはあくまでパターンなのでオブジェクト指向の理論とは関連が薄いから
実質2ch一番人気のオブジェクト指向本となる。

サンクスです
アマゾンの書評みたら。。。
『全米が泣いた！！』みたいな感じでｗ

明日から読んでみよう
でもってまだわかんなかったら
ここに粘着

古め（？）の本が多いみたいだから
モダンな ooもどうぞ
例えば
http://www.amazon.co.jp/exec/obidos/ASIN/4797323361/qid=1135909350/sr=8-4/ref=sr_8_xs_ap_i4_xgl63/250-9699570-0684244

オブジェクト指向なんて全然大したこと無いよ
ようは関数の概念をちょっと弄って使いづらくしただけ
オブジェクト指向考えた奴ってアホだな

>>466←こういうのもう相手にしなくていいっしょ？ｗ

憂鬱本読み終わりました
目から鱗でした

でも、図が書けない実装できない
急に面白くない状態になりました

アナリシスパターンとかよく使うんですか？

仕事で？使わないよ

アナル挿すパターン

イベントドブリン型も知らないで何がオブジェクト指向だか・・
最近の若いプログラマーは流行だけを追いかけて頭でっかちで全然使い物にならん

ドブリンかい

全然関係ないけどドリブンってドライブの過去分詞だけど、
微妙に直感的じゃないんだよな。
イベント駆動とかイベントドライブとかの名前にしたほうが全然わかりやすかったと思う。

厨房のころ「イベントドンブリ？なんかよくわかんね」って投げ出した思い出あり。

>>474
>イベント駆動とかイベントドライブとかの名前にしたほうが全然わかりやすかったと思う。

安心しろ。
それは、お前に説明する為に作られた言葉ではないから。

イベントドブリン型も知らないで何がオバジェクト指向だか・・
最近の若いプログラモーは流行だけを追いかけて頭とっかちで全然使い物にならん

今時イベントドリブンを知らんプログラマなんかいるのか？

だから、
イベント【ドブリン】じゃなくてイベント【ドリブン】だって。

まぁ、コピペの釣りだからしかたないか。

イベント丼か

>>477
あまりにもありふれすぎててその名前を聞かないだけだと思うんだが。

きちんとインストロールしないからだ

>>476
たしかに自己満足のコード書いて自慢する新人が増えてるね
俺の配下からは追い出してやったけど

イベントドンブリ

>>1
とりあえずどんなOSでもいいからGUIシステム実装してみろや、出来上がるころには確実に身についているはず。

つか、何故オブジェクト指向スレにきてイベント丼の話をしだすのか不明。
あんなの適当にめっさげが降ってくるだけじゃん。
スウィッチケースでテキトーにわけて処理核だけじゃん。
何えばってんの？この人。
頭弱いんじゃない？
豆腐だな豆腐。

>>485 m9（＾Д＾）ﾌﾟｷﾞｬｰ

>>485
>あんなの適当にめっさげが降ってくるだけじゃん。
めっさげてｗ
マッサージの読み方も知らんのかｗｗ

うますぎて付いていけん

「冬厨になりきって冬を満喫するスレ」かと思った

自分は、「降ってくる」ではなくて「上がってくる」という感覚なのですが。

>>490
マジレスですか？

Win32APIをベタで書きで、「降ってくる」ようなイベントの記述もあったような希ガス(めちゃ汚いソースだが)
じゃばらーのイベントのイメージはやっぱり「上がってくる」って感じ？

「上がってくる」のは例外かな・・・
俺は後で呼んでもらうために参照を渡しておく程度の感覚しかない

エロで検索してたら良スレﾊｹｰﾝ

うわぁーーー
プログラムの　分割民営化やー

オブジェクト指向を理解できないやつは、どんな仕事も非効率な無能人間。

コボラーのことか？

うわぁーーー
プログラムのノルディック復号や

うわぁーーー
プログラムの年末工事や

ロボットの話に戻るけど、
顧客から「ガンダムやドラエモンからも白い物を出させたい」って
言われたらどうするの？

ロボットクラスの出るものをコレクションにすればいいのかな？
これだとスーパークラスを変更しなくちゃならないけど。

「これ、何に見えます？」
「えぇ～っ飛行機をロボットにぃ！？」

>>501
二重継承ですか。

>>499
しごく

白いものって、白けりゃ何でもいいのか？

煙くらいなら、デフォでガンダムとか出るんじゃまいか？ｗ

トラックバック:http://app.blogs.itmedia.co.jp/t/trackback/4088073

脱オブジェクト指向のススメ
ttp://blogs.itmedia.co.jp/tamaki/2006/06/post_57ab.html


このイーキャッシュの代表取締役玉木の発言がおかしいから
このスレからpinする。

オブジェクト指向のことをまったくわかっていません。
というか、かなり勘違いしています。
そのくせにオブジェクト指向を否定しています。


あまりにも突っ込みどころが満載です。

これで代表取締役が務まるのですから
思いっきり叩いてやっちゃってください

>>505
「IT」業界の人の言う事ですから
コンピュータ業界とは違う常識があるんでしょう。

読みやすいプログラムとか、拡張しやすいプログラムにしようとすると
知らないうちにオブジェクト指向的なものになることが結構あるんだがな・・・

>>505
んー結構あってんじゃない？
なんか間違ってる？

なんか最近オブジェクト指向って言葉を拡大解釈してる奴がいてうざいけど
オブジェクト指向自体は何も生まんし、生産性なんかあがらんし、再利用なんて狙ってないし、
ただ、ただ、単にオブジェクト単位でクラス作ろうぜってだけなんだけど。

なんか、これ以外の意味をもたせることに必死なボーヤがいるようなんだよね。
オブジェクト指向自体はオブジェクト単位でクラス作るってただそれだけしか説明してないし、
こう作るとうまくいくっぽいよ。マジで。としかいってない。
なにせ、しょっぱなはシミュレーション用に作られたもんでオブジェクトごとに作るといいっぽいよってホントただそれだけで
別に何がどうとかカニがどうとかそんなもんはこれっぽっちもなかったはずだよ。

>>508
ラリった中年のような文章だ。

508は最初の最初は避妊に失敗して産まれたんだけど、
そのうちに偉大な人間になるようにと願をかけられて、
結局今のていたらくがあるわけだ。

508が痛すぎる件について
ネタか釣りかコボラーだよな、な？

オブジェクト指向で再利用を狙っていない？
確かにオブジェクト指向を信仰している奴は多いが、再利用を狙っていないと言うのはおかしいな。
元々は再利用のための技術だぞ、それも「Windowプログラム」のな。
構造化CでWinやXのWindowアプリケーションをつくってみろ、そうすれば分かる。
今はそれが他のプログラムにも転用されているがな。

http://d.hatena.ne.jp/yaneurao/20051230
http://www.rubyist.net/~matz/20060120.html#p01
オマエラが好きそうな厨房系天才プログラマの２人も同じようなこと言ってるけど
これについてはどう思うんだ？

やねうらおは所詮8bitアセンブラで思考が止まっちゃったような人だからな～・・・

>>512
嘘吐くな。
オブジェクト指向は元々はシミュレーションのためのもの。
再利用しやすいってのはあくまでおまけ。

再利用つうのは大昔からソフト業の悲願なんだよ。
おまけであろうがなかろうが「再利用可能」つうのは
何よりも大きなウリなんだ。
もちろん「可能である」ということは
「誰にでも再利用可能なものを作る事ができる」
という事では無いことは御承知だと思うけど。

>>516
それ、お前の勝手な考えだろ？
再利用なんてのはプロジェクトが完全に終わってからでないと
それがよかったか悪かったなんて判断できないだろ。

ＡクラスとＢクラスの両方で使われているＣクラスが
プロジェクトの最後までＡクラスとＢクラスの両方で使われる保障なんてそうそうあるもんじゃない。
ちょっとした仕様変更で
Ａクラスで必要なＣクラスとは似て非なるＡＣクラス、
Ｂクラスで必要なＣクラスとは似て非なるＢＣクラスが
いつどういう形で必要になるかは正直予想できない。

このとき、ＡＣとＢＣが共通のつもりで使っていたＣクラスを継承することで
できるかどうかだってやっぱりわからない。

また、再利用ができたって、だからどうしたって思うんだがな。
具体的に何がどういいんだ？
メリットとそれと同じ数のデメリットを抱えるだけの話であっていいだけでは終わらない話だと思うんだがね。
ただ、まったくやらないという話ではなくて、あくまでシステム的に自然とそうなるものであって
再利用を狙ってやるようなことは「俺は」無いけどね。

>>517
>それ、お前の勝手な考えだろ？
匿名掲示板は自分が思う事を書く場所さ。
「勝手な考えだ」と思うならそう思いなさい。それはお互い様だ。

OOPLを広める為に「これは再利用可能なプログラムを書くことができます」
という表現が多用されたのは事実だよ。

>具体的に何がどういいんだ？
俗に言うアプリケーションコンテナを使った事はありますか？

>>518
質問に質問で返すアホとは会話できません。

一つのファイルで複数のオブジェクトプログラムが作れる→なんか楽→ｳﾏｰ

という漏れの考えは間違ってますか？

オブジェクト指向って、別に具体的なメリットを求めてるわけではないと思う。
手続き型よりオブジェクト指向のほうが直感的だと思う人がいて、そして
そういう人たちにとって直感性に優れることから、派生的になにがしかの
メリットが得られるという感じ。

>>521
そうそうそんな「感じ」。
その「感じ」ってのをつかむのが一部の人間にとっちゃ難しいってのがオブジェクト指向だと思うんだよね。
はじめシミュレーションで活躍してたってところからなんとなくイメージしてみてよって感じだが。
ホント大事なのはこの「感じ」って部分だと思う。

>>515
>オブジェクト指向は元々はシミュレーションのためのもの。
と強弁してるのは多分君だけ。
事実だとしても、「元々」 が今の話にどう関係してくるんだ？

>>523
なにそれ？
今と昔でオブジェクト指向の意味が違うとか言い出す気？

>>523
http://ja.wikipedia.org/wiki/Simula
これが最初だボーヤ。

>>524
十数年も経てば違って来ているとしても不思議はない。
増してや、お前のいう「シミュレーション」以外に応用しようとするなら。

…Simula かよ…
そりゃ OOPL の始まりであって
OO の最初じゃないだろうに。

>>526
じゃあ、何を規準に正しいとするわけ？
まあ、変わったと主張するとしても今と昔でどう変わったのかも知っておいたほうがいいんじゃないの？

俺は最近のオブジェクト指向を唱える奴ってのは
はっきりいって勘違いした、間違ったままのことを言ってる奴が多いと思うね。
まあ、雑誌とかでも平気でそういうことが書かれてるからそれが正しいと思っちゃうのかもしれんけど。

いま、ものすごくごちゃごちゃになってるよね？
オブジェクト指向って結局なんなの？ってのがわからないのをいいことにみんながみんなテキトウなこと言ってるから。

始めは

開発の動機は、ある制限化におかれたモデル群の全体の挙動をどう記述するか、というものである。
気体の分子運動を例にとると、システム全体を考えてその中の項として分子を扱うよりも、
一つの一つの気体分子をモデル化し、それぞれの相互作用の結果をシステムとして捉える方が自然で取り扱いやすい。
その為には小さなモデル、関連する法則、それらを一度に複数取り扱う能力が必要となる。
こうして属性を備えたオブジェクト概念と、それに従属するメソッド概念が生まれたのである。

ってことなんだよ。
そんな難しいこと書いてないだろ？
もしかしてちょっといいんじゃね？程度だ。
別に開発期間がどうだとか、再利用がどうだとか、そこまで計算されてねぇよ。

>>527
はぁ？ちゃんと読んでよ。

なお、Simula当時「オブジェクト指向」という言葉はまだない。
この用語はアラン・ケイがSmalltalkの概念として70年代ごろに使い出したのが始まりといわれている。
従ってその意味ではSmalltalkが世界最初のオブジェクト指向言語であり、
Simulaは「オブジェクト指向として再認識が可能な最古の言語」ということができる。

>>529
そうだね。クラスやオブジェクトは、実はオブジェクト指向とは関係ないところで考え出された。
ストラウストラップは C に「Simula のクラス」を使って、抽象データ型、つまり、ユーザーが型を
定義できる機能を付加した。これがオブジェクト指向プログラミングのスタート。

それとは別にアラン・ケイの「メッセージング」というパラダイムに基づくオブジェクト指向がある。
この２つがごっちゃにされているから、言語間宗教戦争とか、おかしなことになるんだ。

ttp://d.hatena.ne.jp/sumim/20040525/p1
「オブジェクト指向の概念の発明者は誰ですか？」

アランケイのオブジェクト指向とSIMULAのオブジェクト指向は別物だな。
アランケイのオブジェクト指向はなんか複雑なだけで恩恵は無い気がする。

俺はストラウストラップ自身もSIMULAのオブジェクト指向（？）は理解できてなかったと思うけどね。
なんかいってること違うしね。

いや。理解するも何も、Simula にオブジェクト指向はないんだって。
クラスやオブジェクトを拝借したストラウストラップがリスペクトして「オブジェクト指向言語」だと
言っているだけで。本当は、彼のオブジェクト指向にてらしても、Simula はその範疇にない。

>>531
アランケイのオブジェクト指向は単純だと思う。なんでもメッセージ、それだけ。
あえて難しくいうと、疎結合とか、徹底した動的性なんだけど、まあいいや。

>>533
いや、でも>>528の気体分子の例は明らかにオブジェクト指向だと思う。
これをオブジェクト指向といわずに何をオブジェクト指向と呼ぶのか？ってぐらい。

>528
とても参考になりました。
528の言う事が非常に納得できるので、シミュレーション派に寝返らせていただきます。
シムラ万歳！！

Cでオブジェクト指向プログラミングするとしたらどうなるのよ

ひとつの処理をファイルに纏めるの???
グローバル変数をstaticで宣言するの???
set_**** って感じで上の変数に入れるの???

教えて

>>537
// コンストラクタ
FILE* fopen(const char* filename, const char* opt);
// デストラクタ
int fclose(FILE* fp);

なるほど
例えば リスト処理の時もあちこちにコードを書かないで
add()
del()
と書けばいいのですね?

リストからtitleの値を取り出すとき
get_title(list)
とするか
list -> title
とするかどっちがいいですか?

知らんがな

晒しage

回答待ちage

sage

sage

>>542
別に普通にできるじゃん。
そんなのもわからないならはやく死ねよ。

>>542
あーお前さんの言う
「オブジェクト指向プログラミング」
ってのが何を想定してるのかがわからんのだが

データとメソッドの融合は無理すりゃCでもできるけどメリットない
けど「オブジェクト指向設計」は十分Cでもメリットある

無論「オブジェクト指向言語」を使ったほうが
設計と実装の乖離が少ない分メリットは大きいが

http://www.sage-p.com/process/cool.htm

>>542
こんな感じで構造体の中身を外部から隠して抽象データ型を表現するのは、
オブジェクト指向が流行る前からあったテクニックだよ。

ヘッダファイル(list.h)
typedef struct list *LIST;
LIST list_make(初期化パラメータ);
int list_free(LIST);
char *list_title(LIST);
int list_add(LIST, x);
int list_delete(LIST, x);

本体ファイル(list.c)
struct list
{
char *title;
…;
};

char *list_title (LIST l) { return l->title; }
int list_add (LIST l) { … }
int list_delete (LIST l) { … }

よくわからんが
>>538
みたいな感じで書けばいいの?

>>549
Cでオブジェクト指向風のコードを書くなら、Cの構造体はC++のように必要なメンバ変数だけ
隠したり公開したり出来ないんで、パフォーマンス的にシビアな場面でない限り、>>539の前者のように
実装は完全に隠して関数を通してだけアクセス出来るようにしたほうが安全で変更に強い。

>>550
C++ でいう viratual を実装するのに 関数へのﾎﾟｲﾝﾀをﾒﾝﾊﾞに持たせたことはあるが…
直接呼出しの obj_ptr->func() よりも、
関数呼び出しｽﾀｲﾙの func(obj_ptr) で記述するほうが、間違えﾄﾗｯﾌﾟしやすいしね。

設計&整理の手法を真似て、記述法は真似ない　というあたりが落とし所かな？　と思った
# 単継承限定でも C++ to C ｺﾝﾊﾟｲﾗ があれば良かったんだけどね…

age

>>551
ポインタの保持はグローバル変数やgotoと並ぶ大罪だぞ。

javaはこれを無くすためにごちゃごちゃやってあるが、
逆にインスタンスがよくわからなくなって失敗してるがｗ

>>553
ﾊｧ?

>>553
ゲームだとDirectXでD3DDeviceを各クラスで保存しちゃって
Alt+Tabでロストしたとき、どうしようもなくなっちゃうお馬鹿なプログラムがよくある。

ヒープ(?)を指すポインタとstaticな関数ポインタを
ごっちゃにしてしまうような人が来るのは、
やはり無闇にageた所為でしょうか?

>>556
すいません。>>553の「ポインタの保持」だけに脊髄反射しました。

ネットで「オセロをオブジェクト指向で考える」と言うのをよく見かけます。
盤面オブジェクトってのが出てきて、石の状態は盤面オブジェクトが管理
していたりします。
プレイヤーオブジェクトの役割といえば、次の一手を考えるだけです。

不自然じゃないですか？

現実世界では、石の管理もルール解釈も次の一手もプレイヤーが行います。
このギャップは何なのでしょうか。
このギャップがオブジェクト指向の理解を妨げているのではないでしょうか。

世界の切る際に、切ることに何を求めるか。

大抵は ある程度の規模・期間で作るときのコスト低減を狙うと思うので
それを実現するために（多様な）プレイヤ実装を念頭において
盤面オブジェクトに 現実にはプレイヤにある機能を移すんじゃないかなと。

>>558
それは動作じゃね？
まず、設計時点ならそれぞれの情報を
各オブジェクトが内包している状態さえクラスで表現できればいい。
例えば盤に並んでるオセロの石が表か裏か配置されているかどうか
配置されてるならどこに配置されてるかってのを表現できればいい。

>プレイヤーオブジェクトの役割といえば、次の一手を考えるだけです
>現実世界では、石の管理もルール解釈も次の一手もプレイヤーが行います
これはセンスだな。
オブジェクト指向ってのはあくまでできるだけオブジェクト単位で処理するってことしかいってない。>>525参照。
つまりクラスにわけた時点でオブジェクト指向は終わっている。

別にわかり易くなるならプレイヤーと審判、オセロの石管理者みたいなのを用意してもいい。

オブジェクト指向とは何か？

宗教です。

これからは自律オブジェクト指向の時代だよ？

オブジェクトは意思を持ってます。
オブジェクトは自らのバイナリイメージを書き換えて成長します。

でも、環境の変化に弱く、環境(CPU)が変わると息絶ることがあります。

自律オブジェクトは生みの親の顔を覚えています。
親の電子証明書を期限切れにすると成長が止まります。

ウィルスではありません。
自律品種改良です。

全く無知の俺が
２ヶ月でC++をマスターする。
その為に独習C++と言う本を買って来たぜｗ
さぁて早速始めてみるか…

つかCは飛ばしたけどこの本の内容…理解出来るかな…

>>564
出来るよ。マスター出来ないとは思うけど。
一通り読み終わるには２ヶ月で十分な時間だよ。
で、それから、いろいろ作るうちに少しずつ理解できるからがんばれ～って俺は思う。

>>564
なんで憂鬱本買ってこなかったんだ。
http://www.amazon.co.jp/exec/obidos/ASIN/4881356194/
人気書籍ぐらい調べてから勉強はじめろよ。

憂鬱本はC++をマスターするための本じゃないし。

>>567
色んな本を読むべきだと思うよ。
色んな本を読むのはいいことだ。
物事を色んな視点から見る目を養ってくれる。
１つの本だけを集中的に読んでもそれは１人の人間だけの考えを深く知るに過ぎない。

>>565
この本Cを読者が知ってる者とします…
って書いてあったが大丈夫かな…
まぁ頑張ります
>>566-567
オブジェクト指向がなんたらって奴はこの本読み終わったらやろうと思う

>>568
㌧
色んな本を読んでみるよ
頑張ります！

>>569
本の読み方が下手糞。
はじめに２～３冊買って見比べながら読むのが効率のいい読み方。

>>565
君の書き込みを読んで俺は、ふーんと思った。

「脱オブジェクト指向のススメ」
http://blogs.itmedia.co.jp/tamaki/2006/06/post_57ab.html

>>572
玉木　栄三郎　（　たまき　えいざぶろう　）
イーキャッシュ株式会社代表取締役。
創業に技術担当非常勤取締役として参加するもその後経営不振により、製品開発、営業を担当するようになり、気が付けば代表取締役に。
業績のV字回復を達成するも、株主と社員に挟まれる中間管理職として日々苦悩している。
略歴など
1972年。香川県生まれ。
麻布大学獣医学部獣医学科卒（獣医師免許取得）
東京医科歯科大学医学部大学院博士課程修了（学位取得セズ）
動物病院勤務医、フリーランスエンジニア、大手メーカーなどを経て現職。
2006年1月より、Microsoft Regional Director に就任。

最近参画したプロジェクトでは、
データを保持するクラスのメソッドはgetterとsetterのみが許されていて
値をいじるのは制御側という構造になってて
ちょっと萎えた

VBでボタンクリックしたらクリックイベントが実行されるだろ
それがイベントドリブンだ

腹をくだすと下痢になるだろう。
それがトイレットゲリベンだ。

びみょ
おもろない

>>572
その内容は、なんちゃってオブジェクト指向マスターに対する皮肉だと思われ。

きのうオブジェクト指向が理解できた
半年かかった

>>1
感謝するぜ。
大昔にＣ言語をちょとかじって構造化やカプセル化といったことは
概念的に理解した後、しばらくＶＢ漬けになってんで
いわゆるオブジェクト指向の考え方がとんとわからない
浦島太郎状態だったんだけど
なんとなく色々理解できてきたよ。

なんていうか新しい概念とかそういう捉え方ではなく
何々の発展形って表現してもらえると非常に自分には
わかりやすい！

とにかくありがとさん！！！

>>528
>>530
参考になりました。
オブジェクト指向プログラミングに関する理解、知識が深まりました。

オブジェクト指向で重要なんは、
Ｃだろうが、Ｃ＋＋だろうが、Ｃ＃だろうが、
ＶＢ（ここじゃ.netに限定）だろうが、
１ソースファイルには機能に限定したもんしか、
書かんことが重要や

その意味ではクラスを定義できる言語は
綺麗なソースになりやすいんや

Ｃはグローバル変数をexternするなんてことすると
読みにくてかなわん

そんなアセンブラの時代から当然の、オブジェクト指向と何の関係もない話を
何を得意げにいってるんだろうな。

いや、というかexternが問題だという奴初めてみたよ。w

それが問題なら最初からファイルスコープっていう概念がないC#とかVBは
もっと問題じゃん。

>>583
お前も得意気だな

素人が作ったソースのカプセル化、隠蔽にメリット無し。

それやってるうちに学んでいって上達していくんだから、
メリットなしというのは本末転倒。

同意

間違いに気付かずにそれを覚えられたら大変だな。
メリットなしというより、大きな賭けなのでは？

どんな奴でも多かれ少なかれ間違って覚えてることはあるよ。
経験を積むうちに勝手に修正されていくから無問題

OOに固有の話題ではないな

クラス図を描ける便利なフリーウェアってあれば
教えてください。

新Visual C++6.0入門 シニア編 林晴比古/著
新C言語入門 ビギナー編 林晴比古/著
を新入社員に薦めている会社ってありますか？

>新Visual C++6.0入門 シニア編
新C言語入門 シニア編
です。

>>593
うちの会社では「新Visual C++ .NET入門シニア編」を使ってます。

何人かの知人に聞いたところ、
私のところもそうですが、林晴比古シリーズ使っている人が
多かったです。（なんで？そんなに良書なの？）

ウチはハルヒ子禁止。

>>596
何故？禁止にするのか！

>>595
次のステップにいけない本だけどなｗ（書いてる本人が一番わかってるだろうけど）
とりあえず、使うだけだけどＭＦＣはそれじゃ組めない。
ちょっとだけ遠回りになるけどＷｉｎ３２ＡＰＩでのプログラムを理解しないとすぐにドツボにハマル。

本当にＶＣ＋＋が組めるようになりたいなら
「猫でもわかるWindowsプログラミング」がいいと思う。
何度も何度も理解できるまで繰り返し読むといいと思う。

>>598
猫から出発した俺はいまだに MFC 使えない…
Doc View 構造を強要されるのが好かんな。

割り込んで申し訳ないんですけど
オブジェクト指向用の宿題スレとかありますか？
ここで聞くとおそらく場違いだと思うので。

プログラム板に行きなさい

それがプログラム問題じゃなくて、
オブジェクト図を描けとか、国クラスと都市クラスの関係を表すクラス図を作れ。
とかそういうのばかりなんですよ。
それでもプログラム板になるんでしょうか？

ム板でいいと思うけど、ム板のくだ質で追い出されたら情シス板にでも行ってみたら

どうでもいいけど自力でやれよ

>>603-604
ちょっと調べてみます、そちらの方を
自力でやってわからないところだから聞こうと思って

宿題出した教師に聞け

>>603
>情シス板にでも行ってみたら
就職相談板で何を訊けと。

ｸｿみたいな憂鬱本にはﾏﾝｾｰしまくって
自分の気に入らない著作/blogへのﾈｯﾄ攻撃を推奨しちゃうｱｲﾂ、
いい加減なんとかならんのかなぁー

たかひろ、お前のことだよ

シュミレーションで考えよう！
インスタントは実体であり、オブジェクトは概念だ。
デザインパターンでセンスを磨け。

(´-`).｡oO（インスタント？）

>610
ちゃんとシミュレーションにもツッコミ入れてよ；；

やだぷー

インスタントで考えよう！
3分で完成するという概念がオブジェクトだ。
しかし、3分も待たずに食べ始める、これが実態だ。

さーて、おさんも逝った事だし、
これから暴れるでぇ～

オブジェクト指向って言葉が悪い。

意味ワカンネーよ。

オブジェクト指向はフォースだ。

　さっき雑誌見てたらアスペクト指向っていう言葉が載ってたんだけど、オブジェクト指向とどう違うわけ？

ぐぐれ

インスタントンだろ？トフーフトの

オブジェクト指向をドラえもんや哺乳類を使って
説明されるのはあまり人気がないみたいだけど
昔ドラクエを使って説明してもらったら
俺でもわかったよ。

884 ：仕様書無しさん：2007/05/11(金) 01:43:28
    役者の演技による映画やドラマ作り＝オブジェクト指向開発
    セルやクレイによるアニメ作り＝構造化開発

>>621 下手に例えると迷宮入りの例。

さぁみんな無知な俺に教えてくれ

そもそもオブジェクトって何なんだ？ｗｗｗｗｗ
学校の課題で出たんだがまったく持って説明の仕方がわからんｗｗｗｗｗ

何の前提もなく「オブジェクトとは何か」という問いに答えるのは
何の前提もなく「権利とは何か」という問いに答えるようなもんだ。

課題出した阿呆つれて来い。説教してやるから。

オブジェクトとは

自分とその外を区別できる（アイデンティティを持つ）
働きかけに反応することができる（メソッド）
内部情報を持つ（インスタンス変数）

JIS X 3010:2003 (ISO/IEC 9899:1999) より抜粋
| 3.14 オブジェクト (object)　その内容によって，値を表現することができる実行環境中の記憶域の部分。
| 　　参考　オブジェクトを参照する場合，オブジェクトは，特定の型をもっていると解釈してもよい
| 　　　　　　　(6.3.2.1 参照)。

オブジェクト指向というか、ユーザクラスとかマネージャクラスとかは簡単にわかる。
継承を使ったコンテナ設計やGOFデザインパターンなんかも易しい。
でも、未だに関連クラスの抽出ができない。属性を持たせたクラスの実現方法が
わからない。（C#なんかだと言語仕様にあるよね。あれはアスペクト指向的で、いまいち
属性という認識が持てないけど。）

なんか、だんだん鬱になる。自分頭わるいのな。

>>627 プロｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!!!

ユーザクラスって何？
あと、GOFのAbstract Factoryパターンがいつまでたっても（笑）
わからないのですが、あれって簡単に言うとどんなもんですか？

たとえばFactory Methodパターンだと、
「インスタンス化をサブクラスに任せる」ってので十分に分かる。

>>628
AクラスとBクラスがあって、AクラスにもBクラスにも非常に便利な関数があったとする。
>>628がAクラスの関数とBクラスの関数を、新しく作ったCクラスで呼びたい場合に使う。
AクラスもBクラスもインスタンスとしても無害か、あるいは静的な関係である必要がある。
Abstract Factoryを継承してCクラスを作る設計として、A、B共にインスタンスとして存在
しても問題がないならOK。

実際には、散らばりだした関数を無理やりまとめたりする時につかうパターン・・・、てか
普通に考えればこのパターンになる。まさに有名パターン。
自分はAbstract Factoryクラスを導出しないで多重継承してしまう派。

AbstractFactoryはDIで代替できる

>>629 完全に間違っているのでは？
（いえ、俺が間違ってる可能性が高いですが（笑））

GoFのAbstract Factoryパターンってのはまず、
「互いに関連したり依存し合うオブジェクト群を、
その具象クラスを明確にせずに生成するための
インタフェースを提供する」とあります。

少なくとも「オブジェクト群」を（特に「群」に注目？）
「生成するためのインタフェース」が本質になっている予感。

などと言いつつ、ピンと来てない俺ですが。
ん？いや？「部品を生成する抽象Factoryクラス」てことか？

>>631
ん…間違ってなくね？

・「オブジェクト群」がインスタンスとは限らない
・Factoryはインスタンスを生成する責務は無い
という点でそういう点で、>>631と考えは違うんだけど。

前提も自分とは考えが違っていて、「互いに関連したり依存しあう」って部分は、個人的に
有っても無くても良い。互いに依存度があるなら、Factoryクラスの使い道が限定されて
「環境まとめクラス」みたいになっちゃう。ある意味AbstractFactoryの使い方かも知れないけど。
（※その場合はほぼ必然的にFactoryMethodも使うことになるよね？）

なので、あえてhaveの関係じゃなくてisの関係で書いてみたんだ。
少なくとも、散らばってしまった関数やクラスは「まとめれる」でしょ。

>632
Factoryはインスタンスを生成する責務あります
631の通り

>>632
おまいが間違ってる

>>633
あれ？よくインスタンスをFactoryに渡してたりしたんだけどなぁ。
別にFactoryは部品は組み立てても、部品そのものは具象化しなくても良いと思ってたが・・・。

>>634
理解間違っていたのかなぁ・・・。結城本でも買ってくる(´・ω・`)

FactoryのFactoryMethod化は必要ないと思っているし、使う側が
Factoryから返すオブジェクトをどう使うかだけの問題だと思ってたんけど。

良く、まとまって使わなきゃいけないクラスをFactoryに持たせて（実際にはFactoryを
継承した自分自身に持たせて）、自分自身をどっかのプロダクトに投げる使い方をするんよ。
これがAbstractFactoryのイメージでいたんだけどなぁ・・・。

というわけで間違っていたらすまん>>632

>627が考えてるFactoryってなんだよｗ

> 少なくとも、散らばってしまった関数やクラスは「まとめれる」でしょ。

散らばった（？）ものをオブジェクトコンポジションだとか、
あるいは継承を使ってだとかでまとめ（？）たりするのは、
何と言いますかデザインパターンどうのこうのではなくて、
OOPにおけるフツーのこと、空気のようなものかもしれません。

> 理解間違っていたのかなぁ・・・。結城本でも買ってくる(´・ω・`)

結城本って、Java言語で学ぶデザインパターン入門ですか？
あの本は3800yenもする割に（個人的には）分かりにくかった気がします。
4800yenでオリジナル（を翻訳したやつ）が買えるのでそっちがオススメです。
難しくてとっつきにくいですが、詳細に、厳密に、漏れなく解説してくれてる感じです。

>>638
> 何と言いますかデザインパターンどうのこうのではなくて、
> OOPにおけるフツーのこと、空気のようなものかもしれません。
デザインパターンというものも結局は空気みたいなものだよ。
一定の知能さえあれば誰でも思いつく。
変に神聖視して自分で壁を作らないほうがいいと思うが。

コテ外しますね。

「本書で示すデザインパターンの中には、新しいものや有用性が未確認である
ものは１つもない。だが、そのほとんどは今まで文書化されていないものだ。
オブジェクト指向コミュニティにおいてよく知られているもの、うまくいった
オブジェクト指向システムの要素となっているものである。いずれも初心者が
容易に得られるものではない。したがって本書中のデザインパターンは新しい
ものではないが、我々はこれらのデザインパターンを、一貫した形式を持つカ
タログとして利用しやすいような形にまとめてみた。」
(「デザインパターン」より引用。)

このように、思いつく思いつかないではなくて、カタログ化、
それこどがメリットなんでしょう。カッチリしてるからこそ、
議論や設計の足がかりになるという。空気とは違って。

神聖視、といいますか、壁を低くして（？）といいますか、例えば、
「俺流Abstract Factoryパターン」だとか、
「たぶんAbstract Factoryパターン」とか、
「Abstract Factoryパターンの亜流」とか、
「何でもAbstract Factoryパターンだ発言」とかは排除したいですよね。
そうならないためのカタログ化、デザインパターンではないでしょうか。

やはりこんな統一性のねーもんまったく役に立たんなｗ
個々のパターン見て信者同士でさえ意見が統一されてないのに
こんなもんが普及するわけがないｗ

開発だってうまくいくのか怪しいもんだなｗ

しかも、こんなローテク全然大局的じゃないけど役に立つのか？
使っても使わんでも変わらん結果になりそーｗ
ま、オブジェクト指向じゃないしねｗ

ま、オブジェクト指向じゃない香具師しねｗ

友達と呑んでる間もAbstractFactoryが気になって、会話に集中できなかったじゃないか。
んで最後のコテ。

自分のFactoryの考えは、ただのインタフェースなんだわ。Factory側を抽象クラスに
するんではなくて、使う側のインスタンスで切り分ける方法が好みなので
AbstractFactoryもFactoryは一個のインタフェースとして作る事が多い。
理由は、クラス多くなるのメンドクセ。

結局デザパタ本は買わず、英語wikiの方でクラス図だけ見た。うむ・・・やっぱ大きく
間違ってなさそう。でもクラス構成は全然違った。FactoryがProductに具象クラスを
セットで渡せるメリットって何だろう・・・。自分自身投げた方がやっぱ作りやすいな。

カタログ化、ていう考えには全面的賛成。そうでもないと言葉通じないし。
そういう意味で、自分のやりかたは純粋なAbstractFactoryではなさそう。

最後になるけど、オブジェクト指向じゃない香具師し(ry

デザパタなんてのはいらんと思うけどな
プログラムなんて所詮組めるようになっちまえばそれでお仕舞いじゃん

仕様がわかればもう実装できる

プログラミング的にこれ以上のレベルって必要あんの？
正直、後は設計やらなにやらより対象分野の仕様をどんだけ理解するか？
って話になっていくだけでこんなの必要ないと思うんだけど？

で、対象仕様をまんまプログラムのクラスに反映できればそれでもういいよな
なんでクラスの設計にこんな技巧をこらそうとするのか謎でしょうがない＞デザパタ
だいたいこんなプログラムの設計・実装なんぞに時間かけたって

他の仕様決定・評価期間がアフォみたいに長いんだから実装期間を２分の１にしたって
プロジェクトにはなんの利益もねーんだよｗバーカｗ

学者さんは一生机の上で図でも表でも好きなの描いててくださいｗ

別にデザパタ使わないで上手くいっているんなら問題なくね？
>>644がここに来る理由こそ分からない。

でも、実装期間が２分の１になるんだったら・・・
『とても魅力的だと思わない？』

思わない？あぁ、頑張って稼いで下さいね。

>>644
＞他の仕様決定・評価期間がアフォみたいに長いんだから実装期間を２分の１にしたって
＞プロジェクトにはなんの利益もねーんだよｗ

残業代が稼げると言う事なら同意。

いままではどうやって作るかに重点が置かれていたけど、
デザパタやOOPって、PGを作った人以外が理解しやすい様に作るという領域に入ってると思う。

>>645
たしかに魅力はないな
開発はそんなに重要なファクターではないし

以前ほど汎用性だの開発速度だの問題にならなくなった
ていうか少なくとも設計でなんとかしようって動きはまったくなくなったな

プログラムの見積もり期間なんて決まらんと思ってたが
色々積みあがってくるとそういうのも相場が決まってくるもんなんだな

すげーきついって職場もかなり減ったように見えるっていうか派遣社員がいつかないんだろうなｗ
で外部から「いやー、お宅の環境厳しすぎなんすよｗみんなお宅は残業多すぎて嫌だって辞めちゃうでしょ？ハハハｗ」
なんていわれてきつい職場にはわざわざ人が集まらなくなったんだろうなｗ

続き(>>647)

そのせいもあってこんなの考えなくてもフツーに作ってフツーに開発してりゃ
わざわざ頭使わんでもフツーに開発が終わるようになってきたって背景もあるんだろうな
カタログ化して単調作業にしたかった奴もいたんだろうけど
中国もインドもわざわざ日本にきてもしょうがないぐらい経済押せ押せムードだから
植民地政策もやっぱり失敗なんだろうｗ多分ｗなんでカタログ化も単調作業化もそう望まれてることじゃないとｗ
もちろん、できるかどうかは別にしてねｗ

ということもあってか、学者諸君のプログラマー単調作業化計画は時代のタイミングもあってか失敗したように見えるね
バブルの頃にやった工場のラインとかは強引に単調作業にしたみたいだけど

プログラムは形のないものだからねぇ
俺等プログラマの中にもプログラムは組めなくても口先から産まれてきたような奴もいてか
なかなかライン化は進まなかったんだろうね。
工場の職人気質の人みたいにおとなしくしてるわけじゃないしねｗま、いいんだか悪いんだかｗ

ま、結果として、プログラマの単価は高いまま維持できてるのはいいことだ。
しばらく余計なことすんなよお前等。っていっても誰も必要としてないかｗ

まあなんていうか、「それ」が意味するところや意義を理解してもいない人間が
「それ」を否定するのは滑稽でしかないなw

デザパタというのは、あえて単純化すればコミュニケーションツールなのであって
テクノロジーではないのだが、そんなことも分かってないんだね。

昔偉い学者さんが、ソフトウェアの開発では人月の概念は成立しないといった。
必要なコミュニケーションの量が投入する人数に対して幾何級数的に増えてしまうからと。

デザパタっていうのはそのことに対する処方箋の一つなんだけどな。

そりゃ全員がデザパタに精通していれば
効果があることに同意するけど。
そうなるための処方箋はあるのかい？

結局さあ、デザパタとかそんなんは全部「基本」なんだよな。

逆にいえば、基本が理解できてない・実践できないレベルの奴らは
「仕事そのもの」ができてないわけ。気づいてないかも知れないけど。

たとえば「手続きの中では直接具象を扱わない」とかそういう基本な。

それが何の役に立つんだ？とかおこがましいと思えよ。まずは。

デザパタが基本？あの本が何部売れたと思っている？
プログラマの総人口を知っていて言っているのか？

プログラマの総人口なんて関係ないだろ
基本が出来ているプログラマは、平均的なプログラマより
かなり数が少ないと考えればよい

>>653
逆転の発想ﾜﾛｽｗ

デザインパターンは基本じゃないと思われる。
純粋にOO分析設計をつめていくと似たようなパターンってのが多々出てくるわけよ。
それを後から開発をする人が同じような局面で悩まなくて済むようにカタログ化しただけのもの。


正直この世界のPGって糞レベルばっかりだからそいつらにOOを理解しろって言うのはムリ。
OOを意識するのは設計する人と中心となるPGだけにするほうがいいよ。

でも、デザインパターンを理解することと、設計で実践することは別もんだと思うぞ。

確かに、積極的に実践するのは設計者と中心のＰＧだけでいいかもしれんけど、
その他大勢にも「理解」だけはしてもらわないと・・・結局パターンを外れた
まずいコ－ドが出来上がってしまう。「あ、こういうパターンでやってるのか」
「じゃあ俺の部分もそれに従わないと」って感じで分かって欲しい。
期待しすぎなんだろか。

そういうのって、パターンの知識というより、コードの読解力があれば
出来ることだと思うんだけど。

>>656
期待しすぎ。
具象から抽象を理解するのはその逆よりはるかに難しい。
貴方自身はそれが出来るのかな？

>>658
おいおい本気かw
それこそ（普通に人間にとっては）逆だよ。

例えば、抽象度の順番は
感情 ＞ 愛 ＞ 俺の「この」気持ち

になるが、普通人はより抽象度の低いもの、つまり右の方から順に左に向かって
学習していくもんだ。

脳内　＞　２次元　＞　３次元　＞　現実

>>659
ふーん。そうかぁ。本気なんだけどね。
自分は自分を基準に他者も同様だと考える錯誤をした？
抽象的なほうがわかりやすい自分は少数派なのかなぁ
もしかして・・・貴方は文科系？

　【オブジェクト指向】言語学習が先？概念学習が先？
　http://pc11.2ch.net/test/read.cgi/tech/1073714172/l50

表面上、ポインタを使わないサブルーチン間インターフェイスが上手に出来る仕組みが
クラスとか。

サブルーチン、メインルーチンの使いまわしを言語仕様にした継承とか。

その辺まで理解した。

カプセル化はモジュール指向で取り入れられた手法だからオブジェクト指向だけの物じゃない。

>>663
>その辺まで理解した。
ぇー

>>663
OOを学習するときには、既成の観念は害になるのでいったん捨てろ。

あんたがポインタやサブルーチンを学んだときのように
クラスや継承は、何度も使ってみて本質を見極めた方がいい。

C++周辺の言語の場合、継承元のメンバを再利用する為の継承するんじゃなくて、
継承して出来たオブジェクトを、継承元のオブジェクトを扱うメソッドで同様に扱うために
継承を行う

って事だけは理解した
他にコンポジションとか色々あるけど、
俺の場合どれもこれも方法論、手法としてしか覚えられないわ(本質なんてわからね)
やっぱオブジェクト指向ってどうやって理解すればいいんでしょうね

>>665
ポインタはアセンブラのアドレッシングの延長から覚え、
サブルーチンはBASICで学んだｗ

結局、最終的にニモニックになったらどうなるんだろう？
と考えてしまい、概念的な事は後回しになってしまうんだ。

既成の概念は邪魔なんだろうけど、OOの機能が標準装備ではない言語
との利点などを比べながら、動きを覚える段階だと思ってる。

最終的にどう動くのか？
Cで同じような処理を作ったらどうなるのか？
を考えてる。

OOPLを覚えるのは非OOPLの経験が無い人のほうが早い
との話を思い出させる話であるな

>>666
本質の何割かは理解してるんじゃない？
多態性は使っていくうちに便利さが実感できる。
自分が継承を使うときは親クラスのメソッドで
抽象メソッドを呼び出すとかはよく使うかな

>>666
どうやって理解すれば、ってことは現時点でOOを理解してないってことだろうけど、
その理解っていうのはどの水準の話なの？

わざわざクラス使うメリットが分からない、ってレベルなのか、
もうちょっと高次元の設計とかデザインパターンの意義がわからないってレベルなのか。

オブジェクト指向ってのがいろんな物、事を指すように思える。

デザパタを理解する事がOOPLを理解した事になるの？
よくわからんがしばらくはデザパタなんか勉強しない。

＞デザパタを理解する事がOOPLを理解した事になるの？

ならんが、学習の一助になる。それだけだ。

一助にもならないよ

個人的にはデザパタとOOPLが一緒になってはじめて、
OOPの嬉しさが実感できたことを白状しておこう。
それまでは馬鹿みたいに「CでもOOPできる」とか、
「非OOPLでもOOPできる」とか気軽に口走って喜んでたｗ
OOPの嬉しさも、OOPLのあり難さも良くわかってなかったｗ

オブジェクトが自身のクローンを作るメソッドって、
「クローナー」っていうの？

clone で良いんじゃね？

>675
Rubyではdupとcloneの２つが標準でObjectのメソッドだな。
通常使う分にはあんま変わらん程度だが、確か微妙に挙動が違う。

やはりどちらもシャローコピーである点では同じなんだ。

オブジェクト指向の諸原則(LSPとかOCPとか)も知らねぇような奴らがオブジェクト指向について語ってるのが一番の問題だと思う

俺は、オブジェクト指向の諸原則とデザインパターンの関係が理解できて初めてオブジェクト指向の基礎がわかったいえると思うんだか

とりあえず、オブジェクト指向とかデザインパターンとかがイマイチ分からないという奴には、
「デザインパターンとともに学ぶオブジェクト指向のこころ」
をお勧めしておく

今度はね、デザパタを理解できずにデザパタを叩くやつが出るんだよ。

OOとデザインパターンに何の関係が？

略語から正式名称が逆引きできない俺がいる。
リスコフの置換原則とオープン・クローズド原則か……

デザインパターン→デザパタで。

この二つで意味が変わるなんて変だとは思うが。

>>684
変わらん。
GoFの事なら「GoFの」と前置しとけ。

>685
すまんかった。

どうも会話中で広義のデザインパターンと狭義のデザインパターンがごっちゃになってて、
広義：デザインパターン
狭義：デザパタ
と勘違いしてしまった。

「コンストラクタはオブジェクトを生成するものである」ってたまに見かけるけど間違いだよね？

>>687
new Aなり、A.newなりで、オブジェクトが生成される時、
その初期化のために呼ばれるのがコンストラクタじゃね？

>>687　に便乗質問
コンストラクタを使わないでオブジェクト生成ってできるの？

JavaScriptのアレってコンストラクタと呼ぶのかな

>>689
>>688で答えが出てますよ。
コンストラクタはインスタンスの生成を行うのではなくて生成時に行いたい処理を記述する場所です。
一般にコンストラクタには戻り値の指定が無い事からも分かりますよね？

>>691
で、実際にコンストラクタの呼び出しを行わないでオブジェクトの生成ってどうやるの？

サイズ計ってallocじゃだめ？

>>692
デシリアライズとか
Java限定だけど

というか、何の必要があるのかわからん。
引数なしのスカのコンストラクタつくるんじゃあかんのん？

ああああああもう！小さい！小さいよお前ら！
何でそう用語の定義とか細かい実装テクに話が行っちゃうわけ？
そんなんじゃインドどころか中国朝鮮にすら負けるっつ-の！！

すまん誤爆した。

用語の定義や、細かい話題を軽視すると、
>>696のような人間になってしまうので注意。

>698-697

これは誤爆でつか

>>696
そうなんだよね
オブジェクト指向わからん奴って思考がすっげーミクロなんだよね
大まかに物事をとらえることができない

最近減ってきたけどなんか変なテンプレート挙げて
「これがオブジェクト指向です！」とかいいだす奴前はいたしねｗ
日本人だからなのかなんなのかわからんけど
公式でこうって表せるもんじゃないだけにこの辺の理解がすっげ困難らしいｗ

毎度毎度オブジェクト指向関連のスレみて初っ端の違和感は
レスをつける奴の思考の狭さ

ソースコードの一部分を指して「ここ！ここ！ここがオブジェクト指向です！」って
表せるもんじゃねぇってのｗ

まあ、楽しいからセイゼイあがけやｗって感じｗ

まあ、純粋科学や学問の世界ではそういう理屈もあるかもしれんが、
工学の世界は動いて何ぼだからな。
実装系の挙動はミクロの世界の話かもしれんけど、
マクロの話だけしてても、絵に描いた餅だしぃ。

>>701
それは概要がわかった上での話しだろ？
いままでそう概要部分（イメージ）で間違えるってことがなかったから
ミクロな部分を重視した勉強でよかっただけだろ

物事を理解するときに
「こんなイメージｗ」って部分を間違えてるとミクロな内容を
とりこんでも頓珍漢なことをやってしまう
それは大まかな概要がわかってないから

それがオブジェクト指向関連のスレ
なんかねｗわかってない奴がしつこく居座る傾向がある
逆にわかった奴は何故かしばらく寄り付かない傾向があるように思う

俺も昔は必死に説得を試みたけど、こればっかりはね・・・ｗ

Ｘとりこんでも
○とりくんでも

>>702
うそつけ
説得なんて見たこと無い

>>702
>「こんなイメージｗ」って部分を間違えてるとミクロな内容を
>とりこんでも頓珍漢なことをやってしまう

それでも、（合理的なコストで）動けば工学的には正しいでしょう。
実装は実際に動作させて、現実的な利益を得るためにあるのであって、
マクロな観点というのはそれを理論化して再現可能にするために存在するに過ぎない。

つまり、「マクロな理論とこういう点で食い違っている」なんて説得では
納得する人は少ないんでないかい。
マクロな理論を実現することが目的じゃないんだから。
つまり、オブジェクト指向は手段であって目的ではないわけ。

>>705
そうやって理解できないいいわけをごちゃごちゃ考えてるからいつまでたっても（ｒｙ

>>706
というか、君のその「理解」とやらは、何の役に立つの？

>>707
理解すればわかるよｗ

俺はオブジェクト指向をわかっている厨ﾃﾞﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!!!

( ´,_ゝ`)ﾌﾟッ

>>708
説得を試みたとかいってるけど、
その程度のことを言うことを「説得」と思ってるなら、
誰も納得しないのは当たり前では？

>>710
あー悪いね
「説得」はもうやってないんだ

なんというか、簡単に逆ギレするのは、ゆとり教育の弊害なのか。

>>711 逃げ( ´,_ゝ`)ﾌﾟッ

>>713
いいぜ、別にｗ
俺、お前がオブジェクト指向理解できなくても全然困んねーもんｗ

この程度のことでビビって逃げるようじゃだめだぞ。

今日は煽りに来ただけだしなｗ
昔、みたスレどうなってるかなｗと

まあ、よく見たら昔みたスレはこっちじゃなかったんだけどなｗ

privateの必要性がよう分からない

getter、setterでアクセスするなら同じだろ

アクセッサを介すんだから、そこで色々できるでしょ。
int getValue() {
return hoge && huga && hage ? _value : -1;
}
だとか。

>717
全部publicで書かれたコードを一度でも触れば、いかに糞かがわかる。

>>717
破滅の序曲を聞いたｗ
過去何人がそれで死んだことかｗ

まあ、体験するしかないと思う

class A
{
private:
　　　int hoge;

public:
　　　void SetHoge(int newHoge)
　　　{
　　　　　　if ( newHoge < 0 )
　　　　　　{
　　　　　　　　　hoge = 0;
　　　　　　} else if ( newHoge > 150 )
　　　　　　　　　hoge = 150;
　　　　　　}
　　　}
};

int main()
{
　　　A a;

　　　// a.hoge = 2000;
　　　a.SetHoge(2000);

　　　return 0;
}

　　　　　　if ( newHoge < 0 )
　　　　　　{
　　　　　　　　　hoge = 0;
　　　　　　} else if ( newHoge > 150 )
　　　　　　　　　hoge = 150;
　　　　　　} else {
　　　　　　　　　hoge = newHoge;
　　　　　　}

>>717
構造体を先に作って、ほとんど全てのメンバに getter/setter を書くようなら、メリットは少ないかもね。

これは逆で、クラスとしてのインターフェースを先に書いてから、実装に必要なメンバを追加していく。
それで getter/setter ばかりになっても、それは結果。

そうそう
この変数はこの関数を通してしかアクセスされませんよ
（する必要がありませんよ、した場合の動作は意図していませんよ・・・等）
って制限を与えることによってプログラムの構造を単純にするのが本当の役目なんだよな

メンバの変数全部にsetget作りまくるのはアフォ、なんもわかってない
クラスの仕様として外部からアクセスする必要がないことを明示的にするためのもんといった方がわかりやすいだろうか？
setだけのもんがあってもいいし、getだけのもんも当然ある

> メンバの変数全部にsetget作りまくるのはアフォ、なんもわかってない

クラスを、データの入れ物と機能とに完全に分離したがる人は多いけど
だいたいこのパターンだな

セッターなんて、いつ変更されても構わないものしか付けられないし
ゲッターでもオブジェクトとか配列の公開は、実質的に変更出来ることが多いので怖い

その「怖い」という発想が出てこないのが OOP に浸かった俺には不思議なんだ
本当に公開にできるフィールドなんて極々一部だと思うんだぜ

Hiroyuki = new Hiroyuki();

は、解るんですが、

Person someone = new Hiroyuki();

が、良くわかりません。
出来る、というのは解るんですが、これをやると何がどう得になるんでしょうか。

すいません。下の間違いです。。
Hiroyuki hiroyuki = new Hiroyuki();

#include <iostream>

class Person {
public:
　　　　virtual void SayName(void) const = 0;
};

class Hiroyuki : public Person {
public:
　　　　void SayName(void) const { std::cout << "My name is Hiroyuki" << std::endl; }
};

class Takumi : public Person {
public:
　　　　void SayName(void) const { std::cout << "My name is Takumi" << std::endl; }
};

int main() {
　　　　Person *p[2] = {0};
　　　　p[0] = new Hiroyuki;
　　　　p[1] = new Takumi;
　　　　for (int i = 0; i < 2; i++)
　　　　{
　　　　　　　　p[i]->SayName();
　　　　　　　　delete p[i];
　　　　}
　　　　return 0 ;
}

>>728
改行多すぎって怒れれたから変なフォーマットになってしまったけど、
注目すべきは　p[i]->SayName();。
実装されてないPersonのメンバ関数を使ってるけど、実行結果はこうなる。
My name is Hiroyuki
My name is Takumi

実際呼ばれているのはHiroyukiとTakumiのSayName()が呼ばれる。
異なるクラスのメンバ関数を同じ形で呼び出しているということ。
つまり、呼び出す側を共通化できる点が便利ってことかな。

>>730
レスありがとうございます。
説明で何となく解ったのですが、どんな場面で使うんでしょうか。
上の通り、と言われれば確かにそうだとは思うんですが、何となくまだ自分の中で理解が漠然としていまして。。

>>731
これはポリモーフィズムとか多態性と呼ばれている性質です。
わたしよりずっと説明の上手な人がいろいろ書かれているので、
Googleなどで検索して調べてみて下さい。

例えばこんなのはどうかな。コードの例がさっきはC++で、これのはJavaですが・・
http://itpro.nikkeibp.co.jp/article/lecture/20070131/260122/

例えば、読む負担が軽くなる。

List を派生させた AbstractList, ArrayList, LinkedList, Vector があったとき、
ArrayList arraylist = new AbstractList();などとする場合に比べ、
List list = new ArrayList();などとした場合は、
「具体的な実装について考えなくていいよ、
Listのことだけはともかくするよ」という読み方になる。
新しく何か定義したときも、
List list = new AtarasikuNanikaList();
これから下のソースは、以前Listとしてそのまま使える。

また、メソッドの引数で考えた時に、
void printList(LinkedList linkedlist)とした場合にくらべ、
void printList(List list)とした場合には、
obj.printList(new ArrayList())や、obj.printList(new Vector());
としても呼べる。

具体的な例を見つめながらプログラミングをするのは負担になる。
抽象化して、インタフェースに対してプログラミングできれば、
読む負担が減ったり、実装を入れ替えたりできてうれしい。

>>731
まあ、普通に考えてお前がよくわからんと思ったのと
同じように他の奴も思うわけだ

こういうソースの書き方が業務で使われてたのは俺はみたことないけどな

ソースは他人が読めてナンボだと思うぜ
もちろん読む側のスキルをある程度要求することもあるがな
てか、これはスキルっていうよりあらかじめ実装の対象物の構造が頭に入ってる奴で
かつ、こういう組み方を日常にしてる奴しかこのソースは読め無いと思うんだ

かなり読める人間を限定してしまうと思うぜ
実際この構造を知らずにこのソースの構造から対象物の構造を理解するって話になると
かなり困難だと思うのは俺だけだろうか？

>>731
うんこの色したボタンとちんこの色したボタンがある
どっちもボタンなんで動作は基本的に同じ。
これらのボタンをウインドウに配置するための
setButtonという関数があったとする
もし抽象クラスを用いないのなら

setButton(うんこボタン　button);
setButton(ちんこボタン button);

という二つのメソッドをつくらんとならないが、うんこボタンとちんこボタンがボタンという抽象クラスから継承されていれば

setButton(ボタン button);

というメソッドがあるだけで、

ボタン button1 = new うんこボタン();
ボタン button2 = new ちんこボタン();

setButton(button1); //OK
setButton(button2); //OK

となるだろ？
さらに、小島よしおボタンとかアサヒスーパードライボタンとか、ボタンの数がものすごい増えていったとき
オーバーロードで解決しようとすると、ボタンの種類の数だけ関数書かなきゃならんけど、
抽象クラスにしておけば、ボタンをうけとる関数を書くだけでOK
素敵じゃね？

クラスライブラリだと、ふつーに使われてるだろ?

SQL Server用の SqlConnection や SqlCommandをnewしてるけど、
ロジックはIDbConnection や、IDbCommandを使って組んで、ほかのDBになっても対応できるようにするとか。

>>736
一般的に普及されてて使い方に特に解説がいらないもんならそうだけどね
自分ライブラリで自分仕様のクラスまでそうやって作ってしまっていいのかどうなのかってのは判断できんな

仕様書書いてどこまで説明できるか？ってところじゃない？
ソースそのまま渡して理解はされないと思う

>>735
色は継承じゃなくてボタンの属性でよくね？　白いちんこの奴もいれば、黒光りしてる奴もいるだろうし。
うんこにしたって(以下自粛...

この場合属性でいいんだが、物のたとえだよ
それにしたってボタンの上をドラッグしまくるとだんだんおっきくなるボタンかもしれないし、調子が悪いと水みたいになるボタンかもしれないじゃん？

……まじめな話するとMFCデフォのボタンとオーナードローのボタンとか、ラジオボタンとチェックボックスとか、そういう意味での違いということでひとつお願いします

現実的な話をするとクラスをメンバの変数でもつようにしたほうが経験上うまくいく
ＭＦＣみたいに構造から継承使うように作ってあったらそれに従うしかないけどな

継承すると同名の関数のくせに別の動作をするもんが大量に派生することになる
どれを呼び出してどの関数を通っているのか把握するのがかなり困難になってしまうところも注意

継承は実装の手間が減るだけでそれほどいい技術じゃない
大規模になるほど使わないほうがうまくいく場合のほうが俺は多いと思う

それと別に継承を使うやり方だけに言えることじゃないけど
あんまり部品を使いまわすとその部品が不良品だったときの影響力はあまりにもでかい
その部品の信頼度とかも考慮して、この辺もよく考えたほうがいいところ

>>727
これはようするに抽象化とか一般化とかいうやつだ。
正方形は長方形の特殊なありかたで、長方形は四角形の特殊なあり方。
正方形より長方形、長方形よりも四角形の方が、より一般的とか抽象的とか言う。
Hiroyuki は Person の一部で、Person は Hiroyuki や Yakin らを一般化（抽象化）したもの。
そして、これらに応じて分類(classify)したものをクラスという。
同じ対象を捉えても、分類の仕方はいくつもある。だから設計は多様で、巧拙があり、より良い設計は困難である。

具体的な例が挙がっているので、それでわかるならそれでいい。

>>740
実装の手間が減るだけというのは、それこそ実装のための継承であって、本来オブジェクト指向のための継承じゃなくね？
継承の本質的な意味は特定の振る舞いを変えることであって、実装を使いまわすための技術ではないでしょ。
実装を継承するならprivate継承すればいい話で、しかしprivate継承するならコンポジットする(メンバ変数として持つ）方がいいに決まってる
結合度ぜんぜん違うからね。

上記のような意味で継承を否定するなら、それはそもそもオブジェクト指向にそぐわない設計/実装をしているし
そういう環境に身をおいているという意味で不幸だな。
MFCのように特定のイベントを継承して実装するモデルよりJavaのなんちょれリスナーを登録するとかC#のデレゲートでイベントを表すという
コンポジット志向のほうが優れてるが、それだって根底にあるのは継承であって、単純にメンバ変数として持ってるわけじゃない。
イベントっていう基底クラスの振る舞いを変えた何かを持たせるわけだろ。

抽象クラスの振る舞いを再定義するのは、動作は違えど、期待される振る舞いが実装されることが前提で、そのコードの詳細を読まなければプログラムがかけないというのは困った話。
こういう問題は、オペレータオーバーロードでも同じだし、getXとか書いてあるのにXをgetしてくるわけでもないメソッドとかと同じだよ

継承による影響範囲の話も同じで、重複したコードを無くそうと思ったらコンポジットでも構造化でもなんでも、どこかに切り分けるわけだが
それらが不良品だったときの影響範囲も大してかわらん。むしろ利点は不良品だったとき一箇所直せば全部直るというプログラムの基本に話は戻る。

>>742
影響範囲の話はリスク管理だろ？
投資で一点投資をしないで分散投資をするときの話と似ている

>>742
>実装の手間が減るだけというのは、それこそ実装のための継承であって、本来オブジェクト指向のための継承じゃなくね？
オブジェクト指向の継承って何を狙ってやるもんなの？
メンバ変数でもつ形じゃなくてわざわざ継承をしないと表現できないものってなに？

オブジェクト指向は「考え方」で、それを実装に適用したのが、
プログラミング言語が備えている継承機能（Java の exteds とか）。
でも、この「考え方」は上流工程のモデリングにも適用できる。

オブジェクト指向は目的でなくて手段

＞メンバ変数でもつ形じゃなくてわざわざ継承をしないと表現できないもの

７４５さんのおっしゃる通り（自分の勝手な解釈が入ってますが・・）、分析を踏まえて実装するわけですから、
継承すべきものは継承し、メンバ変数でもつべきものはメンバ変数でもてばいいのでは？
メンバ変数でもつべきものを継承したり、継承すべきものをメンバ変数でもつべきではないですね。
他にも、関連はメンバ変数（ポインタ）で持つべきものだし。

例えばFileクラスとExcelWorkBookクラスというのがあったとする。
FileがOpenしたり、Saveしたり、Closeしたりできる一般的なファイルをあらわすクラスなら、
ExcelWorkBookはFileを継承する。
一方、ExcelWorkBookに他のファイルを埋め込める機能があれば、埋め込むファイルをFileクラス型メンバ変数で持つ。
ExcelWorkBookが他のファイルとリンクや参照を貼る場合は、それらをFileクラス型ポインタメンバ変数として持つ。

>>746
で？なんか長いけど継承すべきものって？何？

age

>>747
継承はテンプレートメソッドパターンみたいに
サブクラスを実装させつつ型にはめたい場合に使うのがいいかも

>>746
実装時の話ならば好きなものをメンバにすればよい。
ただし、インターフェースが先に決まっているのなら。実装からインターフェースが導かれるのは逆。

あと、ExcelWorkBook が File を継承するってのはどうか。
File を引数に取るメソッドが ExcelWorkBook にあるとか、SerializedExcelWorkBook クラスがあるとか、そんなところでは。
リンクも File ではなくもっと抽象的なものだろう。

>>743
それはリスク管理でもなんでもない
似たようなコードを色々なところに分散して書くことがリスク管理になるのか？
ようするに基底クラスを変えると影響する範囲が大きいからテストがめんどくせーとかそういう話だろ
そりゃコピペ推奨しているようなもんじゃん。
たしかにコピペで似たようなものが大量にあれば、影響する範囲はそのコピペのうちの１つを使ってる部分だけになるが
他のコピペコードも潜在的にバグを内包しているわけであって、リスクを管理しているわけではなく、見てみぬふりをしているだけ。
いつ爆発するかもわからない爆弾を大量に抱え込んでるようなもんじゃん。
そいつはあんまりよろしくないと思うんだがな

>>744
継承使わなきゃ表現できないものは、後から拡張するとき。
標準入力から入力を受け付けて、それをファイルに出力するクラスがあったとして
入力をTCPやUDPからも受け取れるようにしたい場面に遭遇したとするじゃん
このクラスはもう安定動作しているので修正させないようにしたい場合、またはコンパイル後のバイナリでしか存在させず
そもそも修正できないようにする場合は、そのクラスの使い手側はメンバ変数に持たせることはできないよなそもそも。
だから、そのクラスはもともと外部から拡張できるような構造として設計/実装しておく必要がある。
だけど、そのクラスを作成するときは、いったいどんな入力が増えるのかわからない。
だったらどうするの？
って時は入力ストリームという抽象化されたメンバ変数を持っておいて、あとから入力ストリームを継承したなんらかの入力クラスを渡せるようにしておくようにする
ここには継承が使われているけど、これを継承を使わないでメンバ変数を保持する形でどう表すの？

コードが編集できる場合も同様で、ある特定の動作に対応させたいからとメンバ変数をもこもこ増やし、
そのメンバ変数を使うためのコードをクラスに追加しまくっていったら、馬鹿みたいにでかいクラスになって涙を流すことになる
だから継承とコンポジットをうまく使って正しくコンポーネントとして切り分けておくことが重要ですよ

>>751
前半の話はあくまで別の奴が
別の奴の作ったコード（つまり把握できてないコードを）をどこまで使いまわすかって話だぜ
１人の人間がよく知ったコードを使いまわす分には１つでいいんじゃね？

後半の話は後から拡張するときってのはおかしくね？
本来する形があるけどしょうがなく継承を使うっていう風に聞こえるけど
そんな都合で設計がかわってしまうのはおかしいと思うぜ

継承による拡張ポイントは、はじめから想定しておく必要がある
これ常識な

でも実際問題としてそれは難しい。
最初から無駄に投機的な継承構造とか作りこんでると、
逆ににっちもさっちも行かなくなる場合もある。

>>752
あくまで継承でしか表現できない、もしくは表現することが辛い場面の話な
継承は設計段階でするかしないかってのを決めるのが大前提だが744にレスるのに
そういうこといったって、絶対納得しないと思うんだよね
だから、継承でしかできなさそうな場面を上げてみただけ。
継承のほうが優れている場面てのは必ずしも拡張だけではないのは当然だよ

前半の話は、
「このクラスよくわかんないけどとりあえずそれっぽい動作しているから継承して俺カスタムにしてやれ」
と、そういうのを繰り返していると基底クラスのコードが変わったときに破滅するってパターンは確かに駄目だと思うよ
だけど、そういう使い方をするやつが馬鹿で、やっちゃだめな継承NO1だと思うだよね
元の投資の話からすれば、よくわからないけど似たような基底クラスが大量にあるから、リスク管理のためにその大量にある基底クラスからいくらか適当に選んで同じようなサブクラスをいっぱいつくって分散投資しといたほうがいいってことだろ？
それはどうかんがえても妙な話で、そもそもよくわからんクラス使うなってことにならんか？
よくわかってるけど不良品（バグ）があるって場合なら、そのバグを修正すればいいわけで、影響範囲がでかいほうが望ましいと思うんだけど。

>>755
後半の話は間違い
よくわからないものはそもそも使うなという話でサブクラス云々は関係ありませんでした

お前らこんなところで長文かいてる暇があったら書籍の一冊でも余分に読んだほうが身のためだ。
駄文練って悦に入っている間にも刻一刻と残りの寿命と人生の可能性が減り続けているんだぞ。

金稼ぎたいなら、能力つけて勝つしかないだろ。
能力無い奴はヒラでも管理職でも将来なんかないよ。

>754
そこで共通性・可変性分析ですよ。

>757
そんな757のお薦めの一冊を是非。

>>742
おまえさんの話は、一見もっともらしいんだが、
コーディングできねぇ奴の空理空論が一箇所見えている。

イベントクラスって、そもそも単なるデータクラスであって、
あれ自体がイベントを制御してるわけじゃねぇ、
ただハンドラークラスがイベントクラスを認識してるから、
イベントのバリエーションはイベントを実装継承/インタフェース継承しなきゃなんねぇ。
そんな低レベルなミスを犯すお前は口先野郎ケッテェだな

こんなとこまで出張して、初心者のあげあしとって喜んでんじゃねえよｗこのブタｗ

ろくなコーディング経験も無いままこんな所で講釈垂れてるのは、
初心者どころか

　　単なる　ネットソフィスト、ネット弁慶　の類い

でしょうね。

そんな身の程知らずな輩はズタボロの袋にされて当然かと。

きゅん萌えうぜ

↑まともな反論もできない
　ネット依存性人格荒廃者

お前馬鹿か？
イベントに何がくるかわかんねえからイベント自体を分離するための構造としてデレゲートやらなんちょれリスナーがあるんだろ？
インターフェイスだろうがデレゲートだろうがそれらを継承することは間違ってないしオブジェクト指向の考えにのっとってんだろ？
それすらしないでお前全部ifとかswitchで書けってーの？それこそ馬鹿の極みだと思うんだけど。
がんばった所で関数ポインタだろ。関数ポインタつったらデレゲートじゃん。
何のためにWIN32のメッセージディスパッチャがC#のWinFormでイベントベースになったと考えるの？
それのどこがコーディング経験も無いにつながるのかさっぱりわからん
そういうものは実際にはやくにたたないっていいたいの？
ようするにデレゲートもsignal/slotも関数オブジェクトも役にたたないっていいたいの？

>>765
横から突っ込むけど、オブジェクト指向と関係あんの？それ？
雑誌の記事に騙されて無い？

言語ってさ、いままで「制限」を付けることで進化してきたんだぜ
これから何かができるようになる進化は何かがおかしい

お前のしたいことって俺にはvoid*にしか見えないんだけど？
安全性の違いはわかるけど、じゃ、それがどれくらいっていうと大して違いがないように見える

設計が下手糞なのを汎用性の向上の問題にすり替えて逃げてるように見える

きゅん萌え自演スンナ
つかおまいら委譲イベントモデルって言葉しってっか？ｗ

なんだこの宗教論争

>>765-766
イベントクラスの継承と
イベントリスナーの話を整理して語る能力のない
キチガイ発見

>>765
郵便ポストの型の話と郵便物の型の話をゴッチャに語った挙げ句に
郵便ポスト内部に宛先別仕分け装置を付けろとかデムパ受信したり、
それは私設私書箱でいいはずだとか


どんだけ話が発散してるんだこのキチガイは


キチガイって、無様だな

どのイベントをひろってどれを捨てるか判断する主体が
ハンドラからリスナに移ったてことが要点なんだろ

キチガイ>>765は、まずは
イベントと
イベントリスナーが
別の存在である事を再確認して
>>742を書き直せ。


今のお前は言葉遣いもいい加減な認識のままデタラメをしゃべって、
大人に相手にされずヒステリーを起こしている、

言葉を覚えたての赤ん坊

みたいな微笑ましい存在でしかない。

>>771
キチガイよ
そんな10年も前に普及済みな知識でﾑｷになるなって

知識じゃねっつの文脈の話してんのコンテキストのよ
わかっか？きゅん萌え

キチガイさんにも判るように、アンタの話のデタラメさ加減を解説してやろう（なんて親切なんだ俺って

①> イベントっていう基底クラスの振る舞いを変えた何かを持たせるわけだろ。

何度も言っているが、イベントは単なるデータクラスであって、
振る舞いを持つのはハンドラー/リスナー側だ。


②> MFCのように特定のイベントを継承して実装するモデルより

それ、イベントの継承よりも、イベント「処理(＝リスナー、デレゲート)」の継承が本質だろ。
理由は①の解説を参照。


③>Javaのなんちょれリスナーを登録するとかC#のデレゲートでイベントを表すという
コンポジット志向のほうが優れてるが、
　　> それだって根底にあるのは継承であって、単純にメンバ変数として持ってるわけじゃない。

お前は継承とメンバ変数で議論をしたいようだが、
お前の言っている事例は「委譲」の事例だ。(この辺ものすごくど素人くせえ)

ついでに言うと、リスナーやデレゲートでイベント「処理」 を委譲し、
ついでにお前さんの認識外にある「イベントディスパッチャー」相当のクラスも独自実装すれば、
イベントの継承＝イベントの型継承などどーでもよくなる。
なぜなら、イベントが特定の型を継承する必要があるのは、
ライブラリに作りつけの「イベントディスパッチャー」相当のクラスが
特定の型しか認識しない(パラメータとして受け取れない)からだ。


このあたり、自分でシステム互換のイベント配送機構を独自実装してみれば、
話はよく判るはずだ。

自分で手を動かしもせず
ネット上の知識だけでいっぱしの論客を気取るデタラメ人間は
火達磨にされてもしょうがないと思った(ﾆﾔﾆﾔ

しょうもねえことで偉そうにしてるお前がまず死ねよ
きゅん萌え

文脈無視して、くだらねえあげあし取りに終始
建設的なことは一切いえずできずで、会社からお払い箱
それがお前だｗ

継承vsインスタンス変数論争でお前の出している例は、
委譲だよ委譲。全然筋違いの例だしてくるから議論が発散するんだよ。
議論の流れの異常さに気付かないお前は異常者そのものだ

>>776
だから、そんなの結果的に型を誤魔化したかっただけの話だろ？
void*でいいじゃん

>>780
キチガイに構うのやめとけ
あと、void*でいいじゃんって意味わからん
キティがいってるイベントって、リスナに送るパラメータのこと

↑典型的なバカ

>>780-781みたいなキチガイが
一流研究者にタメ口きいてくるのって
なんだか滑稽だな

>>1
あんた、知りたがり屋さんだねぇ

>>781
だからさ、その一連の仕組みまるごと説明すると
「型の誤魔化しをして見た目の設計がすっきりするため」のもんなのよ

そんなのなんのためにやってんの？アホ？って話を俺はしてるの

おまえの知能レベルには、MS-BASICがお似合いだ

>>784
OCPってしってっか？

少なくとも同じことをやるだけなら
void*で十分だね
初めの４バイトをＩＤにして後はＩＤごと決まったフォーマットにしておけば「ハイ、完成」
別にクラス弄ってヘンテコな設計して無理やり汎用性なんてつけなくていいよ

言語に型なんてなかった頃は全部ＩＤ＋ＸＸＸの組み合わせだろ

すきにしろとしか

OCP以前に抽象データ型もしらねえか

>>789
関係無し
ＩＤ＋ＸＸＸ
に勝るデータありませんからｗ

これは言語に型ができた理由を理解できない奴に反論は不可能だから面白い

キチガイ警報発令！

関数ポインターだとか、型を誤魔化すだとか、
キチガイの発言はつくづくセンスねえなあ

もおええわ
キチガイばっか

>>791
じゃあ、なんで型を誤魔化すコードを推奨してるの？
そんなもん一生懸命勉強してる奴まとめて馬鹿にしか見えない
雑誌の提灯記事に騙されてるんだよお前等

なんで言語に型ができたの？
どうしてお前等はそれをなんとか誤魔化そうと必死なの？

結論からいうと型を誤魔化して汎用性というやり方はそれ自体がＮＧなんだよ
言語は制限をつける形で進化してきたんだ
その進化の道筋を知らないで結果だけ見るから型が邪魔に思えるんだ
こと言語に関して「～ができるようになる」ってのはありえないって頭に叩き込んどけ

おまえ論点ブレ過ぎだわバーカ

そんなだから誰にもまともに相手にされないんだよ

キチガイ対決wktk

>>794
アレアレ？
反論できないの？
ボディに食らったパンチが足に来てるｗ

幼稚園生(>>793)が
勝手に創作した独自用語で一貫性のない主張を繰り返す痛いスレ

型をごまかしてるってのが良くわからないなあ
ちょっと具体的にコードで表現してみてよ

と煽ってみる

>>797
はぁ？俺はわけわからない言葉なんて使ったりしないもんねー
お前じゃあるまいしｗ
俺はいつでも誰にでもわかる言葉を使って話してるぜ
言い掛りはやめてくれよ
嘘吐き君♪

仕事のねぇ>>793は、
幼稚園レベルの議論で深夜も夜更かしする暇があって、
いいでちゅねぇ

おまぃらOOスレでも暴れてる２人だろ

♪印はキチガイコテのしるし

>>793のキチガイっぷりにwktk

>>798
じゃあ、その前に俺の質問に答えてくれるかな？

なんでさ、「イベント」を執拗に分離して汎用性を上げようとするのかな？

イベントとリスナーの区別すらついてない幼稚園生

>>801
違うぜ
俺は近年めっきり減ってしまったＯＯ原理主義者なんで
多分この板にも１人しかいないと思われる
ＯＯを理解できない馬鹿が書いた本が世に溢れる前なんで比較的マトモにＯＯが扱えるほうかと・・・
明らかにオブジェクトを扱って無いオブジェクト指向を信仰してるアフォが増えてて嘆いているｗ

わかれよｗ感覚でよｗｗｗ

幼稚園生だから、用語遣いがデタラメなのは赦してやれ(w

>>805
今の議論でそんな区別なくていいよね？
なんでそんなこと持ち出すの？馬鹿？

幼稚園生だから、用語遣いがデタラメなのは赦してやれ(w

>>809
おやおや？ｗあんまり悔しくて同じレスを連投ですかｗ

頭が馬鹿なやつほど
デタラメな用語使いをして
相手に意図が伝えられずにヒステリー起こすのなw

哀れ

はんどらかわとりすなかわで
じっそうするひとちがかったらどうする？
それともVB6まんせーってこと？

と煽ってみる

>>811-812
あれあれ？話題が違うところへいっちゃったよ？
本題では勝負にならないから違うところへ逃げて見た？ｗ
哀れーｗ

はんどらとりすながおなじやくめをするものだときっかない馬鹿

稀に見る名勝負だな

深夜に馬鹿議論するほど暇な
社会生活不適合者がただいま暴れておりますｗｗｗ

>>814-815
あれあれ？もしかして自分の常識も壊されちゃってレスで
煽って優位にたってるかのように見せないとプライドが保て無い？ｗ

>>816
オマエモナーｗ

もったいぶらねえで1レスで全部出し切れや
とっくに底の浅さは割れてんだこのド素人が

と煽ってみる

>>819
君はさっさと俺の質問に答えてよソース出してほしいんでしょｗ

どーでもいいべ

キチガイはさっさと頸動脈切って永眠しちまえよ

>>821
ならなんでレス付けるの？ｗぷぷぷｗ
必死にしがみついててミジメーｗ

明日朝は役員会で忙しいんで寝る

キチガイはさっさと首吊ってくれ。約束だよ。

キチガイバトルかみあってねーよ
なんとかしろ

>>824
君の用事なんて興味ないなぁーｗ
なんで理由を言ってから立ち去るのかなぁ？ｗ
別に聞いてもいないのに「役員会」とかさも自分がどこかの偉い人みたいに言っていくなんて悲しすぎるｗ
うきゃーｗｗｗおもしろいｗ

キチガイ常駐警報発令

キチガイ同士なかよくしろ

>>827
このageとsageがセットの人って１人でしょ？
なんで２人いるフリするの？ｗ
病気？ｗ
それとも本当にシンクロしてんの？きんもー☆

幼稚園生を納得させるには、幼稚園生と同じ目線で物事を語ってやればよい。
誰しもかつては幼稚園生だった時代があるだろうから、
その当時の思考形態を思い出すのは不可能ではない。


これに対して、キチガイを納得させるのは存外に難しい。
何故ならキチガイの思考論理など正常な社会人には知る由もないカオスであり、
無理に思考をトレースしたらこちらまでカオスに飲み込まれてしまう。
従って、キチガイが視線を合わせたり議論を挑んできたら
躊躇わずその場を立ち去る
…これが常識人の振る舞いというものです。


失敬

>>830
あー、で、本題へのレスはしないんだ？
やっぱできないからかな？ｗ
ま、賢明かな
これで負けちゃったらプライドズタズタだもんねぇｗ

↑キチガイ常駐警報発令中

動的言語の型管理と大差ないアイデアを自慢気に晒して、
言語に型など不要だと言い切るのは
まごうことなきキチガイ

>>833
はぁ？は？はぁ？
なにいってんの？
アイディア？
は？
なに？

全然話の主旨が違ーう
全然わかってなーい
日本語大丈夫？
あのレス見てそういうこというって相当頭悪いと思うよｗ

キチガイの断末魔をお送りしました。

>>835
話題に絡めないなら無理してレスつけなくていいんだよｗ

まだやってらキチ共

別にあなたにレスしてもらわなくてもいーんですよｗ

ちょっと叩き過ぎたか・・・ｗ

言語に型など一切要らないと断言するキチガイが
今週も誰にも相手にされずに
寂しがっておりますｗ

バカなんだから黙っときゃえぇーのに(ﾆｶﾞﾜﾗ

>>840
お前、全然人の話聞けないのなｗ
誰もそんなこと言ってないのに

このスレを昨日初めて発見。ちょっと気になる所にレスしとく。
リスコフ置換原則については>>344が正しくて>>345は間違い。
Base classを使って正しく動作する所にDerived classを持っていっても正しく動かなければならないって原則。

>>842
ただ、>>345みたいにやっとくと型が隠蔽できて幸せになれる。
これはLSPを少し発展させた考え。

意味不明なんだけど

リスコフ自身がLSPに関して振る舞いが変わらない置換可能な性質が望ましいって書いてるのに
それが間違いだってどういう理屈なんだよ

>>843
>型が隠蔽できて幸せになれる。

呼び出し側で、

>ガンダム.出す()

と記述した段階で、すでに型が露出してしまっているのでは？
型を隠蔽するというのは、呼び出し側では、

ロボット出す()

と記述しておいて、出るのはロボットかガンダムかわからないけれど、
ロボットにしか依存していない記述をしているから、
どちらがでても問題ない、ということでは？

その上で、戻される全ての具象クラスは、
ロボットクラスと同じ性質を備えるべきだ、というのが LSP なんでないの？

>>846
本当だ。
345を誤解してた。
LSPを発展させた考えってのは、
利用側には派生クラスの存在を隠蔽する
(可能ならアクセス不可にする)
って考えだ。
LSPについては、実は皆殆ど同じ事を言っているような…

>>845
>>345で>>344の定義が間違っていると主張しているので、両方正しいということはない。
両方間違っているという可能性ならあるが。

実際のプログラミングでは、最初から派生クラスがそろってるなんてことはないわけで、
戦争初期、ザクしかないころは、

class ムサイ {
　ザク ザク発進 {　・・・　｝
　void 戦闘準備() {
　　　・・・
　　　ザク 一番機 = ザク発進()；
　　　・・・

でよかったわけでしょう。
ところが、ザクとは違うグフが出てくると、MS という抽象クラスが必要になって、

class abstruct MS { ～ }
class ザク extens MS { ～ }
class グフ extens MS { ～ }

として、

class ムサイ {
　MS MS発進 {　　　・・・　｝
　class 戦闘準備() {
　　　・・・
　　　MS 一番機 = MS発進()；
　　　・・・

としなければならなくなる。
一度こうしておけば、

class ドム extens MS { ～ }

が出現したときは、ムサイクラスはそのまま書き換えずに使えると。

あかん、修正

×　class 戦闘準備() {
○　void 戦闘準備() {

ガンダムで喩えられてもさっぱりわかりませんｗ

ザクやグフしかでてこない文章を読んで、ガンダムの話だとわかるのにか？

いやムサイがなんだかわからんのだｗ

某Google にて・・・
　リスコフの置換原則 に一致する日本語のページ 約 380 件中 1 - 20 件目 (0.18 秒)
　ムサイ に一致する日本語のページ 約 209,000 件中 1 - 20 件目 (0.18 秒)

ガノタ死ね

オブジェクト指向っぽく書いてみたけど、
複数のクラスが最終的に1つのクラスに包含されちゃったんだけど・・・
で、最後に残ったクラスがGUIとグラフィックを受け持つクラスとやり取り
するプログラムになったんだけど、オブジェクト指向になってると思う？

ぶっちゃけ、MVCで作ると、コントローラはそんな感じになる。
しかし、データ構造を持つクラスは残るはずだが・・・。

おまいらの話はオーバーライドで解決。

Evaで例えて下さい＞＜

えーと、ざっと読み返してみたら、>>248が元凶の模様。>>248は間違い。
それと他の新しいSub Classを作る必要が出てきたから、メソッドを引き上げましょうとかいうのはLSPとは何の関係もありません。

>>859
だから、

class ゲンドウ {
　ユイ ユイちょっと来い {　・・・　｝
　void 準備() {
　　　・・・
　　　ユイ ユイ = ユイちょっと来い()；
　　　・・・

であるばあいに、

class レイ extends ユイ implements clonable ・・・・　{ }

とすれば、ユイちょっと来い()　が返すのがユイであろうとレイであろうと、
何番目だろうと、ゲンドウには問題ない・・・と。

綾波 extends リリスは魂を持っていてリリスの振る舞いを損なわない＝LSPを守っている
初号機 extends リリスは魂のない器でパイロットが必要＝LSPに違反している

エヴァヲタもうぜーということがわかった

LSPも理解できない低能が必死↑

>>861
そのクラス根本的におかしいだろ

クロエ、Twenty Fourでたとえてくれ、頼む

>>863
じゃあお前は何で例えればうざくないんだ？

class レイ extends リリス
{
　public void insert(ゲンドウ ゲンドウ) 　{
　}
}

class シンジ extends リリス
{
}

レイ レイ = new レイ();
シンジ シンジ = new シンジ();
レイ.insert(シンジ);

レイにinsert出来ません＞＜

ほんとエヴァオタってうざいなｗ

俺今OOの極意をつかんだかもしれん。
class リリス extends ゲンドウ {}
ほらね！

>>868
class レイ extends リリス
{
　public void insert(リリス ゲンドウ) 　{
　}
}

class シンジ extends リリス
{
}

レイ レイ = new レイ();
リリス シンジ = new シンジ();
レイ.insert(シンジ);

これでレイにインサート出来るよ！

なんだこの流れはｗ　どうしょうもねぇ。

> レイ.insert(シンジ);
どうみても、レイがinsertしています。本当にありg（ry

これはひどい

国内でオブジェクト指向の最高権威って今誰なんだろう？
そいつに聞くのがてっとり早そうだ。
前橋とか？

class ムサイ
｛
　private
MS ms[最大搭載数]
搭乗員　man「最大登場数」
パイロット　pailot[最大等乗数]
現在搭載数、現在乗員数、現在待機数
　自爆（）；
public
収容（MS)
　収容（搭乗員）
　収容（パイロット）
　発進（MS)
　降りる（搭乗員）
　降りる（パイロット）
｝
収容（MS）
｛
　ms[]=MS;
　if(もう無理==man.判断（ms[]）){
自爆（）
　｝
｝
判断（MS）
｛
　
　パイロット交換？
pailot.交代（ms[]）
　MS破損？
　　　man.修理（ms[]）
｝
どうよ？　クラスの作り方とか内部処理とか問題があるとこ指摘してください＞＜

モジュールって何？

>>876
>>877
うぜえ消えろ