1 :
憂鬱な名無しさん :
01/09/24 05:01 ・オブジェクト指向の有効性についての議論 ・オブジェクト指向についての疑問、応答 ・OOP言語、UML、分散オブジェクト、デザインパターン等 などなど、オブジェクト指向についてのスレッド。
OO のメリットってなんですか?
医師免許と同様、オブジェクト指向設計も、有資格者のみが行えるよう になるらしい。ウソ
4 :
憂鬱な名無しさん :01/09/24 05:35
>>2 ・プログラムの再利用がしやすい。
・変更が局所化されるので、仕様の拡張や変更に対応しやすい。
・プログラムの構造が把握しやすい。
・状態の管理に優れている。
とくに状態の管理という視点は関数型言語に対するアドバンテージだ
と思います。逆に関数型言語のOOに対するアドバンテージってなん
ですか?
関数型とOOはベクトルが違うので直接の比較は意味がないと思うなあ。
>>5 うむ、確かにベクトルが違うと比較は難しいな。
正反対の方向で進化したベクトルの双璧という感じがする。
しかし、どうしても比べたくなって来るのもまた事実。
>>4 >・プログラムの再利用がしやすい。
再利用できた事の方が少ないが・・。
8 :
デフォルトの名無しさん :01/09/24 05:51
なんつーか、胡散臭いんだよねー。 設計が上手くないと、てんで使い物にならないんだろ? それって実はオブジェクト指向自体に欠陥があるからじゃないか? 仕様変更に対応しやすいってのも疑問だな。設計を変える と根本から作り直しだろ。設計のやり方もわかりにくい。 ただ騒がれてるから信者が増えただけのような気がするんだよな。
構造化できれば十分です。
10 :
デフォルトの名無しさん :01/09/24 05:59
関数型って、Lispとかのこと? OOPだと、ポリモーフィズムができるけど、関数型でもできるの? それともまったく違った方法論なの?
>>10 Lispはそもそも変数に型が無いから、ポインタと言わず
変数に何でも代入できる。
Haskellは型がある関数型言語だけど、型クラスの
仕組みがポリモーフィズムに対応すると思う。
>設計が上手くないと、てんで使い物にならないんだろ? >設計を変えると根本から作り直しだろ。 OOがあってもなくても同じ。
13 :
デフォルトの名無しさん :01/09/24 06:05
>>8 うーん、その類の意見よく聞くけど
設計テキトーにやって何とかなる考え方ってプログラミングに限らずあるかなぁ・・・?
設計していく上で、うまくいく設計の指針みたいな物はやっぱり必要だと思うし。
OO詳しくないから結構テキトーに言ってるんだが、そんな気がする。
構造化が流行った時には、少なくともコーディングレベルでは あっというまに広まったけど、オブジェクト指向は、なかなか そうはならない。 オブジェクト指向って、一般ピープルにはむずかしすぎるんだよ。 オブジェクト指向、破綻説に一票。
構造化が広まったのはC言語の仕様のせい。 C++がグローバル変数とグローバル関数とパブリックなデータメンバを 使用できない言語仕様にしたらあっという間に広まっただろう。
構造化は無理すればBASICだろうが何だろうがある程度はできる。 やりやすい言語とやりにくい言語の違いはもちろんあるが、 かしこいプログラマであれば、ダイクストラが構造化を唱える以前から 無意識のうちに構造化していただろう。 でも、オブジェクト志向だとそうはいかない。 オブジェクト志向のほうが明らかにむずい。
>>15 >構造化が広まったのはC言語の仕様のせい。
それは違うだろ。
当時は、COBOLやFortranような言語でも、構造化の構文が
取り入れられたら、しっかり現場でも使われていた。
オブジェクト指向は、COBOLやFortranに取り入れられても
現場では広まらなかった。
本質的に難しいんだよ。オブジェクト指向は。
18 :
defaultの名無しさん :01/09/24 06:30
良くある風景 メソッドを整えても、俺しか使わない。 俺のクラスから派生などしない。 良く知りもしないクラスの関数を上書きするたび、 そのうち何かあるなと思う。
19 :
defaultの名無しさん :01/09/24 06:35
良くある風景2 構造化しないと、設計は無理。 オブジェクト指向だと、設計が面倒。
>>4 下の三つはわかるのですが、
OO だと再利用しやすくなるってのはなんででしょ?
あと2番目に挙げられていることは、要はカプセル化だと思うのですが、
それに関しては OOP言語でなくとも容易に出来ますよね。
> 逆に関数型言語のOOに対するアドバンテージってなんですか?
なんでしょうねぇ?
>>11 型クラスが無い ML でもポリモーフィズムと呼ばれるものはあるよね。
まあ、Haskell のほうが柔軟な気もするけど。
>>14 -17
構造化は思考の平淡化って感じだしね。
その点、OO は問題を分析して何かを抽出し、そこから基礎を築き
その上にプログラムを築くみたいな感じ(ちょっと謎)だもんなぁ。
>>20 なんでしょうねぇ?で、関数型の信者務まるのかよ。
OOPのライブラリを丸暗記して、 真っ平らに並べたプログラム書いて、(意味判らない人は該当) クラスは単なるサブルーチンに使ってるだけ。 でもってOOを理解したつもりになってるOOオタって多そう。
23 :
defaultの名無しさん :01/09/24 07:12
>>20 クラスライブラリ作るならまだしも、普通のアプリだとねぇ。
>>21 関数型言語が好きというだけで、
決して関数型言語への理解が深いわけではないのです。
スミマセンね、精進します。
>>20 OOにのっとって設計したら 使う分にはもう極楽だよ
再利用性もとても良い 自分で設計して極楽鳥〜
だけど設計と実装が地獄だyo
構造化なんてアセンブラもやってるよ。 つうかメモリにバラバラにデーター配置してたら何がなんだか 判らなくなる。
28 :
defaultの名無しさん :01/09/24 07:40
誤解が無いように補足すると、構造化はどの言語でも必須で、オブジェクト指向時にも当然使用するでしょう。 (構造化の階層を、クラスの派生で補えるわけもない。) 両者を対峙するものとして比較したのではなく、必然性で比較したのです。
>OOP言語を使っても再利用可能なClass・設計の蓄積が無い分, 従来の言語と生産性は変わらず, >むしろ不慣れな分だけ生産性が落ちるというのが現実です クラス資産命だもの>OO 言葉だけOOにしても無意味だyo
再利用性は一般にはない。 あるのは 1)データ操作や入出力の基本関係 2)同じ様な物を作ってる場合 だけ。 プログラムの内、アプリケーションの仕様依存部分が 特定のアプリケーション固有のものなら一般性はないから 再利用できない道理。
「A社の納めたアプリをちょっと変えてB社にも売った。」 というのはOOの再利用性とは違う。
プログラミングに限らずどんな分野でもそうだが、 良かれと思って新技術を導入したらかえって以前よりも生産性が落ちることは珍しくない。 難し過ぎて使いこなせる人が少なければ、 理屈の上では理想的な技術であったとしても邪魔なだけ。
難しいせいじゃないよ、 理屈自体が宣伝する為に作られただけだから。
34 :
デフォルトの名無しさん :01/09/24 08:24
オブジェクト指向って何ですか? まだプログラムについてよくわかってないのですが…… どんなものに使われているのかもわかりません できるかぎり詳しく教えて欲しいです。
36 :
デフォルトの名無しさん :01/09/24 08:48
>34 動作部分は軽く作ってあとから定義しろってことです。
違うと思う。
38 :
デフォルトの名無しさん :01/09/24 10:31
誰かオブジェクト指向をうまく説明できる奴はいないか? 説明してやれ。
39 :
デフォルトの名無しさん :01/09/24 11:33
設計がタコだとどうしようもないというか オブジェクト指向的アプローチからは手の出しようが無くなる よね。 どんな設計がタコでもちゃんと動いてる部品があれば、そいつ に手を加えず継承して後から再利用出来るようなOO言語というか 手法って確立出来ないかな windowsでいうサブクラス(メッセージフック)みたいにさ
40 :
デフォルトの名無しさん :01/09/24 12:40
>34 オプジェクト指向は、プログラムする時の考え方・方法論のひとつ。 構造化プログラミングでは、「どのように行うか」が中心だが、オブジェクト 指向では、「誰が行うか」を中心に考える。 ある機能を実現するプログラムを考えるとき、その機能を分担する「もの」 =オブジェクトを考えて、そのオブジェクトに仕事をさせるということ。 例えば、ボタンを押すとメッセージを表示するダイアログを作ろうとする と、機能中心で考えれば、一連の流れとして、「ボタンが押されるのを 見張っている」「ボタン押されたら、メッセージを表示する」「また、 ボタンを見張る」といった流れだと思うけど、 オブジェクト指向では、「メッセージを表示するのはボタン」「ボタンを 押すのはユーザー」と考えて、ボタンオブジェクトにメッセージ表示の 責任を持たせる、といった考え方をする。 換言すれば、機能中心で考えれば、ボタンはユーザーの入力を受け取るため の仕掛けに過ぎず、入力の受け取り、受け取った後の処理は、そのボタンを 見張っているコードが責任を持つけれど、 オブジェクト中心で考えれば、「押されたら何らかの行動をするボタン」を 作って、後はほっとく、という感じかな。 だから、ウインドウシステムのような、イベント駆動型のプログラムには適 している、というのはわかりやすいんじゃない。 もちろん、それだけじゃなくて、プログラム全般に有効なんだけど、その説明 は本でよんでね。
41 :
デフォルトの名無しさん :01/09/24 12:44
実際世の中にはMFCとか、クラスライブラリを ベースにしたソフトが死ぬ程出回ってるわけで 再利用性が高いことが証明されまくっていると思う。
42 :
デフォルトの名無しさん :01/09/24 14:45
>34 オブジェクト指向なんて無視して、僕が言うとおり 何かするオブジェクトを作ったら動作部分は軽く作っておいてあとから継承したオブジェクトで定義すればいいんです。それが有効に使える技です。 あとは秘密です。
MFCがオブジェクト指向かというと フレームの元になるから言いたくないけどさ クラスライブラリ=オブジェクト指向 じゃないかもしれないな という線で
>34 どうやって実装しているかそのクラスを使う人に見えてはいけません。 あくまでも、開発者の視点ではなく、ユーザーの視点でクラスのメソッド等を決めなくてはいけないです。
>>44 >どうやって実装しているかそのクラスを使う人に見えてはいけません。
Javaはそれやってるから糞言語なんだよねー。
見えてるというか「さあ見ろ!見ないと使えないぞ!」って構造。
ユーザーが使うクラスは Aだけなのに、使いたければ
継承元のクラスと、その継承元のクラスと、継承元のクラスと、継承元のクラスの
メソッド(メンバ関数)を参照してね。とかやってる。
SUNの設計者は単なるクラスヲタであってOOPの設計をしていないと思う。
>45 まともなクラスライブラリって例えば何?
汎用的なクラスライブラリってデカイ割に使えないよね。
今時なんでもかんでも CObject から派生してるやつとかね(藁
>>46 マシ、というのであれば、MFCの方がマシ。
>>46 BeOS の標準 IDE のクラスライブラリは使いやすかったなぁ
>>48 激しく同意。
別に全てのクラスが一つの基本クラスから派生してなきゃいけない理由
なんか無い。
52 :
デフォルトの名無しさん :01/09/24 15:50
>>49 それはあなたが MFC に慣れているというだけじゃ?
Java はけっこうコダワリ OOP という気がする。
OOP という話なら、MFC は糞。
53 :
デフォルトの名無しさん :01/09/24 15:54
もはやアレだけど Metrowerks の PowerPlant はけっこう良いです。 そこかしこにこっそりデザインパターンもちりばめられている。 BeOS のそれとも似ているかも。
>別に全てのクラスが一つの基本クラスから派生してなきゃいけない理由 >なんか無い。 んなこたない。 言語仕様として基本クラスのないOOPLなんてC++くらいだよ。
55 :
デフォルトの名無しさん :01/09/24 16:01
MFCやったことないけど、CObjectて何??全てはMFCのクラスだから基本のCObjectから派生するの?
>言語仕様として基本クラスのないOOPLなんてC++くらいだよ。 C++ 自体は君が思っているほど OOP べったりな言語ではない。 それに静的な言語と動的な言語をごっちゃにするのもどうかと思ふ。
57 :
デフォルトの名無しさん :01/09/24 16:07
>>56 >C++ 自体は君が思っているほど OOP べったりな言語ではない。
そんなことは百も承知だがここはOOPスレだろ(藁
それに今時の言語は動的・静的の区別は
かなりあいまいになってきてるから
ごっちゃにしないのもどうかと思ふ。
>>52 MFCのSerializeとJavaのSerializableの説明の比較をしてみよ。
MFCの方はそれ読んだだけで組めるけど、(MSDN)
Javaの方はあの説明だけでは(APIドキュメント)
「結局自分で実装するのか?」(説明文が糞)
「どうやって実装するのか」(他のクラスの事だから?触れていない)
さっぱり判らんぞ。
>>57 生意気言ってすみませんでした。
よくわかんないんで、どのへんがあいまいになってるのか教えて下さい。
>>54 クラス原理主義者発見!
Object基本クラスなぞOOとは関係無いぞ!
>>54 じゃあStringの基本クラスにCharクラス持ってきて使ってね 藁
>>58 それじゃ設計じゃなくてドキュメントの問題じゃん。
64 :
デフォルトの名無しさん :01/09/24 16:28
結局、オブジェクト指向という思想は無視して、現実的で美味そうなところだけピックアップして使えってことだろ。
65 :
デフォルトの名無しさん :01/09/24 16:34
>>64 >>オブジェクト指向という思想
について解説お願い。無視するかどうか、知ってから考えたいので。
66 :
デフォルトの名無しさん :01/09/24 16:45
原子力発電は危険なので色々議論がかわされるが、いちいち危険なんか気にしてられないのでどんどん原子力使えってことです。
原子力発電は危険な面もあるので議論の対象となっているが、 作られた電気に区別はなく、利用者には区別のしようもないという事では?
原子力発電は危険なので色々議論がかわされるが、いちいち危険なんか気にしてられないのでどんどん原子力使って電気取ることだけ考えろってことです。
>>65 オブジェクトからオブジェクトにデーター渡すだけで必要な
プログラム動作が得られるような構造。
例:テキストエディタが作りたければ
KeyBoardObject →データ→ DisplayObject
でエディタが完成する様に両方のオブジェクトをつくればいい。
DisplayObjectは他の入力(ムービーファイルやマウスドロップ)
にも対応す汎用性を持っていなくてはいけない。
にも対応す汎用性を持っていなくてはいけない。 × にも対応する汎用性を持っていたほうがいい。 ○
>オブジェクトからオブジェクトにデーター渡すだけで OOP的にはそうだがOO的には「オブジェクトにメッセージを送ることで」 この概念のレベルと実装のレベルがごっちゃにされやすい。
↑ ...
>67 いや。
あーう「メッセージ」。 出ましたか。 出ましたね。 信者登場ですね。
設計レベルでストリーミングデータやファイルデーターを 「メッセージ」と呼ぶ奴いたら病気。
その心は。
>>66 +67+68
「原子力発電」=オブジェクト指向テクニック、「議論」=思想、という
ことですか。
思想はいらないから、テクニックはどんどん使えということ。つまり、
OOPしろということですね。了解。
>>69 レスありがとうです。
今いち理解が及びませんが、勉強してみます。
一般のOOの解説ではメッセージの他にデーターの流れの説明してるのかな? メッセージしか書いていないんじゃない?
>>74 OO信者だけど何か?
分析・設計段階ではメッセージでいいじゃん。
でもまあ、データ中心なプログラムとは相性が良くないね。
そういうのにはDFDでも使うべし。
OO否定してるのは、OOがよく理解できない馬鹿だろ。 理解できなかったら上手く使えるわけも無い。 そういうやつがOO使えるやつを批判して、OO使うなという。 なんのことはない、OO使えるやつの足を引っ張ってるんだよ。 OO否定するやつは世間に迷惑かけてる害虫なんだよ。
81 :
java厨房 :01/09/24 17:29
>>71 ,75
メッセージは、オブジェクトのメソッドの呼び出しでしょ。
データ自体がメッセージなの?
>>81 データを包んだオブジェクトの参照がメッセージに乗って運ばれる。
84 :
デフォルトの名無しさん :01/09/24 17:51
オブジェクト指向の話題==揚げ足取り量産
OOのクラス図って何だ? UMLの分析段階でのクラス図をDFD代わりに使うってのなら分かるが。
86 :
デフォルトの名無しさん :01/09/24 17:53
>>85 クラス間の継承関係と委譲関係を図にしたものじゃない?
OOPプログラムの仕様書に、それが無いと困ると思うが。
あ、MULのクラス図の間違い。
なるほど。そういう流儀のクラス図なのか。 図というとUMLしか思い浮かばなかった。見聞が狭くてすまん。
すいません。OOとOOPってどう違うんですか?
OOPはオブジェクト指向言語 OOはオブジェクト指向概念。 OOPはOOを元に作られた、という体裁を取っているけど、 本当はOOはOOPの後から適当に作られたインチキ概念。 物理学でいうところの原理に相当するものが欲しかったんだろうね。
91 :
デフォルトの名無しさん :01/09/24 18:14
>>90 レスありがとうございました。違いはよくわかりました。
構造体が便利だから操作する関数も一緒に構造体にぶち込んだら
クラスができました!(・∀・)って感じですか?
違うでしょうね(^_^; すいません。
構造体にも関数定義できるよ
関数ポインタテーブル領域が最低限必要>92 C++なら不要であれば自動削除される
>>90 OO はオブジェクト指向
OOP はオブジェクト指向プログラミング
OOPL がオブジェクト指向言語
じゃないの?
96 :
デフォルトの名無しさん :01/09/25 03:55
97 :
defaultの名無しさん :01/09/25 04:06
実際に設計してみれば、矛盾に気づくと思う。 継承重視で設計すれば、メンテナンスが楽? 仕様変更があったら、ソース変更した方が早いでしょ。 そもそも、オーバーライドだけじゃ対応できないし。 プログラムがわかりにくくなるだけ。 オブジェクト単位なら、汎用性がある? 共通サブでもないアプリに、汎用性は必要ない。 インターフェイス増やして、工数がかさむだけ。 クラスライブラリの場合、派生させて使用するのが前提だし、 汎用性が必要なのも当然。 しかしアプリの場合、そんな必要は元々無い。
98 :
デフォルトの名無しさん :01/09/25 04:18
>>97 仕様変更のときに普通にソース変更なんかやっていては、あちこちに
変更の影響が波及してバグが発生しやすくなるし、大変だよ。
オーバーライドで対応できないのはもともと分析が悪いか、根本的に大
きすぎる仕様変更があった場合だけで、別にオブジェクト指向が悪い
わけじゃない。
それに、オブジェクト指向分析は何も難しいことじゃなく、現実を
そっくりそのままシミュレーションするように考えればいいだけ。
逆にオブジェクト指向を使わないほうが、指針が無いだけにかえって
安心感が無いな。
アプリに汎用性が必要ないってのもおかしな議論で、万が一に備えて
万全を期すのがいいに決まってる。
99 :
デフォルトの名無しさん :01/09/25 04:25
オブジェクト指向の最大の弱点は、他人が保守する時に その他人もオブジェクト指向の教養が無いと駄目なこと。 その意味で汎用性が無くなる。
仕様変更なんて当たり前。 ゆえにOOは机上の空論。 汎用性のあるアプリなんか作ってるのは安易な仕事やってるだけ。
101 :
デフォルトの名無しさん :01/09/25 04:27
ひゃく ああ、まったく、どいつもこいつもお手軽症候群だ。
(T_T)
じゃあ、株価チャートの表示分析アプリと給与計算アプリで 再利用できるクラスを挙げてくれ。w
>>100 意味がわからん。その当たり前の仕様変更に対応しやすいのが
オブジェクト指向。
そのために汎用性のあるコードを書くのは当然。
設計段階では汎用になるはずだったコードなら書けるけどね。 無理無理。空論空論。
個々のアプリに汎用性があってもしゃーないやろ? でも汎用性たっぷりのMFCとかのクラスライブラリを ベースに(つまり再利用しまくって)作っとるでしょ?みんな。
108 :
デフォルトの名無しさん :01/09/25 04:33
>>106 根拠が抜け落ちてます。もうちょっと詳しく説明してくれないかな?
>>105 自社の給与計算に決まってるのに、請負いで他社の給与計算するの?
社員クラスと株価関係ないじゃん。
110 :
defaultの名無しさん :01/09/25 04:34
オブジェクト指向の分析は、現実の世界に即していない。 (継承と再利用に関わる部分。) OOP独自の考え方が必要だと感じる。
>>107 だから、ここでアプリに汎用性があるという言われ方してるのは
アプリに使われてるコードに汎用性があるってことだろ?
この板的にユーザーの視点じゃないだろうし。
OO礼賛してるのって、只のライブラリ厨が多い。
>>107 そんでもって、いつも使う社内用なり個人用なりの
クラスライブラリみたいなの持ってるでしょ?
再利用できとるやん。
>>109 株価チャートと給与計算は独立した二つのアプリじゃないのか?
何が言いたいのかわからん。
まさか、全く違う用途の二つのアプリで共通に使うクラスを
作れってことか?
それが作れないからって汎用性が無い等と言い出すのは
無理矢理な議論だな。
>>110 >オブジェクト指向の分析は、現実の世界に即していない。
あたりまえ。
現実のレベルよりもっと抽象的なレベルで考えるだろ?
持ってないよ。 一般に使いまわしできないもん。 Cのファイル分けだと出来たけどね。
118 :
デフォルトの名無しさん :01/09/25 04:39
OOは先人が作ったデザインパターンを使えるのも大きいよ。 先人の知恵が労せず使える。
121 :
デフォルトの名無しさん :01/09/25 04:41
給与計算アプリで社員クラスがあれば、ある社員が昇進しても その社員オブジェクトが所属する地位を変えるだけで簡単に 対応できる。 汎用性あるじゃん。
>>121 激しく勘違い。
これがOO厨の正体か?
123 :
デフォルトの名無しさん :01/09/25 04:44
ていうか、OO否定派は何が言いたいのかわからん。
124 :
defaultの名無しさん :01/09/25 04:46
結局のところOOPの効用とは、 カプセル化記述の美化と、派生と上書きによる クラスライブラリのカスタマイズである。 クラスライブラリを作るような気持ちでアプリを作ると、 とんでもないことになる。
まあ。クラス礼賛してる奴はそれまで再利用性のあるプログラム 書けなかった人だろうね。 クラス導入で言語の助けを得て初めて再利用できるようになって 感激しているというところか。
126 :
デフォルトの名無しさん :01/09/25 04:47
>>124 クラスライブラリを作るつもりでアプリ作るのがOOPなのか?
Javaだと全然カプセルに見えませんが何か?
>>125 で、オブジェクト指向の欠点とは何でしょう?
>>125 じゃあ、あんたは普段再利用性の高いコードを書くために
どういった手法を使っている?
133 :
デフォルトの名無しさん :01/09/25 04:55
>>118 そして、デザインパターンを知らない他人がソースを
保守できなくなる。
135 :
defaultの名無しさん :01/09/25 04:57
>>126 OOPの概念の多くを、アプリに持ち込まない方がいいのではという意味。
クラスライブラリから派生させて使ってる程度が、ちょうどいい。
>>134 それは、Cを知らない他人がCのソースを
保守できないのと同じことではないんですか?
>>136 Cとデザインパターンでは、使えるまでに必要な知識量が全然違う。
>>134 ようはあれか?
少年野球チームに突然西武の松坂が助っ人に現れて全力投球したのはいいが、
キャッチャーがボールをとれなくて負けてしまったって状況と同じ状況か?
>>138 たとえ C で OOP の概念をつかわずに書いてあったとしても、
そのシステム特有の概念(というかアーキテクチャ)を
理解しなければ保守できないんじゃないの?
で、デザインパターンなんかは、そういったアーキテクチャを
体系づけて再利用しようとするものでしょ?
143 :
デフォルトの名無しさん :01/09/25 05:08
>クラスライブラリを作るつもりでアプリ作るのがOOPなのか? 俺の認識なんだけど、違うと思う。一過性のアプリならOOじゃなくても なんでもいい(らしい)。ただいろいろ作ってきて、構造が見えてきて かつ、使いまわす時点になったら、OOで構造を抽出して再利用を考えて 組むと後の生産性が上がる。 構造を見誤ればぐちゃぐちゃになる。OOは難しいよ。 でも使わないわけにはいかない。
>>141 でもデザインパターンまでにたどり着くには、
C(もしくはJavaなど)やそのアーキテクチャは
必須でしょ。
その後、さらにC++やOOの知識などが必要になる
から、やっぱり保守要員は確保しづらくなる。
>C(もしくはJavaなど)やそのアーキテクチャは じゃなくって、作ったり保守する対象のシステムね
オブジェクト指向は状態を管理する方法の1つの答え 状態の管理…俗っぽく言うと、変数の値の変化の管理 状態の変化をすべて監視・制御できるなら、すべてグローバル変数でよろしい しかし、大規模になれば、または多人数で作るなら さすがにその取り扱いは厳しくなってくる そこで生まれたのが、OOの考え方 しかし、不完全である …こういう意見が、一般的なのはわかるけど じゃあ、何が不完全かっていうのが分からない おそらく、理想系が想像できないから、比べられないためであろう 答えを教えてちょうだい>OOな方々
おしまいですかね(笑
ドキュンな社内で使うな。 個人の趣味に使え。
149 :
デフォルトの名無しさん :01/09/25 05:27
これで双方納得 安らかに眠れるNE!
OOPの話ばかりだね。 OOAとOODはどうした?こちらにOOの優位性があるのではないのか?
あたしもう寝るね。 おやすみなさい☆
>>143 状態はオマケ。
データーフローが入ってない。
>>146 ソフトウェアの開発にオブジェクトというメタファーを導入するのがオブジェクト指向。
オブジェクトにメッセージを送ると何らかの仕事をしてくれる、
このオブジェクト間のメッセージ通信でソフトウェアを構成するというモデル。
オブジェクトという単位を持ち出したことで、
処理の責務をソフトウェアの対象ドメインに由来させることができるわけ。
業務の概念とプログラムの概念を近づけることで、開発をしやすくしようというのが狙い。
例えば売上伝票のデータを整形するモジュールを作るとして、
伝票オブジェクトがあってプロパティを設定するのと、
denpyou_format関数にパラメータを渡すのとでは、
前者の方が分かりやすいはず。
(例がおかしいけどつっこまないで…)
クラスレベルでの再利用が難しいのは JavaBeans の何たらプロジェクトの失敗で明らか。
業務は業務によって激しくロジックが異なるので再利用を見越して作るのは至難。
今さかんなのは設計レベルでの概念の再利用/共有化。
つまりアーキテクチャパターンやデザインパターンなどのパターン技術というわけ。
>>8 オブジェクト指向は、再利用しやすい、設計がいい、仕様変更に耐えるものではないのです。
再利用しやすい、設計がいい、仕様変更に耐えるもに、「あなたが努力する」道を提供する技術なのです。
157 :
デフォルトの名無しさん :01/09/25 06:39
158 :
デフォルトの名無しさん :01/09/25 08:48
こっちの話の方向が面白いと思うのだが? ----------------------------------------------------- 39 名前:デフォルトの名無しさん 投稿日:01/09/24 11:33 設計がタコだとどうしようもないというか オブジェクト指向的アプローチからは手の出しようが無くなる よね。 どんな設計がタコでもちゃんと動いてる部品があれば、そいつ に手を加えず継承して後から再利用出来るようなOO言語というか 手法って確立出来ないかな windowsでいうサブクラス(メッセージフック)みたいにさ ----------------------------------------------------- たしかに、親クラスに手を加えだしたらオブジェクト指向的とは言えないような感じがするよね でもMFCやVCLだってクラスライブラリがバージョンアップしてるし
>>154 データはオブジェクトの属性でしかないと思うのだがどうよ。
データの流れを軽視しているという意味じゃなくて、
データが重要だからこそ、オブジェクトに責任を持って管理してもらうのだよ。
だからオブジェクトの振る舞いが主役になる。
例えば図書館があったとして、書籍の貸し出し記録というデータがあるとする。 来館者が自ら記録するようにし、記入漏れがないように来館者を教育するのが構造化。 誰がどういうときに記録するのか、データフローなどで管理する。 来館者は楽だけど、時々貸し出し記録が狂って本が無くなるので、 常により厳密な管理が求められる。 貸し出し窓口を設けて、窓口に問い合わせて書籍を借りるのがオブジェクト指向。 書籍の貸し出し記録へのアクセスは窓口の担当者のみがアクセスできる。 貸し出し記録は万全だけど、来館者は書籍へのアクセスを面倒だと感じる。
オブジェクト単体ではオブジェクト指向できないと思われ。 せめて二個ないと・・。
162 :
デフォルトの名無しさん :01/09/26 00:04
>>155 >>160 どちらの例もOOを有利に見せかけるためにでっち上げられたような気がする。
あと手続き(関数の中身というかアルゴリズム)をどうでもいいことのように
扱ってるOO本が多いような気がする。分析の際に言語考えるななんて無理。
オブジェクト指向の利点ってのは、図書館で言うなら 利用者が図書館のどこに目的の本があるか知らなくても 館員に持ってこさせれば済む、ってことじゃないのか。
>>162 OOを使うと有利な場合には大いに使いましょうというだけ。
メソッドの中身をどう実装するかはそれほど重要でないのは確かだね。
設計したインターフェイス道理になっているかが重要。
リファクタリング本を読むと目から鱗かも。
叩かれそうなこと発言するが良い? って、悪いって言われても言うけど(ぉ 過去の自分を振り返ってみて、VisualBasicって かなり隠蔽がうまくいってるケースだと思うな。 自分でクラス(?)を変更できないのがイタイけど。 っていうか、もう使ってねーし>VB
166 :
java厨房 :01/09/26 01:13
非OO派の皆様へ。 言語は何を主に使用されていますか。 小生、java厨房なので、OOしないと非効率的なのですが。
167 :
VBエキスパート :01/09/26 01:21
VBですがなにか? OOなんて下水道みたいなもので、必要ではあるけど 普通の人はわざわざ関わらないものなのです。 汚水の処理は汚水に適した人間がやればよいのです。
VB=汚水 OO=オアシス
170 :
デフォルトの名無しさん :01/09/26 01:30
プログラムかけないやつがOO分析ってありなの?
171 :
デフォルトの名無しさん :01/09/26 01:33
オブジェクト指向の考え方はありだと思うけど、 ただの構造体に関数が引っ付いたようなものの癖に メソッドとかメッセージやり取りとかインターフェイスとか 偉そうなカタカナを使うのがむかつくのは俺だけか。
>>170 そういうことしてる奴を見かけたら
可及的すみやかに殺して刻んで海に捨てましょう。
しかし分析段階では実装は気にしないんでしょ? だったらプログラム書けなくてもいいのでは?
そもそもプログラムかけないやつが、分析できるだけの知識を持ってる わけ無いだろ。プログラムできないやつが分析しようと思うことなんて ないだろ。 原理的には可能かもしれないが、分析が上手く行ったかどうか自分で 体験できないから著しく不利。
176 :
デフォルトの名無しさん :01/09/26 01:43
OOPは既に「構造化よりは後、汎用プログラミングよりは前」つー意識なんだが…。 プロパティとメソッドで全て、の時代は終わってるんじゃないか? もちろんOOの概念は汎用プログラミングのベースとして重要なんだけどさ。
>>176 汎用プログラミングって何ですか?
教えてください。
178 :
defaultの名無しさん :01/09/26 01:57
>>174 理論的にはその通り。しかし現実的ではない。
179 :
デフォ@146 :01/09/26 02:31
なんとなく、テキト〜に思いを巡らせてみたんだけど 以下の考え方に間違いがあったら指摘してちょうだい>OOに詳しい人 オブジェクト 任意の責任のもとにまとめられた状態と振る舞いの集まり 振る舞いは状態の変化とともに行動が変わる オブジェクト間に許された行為は、ただ通信のみ クラス オブジェクトの記述方法の1つで、オブジェクトの静的側面を示す クラスを用いなくても、オブジェクトの構築方法はある 主に、振る舞いの制御に威力を発揮 で、オブジェクトの「責任」「状態」「振る舞い」の 3つのどれを中心に考えるかで、分析・設計方法が変わる と思ってみたけど、あんま自身ないな… しかし、「ただ通信のみ」ってところで、自分で書いててなんだが カイジの8巻を思い出したw
180 :
デフォルトの名無しさん :01/09/26 02:36
>>177 かなり自信無いんで、外してたらすまぬ。
全然違うオブジェクトにも、同じ操作が部分的に適用できることは多い。
ってことで、汎用性のある操作はオブジェクトから独立させて、複数の操作を効果的に組み合わせることも意識するような感じだろうか。
操作そのものをオブジェクトにしちゃった関数オブジェクトの概念もかなり重要。
ベースはOOだから、汎用性の無い操作はメソッドとして隠蔽するけど、その枠に無い操作も多い。例えば比較とかソートとか。
純粋OOにこだわったら、例えば高速なソートを自前で起こしても、それを文字列中の文字のソートとかに使うにはクラス定義の変更が伴う訳で。
C++で例を挙げると、
MySort ( coll.begin(), coll.end(), less<string>() );
みたいなコードが、collが配列でもリンクリストでもファイルでもとにかく呼べる、と。
OOの枠からは外れるけど、実際に楽だし、素直に納得の行くパラダイムだと思う。
で、
MySort ( coll.begin(), coll.end(), greater<string>() );
とすれば逆順になり、
MySort ( coll.begin(), coll.end(), less_ignore_case<string>() );
とかだと大文字小文字無視になる、という感じで。
さらに、数値の入ってるコンテナなら
MySort ( coll.begin(), coll.end(), less<int>() );
とか。
あと、上記の例くらいなら、Cでごりごり書くのと速度もメモリ消費も同じにできるのもポイント。
まだ自分でもこなれてない手法なんで、いろいろ甘いのは勘弁。
C++だとコード部分のメモリ消費が大きくなりがち、ってのはあるな…。
184 :
デフォルトの名無しさん :01/09/26 03:00
あ〜、汎用プログラミングってジェネリック・プログラミングのことか。 「共通プログラミング」なんて訳してる本もありますよね。 ちなみに、構造化〜、オブジェクト指向〜、ジェネリック〜は どれが上、どれが下というもんでもないし、 それぞれ相反するものではないと思いますよ。
185 :
defaultの名無しさん :01/09/26 03:14
プログラムAは、オブジェクトabcdeから出来ています。 新たにプログラムBを開発するときは、aeを流用し、 bを継承してb’を作り、ab’efgとなり、 新規開発はfgだけで済みました。 更にプログラムCを開発するときは、ac’fとなり、 プログラムを良く知らない新入社員でも、 開発できてしまいました。 プログラム資産を蓄積すれば、大抵のアプリケーションは、 既存のオブジェクトの組み合わせと、 継承によるカスタマイズだけで、出来てしまいます。 すばらしい!
>>180 LISPにとっては何をいまさらという感じだが。
187 :
デフォルトの名無しさん :01/09/26 03:18
>>185 モジュール化、実装隠蔽、差分実装、の3つの組み合わせでできることだよね。
これは必ずしもOOに特有の話じゃない。
・・・などと書いてみるテスト。
188 :
defaultの名無しさん :01/09/26 03:25
汎用プログラミングとは、メインフレームのプログラミング、 つまり、COBOLやPL/Iのプログラミングのことです。(嘘) 汎用プログラミングがジェネリックプログラミングなら、 C++でいえばテンプレートですね。
189 :
デフォ@146 :01/09/26 03:48
>>180 この手の状態により振る舞いの変化しないものを書くには
Lispのような関数型言語(実際には、Lispはそうでもない)の方が強力だと思われる
>>146 で述べた状態の管理の代表的なもう1つの解が関数型言語
自身では状態を持たないので振る舞いの変化もない
じゃあ、状態の変化をどう管理するかというと
ある「もの」の状態の変化の変遷を
例えば、すべてリスト状に書き下すことによって、管理したりする
100から25,20,30の引き算とかは、100 - (25, 20, 30) => 25
しかし、こういう管理方法も不完全である
なぜかは、やっぱり、よく分からないので答えてください>関数型言語の方々
オブジェクト指向、関数型、どちらも興味はあるのだが、
どちらも相容れないパラダイムなのかな…
C++のテンプレートは意味的にかなりイイセン行ってると思う んだけど、言語全体から見たら、なんだかなあ・・って感じ。
191 :
デフォ@146 :01/09/26 04:03
>>190 あんまり、C++のテンプレートはよく知らないんだけど
あれって、明示的な型宣言のないRubyやLispやSmalltalkでは
明白で簡潔に書けるのに、C++では明示的な型宣言が存在するために
あえてああいう書き方でしか表せないパラダイムの1つ
…のような気がするんだけど
「どんな型でもいいよ〜」っていう以外に効用ってあるの?
あと、
>>189 は、激しくスレ違いの予感…
192 :
defaultの名無しさん :01/09/26 04:07
OOPの目指す汎用的なプログラミングっていうのは、
>>185 みたいな感じだと思う。
>>188 は、ジェネリックプログラミングの説明です。
Modula-2とまでいかなくても Delphiの前の(TP)=オブジェクトパスカルの モジュールレベルの方が今のOO言語の窮屈なクラスレベルより設計も実装も 再利用も楽だった気がするのは年寄りだからかな
194 :
デフォルトの名無しさん :01/09/26 10:00
>>171 そもそもメソッド、メッセージ、インターフェイスという単語は、
英語的には普通の単語過ぎてダサい感覚です。
シニカルに見えて鼻につくと思うのは日本人だけ。
(だから日本で流行らないんだろうなぁ)
メソッド→手順
メッセージ→伝言
インターフェイス→境界
オブジェクト→物体
クラス→種別
インスタンス→実体
なんてどうでしょうか。
>>192 >>185 みたいなのは「差分プログラミング」っていうんじゃないの。
「ソフトウェアIC」なんていう私語もあったね。:-P
じゃ 3目並べゲームをオブジェクト指向で表現してみてよ 簡単すぎるならテトリスでもいいよ
>196 自分でやれ。 手番からなにからすべてクラスで定義した厳密バージョンと、 コード・設計が最もシンプルになるような最適バージョンの両方作ってみな。 もちろんプレイヤーは人間・CPU・ネットワーク越しすべてを透過的に扱えるように設計しろよ。 その程度なら厨房でも何とかこなせるし、良い勉強になるよ。
>>195 差分プログラミングなんて用語は始めて聞いたぞ。
ソースをコピペして一部を改造するという腐ったやり方のことか?
>>198 継承ベースのプログラミングのことだよ。
最近継承は人気ないけどね。
あ、間違えた。 199=195
いや俺は配列使ってメインでゴリゴリ書く方法しか思いつかんもんで・・・
202 :
デフォルトの名無しさん :01/09/26 11:23
身近なオブジェクト指向は会社組織そのものだったりする。
>>197 JDKのサンプルアプレット(TicTacToe.java)で300行ちょっとだね。
憂鬱本の魔方陣に納得できない漏れにはいい課題かも。ありがとう。
204 :
デフォルトの名無しさん :01/09/26 11:30
オブジェクト指向は複雑な物をシンプルにするのが得意。 すでにシンプルな物をよりシンプルにするのは苦手というか、効果が薄い。 そういうところはアルゴリズムにまかせたほうがいい。 有用な技術だけど、すべてにおいて効果を発揮する万能薬じゃないのだよ。 会社組織にたとえれば、2〜3人の小さな組織で備品購買担当を決める意味があるのか。 こんな小さな組織で下手に担当を決めるとかえって窮屈になる。 だから3目並べやテトリスくらいでは、デメリットばかりが目立っていい例はあげられない。 しかし大きな組織になったら担当が必要になる。 100人の社員が好き勝手に備品を買ってきたらえらいことになるし、 管理するのは大変だから担当を決めて、決済や稟議というメッセージを仲介し、 購入という操作や、予算という属性を隠蔽する必要が出てくる。 組織を知ればオブジェクト指向は見えてくる。
判りました。 ようはジム屋さんのツールって事ですね?
ああ、これで終ったら単なる煽りですね 普段、MFC/VCLを【使う】事はやってましたが、 いまひとつオブジェクト指向ってのが理解出来ないというか クラスライブラリっってGUI用で(TCのテキスト窓用のも類似として) これはオブジェクト指向そのものとはちょっと違うんじゃないかと思ってました。 COMを作るのにオブジェクト指向なんて概念は必要なくてインターフェースさえ 決めればいいので、インターフェースを決めるのにオブジェクトやクラス(つまり 現実世界の物を抽象化)なんて考えてませんでしたから つまりはオブジェクト指向のいうオブジェクトは業務系の用語だという事なら 理解出来ます
>>204 いいかげんその手の半端で不正確で
読み手をあらぬ方向へ誘導する説明を得意げにするのはやめろ。
何の役にもたたん。
>>175 >そもそもプログラムかけないやつが、分析できるだけの知識を持ってる
わけ無いだろ。プログラムできないやつが分析しようと思うことなんて
ないだろ。
ファウラーによると、「最高の分析者はそのドメインのスペシャリスト」だ
そうですけどね。でも確かに現実の顧客にモデリングを教えてやってもらう、
ってのは想像できません。
その前に自分がモデリングできなきゃいけない…あ、ファウラーみたいな
コンサルタントがついてるからできるのか。
>原理的には可能かもしれないが、分析が上手く行ったかどうか自分で
体験できないから著しく不利。
モデリングできたら、そのモデルを「実装」してみればいいのでは?
分析モデルでも動くモノはできるよね。
209 :
デフォルトの名無しさん :01/09/26 12:33
>>206 業務系や事務系の用語となぜ決めつけたのか知らないけど、
オブジェクト指向はゲーム開発だろうがなんだろうが使えるよ。
なんか堅苦しく考えすぎているような……。
TRadioButtonはラジオボタンを担当している。
ラジオボタンがラジオボタンである責任をTRadioButtonが負っている。
もしラジオボタンの表示が崩れたり、表示とチェックの状態が異なっていたりしたら、
それはTRadioButtonに問題があるからであり、TRadioButtonの責任だけを問えばいい。
当たり前のことだよね……。
フォームに6個のラジオボタンと、6個のチェックボックスがあるとする。
非オブジェクト指向なら、フォームを再描画するとき、
コンポーネントのテーブルを調べて、各ボックスの状態を調べて、
コンポーネントの種類に応じた描画関数を呼び出していくだろうか?
オブジェクト指向の場合、そのコンポーネントの正体は知らないまま、
フォームに張り付いているコンポーネントに対して再描画のメッセージを
送っていくだけで事足りる。コンポーネントの種類が増えても、
フォームの処理を返る必要はない。
これは各コンポーネントが、それぞれの役割りに責任を持っていることが保証されて
はじめて成り立つんだよ。
210 :
defaultの名無しさん@職場 :01/09/26 12:57
誤解無きようにいっておきますが、 185 のすばらしいは、本当にそんなことが出来たら すばらしいって意味ですよ。
オブジェクト指向はGUIパーツでは成功しやすいよね。 ところで、ゲーム業界ではパックマンのころから、表示物体の事を 「オブジェクト」って呼んでたの知ってる?
>>207 オブジェクト指向アレルギーの典型的症状が現れています。
理解できないから理解しようとしない、
理解しようとしないから理解できないという悪循環に陥っていませんか。
>>211 > ところで、ゲーム業界ではパックマンのころから、表示物体の事を 「オブジェクト」って呼んでたの知ってる?
だって物体(実体)を表わすための汎用名詞じゃん :-)
コンピュータ言語で言うところの "object" とは別の意味だ。
>>211 > オブジェクト指向はGUIパーツでは成功しやすいよね
それは単にユーザインターフェイスを構築する際はユーザの
取りうるアクションそれぞれに対して振る舞い(reaction)を
定義しなければならないから複雑化しやすく、複雑化した
モデルに対してはオブジェクト指向がよりよい手法であるから
ユーザインターフェイスに対してオブジェクト指向は成功しや
すい、ということでしょ。
>209 OOPがゲームだろうがなんだろうが便利に使えるという事なら同意するけど オブジェクト指向ってのは >「オブジェクトとは,日常生活に見られる物体を、ソフトウェア・プログラミング上でモデル化して表現したものです」 っていう所からよく入るだろ? プログラミングの立場から見ればモデル化というか抽象化は当然やる。 というよりプログラミング=抽象化だと思う プログラムするのだから抽象化するのは当たり前なんだから、後半に意味はない。 なら「日常生活に見られる物体を、」ってあたりがオブジェクト指向なんだろうか? そういう目で見れば、TRadioButton とか まったく日常に見られる物体とはかけ離れた 動作、仕様で実装されている。 それはWindowsコントロールのラッパーだからしょうがないというなら、じゃいったいオブジェクト指向って何? 結局、 継承や、データ+メソッド構造の事じゃないのか?と思うけど、そうじゃないんだと多くの 入門書やサイトは言ってる。 じゃ何なんだ? って疑問があったんだけど 業務系や事務系の【金を取る為の】 用語なんだと理解すれば 色んな疑問が全部納得出来るんだ。 組込み系でいえばニューロとかファジイとか1/fの用語と一緒だね
216 :
デフォルトの名無しさん :01/09/26 15:40
>196 結局、 >業務系や事務系の【金を取る為の】 用語 としての「オブジェクト指向」はいやだ、というのはわかるけど、 >OOPがゲームだろうがなんだろうが便利に使えるという事 >継承や、データ+メソッド構造の事 を196はなんて呼ぶの? それがオブジェクト指向なんじゃないのかな。
217 :
デフォルトの名無しさん :01/09/26 15:50
>>215 >なら「日常生活に見られる物体を、」ってあたりがオブジェクト指向なんだろうか?
>そういう目で見れば、TRadioButton とか まったく日常に見られる物体とはかけ離れた
>動作、仕様で実装されている。
>それはWindowsコントロールのラッパーだからしょうがないというなら、じゃいったいオブジェクト指向って何?
現実に喩えるということと、現実に合わせるということは違うんだよ。
オブジェクト指向は、現実世界にある「責任分担」などの仕組みを真似ましょうと言っているに過ぎず、
ソフトウェアを現実世界と同じ形に置き換えましょうと言っているわけじゃない。
オブジェクトが担う責任についてもっとよく考えてみよう。
誰かに責任を負わせるということは、それ以外の誰かが負う責任が減るということ。
ラジオボタンの責任をTRadioButtonに一任しているからこそ、
TFormはラジオボタンに関する責任を負わないで済む。
こういう責任分担のしくみは、会社組織の中にあるそれと全く変わりがない思うけど。
別にVCLのコンポーネントに部長や課長や西地区担当という名前を付けることを求めたりはしない。
データ+メソッド構造をオブジェクトと呼んでもいいけど、それには但し書きが必要。
そのメソッドにはオブジェクトの一部としてデータを維持管理する責任があり、
その責任が負えないようならオブジェクトの構成要素とは呼べない。
ちなみに俺は組み込み系とゲーム系しか知らないから、
業務系、事務系、勘定系のことは知らん。
>>215 本当に理解したいなら、2ch で書いててもどうせ適切な説明は返ってこない(ここは
匿名で短いコメントを次々とつけていく形式だから、包括的な説明するには向かんメ
ディアだ)から「憂鬱なプログラマのための…」でも買ってきて読むことを勧めるが。
たんに煽りたいだけなら、止めないけど。
> 業務系や事務系の【金を取る為の】 用語なんだと理解すれば 色んな疑問が全部納得出来るんだ。
OOはすでに「現場で」使われている技術だよ。看板だけ会って中身がない単なる用
語とは違う。
あとOOの真髄は、プログラミング言語よりもむしろ分析/設計段階にある。OOで分
析/設計した結果を素直にコーディングするために必要な機能を取り入れた言語を
OOPL(オブジェクト指向プログラミング言語)と呼ぶわけだが、その言語の機能を
見てOOの全体像を知ろうとするのは、木を見て森を想像するのと同じぐらい難しい。
というわけで、まずはOOの分析/設計について調べるのがいいと思うぞ。
219 :
デフォルトの名無しさん :01/09/26 22:18
自分でクラス設計しようと思うとどこで切り分けるのが良いか 悩みますねぇ〜。 実装方法も継承主体でいくのかオブジェクトコンポジションを 使ったほーがいいのかとか。 OOの分析/設計の勉強をきちんとやったほうがいいんでしょうね。
220 :
サブジェクト志向言語 :01/09/26 22:39
/******************/ /*表題を書けやゴラァ*/ /******************/ void hoge(void){ printf("表題が必要です"); }
読み返して見たけど、オブジェクト指向の失敗は 「オブジェクト指向を理解しているのは俺だけ」 「本当は難しくて抽象的でお前らなんかに理解できないんだよ」 みたいな厨房を大量に生んでしまった事のようだな。
自分はそれなりにオブジェクト指向を意識して、まあそこそこまとまったプログラミングが できてるんじゃないかと思うけど、パーサ系(状態遷移とかのある)がどーもうまく 設計できなくて、変数いっぱい・関数長い・インデント深いと三拍子揃ったソースを 書いちゃってて今鬱… 誰かやり方知ってたらヒントでも教えてください。。
223 :
Delギコ :01/09/26 23:08
∧ ∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
( ゚∀゚) <
>>221 藁夕
| つ[|lllll]).\_________
〜| |
∪∪
オブジェクト志向のメインは単に構造体がメソッドをもてることだと思フ
>>222 とにかく、出来あがったら別ファイルにするなり(カプセル化)
して目に触れないようにすれば(隠蔽)OKダ。
>>222 そんな極度に抽象的な処理をオブジェクト指向にする必要も無いと思うが。
>>224 んー。それはやってます。
ただカプセル化した中とはいえ、ネストの深いifとかはなんとかしたくて。
うーむ。
>>225 確かに、具体的にイメージできるもの(オブジェクト)があったほうが設計しやすいですよね。
227 :
デフォルトの名無しさん :01/09/27 00:01
今度は3勝0敗から4連敗するなよ。
まさかStateパターン知らないとか? while (!state.isFinal()) { state = state.parseNext(context); }
229 :
デフォルトの名無しさん :01/09/27 00:34
>>193 Modula-2をつくったNiklaus Wirthはオブジェクト指向言語Oberonをつくった。
>>196 オブジェクト指向を理解してない。
>>211 関係ないけど、表示物体をクラスにするのは典型的なオブジェクト指向だと思う。
230 :
デフォルトの名無しさん :01/09/27 00:44
>>222 ラベルを状態にみたてて goto で回す。
それかテーブル駆動。
汚いと言われようが何しようが、
カプセル化してしまえば内部は好きかって。
非OO派の発言が、
>>167 以降勢いがなくなったのが笑えた。
VBでもOOできるよーん。
>>231 VBの継承ができないという仕様はある意味潔い。
そうそう、おいらは全体的にはオブジェクティブ 細部は好き勝ってという手法が好きです。 あんまりオブジェクティブを徹底しすぎてもちょっとアレ。
>>233 同感。
Stringをオブジェクトにした奴は死んで欲しい。
やっぱしループ変数iとかもクラス作って使わないとね。 信者にふさわしい死に方をきぼんぬ。
237 :
デフォルトの名無しさん :01/09/27 01:19
VBって継承できないのか。。。
>>234 ごめん、string を始めとする STL は大好き。(^^;
MFC の CString はやりすぎ。
VB,C++厨房はここから出て行け
それからStringはCharクラスを継承してないんで、原理原則に 従ってちゃんと継承して作りなおして、信者にふさわしい死を・・・。
オレのことかい?
242 :
デフォルトの名無しさん :01/09/27 01:24
>>235 1 to: 100 do: [: i | Transcript show: i ; cr.]
244 :
デフォルトの名無しさん :01/09/27 01:27
>>243 Smalltalk だよ〜。
1 というオブジェクトに to: do: というメッセージを送ってる。
こいつを受け取ると、1 は 100 まで数え上げて、
do: に与えられたクロージャをその都度呼び出す。
で、その際の現在の値が i に与えられる。
Smalltalk 知らない人には Transcript が最も謎だと思われ。(w
>>222 Design Pattern の Interpreter と State の組み合わせで
いけないかな。とはいえ、もう試しているけどうまくいかないから
書いているんだろうから、余計なお世話だな。
247 :
defaultの名無しさん :01/09/27 02:34
メンテナンスや再利用を意識した、機能単位のプログラム分割は、 (つまりはカプセル化)OOP以前からやってること。 つまり、OOレベルでは構造化に対してアドバンテージが低い。 OOPの構造化に対するアドバンテージは、継承にある。 OOPの継承で設計すると、抽象化による共通部分の ベースクラスへの切り出しが必要だが、これが問題だ。 システム化というのは、現実の世界の処理を具体化し、 機能別に再構築する物だと思う。 にもかかわらず、派生によるメンテナンス性向上のために、 無理に抽象化することに意味があるのか? (それ以前に、派生でメンテナンス性が向上するとは思えないが。) また、今までカプセル化は、設計上の必要性で行ってきたのだが、 OOPだからと何でも細かくオブジェクト化し、 インターフェイスやメソッドを増加させるのはどうかと思う。
>>247 機能単位のプログラム分割とカプセル化は全然別物だと思うよ。
249 :
defaultの名無しさん :01/09/27 03:09
>>248 違う場合もありますが、全然別物ではありません。
共通サブルーチンや共通モジュールを、想像してください。
印刷サブルーチンは、各種パラメータにより、
内部の印刷モジュール(メソッド)を実行します。
コール元からすれば、直接メソッドを呼ぶのか、
パラメータを指定するのかの違いだけです。
250 :
デフォルトの名無しさん :01/09/27 03:16
>>249 同じ場合もありますが、別物なのが普通です。
例えば、クラスとインスタンスを例にあげて言えば、
インスタンスは複数あるのが普通だし、持ち運びもできる。
非OOなモジュールの場合にはそういうことは考えない。
「もの」として持ち運んだり複製したりできることが重要。
251 :
デフォルトの名無しさん :01/09/27 03:22
252 :
defaultの名無しさん :01/09/27 03:22
>>250 OOレベルではの話です。
OOPレベルだと、その利点はありますね。
253 :
デフォルトの名無しさん :01/09/27 03:35
>>252 OO、OOP、OOA、OOD、の使い分けがよく分かりませんです。
どういう基準で使い分けてますか?
254 :
defaultの名無しさん :01/09/27 03:50
>>253 OOレベル、設計レベル(OOA+OOD)。
OOPレベル、実装レベル。
設計レベルでは、データフローに対する
処理単位(クラス)で考え、同じデータフローを
個別データ単位(インスタンス)では考えない。
>>252 OO=オブジェクト指向パラダイム
OOP=オブジェクト指向プログラム
OOA=オブジェクト指向分析
OOD=オブジェクト指向設計
で、カプセル化はOOとして(問題をオブジェクトとして見るために)
必要不可欠なキーワードで
構造化なんちゃらのモジュールとは一線を画していると思われますが。
256 :
デフォルトの名無しさん :01/09/27 03:59
249、252じゃないけど。
>>247 オブジェクト(役割単位での分割)とモジュール(機能単位での分割)は区別して考えないと。
モジュールは管理している属性が不明瞭だし、操作する対象も不明瞭のままです。
そこを明らかにすることに価値を見出すのがオブジェクト指向かと。
継承がOOの最大のメリットだというのはそのとおりだけど、
OO初心者にこれを説明しようとするから難しくなるのではないかと思います。
ポリモーフィズムとか、ある程度のデザパタが理解できるようにならないと
継承の本当の美味しさというのは掴めないし。
(
>>223 みたいなことを言っている奴もいるし)
だからまず、オブジェクト否定派には、オブジェクトとは何なのかという
至極当然のところから噛み砕いて説明したほうがいいと思いますよ。
>>254 それはすでにOOではなくフローモデルあたりだと思う。
>>247 > OOPの構造化に対するアドバンテージは、継承にある。
設計/実装段階の要は、むしろ「インスタンス間の相互作用」だと思うが。
継承も相互作用の一形態ではあるけど、むしろ特殊な例。
259 :
デフォルトの名無しさん :01/09/27 04:08
>>254 あまり一般的な分類だとは思えないなぁ。255 さんとかぶるけど、
OO=オブジェクト指向:思想。ポリシー。対象を特に選ばない。
OOA=オブジェクト指向分析:OOに基づいた問題領域の分析工程。
OOD=オブジェクト指向設計:OOに基づいた(ソフトウェアの)設計工程。
OOP=オブジェクト指向プログラミング:OOに基づいた実装工程。
クラスとかインスタンスという概念はOOでよく見られる一つのパターンであって
OOAやOODだからクラスでOOPだったらインスタンスというのは変だよ。
プロトタイプベースの言語だったらクラスないし。
クラス間ならぬインスタンス間の関係を設計段階では扱わないかと言えばんなことないし。
260 :
defaultの名無しさん :01/09/27 04:16
すいません、OOについて勝手な使い方をし、
混乱を招いてしまいました。
OOのモジュール分割と、構造化の機能分割を
同じだとは言いいません。
OOAやOODでもたらされる恩恵は、既存の構造化で、
ある程度満たされていると言いたかったのです。
デザインパターンについても、企業内レベルでは
以前から標準化する努力がされています。
ではOOのアドバンテージは?
今まで存在しなかった、継承やポリモーフィズムに、
真のアドバンテージはあるでしょうか?
>>257 OOD
>>260 何でもいいが、もう少しOOについて勉強してから意見を開陳した方が良い
と思われ。単語レベルで解釈が食い違っているようだと、さすがに議論にな
らないですよ。
262 :
defaultの名無しさん :01/09/27 04:23
263 :
デフォルトの名無しさん :01/09/27 04:26
>>260 まず、銀の弾丸的なものを期待する対象じゃないと思う。<OO
んで、既存の手法に対する全く新規なアドバンテージもないと思う。
なら、何がいいのかというとトータルでは扱いやすいってこと。
むしろ既存の手法にあった色々な考え方を
カプセル化や継承なんていう基本語彙で表現しやすくしたのがでかい。
そもそもSimulaやSmalltalk-72にさかのぼればOOは古典の部類。
既存の手法とオーバーラップしてるのは自然なことじゃない?
大体プログラムなんて最後は全部機械語に落ちるわけで
どんな手法も目標機械語列へのリーチを短くする話でしかない。
その意味では十分なアドバンテージがあると思うよ。
264 :
defaultの名無しさん :01/09/27 04:31
>>263 私もそう思います。それがわかって必要な部分だけ
使用すればいいのですが、過度に使用しようとすると、
問題があると感じます。
265 :
defaultの名無しさん :01/09/27 04:37
クラスライブラリのような汎用的でないプログラムを、 実際に設計・開発した人で、継承やポリモーフィズムの アドバンテージを、実感した人はいますか?
266 :
デフォルトの名無しさん :01/09/27 04:44
>>265 「クラスライブラリのようには汎用的でない」の間違いだよね?
重箱隅な突っ込みは置いといて、状況設定が不適切だと思う。
継承や多態が有効に機能するように、
限定的な範囲内であっても汎用性を意識して設計することが
OOPの有効性の重要なポイントになっているはず。
極端な話、「汎用性をもたせてはならない」という条件をつけたら
どの辺りでOOPが役に立つのか想像がつかない。
267 :
defaultの名無しさん :01/09/27 04:56
>>226 > 「クラスライブラリのようには汎用的でない」の間違いだよね?
はい。
汎用性を前提としたクラスライブラリで、
継承が役にたつのはわかっています。
アプリケーションの設計・開発で、継承やポリモーフィズムが
プログラムの何かに貢献した例についてです。
汎用性をもたせてはならないなどとは、状況設定していません。
アプリケーションの汎用化に貢献したでも、
メンテナンス性の向上でも、システム構造の明確化でもかまいません。
268 :
デフォルトの名無しさん :01/09/27 05:01
>>267 アプリケーションの、というのならもちろん役に立っている。
個人的な経験を挙げれば次の通り。
複数フォーマットのファイルに対応したい場合に
共通インターフェースを Document クラスにまとめて
個別のフォーマットに対応するものを派生クラスで特化する。
Factory パターンと組み合わせれば
特化された Document を追加するだけで
他のコードは一切書き換えずに機能を拡張できる。
同様のことが Command パターンの時にも成り立つ。
構造の明確化、メンテナンス性の向上、どちらのメリットもある。
269 :
defaultの名無しさん :01/09/27 05:08
>>268 私の場合、クラスライブラリのドキュメントクラスから
個別のフォーマットのクラスを派生させて、
そこ個別のクラスから、更に派生する構造はとりません。
共通部分は別クラスにし、クラスのメンバにします。
理由は、この方がわかりやすく、扱いやすいと感じるからです。
>>267 いたるところで役立ってますよ
窓なんてひょろっと必要なところをオーバーライドしたら
アプリが出来あがる。これくらいならモジュールのみでも
無理やりやればできるけど
多態とかインスタンス間の関係まで、デザインパターンに
踏み込めばモジュールでは役に立たない。
271 :
デフォルトの名無しさん :01/09/27 05:22
>>269 クラスのメンバにするというのは委譲のことを言ってる?
これを継承&多態じゃなくて委譲にするのはかなり非常識だよ。
もちろん継承のない言語(VBとか)だったら仕方ないけれど。
継承を使わない=多態を使わない=インターフェースが共通化できない
ということになるから敢えてそうするだけのメリットがないと。
委譲ですらないんだったら根本的に何かを間違えていると思う。
272 :
デフォルトの名無しさん :01/09/27 05:26
>>271 自己レス。
ダイナミックバインディングが前提の言語だったら
継承使わなくても多態は使えるね。VBもその点はそうか。
実装はコピらなくちゃいけないし
ディスパッチャとしてのメソッド実装が必要になるから非効率だけどね。
とりあえずこれで寝。
273 :
defaultの名無しさん :01/09/27 05:31
>>271 インターフェイスの共通化はクラスライブラリレベルで、
クラスメンバにしているのは実装部分です。
>>273 クラスライブラリで提供しているインターフェース以外は、自作のクラスの外に出さない、
ということですか? なんか勘違いしてるような気がしますが(私が)
275 :
defaultの名無しさん :01/09/27 06:27
>>274 故意に共通のメソッドを作らなかったわけではなく、
(過去において)ほとんど必要性がなかったのです。
追加するメソッドに、クラスライブラリ以外のメソッドで、
汎用性な部分がなかった。
共通する処理部分や、共通するデータ部分はありましたが、
これらは別クラスにしました。
継承させた方がOOPらしいのですが、
(少なくとも私は)必要性を感じませんでした。
まれには、共通するメソッドがあって、
継承を使用したこともありますが。
276 :
デフォルトの名無しさん :01/09/27 07:02
277 :
defaultの名無しさん :01/09/27 07:31
ごめん、流し読みで勘弁して。(しかもトップページのみ。) 私がいいたかったのは、何が何でもOOの概念にそって、 継承やポリモーフィズムを使うことが、 わかりやすくもないし、メンテナンスし安くもないということ。 人間クラスと犬クラスを、どうしても継承させたがるのは どうかと思う。 たとえOOの概念から外れても、別のクラスの方がわかりやすく、 メンテナンスしやすいこともある。
>>277 それじゃあさ、compositeパターンの活用例を挙げて、
そのメリットとデメリットを説明してみな。
説明する課程で理解が深まると思うから。
>>278 OOを一生懸命勉強してきたのはわかるけどさ
本を真に受けてOO最高じゃ話が進まないよ
まともなシステム開発したことある?
>>279 OOがまともなシステム開発に使われていないとでも?
281 :
デフォルトの名無しさん :01/09/27 11:25
277=279? GoFパターンにケンカを売ろうという根性だけは認めるけど、 もっと勉強した方がいいね。
282 :
デフォルトの名無しさん :01/09/27 11:55
>>279 酷い事言うなー。今まで必死でやって来た事が、現実じゃ役に立たないなんて言われたら、儂なら泣いちゃうよ。
私は現場でOO使ってるよ。 何でも継承にしようとするOO信者は困りもんだが。 適度に使えばOOは有効だよ!
284 :
デフォルトの名無しさん :01/09/27 12:34
インヘリタンスにシフトウエイトした開発が、 最前線で破綻してるのは周知の事実 書籍を鵜呑みにする偽知識者以外は、みんな知っている だからといって、OOPを否定しようという勘違い者は論外
OOPレベルでのメリットは型と実装の分離、それとポリモーフィズム。 void foo(A& bar) { } 関数fooに渡されるbarは型Aのオブジェクトということだけわかっていれば、 barがどのクラス(実装)のインスタンスかを知らなくてもかまわない。 GoFのパターンも、型と実装の分離を前提にしているものがほとんど。
286 :
チーズはどこへ消えた? :01/09/27 13:06
>>279 へぇ、システムやアプリの開発経験があるんだ。
満足の設計ができた?
もっとうまい方法があるかもしれないと疑問に思わなかった?
ん? そうか、現状に満足しているんだね。
君はすばらしいよ。それならもう僕からは何も言うことがないよ。
287 :
日曜プログラマ :01/09/27 13:20
GoF本読めばOOPの神髄は継承になく、
適切な役割を持たせたオブジェクト同士の協調作業にあると分かる。
言語の機能に思考を縛られていてはいけないと思うな。
>>277 >人間クラスと犬クラスを、どうしても継承させたがるのはどうかと思う。
例の粗を探すのではなく、例から概念を理解してほしい。
おそらくあなたは、「コードの把握しやすさ」は理解できても
「ソフトウェア構造の把握しやすさ」という概念は理解できていないのでは?
共通部分を括り出すだけでは自分用関数ライブラリと変わらない。
デザインパターンは、ソフトウェアを開発していると良く出くわす
*設計上*の問題とその解決法に名前を付けたもの。
名前があるおかげで、
「これはfactoryパターンでやるといいんでない?」「あ、なるほど」
というやりとりができる。
まあ、みんながパターンを知ってないと共通語彙として使えないから
まだまだ浸透するには時間がかかるだろうけどねえ。
>>287 継承するために継承するわけじゃないよ。
多態性を実現するために継承する。
278さんが言っているようにcompositeパターンは良い例だと思う。
>>289 継承と書くときには、「インターフェースの継承」なのか「実装の継承」なのか
明記したほうが良い。混乱の元だから。
>>287 >つまり継承って事では?
言語によっては、継承によって実現せざるをえない場合があるが、Javaのように
interfaceとclassによって実現できる場合もある。重要なのは「型」と「実装」
の区別を意識すること。
292 :
真のプログラマー :01/09/27 21:18
真のプログラマーは継承などしない。 全てを具体的に扱うことができれば抽象化など全く不要だからだ。
293 :
真のプログラマー :01/09/27 21:18
真のプログラマーはデザインパターンなど使わない。 見ず知らずの他人になど頼らずとも常に最良の設計を創造できるのだ。
294 :
デフォルトの名無しさん :01/09/27 21:18
真のプログラマーはコードの再利用などしない。 過去のコードは全て脳にインプットされ、 いつでも常にフルスクラッチで書き起こせる。
295 :
真のプログラマー :01/09/27 21:19
真のプログラマーはオブジェクト指向なんか使わない。 これまで設計ミスなどという愚考を犯したことが無いからだ。
296 :
デフォルトの名無しさん :01/09/27 21:19
297 :
デフォルトの名無しさん :01/09/27 21:20
>>295 というより大規模なやつを組んだことがないんだろ?
298 :
真のプログラマー :01/09/27 21:21
真のプログラマーはミスを犯さない。 犯さないったら犯さない。 名前の記入を忘れたり、 ましてや愚行を愚考と書いたりなどするわけがない。
299 :
デフォルトの名無しさん :01/09/27 21:21
>>293 簡単なアルゴリズムしかつかわねーんだろ?
300 :
デフォルトの名無しさん :01/09/27 21:22
>>298 そんなチンケなこといってるやつは真のプログラマーではない
むむ、真のプログラマーネタが解らない奴がいるとは……。 マジレスされると嫌味効果が薄れるからやめてくれ。
302 :
デフォルトの名無しさん :01/09/27 21:23
というよりオブジェクト指向がわからずに、 技術の進歩についていかれないだけだろ?
ネタにマジレス、カコワルイね。
306 :
デフォルトの名無しさん :01/09/27 21:54
>>277 今ごろ気づいたけれど、別クラスのほうがわかりやすいって何?
継承したって、人間と犬と猫は別クラスであることにはかわりないじゃん。
共通部分は動物クラスにまとめられるから、同じ処理が犬や猫クラスに重複しないし。
メンテナンスしやすさ、わかりやすさ、どこをとっても継承したほうが上では?
継承を使わないで何がよいのかさっぱり解らないよ。
単に継承が理解できないから使わないと言っているようにしか聞こえない。
307 :
デフォルトの名無しさん :01/09/27 22:00
ポリモーフィズムが俺としては欠かせない
308 :
デフォルトの名無しさん :01/09/27 22:02
ポリモーフィズム使わないのに、 継承っていうのも、あまり俺は好きじゃない 継承するとメンテナンスしずらい気もする もちろん、ポリモーフィズムのためなら関係ないが
人間と犬を抽象動物クラスから継承しないのは間抜けだろう。 だが、抽象動物クラスには「前足」があるのかそれとも「手」があるのか?なんてことを 考え出すと、手だか足だかは別クラスにして接続したほうがよさそうだ、と判るんではないかと。
ここにいるOOマンセーな皆の会社ではOO、デザパタなんぞ常識レベルなの? 俺もOOマンセーなんだけど、引継ぎで 俺「ここの状態遷移はStateパターンそのままで・・・」 相手「ハァ?すていとぱたーん?」 俺「個々の状態を、AbstractStateクラスのサブクラスで定義して・・・」 相手「ハァ?クラス?構造化プログラミングの言葉でいうと何?」 てなことがしょっちゅうなんだけど。 思うにOOの弱点は ・OOへの理解が浅い人間が設計するとどこまでもひどくなりうる。 ・もともとの設計がまともでも、OOへの理解の浅い人間がソースを引き継ぐと 理解できない、またはどこまでもひどくなりうる ・上記2点にもかかわらず理解を深めるのが難しい。(このスレの混乱振りを見れば明らか) つまり、フールプルーフがなってない。 よって、設計・実装・保守を行う者と、利用者が明確に区別できる場合 (たとえば自分用クラスライブラリや、商用クラスライブラリや、長期に渡って 同一人物やチームが保守することができる場合など)のみしか有効でないと 思うんだがどうよ? #OOへの理解が浅いのはオレモナー
311 :
デフォ@どうなんすか? :01/09/28 00:42
なんか、
>>276 で示してるページでも書いてる通り
継承は、規格化(通信規約)が第一目的
これにより、交換可能を実現できる
…と思う
しかし、オブジェクト指向が再利用性と交換性を目指してるのは分かるけど
デザパタとか見てると、交換性はうまくできてるけど
再利用性はいまいち実現できていないように感じるけど、いかがか?>OOの人
312 :
デフォルトの名無しさん :01/09/28 01:06
デザインパターンはコード自体の再利用でわなくて、 アーキテクチャの再利用を目指していると思われ。 おいら自身もコードそれ自体の再利用性に あんまりこだわるのもどうかと思う。 もちろん意識することは吉だろうが。
313 :
デフォ@どうなんすか? :01/09/28 01:19
>>312 少しそういうもんかな?とは、思っていたけど、やっぱそういうもんすか
交換性を有するという事は、その部分以外での構造を再利用をしているのと等価かなとは思ってたけど…
じゃあ、オブジェクト指向って抽象クラスとかでコード内で規格(制約)を設けることで
構造を再利用させることが目的なの?>OOの人
そうであれば、扱う問題ごとに制約が存在することによる理解のし辛さ(デメリット)は
仕方なくついてまわる問題なのかもしれないですね
開発環境なんかでこのデメリットはやわらげられるのか、どうか…
314 :
デフォルトの名無しさん :01/09/28 01:26
唐突ですが 真のオブジェクト指向言語は何ですか?
OO の目的は変化に対応しやすくすることだと思う。 おいらは OO はそれなりに好きだけど、原理主義ではないので そのスジの人の意見は違うのかもしれんけど。
316 :
デフォルトの名無しさん :01/09/28 01:30
318 :
デフォルトの名無しさん :01/09/28 01:39
>>313 「構造の再利用」はOOの目的ではなくデザインパターンの目的である、
と
>>312 は主張していると思われ。
しかしながらデザインパターンでもアダプタやデコレータの用に
既存のソースコードそのものを修正することなく再利用することを
目的とするものもある。
とはいえ、ほんとにまったく修正しないで再利用するのは現実には
結構難しいのは同意。
>>313 OOはコードの利用方法に適切に制約を設けることで可読性/保守性を高めます。
ってこれはOOの特徴と言うと語弊があるけど、デザインパターンってのは触らせる
部分と触らない部分をきっちり分けているわけでさーよ。
OOPLであれば、触らせないことを保証する為の仕組みが備わっているものが多い、とさ。
320 :
デフォ@どうなんすか? :01/09/28 01:47
そこも、以前から疑問に思ってたんだけど… デザインパターンは別にOOに含まれるというものではないのですか?
「デザインパターン」といえばGoF本の物を指すことが多いからOOと関連付けられることが多いけど、 それはあくまで「OOにおける再利用のための」という部分を省略してそう呼んでいると考えれば? 広義にはOOじゃないデザインパターンというのも考えられるでしょ。 ま、前者の意味が浸透してるから「デザインパターン」->OOという図式を崩せはしないだろうけど。
322 :
defaultの名無しさん :01/09/28 01:54
>>306 必要ない場合には、クラスライブラリからの派生で止めておけば、
わかりやすく、メンテナンスしやすいという意味です。
4階層継承したアプリケーションの場合、
OOのいうように最下層のオーバーライドで
メンテナンスが用意かというと、そうではない。
実際には、最上位クラスまでさかのぼって、ソースを見るんです。
クラスライブラリからの派生のみなら、メンテナンスは比較的容易です。
クラスライブラリからの派生だけでも、クラスライブラリレベルでは、
インターフェイスは統一されていますし、ポリモーフィズムも使えます。
それでもなおアプリケーション内で継承するのは、
あくまで追加する共通のメソッドがあり、ポリモーフィズムを、
追加したメソッドで使用する必要がある場合だと思います。
(業務で扱うオブジェクトを、対象を意識せずに使うことは、
あまりありません。)
OOは絶対に良いものだから、OOの概念に沿わせるために、
抽象化するのでは、OOのためのOOになってしまいます。
>>322 クラスライブラリから派生せず、独自の階層を持つクラスは作らない、という
主張ですか?
たとえばドロー系のツールなら、そこで扱う「形状」を表現するために
class Shape {};
class Circle : public Shape {};
class Rect : public Shape {};
...
みたいなクラス階層を考えるのが普通だと思うんですが、どうしてるんでしょう?
>必要ない場合には、クラスライブラリからの派生で止めておけば、 >わかりやすく、メンテナンスしやすいという意味です。 に対して >クラスライブラリから派生せず、独自の階層を持つクラスは作らない、という >主張ですか? なの?
325 :
デフォルトの名無しさん :01/09/28 02:14
めんどくせー。 プログラムA −> コネクタ −>プログラムB でいいじゃんか。
328 :
ななしヘタぐらま :01/09/28 03:44
>>276 すごいー,このサイト,かなりわかりやすく説明が書いてありますね.
難しい事柄をこうやって易しく説明できる人って尊敬しちゃうな.
全てのプログラマー,必読!
いいページ教えてくれてありがとう>
>>276 さん
330 :
デフォルトの名無しさん :01/09/28 08:56
なんかOO原理主義者って OOを賞賛しない人を 馬鹿扱いすることでしか 反論できないのね 優越感に浸りたいのは わかるけど SEとしての決定的な資質に かけてると思う
>>330 事実、OOを否定するのは、おまえみたいなバカ。
自分が理解できないのを、OOの欠陥のようにいう。
333 :
デフォルトの名無しさん :01/09/28 09:33
>>330 激しく同意。結局、OOの唯一の欠点は、アホには理解できない事。理解できないアホに、何をいっても無駄。
334 :
デフォルトの名無しさん :01/09/28 09:34
335 :
デフォルトの名無しさん :01/09/28 09:51
>>330 OOを理解した上でOOを批判するのであれば素直に読むけど、
OO批判のほとんどはOOを理解してないことが明らかだからね。
否定派を馬鹿扱いしているのではなく、
理解できない物を無闇に批判する人たちを馬鹿扱いしているだけだよ。
336 :
デフォルトの名無しさん :01/09/28 10:20
>>335 OOの概念を使わない人を、OOを理解できない人と決めつけるのは、どうか
と思うよ。デメリットから、あえて使ってない人も多いと思うし。反対意見に
も謙虚に耳を傾ければ、得られる物もあるんじゃないかな?
よけいなお世話だったかな?
>>336 なんか的外れというかなんというか…
ちゃんと読めよ
>>336 そもそも 335 は「OOの概念を使わない人を、OOを理解できない人と決めつけ」て
いないと思われ。
>>336 ここで叩かれてるのは明らかに理解してない
人ばかりだろ。
誰も決め付けてないよ。
340 :
デフォルトの名無しさん :01/09/28 10:42
日本では信仰の自由が保障されているのだよ。 オブジェクト指向原理主義者にとって、 その思想は正義なのだ。絶対なのだ。 疑問を抱くことも許されぬ、絶対不可侵の物なのだ。 その思想に沿わない設計をする奴は、 オブジェクト指向を理解できない馬鹿以外の 何者でもない。 ましてオブジェクト指向を批判する奴など、 悪その物に他ならない。 正義の制裁を加えるべき対象なのだ。 考えてもみよ。ユダヤ教を信じている人間に、 思想の矛盾を言ってなんになる。 信じている根拠を聞いてなんになる。 彼らにとって、教えに従わない人間は、 愚かな異教徒以外の何者でもない。
age 荒らしは放置でお願いします>みなさん
だんだん2ちゃんねるらしくなってきたねぇ
>>340 信仰は自由なんでしょ。だったらいいじゃんほっとけば
344 :
デフォルトの名無しさん :01/09/28 11:06
相手が信じている物を非難すれば、怒るのは 当然だ。OOとか以前に、人として間違って いる。
345 :
クズは氏ね :01/09/28 11:12
OOに文句つける奴は、クズばかりだな。おまえら愚民は、構造化使ってりゃいい んだよ。OOは、俺達選ばれた民だけ使いこなせるのさ。
OOは馬鹿以外の特権ということで −−−−−−−終了−−−−−−−
347 :
デフォルトの名無しさん :01/09/28 11:42
>>345 OOを使っている人が少数派だと思っている?
348 :
デフォルトの名無しさん :01/09/28 11:45
OOな人たち気を悪くしないでね。犬クラスと猫クラスがあったらスーパーク ラスに動物クラスがあって当然だってことがOOは正しいってとこからス タートしているとおもう。だからそれ以外の考えはOOを理解してないってこ とになるとおもう。デモそれってOO的な考えをしない人=OOを理解してな い人ってことでしょ。これだとOOのにそってない人がみんなOOを理解 してない人になるとおもう。OOを理解している人はOOな人たちだけになっ ちゃうとおもう。これっておかしいとおもう。
>>
>>348 御前みたいな低脳がOO語るのは10年早いんだよ
Rubyでもやってろ!
350 :
クズは氏ね :01/09/28 12:01
>>347 猿程度の知能があればOOは理解できる。しかしクズは別。ここにはクズが多すぎ
る。
何をいまさら お前もくずの一員だと言うことを認識せよ
>>350 非OOP派も猿程度の知能はあると思うよ。たぶん(^^;
353 :
クズは氏ね :01/09/28 12:14
今までの流れを 1 OO否定派 2 OO肯定・継承否定派 3 OO肯定・継承肯定派 と勝手に分類してみる オレは今の所は2だが・・・ 3は2まで罵ってしまうのが痛い オブジェクト指向原理主義過激派(3)は穏健派(2)まで敵にしてしまい、 それを見た1は2と3の両方を嫌ってしまう OOはとりあえずはカプセル化だけでいいのでは? カプセル化のメリットは誰にでもすぐ分かるだろうし オレ自身はカプセル化が最大のメリットだと思っている 継承や多態性はそのメリットが分かりにくいし、考えずにやると破綻しやすい 継承しなきゃOOじゃないというのはおかしいだろう
継承も多態もカプセル化もOOの本質ではない、と思うがどうか。 それらはOOのある特定のパターンの実現手段に過ぎない。
356 :
デフォルトの名無しさん :01/09/28 12:54
>>354 アンチャン、わかりやすいじゃねーか。おりゃこれでいくと、基本的には3だな。
趣味で作ってるプログラムは、バリバリ3だしな。仕事の大規模システムが4・5
階層だと、さすがにきついがな。
357 :
デフォルトの名無しさん :01/09/28 13:04
>>OOはとりあえずはカプセル化だけでいいのでは? ナンデ言語の進化を否定すんだ?そうすると殆どのクラスライブラリはなくなるし、 クラスを派生させて振る舞いの差分をコーディングするって当たり前の事が出来なくなるYO! 継承には明確なメリットがあって、通常のOO言語仕様にあるのに。
>>354 つか、
主人「猫は「ニャー」と鳴け、犬は「ワン」と鳴け」
猫「ニャー」
犬「ワン」
猿「…」
ってのは OO じゃないだろ。
主人「鳴け」
猫「ニャー」
犬「ワン」
猿「キィキィ」
じゃないとダメ。
メッセージに対してオブジェクトが自分で振る舞いを決めるてこそ OO だろ。
「多態無しですが、自分は OO やってます」なんて意味無いし。
359 :
デフォルトの名無しさん :01/09/28 13:12
360 :
デフォルトの名無しさん :01/09/28 13:14
>>357 多重継承についてどう思いますか?
>357 継承が許されるのはクラスライブラリだけ、という考えもある クラスライブラリはユーザー共有の知識なのでどこに実装があるのか皆知ってるが、 自作のクラスで継承を多用すると実装がどこにあるのか探すのが大変だろう デバッグする時はなおさらだ。 そりゃクラスライブラリにもバグがあるけどさ・・・
>>357 与えられた道具は、必要なときに必要なだけ使えばよい。
常に使わなければならない訳ではない。と言いつつも、俺は3だ。
しかし、2については気持ちは分かる。1はどうかと思うが・・・
#番号書くと立場が明確になって、良いんではないか?
363 :
デフォルトの名無しさん :01/09/28 13:36
>>348 機能を説明するためのサンプルに、十分なメリットがないと難癖つけていたのでは、
いつまでも機能を理解することはできないよ。
10件のクイックソートの例を見て、ヒープソートの方が速いと言っているようなものだ。
その例が現実にはどのようなことに役立つのか、そこを自分でよく考えて欲しい。
もちろん適材適所で使うべきなのは言うまでもないことだよ。
継承否定派の人たちは、ポリモーフィズムを口にはしていても理解しているようには見えない。
オブジェクト指向でポリモーフィズムしないなんてナンセンスもいいとこ。
きちんと説明する必要があると思うんだけどね。
犬と猫の上位に動物があれば便利ってのが、そもそもインチキく せーんだよな。 実際の仕事で、こんな概念的に整理できる単純ケースなんて、殆 ど無いからな。ましてや巨大プロジェクト全体を眺めたら、概念で 派生ツリー作ろうなんてのが、無理だとわかる。結局のところ、処 理を分析して、地道に共通部分を洗い出して行くしかない。 どうもOO原理主義派??ってのは、机上の空論っぽいんだよな。 趣味でプログラム作ってる、只のオタクじゃないのか?
>継承否定派の人たちは、ポリモーフィズムを口にはしていても理解しているようには見えない。
>オブジェクト指向でポリモーフィズムしないなんてナンセンスもいいとこ。
オレハ 2ミタイ
∧∧ / ̄
>>363 @_(,,゚Д゚) < 全部が全部理解してなくちゃ
⊂,,__つつ. \_ 開発しちゃいけないって事にならない?
クラスライブラリ開発者とクラスライブラリユーザーとを使い分けて
考えたらどうかなあ。クラスライブラリユーザーはポリモを理解してなくて
使いこなしていないだろうけど
OOの恩恵を受けてるわけだからそれでいいでしょ。
> 犬と猫の上位に動物があれば便利ってのが、そもそもインチキく
>せーんだよな。
クラスライブラリを作成するときには考慮する事は必須だけど
現実にソフト作っていく際に必要あれば上位の動物をつくるけど
犬、ネコ、別にしても問題ない時は別々のままにしたりするよねー。
究極的な事言い始めたら
全部のクラスを原子クラスから分子クラス、固体/液体/気体クラス
と作らなきゃっいけないなんていうのはおかしいことなんだし。
>>363 > 機能を説明するためのサンプルに、十分なメリットがないと難癖つけていたのでは、
いつまでも機能を理解することはできないよ
そういう高飛車な態度が反発されてんだよ。いい加減、自分だけ
分かってるような態度やめろよな。
サンプルなんてものは、全く逆の結論をさもまことしやかに見せ
ることが出来ることぐらい、おまえでも分かるだろ?
OO原理主義者ってのは言い得て妙かも (この言葉を広めましょう) この人達って再利用とかわかりやすさとか ほんとはどうでも良くって OOの考え方に則ってプログラム作るのが 1番大事なんじゃない? つまりはOOの原理が1番大事な人達
368 :
デフォルトの名無しさん :01/09/28 14:11
>継承が許されるのはクラスライブラリだけ、という考えもある 考え方はあっても良い。だが、クラスライブラリを利用する人はそのクラスの派生による 差分コーディングで作ってるんだ。 >犬と猫の上位に動物があれば便利ってのが、そもそもインチキくせーんだよな。 クラスライブラリのクラスを継承後、振る舞いを差し替えるいう例。犬、猫、動物関係無し。
>巨大プロジェクト全体を眺めたら、 >概念で派生ツリー作ろうなんてのが、無理だとわかる。 クラスライブラリには派生ツリーがあるのを知らない? クラスライブラリを使ったことあるなら、そのメリットわかるよNE?
>>357多重継承についてどう思いますか? 自分は多重継承使ってないので、使っている人に聞いて下さい。 現在主流のOOPの限界は、単一継承か多重継承かにあるんでなく、 実行時の継承が有るか無いかだと思うけどね。(主流じゃない言語にあるらしい)
>>363 オブジェクト指向でポリモーフィズムしないなんてナンセンスもいいとこ。
うーん。
難しいところだね。
鳴けといえば、相手が何か解らなくても鳴く。
考えると良さそうだけど、現実の業務で犬か猫か解らない物に、
鳴けというケースは滅多にないからね。
上位クラスで扱う必要性があれば、便利だと思うけど。
犬と猫のインターフェイスがあまりに違うなら、継承による依存関係がない方が良いときもあるし。
時と場合によるね。
ポリモーフィズムを使わなくても、犬に鳴けといえばワンと鳴くし、猫に鳴けといえばニャーと鳴くしね。
当たり前だけど。
文章ごちゃごちゃ。結論無いので読んでメリット無いYO!
>>372
なにやら、いろんな派閥があるようだが、派閥はいかんよ、派閥は!
俺はOO肯定・継承消極派だ。何百万ステップのシステムが クラスライブラリもどきのツリーだったら怖い(^^;)
377 :
デフォルトの名無しさん :01/09/28 15:35
インフラが提供する共通クラスなんかは、ツリーになってるよ。
>俺はOO肯定・継承消極派だ。何百万ステップのシステムが 継承による差分コーディングにより、何百万ステップが激減するんじゃない。 ステップ減らせることを否定しちゃイカン。開発もメンテもステップが多いものは×。
書き方悪かった。 クラスライブラリを派生することにより、何百万ステップが激減のが分かりやすい。 自分が記述するコードを大型なクラスツリーにしなきゃならん、という思い込みが間違いだよね。
あとから、猿だのカバだの追加する可能性があると思った時に 動物クラスを作って継承させたらいい。
381 :
デフォルトの名無しさん :01/09/28 15:59
理論と実践の壁は大きい。普遍的なインターフェイスなど架空の花。
>379 クラスライブラリから派生するのはむしろ穏健派の考えでは? それに関してはあまり否定はしない 問題なのは自分で抽象クラスを作って継承する場合 何度も言うがクラスライブラリを利用するのとそれ以外は全く別物 クラスライブラリのような継承ツリーがアプリの中にあったら困るでしょ クラスライブラリは ・変更されることがなく ・ユーザーに共有の知識であり ・ソースを読む必要がなく ・デバッグする必要が無い という点でアプリそのものとは全く異なる(もちろん、完全ではないが)
これって進化論の話? 人間クラスは クロマニョンクラスとか イクチオステガクラスとか アミノ酸クラスとかから 派生させるべきって事? 結論は何なの?
354さん可愛そうですが、全部違ってます。全然OOP分かってない人ですね。 >・変更されることがなく 勝手に内部が変更されるから便利なの。 コンパイラのバージョンが上がったら、ドッキングプロパティが増えてたとか。 >・ユーザーに共有の知識であり 提供された時点では共通の振る舞いだが、派生で振る舞いを変えれるのが良いの。 >・ソースを読む必要がなく 派生して振る舞いを変えるには、該当メソッドを知らなければならないので読まなければならない >・デバッグする必要が無い ?
385 :
デフォルトの名無しさん :01/09/28 16:18
386 :
デフォルトの名無しさん :01/09/28 16:18
OOの思想は間違っちゃいない。専門分野に特化した業務アプリを、汎用的な継承階層にまとめ上げるのが、神業的なだけ。
>専門分野に特化した業務アプリを、汎用的な継承階層にまとめ上げるのが、神業的なだけ。 そうでもないYO! ボトムアップで作っていく場合にも、関数よりクラスのが楽。 専門分野特化業務アプリって大型コードになるが、 クラスとメソッドの枠だけ作ってって、後から中身を作る方が、塗り絵みたいで、精神的に楽。
354さんのどこが違うかと言うと、、、 「クラスライブラリがアプリそのものとは全く異なる」という結論です。 アプリを一から書くのでなく、クラスライブラリからクラスとってきて、 動作の違う部分だけオーバーライドするって開発になるんです。 だから、出来上がったものは、継承ツリーがあってその上位層はクラスライブラリになってた、 って感じで等価になるんです。 そう出来上がってない場合は、 クラスをnewして外からプロパティセットしてメソッド呼んでと、、、 これでは、関数と変わりません。
関数と変わらない方法では、ステップが減らず、OOPのメリットはありません。 そういう開発方法とるのは、ブビ坊がCOMやActiveXを使い場合です。 COMは派生出来ないので仕方有りません。
そういえば構造化も昔は否定されてたよな…。
392 :
デフォルトの名無しさん :01/09/28 16:48
幾多の理論が生まれ、否定され、生き残るのはほんの僅か。 はたしてOOPは?
OOPが消えたら、Win、Winアプリ、みんな消えるYO!
>>392 残るのは、汗で書かれた汎用機OSとLinuxカーネル位か。
X-WindowもC言語かなぁ。
いくつものシステムがこけてるのに、 継承否定派も含めめ、 これだけOO信者が多いのは何故?
395 :
デフォルトの名無しさん :01/09/28 16:58
>>393 「汗で書かれた」=「アセンブリ言語で書かれた」
「汗で書かれた」=「血と汗と涙で書かれた」
>>394 構造化設計のほうがこけている割合は圧倒的に多いと思うけどね。
クソ設計の泥沼に陥っている奴は誰だ?
398 :
素朴な疑問 :01/09/28 17:03
>>396 なるほど。
日本の宗教人口は実人口の2倍っていいいますもんね。
教祖の金儲けのために踊らされてると知りつつも、
信じてしまうのが日本人なのか?
399 :
素朴な疑問 :01/09/28 17:05
>>397 構造化については話を聞きませんが
、やはり悪い酒興のようですね
400 :
素朴な疑問 :01/09/28 17:08
酒興ーー>宗教 です
>いくつものシステムがこけてるのに、 あ、そうなの?初耳。言語は何よ。 >構造化については話を聞きませんが 構造化では出来上がるシステムが知れてる。 >、やはり悪い酒興のようですね こういう人は汎用機に留まって、WinやLinux系に移行しない方が良いと思います。 別にそれを止めはしません。
こういう人は汎用機に留まって、 ↓ 汎用機COBOLに留まって、の方が分かりやすいですね。
403 :
素朴な疑問 :01/09/28 17:15
>>401 すいません、構造化のことは
、まだ勉強していないのです。勉強不足ですいません。
> 構造化のことは、まだ勉強していないのです …(閉口)
>>404 >IBMイコールOOT(オブジェクト指向技術)と考えてもらって構わない
カ、カコイイノカナ?
それはSmalltalk技術者が居ない失敗でしょ
>>404 OOPから失敗というのは間違い。
第三世代言語にクラスが追加されたのがOO言語。
例えば、C++使いながら、実はC関数っていう開発もあるし、
汎用機でJava使いながら、関数単位で、Javaのクラスをnewして、
コボラー人海戦術方式したり出来るし。
なんかOOP否定するのに必死みたいだが、OOP言語にも旧言語仕様は入ってるので。
>>407 否定しようとなんてしてないじゃん…
> OO がいけないわけじゃないじゃん…
って言ってるだけやん…
つか
> > いくつものシステムがこけてるのに、
> って、OO のせいじゃないやん
って言ってみたかっただけやん…
ごめんなさい、読み間違い。失敗例ね
>>408 それから407に色々書いたけど、やっぱり関数セットを一杯書くより、
何でもクラスにしといてメソッドにしといた方が絶対楽。一回やれば分かるYO!
わざとかどうかひどい誤解をする人がいるようなので。 ・継承できそうなら継承しなければならない→嘘 ・現実世界の階層構造を必ず模倣しなければならない→嘘 開発するソフトウェアにとってのみ必要なクラス階層構造にする。 そのための指針が、 アナリシスパターンやアーキテクチャパターンやデザインパターン などのパターン技術。(+プロセス技法) 継承はあくまで差分プログラミングと多態性を実現するための手段であって目的ではない。
賛成です
>>410 >継承はあくまで差分プログラミングと多態性を実現するための手段であって目的ではない。
一旦、差分プログラミングと多態性になれると、
それが出来ない言語は鬱陶しくて、やってられなくなることを付け加えますです。
>>410 同意
> 開発するソフトウェアにとってのみ必要なクラス階層構造にする。
入門書だと、これが抜けてる場合が多い気がします。まずは犬と猫で、上位に動物クラスと
いうのは現実に則していて分かりやすいけど、実用的じゃない。
あくまで問題(ソフトウェア)の性質に合わせてクラスは抽出しないと。
>>410 意見には同意だけどOOの話じゃなくて開発技法一般の話だと思う。
要は教条主義に陥る奴は誰であれバカだよ、と。
>>410 OO信者にしては、だいぶ現実的な思想だな。
しかし、まだ詰めが甘い。
差分プログラミングや多態性は、最終目的ではない。
最終目的とは何かを考えてみよ。
対象のシステムにおいて、差分プログラミングと多態性が、最終目的に対して与えるメリットとデメリットを比較せよ。
それが即ち設計だ。
415 :
デフォルトの名無しさん :01/09/28 18:50
>>410 やっとまともな意見が出てきたって気がするよ
>>357 が410に同意してどうするんだ?
357はもっとOO原理主義的に
・継承できそうなら継承しなければならない→真
・現実世界の階層構造を必ず模倣しなければならない→真
となってくれないと。
パターンという単語が出てきて逃げ腰か?
>>357
>416 OO穏健派的には ・継承できそうだけど、継承したくない→真 ・現実世界の階層構造を模倣できそうだけど、模倣したくない→真 ですね(藁
418 :
デフォルトの名無しさん :01/09/28 19:22
継承(上書・多態)は利点ばかりじゃないからね。 ケースバイケースでしょ。
419 :
OO道師範 :01/09/28 19:31
俺様は必要性や可読性より、クラス階層の美意識を優先する。 それが俺様のOO道美学じゃ。文句あるか!
害を与えないならいくらでもどうぞ。
>>419 はたから見てる分には、カッコいいかも?
でも、一緒に仕事するのはイヤ。
422 :
デフォルトの名無しさん :01/09/28 19:52
俺は型なしOO肯定・多重継承マンセー派。
423 :
デフォルトの名無しさん :01/09/28 20:06
OOって呼び方はダサいな。 αでどうだ。構造化はβ。手続きがγ。
424 :
デフォルトの名無しさん :01/09/28 20:41
実装継承は最後の手段。 最優先の選択肢は「独立したオブジェクト」。 次が「委譲」。 その次にやっと「インタフェイス継承」。 最後に「実装継承」。 ほんとに必要なの?「多重実装継承」。
425 :
デフォルトの名無しさん :01/09/28 20:55
あ い う え お か き く け こ さ し す せ そ た ち つ て と あ い う え お か き く け こ さ し す せ そ た ち つ て と
テスト完了です。 ありがとうございました。
継承の階層が一枚岩的なものがいいか森のようなものがいいかは 言語によっても変わる気がする。 C++なら間違いなく後者だが
>357はもっとOO原理主義的に >・継承できそうなら継承しなければならない→真 >・現実世界の階層構造を必ず模倣しなければならない→真 これは単なる馬鹿な意見ですね。 現実世界の階層構造は一意に決まっているものではありません。 現在主流のOO言語では不可能。不可能を目指してはいけません。
馬鹿な意見がでたおかげで、継承反対派との亀裂がわかりました。 継承賛成派・・・継承でステップを激減 継承反対派・・・現実世界の階層構造を必ず模倣しなければならない なぜ反対派が、極論を言うか。継承が何か分かってないからです。 構造化の初期は同じことが言われたでしょう 構造化賛成派・・・関数でステップ激減 構造化反対派・・・「goto行番号」ならソース1つで良いのに... 手続き分割出来るって、出来るものは全て分割しろよ!
継承賛成派はメリット説明したんで、 反対派はそのメリットにそったクラスを一個でも作って検討してYO!
432 :
デフォルトの名無しさん :01/09/29 00:38
OOがまともに理解できないプログラマやSEが多いのが日本のビジネスソフト 業界の弱さですね。西洋人はオブジェクト指向が出始めた頃から ばりばりとOOプログラミングして、InterViewというフレームワークを作っていたの だけど日本人はそれを真似するぐらいでしたね。日本人には向かない のかもしれませんね。
フレームワークって単なる造語じゃん。 OO出る前からやってたよ。 F6-PageDown-F8->別ファイル-F9
>>432 > 日本のビジネスソフト業界
2チャンねらーの間違いでしょ
435 :
デフォルトの名無しさん :01/09/29 00:45
継承肯定派です。
>>430 なるほど……と一瞬思ったけど、ちょっと違うと思う。
継承賛成派は、使うところと使わないところを見極めた上で、
使うべきところではしっかり使うべきだと言っている。
継承反対派は、全てのケースで無理に使うとよくないと言っている。
つまり、どちらも全てのケースで継承を使うのは良くないと知っていて、
この点では実は同じことを言っている。
それではどこが違うのか。
賛成派は、使いどころの見極めについて具体的な方法論を持っていると思う。
そしてどうすると失敗するのかを明確にわかっている。
だから使うべきところなら迷わず使う。
しかし反対派は、どこで見極めるのか掴めてなくて、
失敗しないために、慎重になるという方法を選んでいる。
だから確固たる信念を持って使うべきという人がいると、
その人には慎重さが足りないと思ってしまう。
継承賛成派、反対派、穏健派という分け方に意義有り。 OOはクラスなど無くても成立します。
異議ね
んで、オブジェクト指向の理解が浅い人に継承のメリットを語るとき、 失敗する可能性を恐れて継承の良さを半端に教えるのはよくない。 まず成功する場合のメリットをしっかり認識させた上で、 さらに失敗する可能性について教えるべきだと思う。 そうしないと、継承を恐れすぎて、身につかなくなってしまう。 さて、どうすればうまく継承できるのか。 何度か失敗してみるのがいちばん手っ取り早いけど、 学生が勉強しているならともかく、実務で作業しながら学ばないとしたら、 これはリスクが高すぎる(俺は実務で失敗して学んだけどね)。 やはりUMLなどのモデリング手法を学んだ上で、 十分な要求定義と分析を重ねるしかなさそう。 あとできる限りデザインパターンから設計を選ぶようにしないといけない。 でもこれをうまくやるにも、経験がものをいうんだよなぁ。 構造化設計の経験がある人にオブジェクト指向を教えるのは案外たやすい。 状態遷移とかERとかDFDとか、かなり似ているからね(つーかほとんどそのまんま)。 でも、構造化言語を使っただけで構造化設計をできた「つもり」になっている人に、 オブジェクト指向を教えるのは非常に難しい。 そういう意味で、構造化設計の経験者なら、オブジェクト指向でも すぐにそれなりの設計ができると思うのだけど。
>>436 クラスや継承が無くてもOOが成立するというのは、間違っては無いですけど、
それは基礎的な話ですよね。
OOをベースにした膨大な技術の蓄積を享受するには、継承は避けられない。
>継承賛成派、反対派、穏健派という分け方に意義有り。 >OOはクラスなど無くても成立します。 確かに現実世界には確固としたクラス階層というものは無いんだよね。 オブジェクトといえるものはあるが。 そういう意味で言うと、 >OO穏健派的には >・現実世界の階層構造を模倣できそうだけど、模倣したくない→真 この人はまだ良く分かってない。
436は継承のこと言ってるんじゃなく、オブジェクトベースのoopを言ってる
>>439 オブジェクトベースのoopでは、クラスが無くて、実行時に継承するそうです。
>>441 ほ〜。そんなのがあるんですか。
知りませんでした。
進化ということを考えても、動物ツリーの下に犬、猫があるという説明よりも、 哺乳類の固体に、有る時期ウィルスがDNAを転写、又は紫外線があたって、 犬に分化したもの、猫に分化したものが出来たという方が現実味あるよね。 そうだと、実行時の継承の方が現実に近い。 だから、実は、動物、犬猫猿が変だって言ってた意見も分かるよね。
後、コンピュータウィルスがインターネットを駆け巡る状況を シミュレーションする場合もオブジェクトベースのが記述しやすいかも。 ではお休みなさい。
>だから、実は、動物、犬猫猿が変だって言ってた意見も分かるよね。 いや、そこはわからない。 現実の世の中を完全に模倣することに、あまり意味は無い。 結局さ、所詮はソフトウェアに過ぎないわけよ。 ソフトウェアから見てオブジェクトが十分に抽象的なら、 必要以上に抽象化する必要は無いでしょ。 あるソフトでは動物クラスという抽象クラスが必要かもしれないし、 別のソフトでは不必要かもしれない。 そこは設計の都合次第。
犬猫を例にとることが混乱の元になってると思われ。
>>445 禿同
抽象とか模倣とか、一部の人たちがやけに
難しいことを得意げに言ってるが、
それって実際役に立ってますか?
少なくとも自分の周りでは役に立ちそうにないね。
>その蘊蓄。
純粋に設計し、純粋に組む。それが正道でしょ?
クラスライブラリをOOと混同してる人が居ます。
449 :
デフォルトの名無しさん :01/09/29 02:05
抽象化をするのは、別の物をある側面で見れば同じものとして扱えるようにすること。これ重要。
450 :
デフォルトの名無しさん :01/09/29 02:18
>>441 >オブジェクトベースのoopでは、クラスが無くて、実行時に継承するそうです。
うーん。それはちょっと違う。
動的な言語、たとえばSmalltalkやruby、ならクラス自体を実行時に処理するんで…。
Objectベースとか「prototype型」と呼ばれる言語は、クラスじゃなく
インスタンス「に」メソッドやフィールドをつける。
Objectを産む方法は、既に有る「望んだものに一番似てるObject」を「コピー」し、
それに好きなメソッドやフィールドをを追加/削除することで得る。
451 :
デフォルトの名無しさん :01/09/29 02:26
>>49 JavaのAPIはクラス設計の抽象化に失敗していて、やたらにクラス増やしてますが
何か?
453 :
デフォルトの名無しさん :01/09/29 02:30
454 :
デフォルトの名無しさん :01/09/29 02:45
>>452 例えばどのクラス群が失敗してると思います?
455 :
デフォルトの名無しさん :01/09/29 02:56
J〜クラス Metal〜クラス ストリーミングクラス ↑このへん。
456 :
デフォルトの名無しさん :01/09/29 03:23
MetalってL&Fかな?これとかストリーミング関連とかは見たことないから知らないけど、 J〜については結構クラス数爆発の印象はありますね。でも、抽象化に失敗かと言うと逆で、 抽象化し過ぎたせいで、強力な柔軟性と引き換えに使いやすさ/分かりやすさを犠牲にした感はあります。 ま、それも抽象化に失敗といえるか(藁
OO否定派が、動物クラスまで必ず作るのがオブジェクト指向 だと勘違いしてるのでは。
>>457 うわべだけで理解したつもりになって
語る厨房は無視したらいい
OOを無価値と思わせるのもそれはそれでいいではないか
>>457 >>458 君たちみたいな勘違い君がいると、我々OO派の見識が疑われ、不毛な議論に逆戻りだよ。
反OO派の為ではなく、まともなOO派のために消えてくれ。
>クラスライブラリをOOと混同してる人が居ます。 こういう意見てどうしようも無いよね。説明してないヤツだし。 オブジェクト指向を否定する人達にクラスベースとオブジェクトベースと 同時に分からせることは出来るわけない。順をおって、クラスベースから説明しないと。 説明ということがどういうことか分からない学生君なら、ちょっかいかけなきゃ良いのに。
こんなに突っ込みどころの多いスレ見逃してた。 二度目読み直し中。
>>459 オマエモナー
OOを語りたがるやつほどOOを知らないことがほとんどだよ
ネット上のDQNOOページのどれほど多いことか
463 :
デフォルトの名無しさん :01/09/29 18:36
オブジェクト指向とドキュメント・ビュー・アーキティクチャは明らかに矛盾しています。 だからMFCは分かりづらい。
464 :
デフォルトの名無しさん :01/09/29 20:36
>>462 そういうのは、DQNではないOOページを作ってから言おうな。
せめてDQNじゃないページを紹介してみろよ。
読んでやるから。
どうでもいいが抽象論で満足してないで
現実にどういう場合にどういう継承を使ったとか言えばいいのにのお。
継承でクラス階層増やしまくって他人には使いにくい
意味不明なライブラリを自作して喜んでる奴が多そうだな
465 :
デフォルトの名無しさん :01/09/29 21:49
>>460 混同してる方が説明を要すると思うぞ。
クラスと00は全くの別物。
466 :
デフォルトの名無しさん :01/09/29 21:55
>>463 ドキュメント・ビュー・アーキティクチャなぞ常識。
だから別オブジェクトにしただけの話。
特にビューの方はパーツ化して使いまわしがしやすい。
十数年前、プログラム組み初めて(アセンブラ)直ぐに気付いて
取り入れたよ。
>混同してる方が説明を要すると思うぞ。 >クラスと00は全くの別物。 小学校一年では、地球から観測した太陽(天動説)を教えてから、 中学生で地動説になるんだろうが。 同じように、構造化プログラミングを教えるときは、 関数を作れって教えるが、それはoopでは間違いになる。 説明の途中でクラス説明したら駄目なのか? 氏ねや厨房。
クラス厨房の逆鱗に触れてしまった模様。
>>468 中身の無い議論に誘導するのはもう止めよう。
クラスとOOはてんぷらと中華料理ぐらい違う。
>>470 眺めてあれこれ言ってるより、さっさと食べて仕事しろってことだな。
中身が無いから名前が「」なんだ。コテハンを「」にしてやるよ。 >てんぷらと中華料理ぐらい違う どっちも食べ物で共通項あるじゃないか。 クラスベースのoopではoo=クラス オブジェクトベースのoopではoo=オブジェクト だろ。「」は人に説明ということがデキンみたいだな。 学生というか中身の無いヤツというか。サヨナラ。
オブジェクトベースのoopの方がクラスベースより現実にあってることは説明しただろ。 「」は自分は全て知ってると悦に入ってるんだろうが、 しかし、オブジェクトベースでさえも通過点なんだ。技術とはそういうもの。 順を追って説明出来ないなら、会話に入らない方がみんなのため。
474 :
デフォルトの名無しさん :01/09/29 22:50
OO設計っていうけど、みんなホントに便利かい? GUI周りは 出来合いのクラスライブラリ使うからOO設計の出番無しさ アプリケーションだとすぐに相互に依存しあってOO設計だと 再利用が逆に難しくなった経験しかないな。 OCXはそのまま利用出来るならいいけどそうじゃなきゃ後になって どこを弄っていいか判らなくなる事多いし 今迄手軽に再利用出来たのはDelphiコンポーネントだけだな しいてクラスが再利用出来た経験は、クラスライブラリをラップする 関数用意しておいた時だな・・・・はは・・・・ スクリプトを継承出来るような構造で書いてさ、結局文字列渡して 実行する関数として使うだけなんてさ・・・ははは・・・・
475 :
憂鬱な名無しさん :01/09/29 23:05
どうも。1です。 私は実はオブジェクト指向でプログラム組んだことは無いんですが、 最近「憂鬱なプログラマのためのオブジェクト指向開発講座」や メイヤーさんの「オブジェクト指向入門」等を読んで、オブジェクト 指向に感動したものです。 オブジェクト指向の分析設計のやり方が良くわからない、または、オブジェクト 指向の分析設計でうまく行くとは思えない人は前者の本を読んでみては どうでしょうか? 誤解も解けて自信が湧いてくると思います。 私の名前もその本から取りました。 このスレにも「憂鬱な・・・」を読んでいると思われる人の発言がいくつか ありました。 って、ちょっとスレの流れとはあまり関係ない話ですみません。
はあ・・・・。
477 :
デフォルトの名無しさん :01/09/29 23:21
このスレはケンカ腰なヤツが多くて笑えるね
478 :
デフォルトの名無しさん :01/09/29 23:22
どうもすいません。ありがとうございます。
479 :
デフォルトの名無しさん :01/09/29 23:23
480 :
デフォルトの名無しさん :01/09/29 23:33
俺はOO派だけど、ここのOO派には疑問を感じる。 差分プログラミングの柔軟性や、多態の便利さは、無条件で得られる物ではない。 実装の継承は依存を発生させ、オブジェクトの独立性を損なう。 インターフェイスの継承でさえ、現実には依存なしの設計は不可能に近い。 クラスの多段階層は実装の位置を不明確にし、メンテナンスやデバッグに弊害をもたらす。 これら支払わなければならない代償について、どうも理解できていないようだ。
481 :
デフォルトの名無しさん :01/09/29 23:40
平べったいクラス群は使えるのかな? 委譲しまくりのクラス思想もどうかと思うけど。群生の初期段階っぽい。 どうでもいいことだがMSの書くものはOOとは認めたくない。 あんなのはOOではあるまいに。病んだOOというか。
>>480 OO本には、そんな事書いてないからね。実際プログラミングした奴じゃないと、
わかららんよ。本に洗脳されて、わかったつもりの奴が多いから。
483 :
デフォルトの名無しさん :01/09/29 23:48
MFCクラス>>>>>Javaクラス
>>481 OOPのクラスライブラリって、どれもわかりづらくて、
使いにくいですよね? たぶん、最も優秀な、最もOOに
精通した人達が、作ったと思うんですが?
そこで私が思うのは、作りが悪いのではなく、OOで作る
と、OOでの開発が向いていると思える汎用クラスライブ
ラリでさえ、ああなっちゃうのかなと。何かOOの限界が
見えたような気がしてしまうのです。
>>484 俺はそうは思わん。
このスレにも住み着いている、OOオタクみたいのが作るから、継承オバケみたいになる。
多態の必要性等を十分吟味して作れば、もっとましな物が作れる。
>>485 Object Oriented Otaku OOOですね!←しょーもな
487 :
デフォルトの名無しさん :01/09/30 00:12
>>484 機能にムダがありすぎ
仕様がいいかげんすぎ
相互関係がしょぼすぎ
だからです
クラスの多段階性で実装位置がわかりにくくなる問題は VCのクラスブラウザとかがあれば結構マシになる。
489 :
デフォルトの名無しさん :01/09/30 00:20
>>488 階層が深くて、何度もオーバーライドされてて、
オーバーライド中では上位クラスの実装もよんでて。
やっぱ探すの大変だよ。
>>489 上位クラスに、ツリー形式ですぐ飛べるようになってるから
随分マシだよ。
491 :
デフォルトの名無しさん :01/09/30 04:18
話は飛びますが、生産性のついて言うなら結論出てると思うね。 OOPで生産性上がるならOOP採用してる会社は利益率上がって 採用してない会社を駆逐してるはずだよ? 現実はなんかOOP採用してるとこの不振が目立つ・・・。 これが世の中の動きという奴。
492 :
デフォルトの名無しさん :01/09/30 04:42
採用することと使いこなせていることとは同義ではない。 更に、使いこなせないものに引きずられるのは 自分の使うべき道具を見切れていないその企業自身の問題でしかない。 OOに限らず、ソフトウェア開発プロセスが流行った時代にも同じようなことはあった。 もちろん、だからと言って、OOが有益である、と結論できるものでもない。
493 :
デフォルトの名無しさん :01/09/30 04:54
一つや二つの企業ならそう言えるかも知れませんが、全体的に生産性 上がってないのなら企業の問題ではありません。 OOは使いこなすのが難しいっつう事でビジネスとしてのOOの評価は 終わってしまいます。
494 :
デフォルトの名無しさん :01/09/30 04:59
具体的な企業の名前や数と業績不振を示す指標を提示して 非OOの場合の同様のデータと比較しなければ意味がない。 そういう具体的な話が持ち出せない限りは煽りと変わらない。 言っておくが、OOを擁護したいわけではない。
495 :
こんなのは? :01/09/30 05:17
そんな一社だけの例をあげられてもな、、、 その記事ではOOのことには触れられてなくて、実行速度が悪かった としか書いてないし。
>>495 何百人いても無能が揃ってるとどうしようもないだろう
逆に十数名でもOOを武器に生産性を上げている企業も多い
AIは専門家がいなければアホなものしか作れないしな
結局アホの集まりだったということだろう
498 :
デフォルトの名無しさん :01/09/30 08:00
>>497 495の話は、OOとの因果関係が非常に不明瞭だけど、
失敗の原因を究明するときに、何でもアホだからとか馬鹿だからとか、
短絡思考過ぎると思うけど。
失敗原因の分析能力に欠ける上、何の発展性も改善も得られないよ。
499 :
デフォルトの名無しさん :01/09/30 08:06
>>498 同意
プロジェクトは、優秀な人材集めりゃ成功するわけ
じゃない
逆に一部の優秀な人材と、多数の凡人でも、十分成
功できる
むしろそれが出来ない方法論なら、方法論に問題が
あると認めざるおえない
>>491 それでは非オブジェクト指向言語がオブジェクト指向を
サポートしようとしている現状にはどう思われますか?
501 :
デフォルトの名無しさん :01/09/30 13:29
「DirectXはオブジェクト指向で作られてる」とか言い出しそう。
502 :
デフォルトの名無しさん :01/09/30 13:34
>>499 >むしろそれが出来ない方法論なら、方法論に問題が
>あると認めざるおえない
それは問題分析者がアホなんだよ
OOにせよなんにせよ、プランを立ててから実行資源、条件を
綿密に計画しなきゃ意味がない。OOはそれが特に顕著。
ふさわしい言語、解析は問題によりけり。それがわからないアホなら
どうしようもない救いもない。
なんでも方法論のせいにする前に、問題解析さえできていない
アホのほうがはるかに問題だろ。
503 :
デフォルトの名無しさん :01/09/30 13:37
OO採用会社の不振の統計なんか出てるような誰にでも判るような状況なら 皆逃げ出してるって。
504 :
デフォルトの名無しさん :01/09/30 13:42
「OOで成功してる」とか言ってるのは競争の無いところの話ばかりじゃん。 WIN用の店で売ってるようなソフトで成功してるところなんか無いんじゃない?
> WIN用の店で売ってるようなソフト アマですか?
銀の玉なぞない。 ただ最善を模索するのみ。
MFCもVCLもWTLもみんなOOじゃん。
508 :
デフォルトの名無しさん :01/10/01 00:25
オブジェクト指向の利点はクラスを定義できること。 構造化の利点は関数を定義できること。 クラスを定義できなくてもいいと言うのは 関数を定義できなくてもいいと言うのと同じ。 関数を定義できるようになったことが進歩であるように クラスを定義できるようになったことはさらなる進歩だ。
509 :
デフォルトの名無しさん :01/10/01 00:54
>>508 クラスのないオブジェクト指向言語もある。
それは利点のない言語か?
510 :
デフォルトの名無しさん :01/10/01 02:32
>>507 MFCってOO実践してると言っても良いんだろうか・・・?
要は運用次第って事でしょ。
共産主義という考え方があっても運用次第では旧ソの様になってしまう。
運用しずらい概念であるということなのかも。
だから、結局 オブジェクト指向って何だよ?
もう、なんでもいいじゃん、このさい。(藁
ひゃっほう!512!
514 :
デフォルトの名無しさん :01/10/01 08:25
ああ、今わかった。 オブジェクト指向は計画経済、共産主義みたいなもんだ。
515 :
デフォルトの名無しさん :01/10/01 08:27
需要をピタリと予測できれば計画経済は成功するが、 予測に失敗すれば経済は破綻する。
516 :
デフォルトの名無しさん :01/10/01 08:29
OOの設計も同じ。
つうことで
>>510 さんきゅー
517 :
デフォルトの名無しさん :01/10/01 08:45
技術としての オブジェクト指向 は結局IOOPをどう上手に使うかって事でしょ? 営業用の「オブジェクト指向」があって、これはお仕事を貰う為の格好付けみたいなもんでしょ
>話は飛びますが、生産性のついて言うなら結論出てると思うね。 >OOPで生産性上がるならOOP採用してる会社は利益率上がって >採用してない会社を駆逐してるはずだよ? >現実はなんかOOP採用してるとこの不振が目立つ・・・。 >これが世の中の動きという奴。 これは一体どこの話なんだろう。OOPを取り入れない会社とOOP取り入れた会社の2種類に分かれる? 今、OOでない言語って、VBとCOBOL類(OO-COBOLは余り聞かない)しか無いよね。 どこの会社でも、VC++、DelphiVCL、Javaと取り入れている。 10年前のUNIX/プリプロセッサC++は取り入れてるところはあまり無かったようだが。 システム開発失敗事例というものは年に山ほどあって、その解決策としてクラスライブラリというのが一般的。
Java自体の失敗はここに書いてあるね
ttp://www2.gihyo.co.jp/text.asp?ID=112 ■期待を裏切ったJava
純粋に技術的に見ても,Java不振の原因には2つあると思います.
まず,グラフィックスの描画速度が不自然に遅いという事実.これは,互換性を向上させたSwingに至ってさらに悪化.
もうひとつは,実は本当に矛盾しているのですが,互換性の欠如.それも,異なるJavaのバージョン間での互換性も含めての話です.
まともにJavaを使おうと思えば思うほど,Javaの環境設定に注意を払わねばなりません.Java開発環境,実行環境を何種類も載せて,注意深く切り替えて使うなんて状況も,決して珍しくありません.
とにかく,Javaは遅くて面倒なのです.
■Javaを蹴落としたLinux
私には,LinuxはWindows市場ではなく既存のUNIX市場を食い荒らしたとしか思えません.Linuxこそ,Microsoftの最大の陰謀ではないかとも思いたくなります.
直リンしない奴 = アホ
357さんと共闘すべきか対立すべきか迷うYO! 自民党と共産党の間にいる民主党みたいだな(藁 誰が敵なのか分からん
僕、別に闘う気ないYO! 自分が断言出来ることは断言して、会話の進行を加速したいだけ。 もし、自分の断言が間違ってたことが分かったら、それはそれで収穫だよ。
でも、なんとなく、オブジェクトベースのooの話が立ち上がった直後、 それをマターク理解しないスレが続いて、このスレ終焉した感じ。
526 :
デフォルトの名無しさん :01/10/01 16:23
終演したところで、取りあえず何で評判なのに 本屋で一度も見掛けたこと無いのかを教えてくれ。 「憂鬱なプログラマのためのオブジェクト指向なんちゃら」 え?絶版?
いや、今も売れてる。
>>526 それなりに技術書が置いてある本屋なら大概置いてあるけど。
526はどこに住んでるの?
>>509 プロトタイプベースのオブジェクト指向言語のことですね。
オブジェクト指向言語万歳
530 :
デフォルトの名無しさん :01/10/01 17:55
>>360 多重継承は言語がちゃんと設計されていれば有効です。
Javaふうに説明すると
class B extends A, A, A {} が
class B extends A {}
と同じになる必要があります。
例をあげると
class A { ... } extends Object
class B { ... } extends Object
class C extends A, B {}
AとBを通じて継承された2つのObjectは1つになる必要があります。
他にも名前の衝突とかオーバーライドとかあるけど省略。
531 :
デフォルトの名無しさん :01/10/01 18:55
A.equals()とB.equals()が別々にオーバーライドされ、 Cでは特にオーバーライドしない時、 C.equals()の動作をどのように規定するのでしょうか? オーバーライドされていなければコンパイルエラーとかに すればいいのかな?
532 :
デフォルトの名無しさん :01/10/01 19:35
>>531 C++の場合、これはコンパイルエラーになります。
(呼び出し先が曖昧と言われる)
operator=をclass Cでも使いたければ、
class Cがきちんとoperator=を用意しないといけません。
ところでJavaの場合でインターフェイスのメソッド名が重複したとき(参照)はどうする?
class CFile {
public:
bool Open(string &filename);
};
class CWindow {
public:
bool Open(HWnd handle);
};
class CFileWindow : public CFile, CWindow {
private:
bool Open(string &filename); //使用禁止
bool Open(HWnd handle); //使用禁止
public:
bool Open(HWnd handle, string &filename) {
CFile::Open(filename);
CWindow::Open(handle);
}
};
(参照)→(下のコード参照)
534 :
デフォルトの名無しさん :01/10/01 22:03
>>532 javaでは、メソッド名だけではなく、パラメータまで含めてシグナチャなので
例のコードではインターフェイスのメソッド名の衝突にはならない。
また、同じシグナチャのメソッドを持つ複数のインターフェイスを実装しても、
メソッドはひとつでいい、というかひとつしか作れない。それで問題も起きない。
例
interface A{
void say(String mes);
}
interface B{
void say(String hello);
}
class C implements A, B{
public void say(String hoge){
System.out.println(hoge);
}
}
例が間違ってた。すみません。 class A extends Object { ... } class B extends Object { ... } class C extends A, B {} AとBを通じて継承された2つのObjectは1つになる必要があります。
>>528 広島。たまに大阪に出るから良い店教えてちょんまげ。
梅田のジュンク堂、紀伊国屋、旭屋やらまわったが見つけられなかった。
探し方ヘタなのかな・・・?
俺も疲れるもんで題名分かってる本は通販するんだわ。 esBooksに頼んだのが運の尽きかしらんけど、 発注して5日後に本社にしか在庫ねぇってメール来て、 入荷したら又メールするって来たんだわ。 で、それからさらに5日経過してるが、未だにとどかん。 計10日も待たされる・・・。 esBooks amazone クロネコブックサービス 紀伊国屋 どこが一番在庫量豊富なんだろう
>>531 Eiffelふうに書くと
class A {
public x() { ... }
}
class B extends A {
public x() { ... }
}
class C extends A {
public x() { ... }
}
class D extends B rename x as x1
select x1
end
C rename x as x2
end
{}
D d = new D() ;
A a = d ; a. x() ; // x1がよばれる
B b = d ; b. x() ; // x1がよばれる
C c = d ; c. x() ; // x2がよばれる
541 :
デフォルトの名無しさん :01/10/02 01:17
ライブラリに問題があれば新しいバージョンでそれを直せば良い。 Javaにはそれが出来ない宿命があるから改良する度にクラスがごっそり増える。藁
オブジェクト指向って いろいろボタンはついてるけど、説明書読まなきゃ何の事か分からない多機能リモコン みたいなもんに感じる
>543 それは言語仕様について? それともライブラリについて? 後者ならば確かに情報が多いが故に探すのが大変という、ネット社会にも 通じる議論になるが、過去の言語なら自作する必要のあったモノを利用できるのは 便利なはず。ただ、よく使うクラスをヘルプで特記してくれりゃ、とは思うが。
まあでも、OOに関係なく大きなライブラリになってくると どっかで探すより作った方が早い という分岐点があるように思うな。
546 :
デフォルトの名無しさん :01/10/02 08:53
>>539 技術書ならcbook24が速い。即日発送だし。在庫もすぐ確認できる。
bk1も関東なら(?)today便で翌日には届くが、予約も併用しないと送料がかかる。
amazonは配送は上記に比べて遅いが注文後のキャンセルがwebだけでできるので安心。
憂鬱な〜はかなりあちこちの本屋で売ってるな。
「憂鬱なプログラマのための」は小さく脇にあるだけで
オブジェクト指向〜がでかいタイトル。
>オブジェクト指向って >いろいろボタンはついてるけど、説明書読まなきゃ何の事か分からない多機能リモコン これは、全くの勘違いですね。 関数ライブラリというものが、呼び出し手順仕様書を読まなきゃ何の事か分からない多機能リモコン。 例えば、一万近くあるWin32API。殆どがサンプルコードを読まなければ使えない。 oopではWin32APIのコールセットがメソッドに纏めてあるので、呼び出し手順を意識しない。
そうかな? Win32APIはボタンが1万個ある単純なリモコンだと思うぞ。 OOライブラリはボタンの数を減らそうとして結果的に「多機能リモコン」 になってしまう。 関数は呼び出して返り値を使うことしか考えなくていいけど、クラスはいろいろと 考えなくてはならないことが多い。 #ちなみにだからOOはだめといってるわけじゃない
はぁ? >Win32APIはボタンが1万個ある単純なリモコンだと思うぞ。 リモコンのボタン押す順番間違えたらエラーになるよ。 >関数は呼び出して返り値を使うことしか考えなくていいけど、クラスはいろいろと 意味不明。メソッド名で処理が分かるじゃない。 関数は一個じゃなくて複数あるものを、正しい順番で呼びださないと。
550 :
マジアドバイス :01/10/02 17:16
なあみんな、「憂鬱な〜」よりも、メイヤーさんの「オブジェクト指向入門」を読もうよ。
>>549 >リモコンのボタン押す順番間違えたらエラーになるよ。
でも押すだけだから「単純」だろ?使いやすいといった覚えはないぞ
>>関数は呼び出して返り値を使うことしか考えなくていいけど、クラスはいろいろと
>意味不明。メソッド名で処理が分かるじゃない。
>関数は一個じゃなくて複数あるものを、正しい順番で呼びださないと
よくわからん。正しい順番で呼ぶ関数を新たに作ればいいんじゃない?
それともコンストラクタとデストラクタが自動的に呼ばれるということ
いってるのか?
それが有効なのは同意するが、ゆえに高機能で使いこなすのが大変な
(そしてもちろん使いこなせれば役に立つ)高機能リモコンなのでは?
つーかリモコンと喩えたアホが悪い
555 :
デフォルトの名無しさん :01/10/02 19:33
>>553 単純 = 簡単、 高機能 = 使いこなすのが大変
という図式は、逆だよね。
同じことをするのに、
単純 = 手間がかかる、 高機能 = 簡単
が普通だよね。
>>555 人によると思うよ
高機能なものは俺に取っては簡単ではない
俺は記憶力が他人に比べて異常に悪い(一つプロジェクトが終ると
前の事聞かれても全く覚えてないほどだ)だから
単純で機能がはっきりわかるものを組み合わせられる仕掛けならいいけどさ
BASICのように MID/LEFT/RIGHTと高機能な関数があるよりは
while(*d++=*s++); と基本タームを組み合わせる方が楽だ
>>556 関数によるアプローチが招く複雑さについてはメイヤーさんの本でも議論されとるぞい。
>>556 あんたはもうプログラマを辞めたほうが良いよ。
時代の変化についていけない哀れなC使いにしかみえん。
559 :
デフォルトの名無しさん :01/10/02 21:53
リモコンの例えはおかしいな。 オブジェクトはボタンがたくさんついているリモコンじゃないからな。 そもそも関数郡が単純なリモコンというたとえに無理がある。 オブジェクト=高機能でもない。 関数ライブラリこそ高機能なひとつの機械。 クラスライブラリは単機能な機械の集合。 関数ライブラリを使いこなすにはかなりの習熟が必要。 クラスライブラリもある程度の習熟が必要だけど、 関数の数よりクラスの数のほうが少ないから、 探し出しやすい。 またクラスを見つけた後は、機能がシンプルだから 操作方法が推定しやすい。 もちろん高機能なクラスが混じっていたら使いづらくなる ということは言うまでも無いが、 関数ライブラリは、個々の関数は単機能でも、 全体としてかなり高機能になってしまう。 だいたいクラスライブラリでも関数という単位はあるしね。
できのいい関数ライブラリはオブジェクト指向になっている。 オブジェクト指向に都合がいいことを言っていると思うかい? いやいや、オブジェクト指向とは突然湧き出てきたものじゃない。 「よいプログラム設計を分析して得られた結果」がオブジェクト指向なんだよ。 むやみやたらに作ってもなかなか上手い設計にはならないし、 全てのプログラマーが経験で学ぶというのも限界がある。 だから過去の成功例や失敗例を分析して、 誰でも成功できるように導いてやるほうがいい。 オブジェクト指向が完全な答えかどうかはわからないけれど、 一つだけ確実に言えることは、オブジェクト指向を学んで損することは何もないということ。 だからよけいなアレルギーは捨てて欲しいなぁ。
オブジェクト指向はよく難しいと言われる。 難しい概念だから、良くない概念だと思ってしまいがちだし、 それを振り回している奴らは鼻持ちならないように見えるかもしれない。 しかしオブジェクト指向はプログラミングの方法論ではなく、 プログラム設計の方法論なのよ。(※OOPはOOの実現方法でしかない) プログラミングができるようになっても、 うまく設計することがいかに難しいかは、 業務でプログラムしている人なら知っているでしょう。 それなら方法論がある程度難解になるのは 仕方がないということを悟るべき。 幸い、オブジェクト指向は、これまで生まれてきた 設計手法に比べて単純明快。 オブジェクトに仕事を委託しよう、 オブジェクトが作業する手段として関数と変数を所有させよう、 オブジェクトは契約を守ろう、というだけのもの。 (正確な表現じゃないけど、解りやすいでしょ?)
562 :
デフォルトの名無しさん :01/10/02 23:35
>>561 そして数百ページに及ぶ契約書を読まないと使えないのね。w
>>559 >関数の数よりクラスの数のほうが少ないから、
なにコレ?
564 :
デフォルトの名無しさん :01/10/02 23:50
>>561 反OO派の人も、カプセル化の意義について、疑問を感じる人は少ないと思うけど。
焦点はやはり、上書と多態を得るための代償(継承)についてでしょ。
OO派の人も、そろそろ理解できたと思うけど。
リモコンの話はもうやめたら? 例が悪いよ。
566 :
デフォルトの名無しさん :01/10/02 23:53
やっぱ無印サブルーチンとクラスの併用が一番優れていると思う。
567 :
デフォルトの名無しさん :01/10/03 00:34
>>566 あなたが正解!!
オブジェクト指向の生産性は最悪なわけよ。
だから小さなクラスライブラリと強力な関数なの
派閥毎の対抗意識が強すぎて、現実的な話しになりづらい。
ドーデも良いがいまどきオブジェクト指向を理解していない奴がいるのか? さっさと理解しておかないと職をなくすよ。
>そして数百ページに及ぶ契約書を読まないと使えないのね。w winapiを使ってたころは、リファレンスヘルプを印刷しまくってコーディングし、 エラーや動作しない場合は、サンプルコードを沢山探し印刷して理解した。 クラスライブラリでは、該当クラス宣言した後は、メソッド、プロパティ一覧されるから、 適当な呼び出しで動作する。その動作でどんなapiが呼び出されたのか知りたい場合、 そのプログラムをデバッガで中に入るだけでapiコールが全て見えるため数分で作業が終る。 つまり クラスライブラリ > リファレンス+サンプルコード
注意:クラスライブラリの下位では、apiをラップしたメソッドがあるので、apiを知りたい場合も余りない。
573 :
デフォルトの名無しさん :01/10/03 01:26
>>571 Javaの事を言ったつもりだった。
MFC>>>>>>JAVA
>>関数の数よりクラスの数のほうが少ないから、 >なにコレ? win32apiは一万を超えているが、クラスはその100分の1じゃないかな。 >焦点はやはり、上書と多態を得るための代償(継承)についてでしょ。 >OO派の人も、そろそろ理解できたと思うけど。 ?
575 :
デフォルトの名無しさん :01/10/03 01:28
ちなみにJavaでクラスブラウザ使っても、訳判らんクラスと 訳判らんメソッドが大量に画面埋め尽くすだけだと思われ。
576 :
デフォルトの名無しさん :01/10/03 01:29
APIってそんなにあるのか?一万。
>>572 apiをクラスでラップされると、環境毎(処理系、言語毎)
に異なるクラスライブラリを把握しないといけない。
素直にDLLにアクセスでき、関数が見えていてくれた方が
良い場合が多い。もしくはCOMの様なインタフェース。
(COMの実装が良いとは言わない)
apiからは離れとけ>357
そんなことよりOOの学習コストの高さによる 厨房OOPerの氾濫が深刻な問題なのである。
せっかくOOを理解しても、協調作業でそれを生かせられないと意味ナインだよね。 OOへの理解度のギャップを埋め合わせるためのうまいやり方ないかなあ。
580 :
デフォルトの名無しさん :01/10/03 01:37
サブルーチンが欲しい時にはクラス邪魔。 C++で全部クラスにする奴は逝って良し。 全部クラスにしないと使えないOOPな死ね! ||||| ______________ ||||| /_____________/| ||||| ___________ | | ||||| | | | || (* ゚Д゚)さん 投稿日:‐‐‐ | | | Λ Λ | |氏ね!! | | | / __/ ||クソ言語 が!! | | | /uu ||||||||||||\ ||クソスレ立てんな! | | | |∪u U | ||逝ってよし!!カス!! || | \_u___ / ||___________| |/| / \ |_____________/ | / \| A:=== | /|___ | \_____B:=== __ |/ | /) | |\ \@ABCDEFGHー / / // | | \uU ))□□□□□□□ / / // | \ )))________// // | \ ――――――――― // ――――――――――――
反OO派の人、OOを全否定は無理があるんじゃない? OO派の人も、OOの欠点を指摘されると、相手の理解不足にすり替えるのはやめたら?
OOを使うべき場合、使うべきでない場合、を切り分けてみたらいかがかしら?
OO分かる人が問題切り分けを行うべきってこと? まあ、それでもいいけど
OOは既存の方法論の延長線上にあるのだから、 全否定というのは無理だと思う。 反OO派の人は、まずこれを認識すべきでは? OOは方法論の最終形態ではないのだから、 欠点を全て否定するのは無理だと思う。 OO派の人は、まずこれを認識すべきでは?
>>586 OO派/反OO派って何?
きみ一人で言ってない?
588 :
デフォルトの名無しさん :01/10/03 02:23
他人を馬鹿にするのはタノシイのよ。日頃みんなに馬鹿にされてる人間でも、エラ クなった気になれるでしょ。そういう人間には、何いってもムダ。
>>587 〜〜派というのは、正誤に関わらず、自分の気に入った結論へ、
話を持って行こうとする人のことです。
そういう人が、かなりいると感じたので。
>>590 あなたの望みは、くだらない煽り合戦のようですね。
先が見えてきたので、もう寝ます。
>>592 両陣営とも、聞く耳なんて持ってないよ
今までのスレみれば、判りそうなもんだが
594 :
デフォルトの名無しさん :01/10/03 03:01
OOなんて大したことね〜よ。 高水準言語の常識、いまじゃあピンからキリまで使っている。 いまだにOOうんぬん言ってたら時代遅れになっちゃうぞ。
>>594 このスレ自体がナンセンスという事かな♪
596 :
デフォルトの名無しさん :01/10/03 03:11
>>594 殆どはOOPでクラス使って手続き型組んでるのね。w
597 :
デフォルトの名無しさん :01/10/03 03:25
>>596 OOPで関数型で人工知能エージェント型じゃなくて?
598 :
デフォルトの名無しさん :01/10/03 03:28
それも言語解析付きで? そりゃすごい。
599 :
デフォルトの名無しさん :01/10/03 03:31
XMLプロセッサと自然言語認識も付いて? すごいね。
600 :
デフォルトの名無しさん :01/10/03 04:49
Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高! Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高! Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高! Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高! Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高! Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高! Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高! Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高! Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高! Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!Ruby最高!
601 :
デフォルトの名無しさん :01/10/03 07:56
>
>>561 >そして数百ページに及ぶ契約書を読まないと使えないのね。w
おまえはDelphiのコンポーネントを使ったことがあるのかと問いたい。
問い詰めたい。小一時間問い詰めたい。
WindowsAPIのリファレンスを読むのと比較にならないくらい楽なのちゃうんかと。
>>594 激しく同意。
602 :
Delギコ :01/10/03 10:00
∧ ∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ (,,゚∀゚) < 問い詰めてヨシ | つ[|lllll]). \_________ 〜| | ∪∪ ∧ ∧ / ( ゚Д゚)< でも、疑問があるから聞いてよい? |つ つ \ 〜| | ∪ ∪ MyClassというクラスがあってそれが実用的なGUI部品だとしよう で、A,B,C,Dという4つの別々の機能があったとして それをMyClassに組み込みたい場合 どうやって実装すると綺麗? 派生してMyClassExとしてA,B,C,Dをすべて詰め合わせパックにしたらいいの? ここで全く別のアーキテクトから派生している MyClassChildという実用的なGUI部品があったとして その部品にA,B,C,Dの別々の機能を付加させたい場合も 考慮して設計を教えてくれるとありがたいのニャー
VCLはオブジェクト指向だって事でいいの?
VCLが オブジェクト指向だという結論なら オブジェクト指向マンセー
>>602 MyClassをMyClassChildは継承してるの?
継承してるなら MyClass+A+B+C+D をメンバーに持つクラスを作ればいいし
継承してないなら、MyClassとMyClassChildにインターフェースを被せて
インターフェイスメンバーとして持たせた新クラスを作ったら?
そうそう
純粋オブジェクト志向派みたいなのが
そういう場合は分析・設計段階が悪いみたいにのたまうんだよね
>>602 プログラミング技術としては フックで簡単に解決出来るならフックでやっつければいいと思うんだけどね
605 :
Delギコ :01/10/03 10:17
∧∧ プハー (,, ゚Д゚) =3 < 今日は寒いからココア飲んだ /つ日 〜(_ __) VCLはクラスライブラなのでオブジェ指向っす。 オブジェ指向じゃないわけがないっす。 >MyClassをMyClassChildは継承してるの? 名前の通りしてます。 イターフェースで実装すると ソースが分離しませんか? ソースコピペでインターフェース実装すればいいけど それはソース分離を引き起こすという ジレンマがあるような気がするのですが、、、勘違いかなあ。 いい方法論ってあるのっすか?
606 :
Delギコ :01/10/03 10:22
∧∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
@' ― (,,゚Д゚)つ <
>>604 そのとーり。禿げ同ヨ
し― ∪ \___________
設計が悪いとかノタマーないで欲しい。>>純オブ志派
フック・・・安全にフックorフック解除する仕組みがVCLに欲しい
こういう処理って何ていうか忘れたんだけど MyClassで使いそうな公開部を全部 MyClassExにコピーして その実装は全部 メンバーにした MyClassを呼ぶだけにしとけば 外からは MyClassExは MyClassとそっくりに見える訳ですよね? (ただ is as ではハネラレルけど) これを使えばって事ですよ
608 :
Delギコ :01/10/03 10:30
∩ ∩ | ∪ | | 〜 |∧ ∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ( ,,゚Д゚)つ < コノサイだからガンガン質問してやれ U \________ マタチガウ シツモソ デフ、 継承継承をガンガン行なっていくと SubClassの末端では メソッドの山ができるはずですが そういう所に問題はないのでしょうか? 継承すればするほど 永遠にpublicメソッドが増えていって収集つかなくなると思うのです。 デザパタ読んでいると、場合によってこういう実装するときがあるそうな。 クラス A メソッド 逝ってヨシ メソッド 似てヨシ メソッド 妬いてヨシ メソッド 句ってヨシ クラスB メソッド 逝ってヨシ {(逝ってヨシの実装) 例外発生} クラスBから逝ってヨシメソッドを呼ぶと 呼ばれたくないから冷害を発生させるだけのメソッド。 こんなのを実装する意味があるですか? 項いう事を行なわなければならないのは 既存のOO言語の問題点ではないかと思っているのですが どう思います?
609 :
デフォルトの名無しさん :01/10/03 10:42
>>608 同意
クラスB
メソッド 逝ってヨシ ; アボーン;
で無視されるようになっていればいいかも
(アボーンは継承先でも有効だけど復活も可能にする)
いくらなんでも例外発生を実装するのはダサい
610 :
デフォルトの名無しさん :01/10/03 10:59
>>605 MyClassにABCDメソッドを追加すれば良い。既に継承しているのなら、考える余地
がないと思うが。何が言いたいのかわからん。
>>610 自分のライブラリなら普通そうだけど
他人のライブラリでソース無い場合は?
ようは既にあるのを組み合わせる技術は多少OOの原則から外れる場合はあってヨシ?
613 :
デフォルトの名無しさん :01/10/03 11:32
>>611 例えば、
1 メソッドA,B,C,Dを実装したクラスABCDを作る。
2 MyClassのpublicメソッドとA,B,C,DをもつインターフェイスMyClassAndABCD
をつくる。
3 MyClassの子供MyClassExをMyClassAndABCDをインプリメントして作る。
4 MyClassExには、MyClassAndABCDのオブジェクトを持たせて、メソッドA,B,C,D
はすべてそのオブジェクトのメソッド呼び出しへの委譲とする。
5 MyClassChildはソースがいじれるなら、4と同じ作業をする。だめならMyClassChildEx
を造って4と同じ作業をする。
6 以後、MyClassExとMyClassChild(またはMyClassChildEx)は、MyClassAndABCDとして
利用できる。
なんてどうかな。
614 :
Delギコ :01/10/03 11:55
>>610 さん
>>602 をみておいてね
∧ ∧ / ̄
(∩(,,゚Д゚) < A,B,C,Dは。それぞれ別機能
⊂,,__つつ. \_ A,B,C,Dそれぞれに内部関数が複数あったり
メッセージ横取りをいろいろする必要があるとしよう。
出来ることなら構造化の概念から
Aを実装したMyClassA
Bを実装したMyClassB
Cを実装したMyClassC
Dを実装したMyClassD
を作りたいのだが、
ABを組み合わせたMyClassAB
ACを組み合わせたMyClassAC
BDを...MyClassBD
全部の組み合わせ
これも使いたい場合がある。
各々の実装を考えると気が狂うからABCDをすべて実装した
MyClassABCD=MyClassExと名前付けた
ものを実装するというイメージをしてくだされ。
(すでにこのあたりからOO的継承の問題点が露呈しまくり)
このMyClassExは普段プログラムで使えるベンリ部品として
使いつづけるとしましょう。
で、それを
MyClassから更に別の機能をもたせた派生クラスMyChildClass
をもってきたとして(MyChildClassもベンリ部品として使いつづける)
MyChildClassABCDを作る時には
どうしたらいいのか?
ってコトを聞きたい。
MyClassExのソースをコピペして
MyClildClassExを作るのは簡単ですがバカバカしいでしょ。
今時ソースコピペなんてさ。
615 :
Delギコ :01/10/03 12:00
>>607 さん。
デコレーションでしたっけ。
∧∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
(,,゚Д゚) < ただ、既存のクラスライブラリ(VCL)を使ってると
ヽ/つ且~~ \_無理なんですよね・・・・・・
(__ _)
ムズカシイ モンダイ
ここで「設計が悪い」なんて、
VCLより使いやすいクラスライブラリを作れる自信がないなら
言わないで欲しいニャ。
>>609 さん。
∧∧ / ̄ですよねー。
(,,゚Д゚) < 継承先クラスが継承元クラスのすべての
ヽ/つ且~~ \_メソドを実装する仕組み。が
(__ _) なぜ当然のものとして受け入れられているのか・・・ネコニャわからない
ただ、C++だと
クラスB
メソッド 逝ってヨシ ; アボーン;
の"アボーン"をマクロで例外発生するように
書いておけといわれるかもしれないけど、
言語レベルでその仕組みを(当然)実装するべきなんじゃないかと。
616 :
Delギコ :01/10/03 12:05
>>613 さん
∧ ∧ / ̄ ありがとございます。
(∩(,,゚Д゚) < がんばって考えてみます。
⊂,,__つつ. \_
【インプリメントして作る】の意味が イマ3つ くらいわからないっす。
617 :
デフォルトの名無しさん :01/10/03 12:13
>>615 607じゃないけど、
>継承先クラスが継承元クラスのすべてのメソドを実装する仕組み。が
>なぜ当然のものとして受け入れられているのか・・・ネコニャわからない
って言っても、もし選択的に継承できたら、ポリモーフィズムができな
いんじゃないの?
>>616 ごめん、Javaです。
インプリメント=実装
インプリメントしてつくる、は単に、インプリメントする、と言うべき
でした。
619 :
Delギコ :01/10/03 12:25
> ここで「設計が悪い」なんて、 > VCLより使いやすいクラスライブラリを作れる自信がないなら > 言わないで欲しいニャ。 チトイイスギタ ∧ ∧ / ̄ (∩(,,゚Д゚) < 「設計が悪い」っていう言葉で ⊂,,__つつ. \_思考停止しないで欲しいってコトです。 どうやって設計しておくべきか。 どうやって改善するべきかを、考えてくださると、サイコーっす。 みなさんが知っているOO言語や 既存のクラスライブラリなどで こういうことを解決されているものがあるのでしたら、 ∧ ∧ (,,゚Д゚) 教えてチョーダイ にゃー / つつ ⊂ ノ /(/″ LISPで実行時にソースを読ませるコトができるなら 簡単かもしれない...でもLISPは全く氏らん
620 :
Delギコ :01/10/03 12:26
∧ ∧
>>617 (゚Д゚,,) だって例外発生するだけならメソッドがないのといっしょじゃーん
⊂ ⊂)
⊂ ノ そのメソドについてはポリモする必要がない場合だと
/(/″ 考えておくんなまし。(どこの方言?)
>>Delギコ C++/Java/ObjectPascal といった言語に拘らなければ方法はあるけどねぇ。 こういう言語で書かれた既存の資産があるという状況じゃ難しいわな。
>>611 > 他人のライブラリでソース無い場合は?
だったらMyClassなんて名前つけるなよ。付き合いきれん。
623 :
Delギコ :01/10/03 13:01
>C++/Java/ObjectPascal といった言語に拘らなければ方法はあるけどねぇ。
それでもYOいから教えて教えて
>>621 ∧ ∧
(,,゚Д゚) 教えてくんないとダダこねるぞ(ウソ)
/ つつ
⊂ ノ smalltalkやO-Cなどでは実現できるのかしら?
/(/″
∧_∧ <<しーちゃん
(*゚ー゚)
C#でもいいです。
JavaかDelPascalかC#が何らかそういう進化をするとうれしい。
(C++の進化には気体しませんが)
∧∧ /
>>610 @' ― (,,゚Д゚)つ < 理解できないのを付き合いきれん
し― ∪ \ というのは、どうかと・・・
611はオレ ト チガウシ
>>620 前提として、なぜ子クラスで、親クラスにあるメソッドをなくしたいのか、という
点だけど、呼ばれるとまずいから、だよね。
であれば、呼ばれたら例外を投げるということで問題ないと思うけど。
コンパイル時にそれをチェックしたいということなら、javaの場合は、その
メソッド以外のpublicメソッドだけを含んだinterfaceを定義して、子クラス
はそれをインプリメントして、以後、子クラスのオブジェクトはそのinterface
の型として扱えばいいと思うけどね。
Delphiではどうやるのかな?
>>Delギコ デコレータパターソでそういうのはやるのでは? ガイシュツか。 じゃ別の方法, 1)a,b,c,dの機能を実装したクラスA,B,C,Dをそれぞれ作る。 2)クラスA,B,C,Dのオブジェクトをメンバーに持ち委譲するための メソッドを持つクラスmixA,mixB,mixC,mixDを作る。 3)MyClassとmixA〜mixDを必要なだけ多重継承した新しいクラスMyClassExをつくる。 ってのは? え?多重継承出来ないって?
多重継承の代わりにインターフェースでやればいいでしょ というか A,B,C,Dにとって必要な操作 IMyInterface を定義しといて MyClass と MyClildClass に被せて A,B,C,Dは独立なインスタンスでいいんじゃないの?
628 :
Delギコ :01/10/03 13:36
>>625 さん
>であれば、呼ばれたら例外を投げるということで問題ないと思うけど。
∧∧l||l そっすか、メソッド隠蔽の必要はないと・・・
/⌒ヽ) トホホ
〜(___)
''" ""''"" "''
>そのメソッド以外のpublicメソッドだけを含んだinterfaceを定義して、子クラス
>はそれをインプリメントして、以後、子クラスのオブジェクトはそのinterface
>の型として扱えばいいと思うけどね。
!
∧ ∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
(,,゚Д゚) < なるほど!(ざ わうるど)
./ | \__________
〜(___/
デ…デルフィ でもできるかな…
>>626 さん
>デコレータパターソでそういうのはやるのでは?
概念的に全てのメソドをデコレすれば
GUI部品でもオナジコトは出来そうなのですが
VCLのGUIクラスでは....できるのかな,,,なんか無理そうです。
>え?多重継承出来ないって?
ガビーン・・・(゚Д゚;)ツョック
>>627 さん
そうですそうです。そうできればいいです。
>多重継承の代わりにインターフェースでやればいいでしょ
でもインタフェスは毎度毎度同じ実装しなきゃいけない気が…
ソースコピペ???
ソースコピペって? 同じメソッド名 プロパティ名にする以上になにか必要なの?
>>627 が言っているように,その機能を受け持つインスタンスを独立に生成しておいて
そのオブジェクトに委譲するようにすれば委譲のためのコードを書くだけですむから,
(本来の)実装コードを書く必要はないと思うけど?
631 :
デフォルトの名無しさん :01/10/03 14:01
話が若干それるけど スタティックバインドを前提にしてる言語に ダイナミックバインドを付加するために 未定義メソッドが呼ばれたらそれ用のイベントを発生させて そいつを呼び出された側のインスタンスで実装できるってのどうだろう? こんなの。 main(){ (new Hoge()).undefinedMethod( x, y) ; // Hoge には undefinedMethod は定義されていないとする。 // この呼び出しは Hoge::onMisbinding を呼び出す。 } class Hoge{ handler void onMisbinding( CallContext context){ // context には呼び出されたメソッドの名前、 // 呼び出しの引数、期待される戻り値の型などが含まれる。 } } ; これとリフレクションを組み合わせれば、委譲の実装がすげー楽になるような。 あ、もちろん、そういう風な言語が作れないかな、って話ね。
MyClassとかのメソッド置換(継承)が必要なければ type IMyClassCtl = interface (IUnknown) function Execute: Boolean; // とか MyClassの制御に 必要な全部のメソッドを定義 end; 後は TMyClass = class(TOpenDialog,IMyClassCtl) end; TMyChildClass = class(TSaveDialog,IMyClassCtl) end; みたいに1行書くだけ A,B,C,Dのメンバーに var My: IMyClassCtl; を持たせて My:=TMyClass.Create(nil); とかでメンバー設定すればいいわけで A,B,C,DがMyClassを使う為にMyClass側のメソッドの置換(継承)が必要なら、 継承が必要な部分をイベントにして A,B,C,Dの全てが使えるにようにしてやればいいんじゃないの?
たとえば A,B,Cの3つが Windowメッセージに割り込む必要があるのなら OnMessageA/OnMessageB/OnMessageC と3つのプロパティを用意してやるって事ね ただ、TMyClassを設計時に使いたいとか言い出したらメンドクサイ事になるけど
634 :
Delギコ :01/10/03 15:04
∧ ∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄
(,,゚Д゚) <
>>632-633 すばらC.
| つつヾ \_______
〜| | パチパチ
∪∪ アリガトー
実装しないとわからない所が出てきたのでガンバテみます。
636 :
デフォルトの名無しさん :01/10/03 15:18
>>619 >どうやって設計しておくべきか。
>どうやって改善するべきかを、考えてくださると、サイコーっす。
「この場合はこうだ」という明確な答えはない。
でも改善法なら教えられるぞ。
まず一つが状態遷移。継承がどうこう言う前に、オブジェクトがどのような状態をとるのか、
しっかり把握しないといけない。オブジェクトには状態がある。
内外から発生するイベントによって状態が変化するというモデルがある。
それをふまえた上でクラスを設計できるようになってないでしょ?
これについては憂鬱本が詳しいので参照して欲しい。
次に勉強すべきはデザインパターン。
今回のギコの例で言えば、Decorator、Facade、Mediator、Strategyなどのパターンが
応用できると思われるし、他のパターンも流用できるかもしれない。
どのパターンが適切かは状況にもよるし、設計者の好みにも依存するから、
ギコ自身が選択しなければならない。
とにかく新しいパターンを生み出す前に、過去のパターンをよく研究した方がいい。
そしてUML。設計の善し悪しを判断する最高の方法は現時点ではUMLを使うことだと思う。
目に見える形になることで頭の中が整理されるし、
オブジェクト同士の関連線を減らすという機械的な作業で設計を改善できるところがいい。
さらに他人でもクラスの設計が容易に把握できるようになり、
一人の考えではなく、大勢の意見を採り入れた設計ができるようになる。
言い換えれば、一人でコードをこねくり回しても限界があるということ。
>>628 たとえばStateパターンで実装するときに、当然それぞれのStateの
Concrete Classは同じインタフェースを持つわけだけど、状態に
よっては実行できないメソッドも出てくる。
元々のコードが
void foo::bar() {
if(state == xxx) 例外;
処理;
}
だとすると、その状態を抜き出したConcrete Classのメソッドは、
void fooStateA::bar() {
例外;
}
になると思う。
638 :
Delギコ :01/10/03 17:08
∧∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
〜''~(,,゚Д゚) < ありがとうございます。
>>636-637 UU'UU \________
デザパタ はJava結城本で勉強中です.これ面白くてたまりません。
憂うつ本も1度は読んだのですが、身についてないのかな。
サイキンはDelphiでVCLの継承をして
機能追加を計ることが多いのですが
それで、中々うまく出来ない部分があって大変なのです。
…つまり、MyClassは素のクラスじゃなくてVCL継承クラスとして
想定していたのですが…
デザパタの話も読んでいてわかるのですが
Java結城本に出ているような
簡単なものならOKですが
どうしても、GUI部品クラス(VCLでいうとTWinControl以下)になると
理想どおりには扱えなくて応用がつらいものがあります。
世間のクラスライブラリでGUIで
しっかりとデザパタ物を扱えるものってあるのでしょうか。
例えばJBuilderしか使った事ないのですが
JavaでTextField(JTextFieldでしたっけ?)を
HasAしてまるでTextFieldのように扱えるのでしょうか。
DelphiRADの設計時までを想定しているから
一人で落とし穴に落ちているだけかな…
Delギコって説明下手だったんだなぁ。
640 :
亀レススマソ :01/10/03 19:12
>>638 >JavaでTextField(JTextFieldでしたっけ?)を
>HasAしてまるでTextFieldのように扱えるのでしょうか
正直、これは大変すぎると思う。やったことないけど。やはり、この場合は、
素直に継承して必要な機能は付け足すか、または、継承せずとも、リスナなど
を工夫して、必要な機能を付加するなどのアプローチでは。
デザパタのDecoratorパターンでも、componentとdecoratorが共通して
継承するComponentクラスは軽くなければならないと言われているけれど、
javaのJTextFieldの継承しているJComponentクラスは、決して軽くない
からね。
642 :
デフォルトの名無しさん :01/10/03 21:06
>>638 知ってると思うけど、VCLはCompositeパターンだぞ。
無理に継承しなくていいんじゃないのか?
単にhasしておけばいいのでは。
ていうかこういう場合はC++の出番(Eiffelでもいいけど)。
TMyForm<TButton, TPanel> *p = new TMyForm<TButton, TPanel>(this);
C++Builderでは、このコード動くよ、マジで。
まぁこれがObjectPascalの限界ってことかな。
書いた後で気づいたけど、これはdelギコの要求を満たしてないなぁ。 テンプレートでスーパークラスを抽象化してみると……。 template<class T> class MyForm : public TForm, public T [C++ エラー] Unit1.cpp(18): E2278 VCL クラスでは複数の基本クラスはサポートされない C++BuilderでもVCLだけは多重継承できないように制限されているのか…。 ObjectPascalは多重継承ができないから、 Javaのようにインターフェイスと実装を分けなければならなかったのに、 VCLは実装継承でライブラリのツリーを作ってしまった。 ここに問題があるのでは? たぶんDelphiが元からC++だったら問題はなかったと思うよ。 だとするとやはりDecoratorパターンを使って誤魔化すしかないか。 多重継承できないんだからしょうがないよ。
(ワラタ Delウザ&ダザ せいぜい低レベルOOPやってろ お前にはその程度がお似合いだよ
645 :
デフォルトの名無しさん :01/10/04 01:01
まあ、あれだ。 何も継承してない「サブルーチン・ライブラリクラス」作って 何もかも詰め込んで委譲で実装。終了だな。
646 :
Delギコ :01/10/04 10:40
∩ ∩
| ∪ | コンバンハ アメ ダッテヨ
| 〜
| ∧ ∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
|( ,,゚Д゚) < おはようSUN
U U \________
>>641 >デザパタのDecoratorパターンでも、componentとdecoratorが共通して
>継承するComponentクラスは軽くなければならないと言われているけれど
なるほどです。
DelphiのVCLも似たようなモンダイを抱えていて(本当かな)
TEditをHasAしてTEditのようには今ひとつ自由に扱えません(タブン)
とくにRADとしての設計時の動作を考えると無理っぽいです。
(DelphiRADは設計時にもインスタンスが生成されてるから)
逆に実行時の事だけ考えたらTEditをHasAしてもなんとかなりそうだけど
>>642 >知ってると思うけど、VCLはCompositeパターンだぞ。
え?どのあたりがですか?
開発者にはあまり見えなくなっているのですかね。
>>643 泣きますか・・・
もうすこし、Interfaceの理解を深めてみます。
>>645 ・・・そういえば折れはOO指向継承懐疑派です。
647 :
デフォルトの名無しさん :01/10/04 10:49
・Fオ・(�OクФ9ノ9YL2ラh爐3槽、2哂.。G ,(・ォkャ偶黐鉗ゆ2g5ゥ・ュ>US3 kHW賎N杏レ1オ音n痰~ �ニ倪Sツ・躑ロヨ・・雰サ・・2ニ♪Dケ8FぼU・「T・T&<・3>he・~5 頚{土`ハタWョミ堕キマoF ス・oウ゚rサ}ノ・儻lコd閨メシュl・。ン熬レフLル4カ`サ・7M@ヒ|鴻犒m゚ ・(妥チUHノLm!ヲ`・ノロモ_些幼」v・、忝紮ュF蕈\yュォ鯆Q|fヘ粫J`lwq ・覡Xム卯Hォユユ ?リm/・能ゥコ・{ヘU25Ek私槁ロPc�Zlレネク・\ ロォL・Yツ�ユ・・ュ・ノ5ェニfセ/ェ%#K煙mxjJオO<ス*・78=ュケァクニt杠<m智]ア`:マLケ。*ハ・ < でd +1グアVJタ',セBナJB\ェ勧f・・マヒN%・Vrケレe・Uサク・P!Rー性ァ]uユキウ云GァS�*g: ・^H4ソイ ウ隆e\m純9Rメテ@・{臙i・・~ヤH垈スmェフ|Kエd・~QッニヘN・呼.nWオ罔N゙Nラテモi&問 ・破ラ隨Nc・tナАJ・'ネkoヒシi儘∵ミx7ユFセ蠕ッ・sスk^ラBヨ?・~ロwノ0Q%ル6o假Afi オウぐ;。AノG6衞。Yz瓔ユマlBリ*)」E・エァカ 達ユ髴~�ィ%?,ロ鋤De
OOなプロジェクトで成功してるものって腐るほどありますよね。 KDE, WindowsはNT3.51から, BeOS(これはある意味失敗か) qmailもOOな設計ゆえあのような形態になったそうです。
649 :
デフォルトの名無しさん :01/10/04 11:42
今、OOじゃないプロジェクトって、元COBOLERのJava開発とブビ坊しかないYO!
>>649 HSPを忘れるな
プロジェクトと呼べる物をやってるやつがいるかどうかはあやしいが
651 :
デフォルトの名無しさん :01/10/04 16:49
忘れる前に、知らなかったYO!
>>646 >>知ってると思うけど、VCLはCompositeパターンだぞ。
>え?どのあたりがですか?
TComponentがだよ…
それと、これを継承した全てのクラス。
>開発者にはあまり見えなくなっているのですかね。
丸見えだと思うが…
本当にVCLを使ったことあるの?
653 :
Delギコ :01/10/04 22:10
,,'''~''~'∧,,∧
>>652 〜′,,,;;,, (,゜Д゜)
UU" " U U
アア カルシウムブソク
ちゃんと説明したらどうヨ?
>Delギコ相談室スレ全部よんどけ。
・Compositeパターン
容器と中身を同一視して再帰的構造を作る
って、TComponentのどこに再帰構造があるの?
∧∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
(,,゚Д゚) < 単なるあおりに反応してしまっただけかも。
@/つ且~~ \___________
(__ _) オレ ガキ ダナー
デザパタ本が糞なのか。読み手がアフォなのか。 たぶん後者だろう。
>>653 TComponent.Components
656 :
Delギコ :01/10/04 22:22
| 電 | カゲデコソコソ イッテヤル |∧ ∧ 柱 |,,゚Д゚) <ナナナ・・・るほど。 ⊂ | | | シカシ、普段ComponentsなんてFormでしか |∪ つかーねだろ。むしろControlsプロパの方が・・・ , ' , ; ' ; ミグルシイイイワケダ
いや、きちんと説明したほうがいいか。 すぐわかるかと思ったんだけど、どうやら真性みたいだからな。 いいか、TFormもTButtonもTComponentなんだよ。 一見するとTFormがTButtonなどのビジュアルコンポーネントを持てるだけに見えるかもしれないが、 しかしそういう仕組みにはなっていない。 TComponentがTComponentを所有できるようになっているだけ。 TComponentがTComponentを再帰的に所有できるんだよ。 TComponentのComponentsというプロパティに、 TComponentが所有している他のTComponentのリストが入っている。 これがあるからTFormはTButtonを所有することができる。 コンポーネントをクリエイトするときにOwnerへのポインタを渡すだろ。 これは、親のComponentsに自分を登録してもらうために渡している。 つまりキミは日常的にCompositeパターンを使っているんだよ。 TButtonがTFormを所有することもできるはず。 TFormが小細工していなければ、だけど。 TFormにTFormを貼り付けることもできる。 ただしフォームデザイナからはこういう操作はできない。 コンポーネントパターンはこうした自由度をもたらすパワーがあるけれど、 フォームデザイナの都合でちょっとパワーダウンしている。 それでもCompositeパターンの強力さを垣間見ることはできるはずだ。 ビジュアルコンポーネントではないTOpenDialogをTFormに貼り付けられるのも、 これがTComponentを継承しているからなんだよ。 これでわかった? それともサンプルプログラムでも書かないとわからないかい?
>>656 おお、前後してしまった。
わかってくれたようでなにより。
VCLはコンポーネントのリンクを維持するためにComponentsプロパティをフル活用しているよ。
Visual "Component" Library という名前はCompositeパターンに由来しているくらいだからね。
古勝用
660 :
デフォルトの名無しさん :01/10/05 01:17
661 :
デフォルトの名無しさん :01/10/05 01:28
/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ | ありがとうございます。首相並に感動しました。 | 丁寧な解説でより理解できました。 | ご親切な方ですね。 \___ _________ ∨ ♪ ∧ ∧ ♪ (,,゚Д゚). ♪ |つ[|lllll]). 〜| | U U ウーレシ 真性とかイワンで〜 デザパタしらないでいたら Componentsが再帰的とか知らない&気が付いてない人は 山ほどおると思いますよ。 コンポ作成していてもInsertComponentをせずに メンバーとして持つ事も多いでしょうし。 最近デザパタやUMLマンセーっす
662 :
デフォルトの名無しさん :01/10/05 01:28
そもそもクラスと言う物の発明は思いつきの産物。 一般化して有効に使えるという証明など無かったのに一般化してしまった。 流行も内輪でやってるなら良いけど、宣伝で会社を巻き込まないで 欲しい。(仕事に影響出てくるんで)
663 :
デフォルトの名無しさん :01/10/05 02:16
>フォームデザイナの都合でちょっとパワーダウンしている。
ComponentsとControlsという、いわば「Compositeパターンの二重管理」状態に
なってるのが、時として自由度を下げているかも、とは思う。
あんまり綺麗ではないな確かに。
>>661 >デザパタしらないでいたら
>Componentsが再帰的とか知らない&気が付いてない人は
俺はデザパタなんて知らなかったが(というかデザパタ自体が
有名になってまだ数年しかたってない)、Delのその部分は
気付いてたぞ。実際自作コンポでもしばしば使ったし。
なんで知ってたかって?そりゃ「マニュアル読んだ」からに決まってる。
ComponentsがTComponent型だと気付いた瞬間に、「じゃあ再帰的に突っ込めるんだろうな?」と
突っ込みをいれたくなる(そしてテストコードを書いてみる)のは、
プログラマならデフォだろう。
抽象的なパターンを考えることと、
具体的なDelのComponentsを考えることとは、
似ているようで、微妙に違う。
もちろん両方を考えて、実は同じことを言っていると気付くことは
最終的に大事ではあるが、それは後でも間に合う。
>>662 証明を期待するなよ。証明できる物事もあるが、証明じゃなく経験で
有用性が見出されるものも、有っておかしいわけじゃない。
発明者(?)の意図を超えるほど有用なもの、ってのは
しばしば有るだろう。
Classもそういうものの1つだった、というだけだ。
それを無理矢理、流行で片付けようとヒッキーごっこするのは
カコワルィよ。
664 :
デフォルトの名無しさん :01/10/05 02:40
>>663 そうそう
>ComponentsがTComponent型だと気付いた瞬間に、「じゃあ再帰的に突っ込めるんだろうな?」と
>突っ込みをいれたくなる(そしてテストコードを書いてみる)のは、
>プログラマならデフォだろう。
テストコードというより
画面の解像度に合わせて部品のサイズを自動調整するには普通そうするよね
665 :
デフォルトの名無しさん :01/10/05 06:02
デザパタをありがたがっているような奴はクズ。 あれぐらいモデリングをしっかりすれば自分で考え出せるだろう。 デザパタの意義は、カタログにしたその取り組みにあるだけ。
デザパタをありがたがっているような奴はクズ。 あれぐらいモデリングをしっかりすれば自分で考え出せるだろう。 デザパタの意義は、カタログにしたその取り組みにあるだけ。
おいおい。あれを使える場面で当たり前のように考え出して使う奴は 天才だろ。時々考え出してしまうこともあるかもしれないが、 多くの状況では知ってなきゃ使わない類のもんだ。 初めて考え付くのが偉大なのに、知った後から「こんなもん簡単だ」 なんて思うのは当たり前。そんなこともわからないのは馬鹿の証拠。
668 :
Delギコ :01/10/05 09:53
>>デザパタをありがたがっているような奴はクズ。 >おいおい。あれを使える場面で当たり前のように考え出して使う奴は >天才だろ。時々考え出してしまうこともあるかもしれないが、 ∧ ∧ / ̄ (∩(,,゚Д゚) < よかった、デザパ初心者だから ⊂,,__つつ. \ 変な意見を鵜呑みにするトコだったよ。 今朝読んだFlyweightパターンは自分で実装してたなあ。 >デザパタ自体が有名になってまだ数年しかたってない)、 プログラネコ-になてからまだ数年しかたってないんですが… >ComponentsがTComponent型だと気付いた瞬間に、「じゃあ再帰的に突っ込めるんだろうな?」と >突っ込みをいれたくなる(そしてテストコードを書いてみる)のは、 >プログラマならデフォだろう。 デ・デフォなんですか? > 抽象的なパターンを考えることと、 > 具体的なDelのComponentsを考えることとは、 > 似ているようで、微妙に違う。 ネコにはまだまだだいぶ違うです >もちろん両方を考えて、実は同じことを言っていると気付くことは まだ、なかなか...その境地に達してないつーかニャー
669 :
デフォルトの名無しさん :01/10/05 18:42
>>667 表現はともかくとして
>>666 に私は賛成の立場です。
「利用する」より「考える」ことの方が重要と思います。デザパタを知る
ことでとても大切な事を考える事が疎かになるならばその先の成長は見込
めないと思います。利用する前になぜそれが必要なのかをじっくりと考え
られればまだ救われますが、それができる人もまた限りられたひとだろう
と思います。天才と簡単に言われていますが、天才というよりも、良い
デザインや実装をしようということに拘ったからこそ、デザパタが作られたので
あって天才だったから簡単に作り出したというわけではないという所が
肝かと思います。またデザパタを知ったからといって、それで簡単あるいは
優れた設計や実装ができる訳ではないと思います。それを知ってもさらに考える
事が必要ですから、その時に再度「考える」という事が問われます。そして
それを突き詰めて考え解決できるならば、デザパタも作り出せるだけの力が
付いていると思われますので、結局はデザパタを知ることよりも「考える力」
を付けることを重視した方が、先に繋がるでしょう。
>>669 急がば回れですね。う〜ん。
確かにそういうことって多いよな〜。学校教育ってもろそういう所
あるものね。問題解決能力を高める事が重要ってことね。
内容なくて、スマソ。
671 :
デフォルトの名無しさん :01/10/05 18:50
>>669 デザパタを通して,考える力を養えればよいわけですよね.
どういう関わりをすればそうなるのだろう.
>>669 なんか違くない?
>天才というよりも、良い
>デザインや実装をしようということに拘ったからこそ、デザパタが作られたので
>あって天才だったから簡単に作り出したというわけではないという所が
>肝かと思います。
>>667 は、天才がデザインパターンを作ったとは言ってないよね。
いちいちデザパタを発明できるような天才はいないと言っているのでは。
デザインパターンがデザインを考える機会を削ぐという発想には反対。
アルゴリズムを学んだ人が新しいアルゴリズムを生み出せなくなったかというと、
そうでもないでしょう。むしろアルゴリズムに強い人は、
過去のアルゴリズムをよく知っている。
高速フーリエを知らない人がMP3を生み出せるとは思えないね。
アルゴリズムを教えると、アルゴリズムを考える力がなくなるから、
大学でアルゴリズムを教えない方がいいの?
それっておかしいよね。
アルゴリズムもデザインパターンも、基礎教育として教えるべきだと思う。
それで思考停止してしまう一万人は無視して、より深い指向ができる百万人を育てようよ。
673 :
デフォルトの名無しさん :01/10/05 19:28
>> 672 |アルゴリズムもデザインパターンも、基礎教育として教えるべきだと思う。 それはなぜですか?
というか
>>666 の逝ってることと
>>669 の言ってることって全然違うだろ。
666みたいのを見ると、漫画初めて物語で観た
「コロンブスの卵」のエピソードを思い出す。
>>673 「情報工学を学ぶ学生の基礎教育として」という意味でした。
言葉足らずですいません。
677 :
デフォルトの名無しさん :01/10/05 20:51
>>676 僕もどちらかというとデザパタに縛られている人には危惧を
感じます。
情報工学を学んだとしても、優秀でない人はあまりその恩恵は受けて
いないようにおもわれます。ここでの優秀というのは問題を突き詰めて考え
られるかどうかという程度です。
逆に、情報工学を学んでいなくても、問題を突き詰めて考える人は
どんどん伸びるように思われますが、どうでしょう?
もちろん学者になろうというのであれば、そういった工学を学び
研究していくという道もあろうかと思いますが、現在の情報工学
は現場ではそれほど生きていないように感じます。
一般的によくみるのは、流行の技術を追い掛け、ちょっと人より
知っていることに優越感を感じそれに満足しているというパター
ンです。そして、そういう人に限ってプロジェクトにあれこれと
文脈を無視した意見をしプロジェクトを路頭に迷わせ、だめな
やつらだと愚痴をいってまた自己満足。そんな人、多くないでしょうか?
デザパタが出てくる前にもOOですぐれたシステムは作られていた
訳ですから必須項目とは思えません。
工学としてならう枯れたアルゴリズムとデザパタを同列に扱うとおっしゃるとおり、知っていた
方がよいという考えになると思いますが、そういったアルゴリズムは
帰納的なもので、
設計というのはそのつど問題に向き合い解決していくものではありますが
答えが一つとは限らない演繹的なものなので、同列に扱うのはどうかと
思います。
>>666 の馬鹿発言が誤解されて、偉く立派な意見に様変わりしてるな。(藁
679 :
Delギコ :01/10/05 20:59
∧ ∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
(,,゚Д゚) < デザパタは設計を考え事を加速させる
| つ[|lllll]). \_________
〜| |
∪∪
クラスライブラリを使っていただけで、なんでも作れると
思ってしまっていたけど
デザパタで深遠なるオブジェ志向の扉を開けれた気がするよ。
>デザインパターンがデザインを考える機会を削ぐという発想には反対。
そうそう。
機械を削ぐとはムシロ逆。
デザインをより深く考えてデザパタを組み合わせたり
自分で新しいものを作る糧になるのでは?
>>672 氏イイ!
でも、基礎教育で教えても
プログラムが余り組めない人に役に立つかどうか…
>677 あんま論理的思考が得意ではなさそうだな。 大学も出てなさそうだな。 SEとコミュニケーションがうまく取れてなさそうだな。 ストレス溜まってそうだな。
681 :
デフォルトの名無しさん :01/10/05 21:02
デザパタに出てくるパターンそのものは大したことないだろう。 大抵のプログラマなら自分で同様の物を考え出して 過去に実際に使ってみたことがあるはず。 ただ、それをパターンという形に括りだして、分類して、 名前を付けて、ああいうカタログ本にまとめたことが偉い。 ノウハウは整理体系化されることでテクノロジーになる、そういうもんじゃない?
682 :
Delギコ :01/10/05 21:03
>>677 氏
デザパタに縛られるっていうのは
いっつも、forループも使わずにイテレタしちゃう人っていう事でしょうか?
それはそれで確かに迷惑かも。
そもそも、イテレタだけは役に立たないと感じたけど。
> 一般的によくみるのは、流行の技術を追い掛け、ちょっと人より
> 知っていることに優越感を感じそれに満足しているというパター
> ンです。
∧ ∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
〜′ ̄ ̄(;゚Д゚)< ガビーン。折れかも。
UU ̄ ̄ U U \_____________
だけど、周りの人がちょっと(いや、かなり)知らないから
半年かかっても出来ない事を
ちょっと知ってて3日で出来たりしたらうれしいし
役に立つと思うんだけど…
例えばタブブラウザ作りたいって時に
ブラウザを1から作っちゃう人ばかりの中に
「IEのActiveX使えばいいよ」
って言えるのって、だめ?
>>680 氏
"だな"、多そうだな
683 :
デフォルトの名無しさん :01/10/05 21:07
>いっつも、forループも使わずにイテレタしちゃう人っていう事でしょうか? 最近はfor使わずにイテレータ、foreachなんかを文法に組み込むのが流行りだね。
684 :
デフォルトの名無しさん :01/10/05 21:11
デザパタもいいけど、リファクタリングもイイ! OOマンセー
685 :
Delギコ :01/10/05 21:28
∧ ∧ そこでリファクタがでてくるとは (;゚Д゚) おぬし、通よのぉ (| |つ 〜| | ∪∪ そうそう。イテレタを教科書どおりにバカ正直に実装されていたら XPマンセーな折れとしては、デザパタを知らなきゃ リファクタリングでシンプルなものを目指して ブチ壊してたかもしれない。 今でもデザパタを読みこなせなければ(読み逃してしまったら) イテレタはつぶしてしまうかもなあ。 要所要所でデザインを考えたり、よりシンプルにしたり その辺のバランス感覚って重要かもと思う。 >最近はfor使わずにイテレータ、foreachなんかを文法に組み込むのが流行りだね。 foreach構文はいいですね。括弧ヨサゲ。クールですわ。 Delにも搭載されないかしら。
>>677 >一般的によくみるのは、流行の技術を追い掛け、ちょっと人より
>知っていることに優越感を感じそれに満足しているというパター
>ンです。そして、そういう人に限ってプロジェクトにあれこれと
>文脈を無視した意見をしプロジェクトを路頭に迷わせ、だめな
>やつらだと愚痴をいってまた自己満足。そんな人、多くないでしょうか?
これについて一言あります。
私は数年前に転職しました。
前の会社はOOに積極的で、デザインパターンもとりいれ、
社内で○○パターンと言えば誰でもわかる状態でした。
多くのプログラムがデザインパターンやOOを活用して作られていましたが、
プロジェクトが路頭に迷ったりすることはなく、
開発効率が高くて開発コストは非常に安く、
不具合発生件数もかなり少なかったのです(この会社がOOに走る前の状態と比較して)。
小さな会社でしたが、品質が高いとよく誉められたものです。
今は別の会社に転職しています。
ここではオブジェクト指向は誰も知りません。
デザインパターンと言ってもさっぱりです。
開発効率も悪いですし、不具合発生件数は非常に高く、
潜在的な不具合は表面化している数値よりはるかに高いと思います。
何度かオブジェクト指向を取り入れさせようと頑張ってきましたが、
自分が頑張ってもしょうがないことを悟っただけでした。
大きな会社ですが、品質が低いとよく叱責されます。
今の会社で、あなたの言う「自己満足クン」になっています。
はたして私は間違っているのでしょうか?
ただ本を読んで得た知識だけで言っているのならともかく、
私は前の会社で、それが役立つことを、身をもって知っているのです。
情報だけの頭でっかちではなく、実際に経験して効果をあげた実績があるのです。
画期的な効果をあげた経験を、理解されないという下らない理由で捨てるのですか?
オブジェクト指向もデザインパターンも、それほど難しい理論ではなく、
きちんと学習すれば必ず身につくと思います。
学習が思ったように進まないのは効果が疑われているからです。
疑いが学習の妨げになっています。
しかし自分の経験では効果があります。
そもそもオブジェクト指向は演繹ではなく帰納なのです。
687 :
デフォルトの名無しさん :01/10/05 21:53
>>672 いい経験も悪い経験もしているようですね。
会社の雰囲気って大きいですよね。一所懸命やってもそれが生かすことができない
ようじゃ自己満足クンになるしかないですね。でもがんばってくださいね。
|そもそもオブジェクト指向は演繹ではなく帰納なのです。
言い切るだけでなくて、この説明をしてください。
688 :
デフォルトの名無しさん :01/10/05 21:55
デザパタって 初心者にとっては過去のアイディアであって、 上級者にとっては、テクニカルタームなわけです デザパタのおかげで、コードにイテレーターって書いてあれば 読むの楽ですよね >最近はfor使わずにイテレータ、foreachなんかを文法に組み込むのが流行りだね そうなんですか・・・ それはあまり好ましくないですね 世間一般で行われていることはレベルが低いといことでしょう
>>686 めずらしい転職のパターンだな。
前の会社のなにが不満だったの?
690 :
デフォルトの名無しさん :01/10/05 21:58
>>686 最初にいた会社とその後変わった会社では、作っているシステムは 同じだったんですか? デザインパターンを使いOOを使うと品質が高くなるというその 理由は、なんですか? そういう経験をしたという事を力をいれて説明されてもそうですか しか意見をいえません。どういったことが影響して品質が高くなる のかを述べてください。 どういう分析をされるかわかりませんが、OOをしなくてもそれ以前 も現在の品質が高いものは作られたわけで、私にはOOをすれば単純 に品質が高まるという主旨のご意見には同意しかねます。
>690 2点質問。 ・OOPを理解してますか?実際の開発に適用したことは? ・あたなが最も効率的に開発を行える言語・手法・パラダイムは?
692 :
デフォルトの名無しさん :01/10/05 22:04
>>690 OOじゃないプログラムって、いったいなに作ってんだ?
OO&デザインパターンを使ったほうが、
設計フェーズで楽できるし、いいものができるのって当たり前だと思うけど
JAVAのライブラリー(デザパタならSWING)とか使ったことないのか?
普通のセンスなら、OOやデザパタの良さが理解できると思うが
693 :
デフォルトの名無しさん :01/10/05 22:04
>>690 そうね。
686の話は、
OOしているかとかデザパタを知っているかとは、
違った所に、問題がありそうですね。そういう経験を単純に関係付け
するような奴がまともにOOをやっていたとは思えないのだが。(藁
694 :
デフォルトの名無しさん :01/10/05 22:05
OOを取り入れれば、多くの場合生産性が上がるのはもはや常識だと思うが? それなのに、せっかくOOを使ってる奴を自己満足扱いにして邪魔者扱いに するのはいかがなものか。OO使わなくちゃいけないとまではいかなくても、 OO使うのは別に悪いわけでは無いじゃん。 明らかに周りが悪いだろ。
695 :
デフォルトの名無しさん :01/10/05 22:06
>>692 RubyにしてもC++にしても、OOで設計実装されてないじゃない。
何いってんの。UNIXだってLinuxだって、そうだよ。
上げだしたら切りがない。
OOしないと品質が上がらないなんて思っているようじゃ厨房ですね。(藁
696 :
デフォルトの名無しさん :01/10/05 22:09
>>694 生産性があがった所もあれば下がったところもあるのが常識です。
OOをしなくても生産性が高い所もあったという事実もしって
おいた方がよいでしょう。
>695-696 お前らも論理に不自由そうだな(藁
698 :
デフォルトの名無しさん :01/10/05 22:12
なんかこのスレすげえいら立ちを感じる。 OOしても品質が上がらない時があるとか、OOをしなくても 素晴らしい品質のものを作ることが出来るとか、OOに頼りすぎ は良くないという話は認めるとするよ。 でも、それがなんでOO知ってるのは自己満足の悪であると いう話に発展するの? むしろOOは多くの場合武器になると言うのに。
699 :
デフォルトの名無しさん :01/10/05 22:16
>>695 >OOしないと品質が上がらないなんて
はて?
OOすると品質が上がると思うけど
>何いってんの。UNIXだってLinuxだって、そうだよ
一応、あれがC流のOOなんですが・・・
RUBYとC++はOOしてもしなくても大して変わらないのは
単純だから
コンパイラも作ったことないのか
ソース見たことないから、OOでコーディングしてるかは知らない
ただ、設計フェーズではOOです
>最近はfor使わずにイテレータ、foreachなんかを文法に組み込むのが流行りだね ハァ?
701 :
デフォルトの名無しさん :01/10/05 22:17
>>696 COBOLなんて、ドメインによってはめちゃくて生産性も品質も高く
開発できますからね。生産性なんて部品的に使えるものが多ければ
高まりますからね。OOかとかそうでないかというだけで、単純には
判断できないものだと思います。
どこに使うか、何に使うか、誰がつかうか、どのように使うかに
よって変わるものですね。
OOをすればそうなるはずという机上論はわかるのですが、それが
実際に達成されるかどうかは別問題。そして、常識かどうかという
のを机上の話でしているのか、事例の話でしるのかを明確にして話
をしないといけないでしょうね。
おいおい、日本はそんなとこじゃないだろ。 OO叫んで袋叩きにあうのが、 ほとんどだよ。9割ぐらいそうだろ。
703 :
デフォルトの名無しさん :01/10/05 22:19
ちなみに、OOを理解してると勘違いしている OOプログラマー多いです とくにJAVAでは顕著です OOの敷居は高いので、あまり見かけないと思うのですが
日本のプログラマは度窮鼠だからな。
>>699 |ソース見たことないから、OOでコーディングしてるかは知らない
|ただ、設計フェーズではOOです
おまえがRuby作ったわけじゃないのになんでわかるんだ。
ソースもみてもないのに。
ばーか。おまえみたいなのが、OO普及のじゃまをするんだよ。
707 :
デフォルトの名無しさん :01/10/05 22:24
確かに、COBOLで作るような簡単なプログラムでは OO使うまでもないね 確かに、何人かで作る時に 馬鹿が混じるとOOどころじゃないね 有能なプログラマーだけが使えばいいと思う そういうわけで、月収が100万を超えてる場合に限り OOを使っております それでも馬鹿は混ざるんですが
OOを理解してると勘違いするプログラマの方が オブジェクト指向に見向きもしない向上心の無い 奴よりマシ。 経験をつめばいずれ気づくし。
709 :
デフォルトの名無しさん :01/10/05 22:28
>オブジェクト指向に見向きもしない向上心の無い奴 普通のリーマンコーダなんてこんなもんでしょ。 だって、今までの経験でこれからも惰性で開発できるんだから わざわざ自腹で本何冊も買って勉強するなんてアホらしいよ。
リファクタリングだけは、ドキュソが混じってもある程度使える。
>>709 だから、普通のそういう奴はドキュソであり、最低ランクだな。
>>690 >デザインパターンを使いOOを使うと品質が高くなるというその
>理由は、なんですか?
私にはこれを演繹的に筋道立てて説明できません。
どういう経験を指して品質が高いと言っているのか、
ということであれば、前の会社がDelphiで開発しているような感覚であるのに対し、
今の会社ではWindows 16APIを直接操作しているような感覚です。
でもこの差を説明しようとすると、
どうしてオブジェクト指向が良いのかを証明しなくてはいけないかも?
713 :
デフォルトの名無しさん :01/10/05 22:30
>おまえがRuby作ったわけじゃないのになんでわかるんだ コンパイラの本読んでみなよ 理由がわかるよ って、ここ大学生少ないの?
714 :
デフォルトの名無しさん :01/10/05 22:32
>>708 大事なのは、顧客にとって質のあるものを作ることですね。
そう考えると、
>>707 で書かれているような悪い環境では
OOをすることよりも他の事に力をいれようと思う人もいる
訳です。現実主義の人、理想主義の人、保守主義の人など色々
といて多様です。どれがいい悪いというよりも、そういった人
達がいることを認め、とことん話をするしかないと思います。
場合によっては、OOよりも構造化設計やCOBOLがいい場合も
あるのですから、何を使うのが顧客のためかという所を大切
にして話し合いをすることが何より大切と思います。
OO+デザパタは外国のオープンソースで導入出来ないんだから、 日本としては、いいチャンスなんだけどなぁ。 だれか仕切ってやればいいのに。
716 :
デフォルトの名無しさん :01/10/05 22:35
>>713 ムキになるな。お前がたいしたことないのはすでにわかってるんだから。
なんかOOPとアセンブラスレで同じ議論が進行してるのは気のせい?
718 :
デフォルトの名無しさん :01/10/05 22:39
>>680 お前の文章は、まったく論理的でないことを理解していっているのか?
本当に馬鹿だな。
たった3行でわかるなんて、すごいですね
なんかややこしいことになってきたなぁ。 OOの無い職場にOOを入れるのは大変で、 向上心のある人が何人かいても難しい。 パーツを一から作り上げないといけないし、 下手なパーツが積み重なって全体を壊すかもしれない。 ところがOOのある職場に、OOの経験が無い人を入れると、 それがオッサンでもすぐに馴染む。 上手くできているパーツを組み合わせるだけだから失敗しようがないし、 どういうパーツがいいパーツなのか、使うだけで勉強になる。 なんとかこの差を埋める方法は無いものかね。 いつの日かあの楽チン環境に戻りたいよ。 同じ事をするのに数倍の手間をかけていると思うと泣けてくる。
>>720 ソースコード盗んでくればよかったのに。(w
転職するときに職場見せてもらって そのとき机に積んである書籍の種類を確認するといいよ。 ボロボロになったK&R一冊とかって会社はやめといた方がいい。
>>720 盗んできたと思ったアーカイブの中には、
別のソースが入ってたんです……。
724 :
Delギコ :01/10/05 23:03
∧∧ /今時OOがダメとかいう
( _(,,゚Д゚) < アホが混じってるみたいだ。
⊂,,__つつ. \_
嫌オブジェクト指向スレでも立ててやってくれよ。
一向に、オブジェクト指向論議が進まなくない?
はじめから仕様が完璧に決まっているなら
OOでも非OOでも品質は同じだろうけど
(多分、非OO派はこういう環境にいるんでしょ
そんな環境ではコーダーとか言われかねないよ)
#COBOLで簡単なものを作るとか、言ってる人もいらっしゃるが
それは違うぞ。仕事のやり方が、完璧な仕様を作ってからコードという
システムになっているらしい。
実際はウソッコだけど。
OOすると仕様変更に非常に柔軟に対応できるようになる
現実のプロジェクトでは仕様変更が日常茶飯事、
特に、最近のプロジェクトは短納期という状況が多いですね。
それに短期間で対応できるOOが
結果的にOOは品質の高いものが作れるよ。
> ちなみに、OOを理解してると勘違いしている
> OOプログラマー多いです
> とくにJAVAでは顕著です
> OOの敷居は高いので、あまり見かけないと思うのですが
Javaの皮かぶったCOBOLerが多いですね。
話を聞いて、元コボラだったら気をつけましょう。
>>712 わかりやすいです。
>>723 ソースを盗むのではなく、ノウハウを盗もうよ。
Delギコ ウザイ。 もうすこしお勉強してから来てね。
726 :
Delギコ :01/10/05 23:14
∧_∧ / ̄ ̄ ̄ ̄ ̄
( ´∀`)<
>>725 オマエモナー
( ) \_____
| | |
(__)_)
/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
∧∧ < よーし、定番定番。
(゚Д゚∧)_∧ \____________
( ̄⊃ ´∀`)
| | ̄| ̄
(__)_)
/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
∧∧ハッ! < なに見てんだゴルァ!!
(#゚Д゚∧_∧ \____________
( ̄⊃ ´∀`)
| | ̄| ̄
(__)_)
>>724 ノウハウは持ってるよ。
実際、そのソースの多くは自分のソースだし、
他人のソースにもある程度自分の意見が含まれている。
だけどそれを会社に広めるのは別次元なの。
一人だけで踊ってもしょうがないのよ。
C++でやるぞ、Javaでやるぞと言っても、
「また自己満足クンが何か言っているよ」と思われるだけだし、
一人だけC++で書いたモジュールを混ぜるというわけにもいかないし。
一人だけでシステム全てをコーディングするのも非現実的だし。
今は10年計画で若い人を育てることに血道を上げてます。
728 :
スレストッパーDelギコ :01/10/05 23:31
∧∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
(,,゚Д゚) < ちょっと遊びすぎた。
Π ̄ ̄ ̄| \
|つゴメン ()  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
| |___.|
∪∪
話を修正
>>714 現実問題として、OO以外の開発って何でやっているのですか?
少なくともOO言語でやっているのなら
ちょっと優秀な人にある部分を任せたら
すぐにOOをしてくると思うのですが...場合によってはそれを否定するのですか?
そんな状況、優秀な人、嫌気がさして辞めませんか?
そういう環境の究極的な解決方法としてXPというものがあります。
ペアプログラミングという方法論があって
それをしたら全員がOOをマスターするのは
人月的にみたら一瞬だと思いますが
どうしてそういうことをされないのでしょう?
>>720 よっぼど楽ならともかく
やめようよ、そういう会社は、
自分のキャリアを汚すだけにしかならないかもよ。
フキョウといえどもソフト業界は人手不足にあふれているさ。
> >オブジェクト指向に見向きもしない向上心の無い奴
> 普通のリーマンコーダなんてこんなもんでしょ。
> だって、今までの経験でこれからも惰性で開発できるんだから
> わざわざ自腹で本何冊も買って勉強するなんてアホらしいよ。
うーーーん、
職業意識とかは芽生えないか、な。
自分より年下の人間にバカにされたいか?
すぐに追い越されるぞ。
>>724 >今時OOがダメとかいう アホが混じってるみたいだ。
っていうのに現実感が感じられないのよ。
727のように、現場では、イタイ人間と紙一重なの。
そこから、責任者とチームを説得し、広めるのに
どれだけ苦労するのかわかる?
>>727 >10年計画
遅いと思われ。出たほうが身のため。
10年後
前の会社にいた人間がどうなっているか想像してみて。
かけはなれてるだろ?
∧∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
(,,゚Д゚) <
>>727 大変よくわかります、その↓
Π ̄↓←←←←←←←←←←←←←←←←←
|つ 境遇 ()  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
| |___.|
>>729 ワカリマス
∪∪
うちの会社はOOを理解してない人はいなかったから
まあまあマシだったけど
変な非効率なやり方を修正しようとすると、つらいっすよね。
面と向かって、"あの人だめだなあ"
なんて同僚でもいいにくいし。
ついでいうと、下請けだったら
上の会社がわかってない所から発注だと
旧態依然とした無意味な納品のためだけの仕様書
とか書かされる。
なんでこの業界、デキナイ人間がデキル人間の足を
とことん引っ張るわけだ?
せめて、生産性の高い人の足はひっぱるなよ、ヒトトシテ
とか、おもうたり〜〜〜
このスレで言う所のOO否定者はOOを理解してから否定している?
そうじゃないのなら、足はひっぱらないで。
クレと、ひっぱらないでクレ、そうしてクレ、と、小一時間問い詰めたィ・・・・(ネタ)
ま、ネコの意見だから無視したい人はしちゃって許してね
731 :
デフォルトの名無しさん :01/10/05 23:59
>>730 > ま、ネコの意見だから無視したい人はしちゃって許してね
公の場に書き込んだ以上、逃げはいかんよ、ヒトトシテ
とか、おもうたり〜〜〜
>>728 >よっぼど楽ならともかく
>やめようよ、そういう会社は、
>自分のキャリアを汚すだけにしかならないかもよ。
>>729 >遅いと思われ。出たほうが身のため。
>10年後
>前の会社にいた人間がどうなっているか想像してみて。
>かけはなれてるだろ?
いや、そこまで悲観しているわけじゃない。
今の会社は良くも悪くも普通。
決して技術力で劣っているわけではなく、
むしろ部分的には見るべきところもあるし。
OOは、あると楽できるというポジティブなものであって、
無いと困るというネガティブなものじゃない。
OOできなきゃ仕事にならんということは無いからね。
あと今後の成長に関しても、そんなに悲観していない。
OOが身に付いていれば最近の技術はすぐ身に付く気がするんだ。
デザインパターンとかUMLとか出てきたけど、
OOは大筋ではもう10年以上変わってなくて、
OOに関連する技術である限り水が染み込むように吸収できると思う。
もうここまで来ると、そうそう若い奴らには負けん。
>>732 失礼かと思いますが、貴殿の話は何か、現実味が感じられません。
話作ってません?
気のせいだったら、ごめんなさい。
734 :
デフォルトの名無しさん :01/10/06 00:27
かつて夢と未来への希望、人々の融和を志して語られた思想が有った。 計画経済、統制、言論弾圧、思想改造、プロパガンダ、異端査問。 それらがもたらした物は人々の望まないこうした物でしかなかった。 祭りは終わった。 だが、まだ祭りの終わりに気付かずに酔いつづける人が星を掴もうとしている。
735 :
デフォルトの名無しさん :01/10/06 00:27
すでにプログラム「技術」板じゃないよなぁ・・・。
>>733 全部事実だよ。作り話に見えるかなぁ。
>>730 でもよくわかるって書いてあるし、
たぶんOOに傾倒している人なら
激しく同意してくれると思うのだけど。
737 :
奈々氏ギコ :01/10/06 00:31
コレデドウカナ
>>731 ∧∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
(,,゚Д゚) < 演繹的・・・えんえきてきって読むんだ…
Π ̄ ̄ ̄| \ ←
|つ奈々氏()  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
| |___.| ネコ ニハ イミ ワカラン
∪∪
>>732 もったいない。オバケが・・・・
δ δ アナタノ ギジュツ モタ〜イナイ
♪ ∧ ∧ ♪ δ モタ〜イナイ
(,,゚Д゚) ♪ イナイ イナイ バア
|つ[|lllll]).
〜( / δ
),ノ
υ
でも、他の人より秀でていると
仕事も楽でいいかも、ですよね。
(これぞ人生の処世術)
>そうそう若い奴らには負けん。
折れ、プログラハジメテマル3年っす。
ネットで調べると後進からの追い上げは怖い。
厨房啓蒙ネタはマ板でないかい?
739 :
デフォルトの名無しさん :01/10/06 00:45
UnitテストってC言語でも出来るものなんでしょうか? 出来るならやり方を教えてほしいです。
できるよ。 山ほどAssert関数作ってtest関数実行すればよい。 特にフレームワークなんて作る必要ないけど、探せば幾つか見つかるよ。
741 :
デフォルトの名無しさん :01/10/06 00:58
UMLは複雑になりすぎ。
>>741 確かにRationalは頑張りすぎ。
UMLマンセーだったけど、最近の仕様追加にはうんざり。
使いたいところだけ使おう。
744 :
デフォルトの名無しさん :01/10/06 02:11
>>686 なんつうか。CだってOOPできるだろ。特に情報隠蔽やカプセル化
なんてまともなCプログラマならみんなやってると思う。
それより非効率な物を具体的に発見して、それの解決法を
提示したときになんでちゃんと納得させられないのか理解に苦しむ。
それができないのは
1・相手のプライドゆえ非効率を認めない。
2・相手が論理的思考が出来ない。
3・あなたが利点を人に説明できるほど理解していない。
4・そもそも(その状況では)利点がない。
5・説得する気なんかない
からじゃない?
1なら納得はさせているのだからあとは対人スキルの問題。
2ならほんとのドキュソ。OOPとかそういう問題以前。
ただ2と3は紙一重だから謙虚に考えたほうがいいと思う。
そして一生懸命説明しているうちに実は4だってことがよくある。
5ならまさに自己満足君だ
746 :
デフォルトの名無しさん :01/10/06 03:00
>>745 激しく同意。
OOPが出てからカプセル化、隠蔽、シリアライズ初めて知った
奴の方がDQN。
747 :
デフォルトの名無しさん :01/10/06 03:08
はぁ?気ティが現れた
>>745 ,746
C言語で隠蔽された関数ってどうやって作るの?
C言語で派生後のクラスからアクセス出来ない変数どうやって作るの?
>>747 擬似的なものは十分作れるよ。
それに、隠蔽や継承=OOという考え方自体がキティ。
sage
749 :
デフォルトの名無しさん :01/10/06 03:14
>なんてまともなCプログラマならみんなやってると思う。 >擬似的なものは十分作れるよ。 「みんなやってると思う」の直後に「擬似的なもの」ってのはやめてよ。恥ずかしいYO!
750 :
デフォルトの名無しさん :01/10/06 03:17
>それに、隠蔽や継承=OOという考え方自体がキティ。 >なんつうか。CだってOOPできるだろ。特に情報隠蔽やカプセル化 自分で言ってること分かってないでしょ!
751 :
デフォルトの名無しさん :01/10/06 03:21
>>750 745-746 != 748
ちなみに俺は 748。
745,746 はOOP自体はCでも
可能(というか言語に依存するもんじゃない)で、
実際、OOPの要素技術として代表的な隠蔽その他もろもろは
Cでも実装できるし、その程度なら誰でも把握してるもんだろ、
という意味に取った。
外してるか?
>>745 情報隠蔽やカプセル化は手段であって
OOPと直接的な関連は無いぞ。
753 :
デフォルトの名無しさん :01/10/06 03:29
全然「擬似」じゃないんだが・・・。
754 :
デフォルトの名無しさん :01/10/06 03:36
>>747 勉強足りないね。最近はOO言語から入る人が多いから仕方ないの かもしれないね。でも、知ったかぶりはかっこ悪いよ。 OO言語は、OOがしやすい言語だよ。C言語でOOするには、 X toolkit を勉強してみよう。クラス(Widget)を設計するのは とっても面倒だけど、隠蔽も継承もできるぞ。
755 :
デフォルトの名無しさん :01/10/06 03:38
C言語でもOOできるが、ただオブジェクトがメッセージで交信するというレベルではなく、 OOらしい設計しようとか、ちゃんとデザパタしようとかするとめちゃくちゃ難しいよ。 仮想関数を活用しようとすると複雑度が危険なくらい増す。 特に非OOなコードがたくさん混じっている状況でOOするのは不可能に近い。 かろうじて自分だけが作ったモジュールだけがOOできるものの、 他のモジュールへのアクセスはやはり非OOにならざるを得ず、 Cではラッパーを作るのも厳しい。
756 :
デフォルトの名無しさん :01/10/06 03:40
>Cでも実装できるし、その程度なら誰でも把握してるもんだろ、 >という意味に取った。 外してるか? 自分でアクセスしないことにしたから隠蔽っていうのは隠蔽じゃないんだ。 大型開発で一人の人間が規則を破ったら終り。また、デグレしやすい。 それに対して、コードでprivateって宣言すれば外からアクセス出来ない、こういうのを隠蔽という。 外してるということを分かって貰えましたか?
OOを知らないくせに隠蔽とかの言葉だけを知っている奴は、 関数やデータや定数を無闇に隠蔽してしまうので困る。
758 :
デフォルトの名無しさん :01/10/06 03:42
>OO言語は、OOがしやすい言語だよ。C言語でOOするには、 >X toolkit を勉強してみよう。クラス(Widget)を設計するのは >とっても面倒だけど、隠蔽も継承もできるぞ。 面倒なことはあなたがやって下さい。自分は嫌です。
759 :
デフォルトの名無しさん :01/10/06 03:42
「Cでもできる」からOOPLいらないって主張なの? OOするのなら最初からC++とかのOOPL使ったほうがいいんじゃないの?
760 :
デフォルトの名無しさん :01/10/06 03:43
>OOを知らないくせに隠蔽とかの言葉だけを知っている奴は、 >関数やデータや定数を無闇に隠蔽してしまうので困る。 自分が知らないんだろ。宣言をprivateからpublicに移動するだけじゃん。
>>756 よほど凝ったことをしなければアクセスできないようにすることはできるけど?
例えば、Windows の API にはおなじみの HANDLE。
HANDLE が指す対象のメモリ上の実データは隠蔽されている。
これじゃ不十分かい?
762 :
デフォルトの名無しさん :01/10/06 03:46
>>762 む。そう言われると少しカチンと来るな。
俺にしてみれば Windows API のデザインは
一応OOの原則に則っていると思っている。
実データの隠蔽やカプセル化、継承などもある程度成立している。
この考え方のどのあたりがダメなのか説明してくれ。
764 :
デフォルトの名無しさん :01/10/06 03:48
不十分とか十分という問題ではない
>>761 クラスにすると明らかに幾つもメリットがあるんです。
それは、このスレで出てるから読んでみて。
>>762 Handleはオブジェクトへの参照だろ。
CでOOする場合の常套手段だよ。
しかしHandleでOOするのは限界がある。
OOを良く知れば、Handleでは不十分なことも知っているはずだね。
766 :
Delギコ :01/10/06 03:51
∧ ∧ OO否定派が、「CでもOOできる、OOP言語使いは、おろか者」
(;゚Д゚) って無茶苦茶な理論を振りかざしてきてるだけじゃないの?
(| |つ
〜| | バカは品なきゃ治らないとか?
∪∪
メモリをポインタ渡しで、間違ったものわたしても
コンパイルエラー出ないような言語
なんであえて使う必要が…
>>745 >なんつうか。CだってOOPできるだろ。特に情報隠蔽やカプセル化
>なんてまともなCプログラマならみんなやってると思う。
まともなプログラマなら他の言語使ってる。
767 :
デフォルトの名無しさん :01/10/06 03:51
>>764 ん?
別にCでも書けるんだからクラスなんて要らないよとか書いた覚えはないぞ。
OOPとOOPLとを混同するのはよくないという視点で書いただけ。
C++処理系が手元にあったらCでOOしたりなんかしないって。
>>765 だからぁ、俺はCで十分だなんて言ってないってば・・・。
できないことはないよ、何故ならOOPとOOPLは違うから、
と、そう言いたいだけ。
770 :
デフォルトの名無しさん :01/10/06 03:56
>OOPとOOPLとを混同するのはよくないという視点で書いただけ。 頭おかしいね。 無限の時間と全てのコードを頭に入れることが出来るんなら、OOPL以外でOOPすれば良いだろう。 プログラミングは有限な中でやるもんだからね。 >C++処理系が手元にあったらCでOOしたりなんかしないって。 はやく手に入れろよ。
OOPLは、単にOO的記述が綺麗に出来るだけ。 OOの概念の多くは、OOPLが登場する以前から、 まともなプログラマならやっていた。 OOPLいらないって主張なの?とか、ボケは勘弁。
772 :
オリジナルギコ :01/10/06 03:59
>できないことはないよ、何故ならOOPとOOPLは違うから、 >と、そう言いたいだけ。 ∧ ∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ 〜′ ̄ ̄( ゚Д゚)< 逝ってよし! UU ̄ ̄ U U \_____________
>>770 OOPとOOPLは違う、というのは、
OOPLはOOPの実現手段に過ぎず、
その具体化である(個々の)OOPLとOOPは1対1対応しない、ということ。
だから、あるOOPLで提示されているOOPのモデルが
OOPの全てのモデルを代表することはないし、
あるOOPLや、非OOPなプログラミング言語でも
OOPを実践することはできる。
そういう基本を言ってるだけ。
仕事はC++でやってるよ。変な煽り入れないでくれ。
774 :
デフォルトの名無しさん :01/10/06 04:01
>>773 ちょっと書き間違えた。
>あるOOPLや、非OOPなプログラミング言語でも
>OOPを実践することはできる。
以下のように訂正。
>異なったOOPのモデルに基づくOOPLや、
>非OOPなプログラミング言語でも
>OOPを実践することはできる。
776 :
デフォルトの名無しさん :01/10/06 04:03
777 :
デフォルトの名無しさん :01/10/06 04:04
>>766 いや、そうじゃなくて,
昔からプログラマが自分で発見していたような技術をOOP出てから
「教えられて」初めて知って「時代に付いて行けないの何の」と
興奮して、「新知識」を振りかざしてる奴が滑稽だっつうの。
OOので述べられているような事は自分で発見していて当然。
教えられて初めて判るような人は才能ないんじゃない?つう事だ。
>>773 OOPLしか知らない人達には、理解しづらい話だと思う。
この世代の人達って、実務でまともな設計経験も無いと思うし。
>>776 OOPと個々別々のOOPLを切り離して考えるべき、
というのは電波な意見なわけ?
そこんところ納得できないんだよ〜。
781 :
デフォルトの名無しさん :01/10/06 04:06
>昔からプログラマが自分で発見していたような技術をOOP出てから >「教えられて」初めて知って「時代に付いて行けないの何の」と >興奮して、「新知識」を振りかざしてる奴が滑稽だっつうの。 それに対して、自分も興奮して意見振りかざしてるんでわ? スレと関係無い分、もっと醜いよ。
>>748 今ここには非OOPLでOOPできないなんて言っている奴は居ないのでは。
非OOPLで十分にOOPができるとする主張に異議があるのでは。
みんなそれは難しいと思っているのでは。
電波扱いされるのもイタいので実例を挙げてみる。 Java/ObjectPacal:多重継承なしのクラスベース。 C++:多重継承ありのクラスベース。 JavaScript:プロトタイプベース。 もしC++しか知らなければ 多重継承ありでクラスあり=OOPだと思うかもしれないけれど、 それはC++に特有のOOPのモデルであって、 他のOOPLでは通用しない。 こういう意味で、区別が必要だと言ってるの。
784 :
デフォルトの名無しさん :01/10/06 04:09
>OOPと個々別々のOOPLを切り離して考えるべき、 >というのは電波な意見なわけ? 別スレでやって下さい。OOPについてOOPLで説明してるスレなんで。 なぜOOPLで説明するかというと、動物-猿,犬,猫では現実味が無いという意見が出たから。
786 :
デフォルトの名無しさん :01/10/06 04:10
クラス邪魔。継承いらない。
787 :
デフォルトの名無しさん :01/10/06 04:11
>多重継承ありでクラスあり=OOPだと思うかもしれないけれど、 >それはC++に特有のOOPのモデルであって、 >他のOOPLでは通用しない。 >こういう意味で、区別が必要だと言ってるの。 がいしゅつです。クラスベースのoop対オブジェクトベースのoopのレスを参照して下さい。
>>782 俺は748じゃないが、勘違いしてるのはどっちか、読み返してみれば分かると思うが。
論点のすり替えは感心せんな。
>>787 このスレで最初に「プロトタイプ」という単語使ったの実は俺。
ガイシュツなのにあんまり区別されてないなぁと思ったので出てきたの。
でもこれで引っ込みます。つか寝ます。
790 :
デフォルトの名無しさん :01/10/06 04:17
良くわからないんだがHANDLEを使えばデータの隠蔽?? OOした事になるの?
コンポーネント指向ってどうよ?
>>790 うむ、OOを知らない人には信じられないかもしれないけれど、
例えばファイルハンドルはオブジェクトへの参照だ。
fopenはファイルオブジェクトのコンストラクタで、fcloseはデストラクタ。
ファイルハンドルを引数に取る標準関数は全てメンバ変数。
ファイルハンドルの先がファイルなのかデバイスなのか隠蔽されているし、
シークポインタも隠蔽されていて、ファイルハンドルに内緒で勝手に変更することは
できず、fseekメソッドでメッセージを送らないといけない。
>>792 簡単に高機能が実現できるが、提供されていない機能の実現には限界がある。
ソースでも公開してくれれば、話は別だが。
795 :
デフォルトの名無しさん :01/10/06 04:24
継承がアホな概念の訳。 例えばファイル操作。 最下層ではopenだのcloseだのとよりハード寄りのコードを書くけど 上位層ではこういったファイル操作を意識せずファイル名を与えるだけで 読み書きできるように作る。 (何時までもファイル操作の度にopen,closeやっていたとしたらそいつは プログラマーの才能無し) 上位層は下位層でやっているような手続きを全く意識させない作りにするのが 正しい設計である。 OOPLの継承は下位層の手続きを丸ごと持ってくるというアホな発明なんで 全然意味無し。 アホPGを量産するだけ。
間違えた。 ↓ ファイルハンドルを引数に取る標準関数は全てメンバ「関数」。
しょーもない議論だ。
>>794 いちおうコンポーネント自作できるぞ。
継承して機能拡張もある程度はできる。
ソースが公開されるならばいいのか。
800いただき
>>799 たとえば君が、何らかのエディットコンポーネントで、
エディタプログラムを作るとしよう。
おそらくコンポーネントの機能拡張の限界に、
すぐにぶち当たるだろう。
802 :
デフォルトの名無しさん :01/10/06 04:32
>>795 それは、File クラスの実装レイヤーの上に
インタプリタみたいなもののレイヤーを載せて、
最上層のレイヤーでは ReadTextFromFile( "filename.txt") ;
みたいな書き方をするべきだという話?
803 :
デフォルトの名無しさん :01/10/06 04:32
完璧にOOを理解している人ってこの板の何%なんだろう?
中途半端に理解して勉強を止めると
>>795 みたいになってしまうんだろうな。
私も気をつけよう。
つーか
>>795 はオブジェクトとは何なのかという
根本から理解できてないね。
半端も何も理解度0%では?
この板が日本の技術力を底上げしていたりして。
などと言っている私のようなヒッキーが幅を利かせているようでは プログラマ板も大したことはありません。
オブジェクト指向の仕様を編み出した人間でもなし。 だからといってオブジェクト指向の新しい言語をつくるわけでもなし。 ただオブジェクト指向の枠組みを無視するアホと押し合いしているだけ。 コンポーネント指向は融通が利かなくてもそこは重箱の隅 コンポーネントを組み合わせて生産的になったほうがいいのでは?
このスレ面白いね 厨君は勘違いしてるようだけどOOはCより古い技術なんだよ 実はCはOOの影響を受けている。面白いから本探して読んでみてね
>>810 OOについてもそうだが、欠点を指摘すると、
すぐ全否定者扱いしてくる奴がいる。(わざとか?)
大抵の物には、利点と欠点がある。
813 :
デフォルトの名無しさん :01/10/06 05:09
個人的には継承は便利だと思うんだけど。 あまり評判良くないみたいね。
>>812 新しい言語を作る人ならば
欠点をついたからにはそれを直そうとする。
しかしそうでないならば、蟻の一穴から全否定を狙っている。
もしくは欠点をついて喜んでいるだけのひねくれ者です。
815 :
デフォルトの名無しさん :01/10/06 05:13
そういえばSmalltalkって結構古い言語だったよね。
>>814 話にもならんな。
俺はコンポーネント指向は、簡単に高機能が実現できると、初めから言っている。
欠点を認めないなら、盲目的な信者だ。
>>816 欠点を認めた上でそれは重箱の隅といっているのです。
機能拡張ができずどうしても必要なものは
コンポーネントを自作すればいい。
それはオブジェクトを自作するのと労力は変わらない。
>>817 > コンポーネントを自作すればいい。
> それはオブジェクトを自作するのと労力は変わらない。
禿しく胴衣。
>>813 私は継承は最小限にしています。
しかし継承にメリットがある場合はどんどん使います。
>>815 まともなオブジェクト指向の最初の言語?使ったことないので知らない。
>>817 結局、欠点を指摘したら、全否定者扱いされて当然って意見だろ。
やっぱり、話しにならん。
あたりまえ過ぎて議論にもならない。さよなら
823 :
デフォルトの名無しさん :01/10/06 05:26
オブジェクト指向がソフトウェアの技術史における 最後にして最上の技術ならば問題ないんでしょうけれどね。 そうでない限りは、次に出てくる技術によって解決されるだろう 何らかの問題を抱えているはずです。 僕は現状のオブジェクト指向やオブジェクト指向プログラミング言語には 建設的なダメだしをすべきところが沢山あると思います。 皆さんは、オブジェクト指向は至高にして最後の技術だと思われますか:)?
>>821 いや、コンポーネント指向ってオブジェクト指向に包含されてる概念だと
思ったもので。
mix-inを文法的にサポートしてくれるOOPLきぼんぬ。
>>824 > コンポーネントを自作すればいい。
の方じゃなくて、
> それはオブジェクトを自作するのと労力は変わらない。
の方に要旨があるって事かな?
>>823 至高ではないです。
私のようなヒッキーにもオブジェクト指向を超えるアイディアが幾つかあります。
私の出る幕などなく、近々そういう新言語が現れると信じています。
>>825 mix-inぐらいなら、多重継承が出来る言語なら実現できるよ。
自分でやる分にはこれで問題ないんだけどねー。
829 :
デフォルトの名無しさん :01/10/06 05:35
>>826 そうそう。
オブジェクト指向でうまく設計されたライブラリが豊富になれば、
末端部分ではコンポーネント指向的に必然的になってくると思いましたです。
>>820 欠点がよく理解していないためにそう見えるとしたら
やっぱり荒れるね
理解度は人さまざまなものだし
オブジェクト指向を否定すると、デザインパターンをはじめとする オブジェクト指向で提唱されてる技術を使うのが非常に厳しくなって くるじゃん。 分析設計の方法を適用するのが難しいし、オブジェクト指向的なこと をC言語でやるのも厳しいし、リファクタリングの方法も限られてくる。 そこまで不便な思いをしてオブジェクト指向を使わないことにする 気も起きない。OOさえ導入すれば楽になる。 OO否定してる人をみると「そんな自ら厳しい道を選ばんでも・・・」と思う。
自分も多重継承でやるんですが、インターフェースと実装は継承するけど デフォルトではメンバ変数がサブクラスから見えなくなる「mix-in継承」って 構文があってもいいかなと。
mix-inってのは、多重継承するときに、 部品(mix-inクラス)+本体(一つまで)→ 新しい本体 というパターンしか許さないってやつでしょ?
>>832 OO否定してる人ってのは、OOを全肯定しない人の事じゃないのか?
だとしたら、俺も含まれるな。
う。ちとオレがmix-inを誤解してるかもしれないんだけど、 普通に実装継承するクラスとmix-inするクラスを構文を見た時に わかるようにしてあれば見やすいかナット。
838 :
デフォルトの名無しさん :01/10/06 05:53
>>836 全否定とか部分否定とかじゃなくて、OOを使わない人のこと。
>>837 なるほど。それは言えるね。
今のところコメントを使うという手ぐらいしかないかな。
つづき。 で、単に多重継承するとメンバ変数の名前がぶつかったりするのがイヤ〜 なので、mix-inするクラスに関してはメンバ変数へのアクセスを自動的に 制限してくれたらええのかも、と思いつきでいってみました。スマソ。
>>838 現実問題、OOの全ての概念を使わないのは、不可能なんじゃないか?
オブジェクト指向やろうとしたら、多態性とか、継承とか、クラスとか は必然的に使うことになる。 それらを全部使わないとOO出来ない場合が出てくるからね。 そういう主要概念のレベルではそれらが全部合わさってOOでしょう。 確かに継承は、それと同等のことを別の方法でやる言語も存在するけど、結局 同等のことをやっている。
>>842 >>843 よく分からんが、OOを使わない人(OO否定の人)の定義は、
継承・多態・クラスを全て使わない人って事で良いのか?
>>844 いや、だから、それら主要概念を一部でも使わない人。
>>845 継承・多態・クラス・その他主要概念の、
1つでも使わない人って事で良いのか?
それと同等なことを別のものでやってる人なんかはOO否定から除くよ。 クラスと同じようなことをクラスの無い言語でやってる人とか。
>>847 俺は多重継承が嫌いだが、俺はOO否定者か?
>>850 いや、俺はまじめだ。
> 全否定とか部分否定とかじゃなくて、OOを使わない人のこと。
> いや、だから、それら主要概念を一部でも使わない人。
いろいろ個人で基準が違うようで、マジで良くわからん。
>>851 ていうか、OO使う人と使わない人っていったら大体わかるでしょ。
それで良いじゃん。何でこだわってるの?
グレーゾーンならグレーゾーンでも良い。 そういう人は意見の対象から除くってことだね。
>>852 俺はよくOO否定者扱いされるが、今の基準じゃ、OO否定者じゃないぞ。
>>854 じゃあグレーゾーンですね。良かったね。
これからは、OO否定者扱いする前に、自分の基準と照らし合わせて欲しいな。
857 :
デフォルトの名無しさん :01/10/06 06:33
>>856 誰がどこでお前のこと否定者扱いしたのかもわからないのに、
勝手にぐちんなよ。(w
否定者扱いされるんだったら多重継承以外にも嫌いなものが
あるんじゃないのか?
>>857 君の基準では、何が嫌いだと否定者扱いするんだい?
859 :
デフォルトの名無しさん :01/10/06 06:44
ところで、コンポーネント指向って何?
たぶん
>>858 はOO否定者ではないが、OOの技能、知識をひけらかす
タイプのプログラマに出会って嫌気がさし、「OO嫌い」になったのでは
なかろか?
マ板向きのテーマかな?
861 :
デフォルトの名無しさん :01/10/06 06:49
>>859 検索で調べろよ。
>>860 だったら、話の流れを遮るような、うざい質問してないで
どうどうと何か主張したら良い。858はアホじゃないのか。
これじゃ技術話じゃなくて宗教論争だ。 sage
>>860 俺をOO嫌い(OO否定者)にするなよ。
>>861 アホだのOO否定者だの、話と関係ない事で因縁つけてくる奴がいるから、
OOの技術的な問題点一つ、まともに議論できないんだよ。
せっかくだから >OOの技術的な問題点 ↑ここに話題を戻してみては。
>>863 話と関係の無いこと言い出したのはお前だろ。
せっかくOOの話をしてるところに、突然否定者の基準とは何だって
わけのわからん質問しやがって。何の意図があるのかちゃんと言えよ。
回りくどいんだよ。
OO否定者だと因縁つけられるのが気に入らなかったなら、
質問してるひまにはじめからそう言えよ。
>>865 きちんとした根拠があるなら、無下に非難も出来まい。
だから先に、基準を聞いたんだよ。
出かける準備があるから、これ以上書き込んでも返事は夜だぞ。
>>866 だったら、「きちんとした根拠があるならいいが、否定者と
決め付けるのはだめだ」ってはじめから言えよ。
お前逝っていいよ。
結局なんだったんだ・・・。 何を批判してたんだろう・・・??
870 :
デフォルトの名無しさん :01/10/06 07:17
>C言語はOOの影響を受けているって書いた人 詳しい情報求む なんかおもしろそう 関数ポインタって落ちじゃないよね? でも、基本的にはSystem370とかを意識してたんじゃなかったけ? ファイルアクセスに関していってる人は 普通に実行時ポリモーフィズムがわかってないみたいだけど... 実行時ポリモーフィズムってどの程度の人が使いこなしてるのか知りたいね 実行時ポリモーフィズムを使う手段として継承は便利だよ だからOOL好きだな 特にJAVAはいいね 多重継承はうまく使うとすごく便利 でも、普通に使うと終ってる まあ、JAVAのインターフェースと単一継承みたいな感じでしか 設計しなくなってしまったけど.... たくさん覚えないと使えないC++ たくさん知ってないと使いこなせないJAVA(ライブラリの話じゃないですよ) 皆さんはどっち派ですか?
871 :
デフォルトの名無しさん :01/10/06 07:21
単一継承しかない言語ってC++で多重継承するようなケースで どうやって対処するんでしょうか?
873 :
デフォルトの名無しさん :01/10/06 07:45
>多重継承するようなケース これをどういった意味で使ってるのか良く分からないけど 短絡的に言えばインターフェース C++で言えば、 純粋仮想関数しかないクラスみたいなもので いくつでもインプリメント(継承と同じ)できる でも、多重継承のためのインターフェースと考えて設計することはない 名前通りの概念でとらえるのが普通かな JAVAの継承はポリモーフィズムのウエイトが大きいって事なのかな?
874 :
デフォルトの名無しさん :01/10/06 09:23
>>873 >JAVAの継承はポリモーフィズムのウエイトが大きいって事なのかな?
禿同!
javaでは、継承も隠蔽も、多態を実現するための手段に思えてくるくらい、
多態しないでプログラムってできない気がする。そこがいい。
875 :
デフォルトの名無しさん :01/10/06 11:50
>>804-807 あほか、話の流れを見てないのか!
OOPLの話だよ。
糞信者が! レッテル貼り、揚げ足取りしかできんのか?
>>875 いや、基本的に下位層の実装をそのまま持ってくるのを
継承って言わないか?
インターフェイスの継承もあるが。
OOPLの問題か?
それ以前に、
>>795 は、継承がアホだといってるが
何がアホなのか良くわからん。
と書いてみたが、
>>804 ,805,807は open〜close並べてるクチだなw
878 :
デフォルトの名無しさん :01/10/06 11:58
879 :
デフォルトの名無しさん :01/10/06 12:06
プログラマーには2種類あり。 常に上位構造の構築を意識しながら書く奴と ライブラリ層をベタベタ並べてるだけの奴。 後者に構造の話をしても大抵通じない。 そういうのがOOPL覚えると只のクラスマニアになるだけ。 上位構造は一般に複数の構造の上位の構造を持っているもの。
880 :
デフォルトの名無しさん :01/10/06 12:44
>javaでは、継承も隠蔽も、多態を実現するための手段に思えてくるくらい、 >多態しないでプログラムってできない気がする。そこがいい。 だけど、javaプログラマーってポリモーフィズム使えない人多い(笑) 多態ってほんとに便利だと思う Javaのストリームに感激 SWINGは作りこみ方がマニアックだと思う そう考えると、マイクロソフトって人件費けちってた以外は 考えられない
881 :
デフォルトの名無しさん :01/10/06 12:49
(゚Д゚)ハァ!? サンの手先ですか?
882 :
デフォルトの名無しさん :01/10/06 13:01
感激とかマニアックなんて技術的に批判しようのない表現されてもねえ・・・。 他人にはJavaを薦めておきながら自分は逃げる準備をしてたり。
少し議論(と発言者)が錯綜していてなんともいえませんが、
自分もOOPL覚えたての頃はクラスライブラリをべたべたと利用する
だけで、いわゆる「open~closeを並べる」タイプだったです。
でもしばらくしてからプログラムしている内容をオブジェクトに切り
分けて、そのオブジェクト間のメッセージのやりとりという観点から
自前でクラス階層を構築する、という作業をしてみると以前よりずっと
実際の問題に近いレベルでプログラムを構造化(?)できるなあ、と
感じるようになりました。
openだとかcloseだとかは自分のつくったクラスのもっと具体的な名前
のメソッドのなかに隠されて外からはすぐに見えなくなると思うのですが。
ですから、
>>795 の
> OOPLの継承は下位層の手続きを丸ごと持ってくるというアホな発明
という感想はそもそも継承の使い方を間違って理解している気がします。
884 :
デフォルトの名無しさん :01/10/06 14:35
> OOPLの継承は下位層の手続きを丸ごと持ってくるというアホな発明 継承では、下位層という風には考えないよね、普通。逆に上位でしょ。 つまり、「隠蔽したい下位層」を継承するという考え方ではない。 隠蔽したい実装はサブクラスで行う。上位では、共通したインターフェイス を考える、ということ。
885 :
デフォルトの名無しさん :01/10/06 14:52
インターフェースの奴隷。
丸ごと持ってくるとなぜアホになるのかわからん。
>>885 他人のつくったクラスライブラリのインターフェースが不十分で
言語的にはインターフェース継承、多重継承ができず、単一継承
のみの場合には、「インターフェースの奴隷」と呼んでいい状態
が発生するような気もしますが、少なくともインターフェース継
承ができれば、なんぼでも回避する方策があるよーな気がします。
888 :
デフォルトの名無しさん :01/10/06 15:42
>>887 >他人のつくったクラスライブラリのインターフェースが不十分
その場合、インターフェイスを変換(および追加)するクラスを
用意してやれぱいいんじゃない。単一継承でもできるとおもう
けど。
889 :
デフォルトの名無しさん :01/10/06 15:54
ねえねえ、永続化をリレーショナルDBで行うときって、 どういうクラスを作るものなの? DBのテーブル = クラス、フィールド = プロパティって感じでいいのかな。 となると、フィールドをプロパティに代入するのはどのクラスが担当するの? そのクラスにはselectメソッドやらupdateメソッドやらつければいいのかしらん。
単一クラスのインスタンスの永続化ならそれでもいいんじゃない。 でも任意のクラスを扱うんだったらAsStringみたいに 一つの文字列(内部はXML見たいなのにして)で扱うとか。
テーブルがクラス?
あ、まちがえた。レコード = クラスです。 テーブル = コレクションクラス?
893 :
デフォルトの名無しさん :01/10/06 17:13
>>887 デザパタにあったね
アダプターだっけ?
894 :
デフォルトの名無しさん :01/10/06 17:37
>>884 結構鋭い指摘かも。
最上位がObjectクラスで最下位がアプリケーションのクラス?
OOPは奴隷用言語?
895 :
デフォルトの名無しさん :01/10/06 18:08
プログラム構造の上下とクラスの上下が逆か。 ここらへんがOOPの欠点かもね。 DQNPG大量生産の予感・・・。
オマエモナ
897 :
デフォルトの名無しさん :01/10/06 20:04
>プログラム構造の上下とクラスの上下が逆か。 多分、君のプログラムの設計は、ハードに密着したところからスタートするんだろうね。 でも、プログラムの目的を見失わずに、最下位から這い登ってくるのって、大変だろうね。
898 :
デフォルトの名無しさん :01/10/06 22:06
899 :
デフォルトの名無しさん :01/10/06 22:36
OOPにそんなに詳しくないけど、業務で使ってる漏れの感想は。 コンポーネントの責務とインタフェースの仕様さえしっかりしていれば、 どんな言語を使おうがプログラミングはなんとでもなる。 つーか、それができていない仕様で仕事まわされて泣く事が多い。 オブジェクト指向(つーかクラス図)は責務やインタフェースが分析・設計とも ビジュアル化しやすくてよいと思ってる。 クラス図読める人が相手なら話もしやすいし。
900 :
デフォルトの名無しさん :01/10/06 23:38
今だ!900番ゲットォォォォ!!  ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄ (´´ ∧∧ ) (´⌒(´ ⊂(゚Д゚⊂⌒`つ≡≡≡(´⌒;;;≡≡≡  ̄ ̄ (´⌒(´⌒;; ズザーーーーーッ
Eiffel, Sather つかってるときは多重継承派。 C++ つかってるときは多重継承きらい。
903 :
デフォルトの名無しさん :01/10/07 01:30
>>902 >C++ つかってるときは多重継承きらい。
両方知ってるぐらいの腕なら多重継承使っても問題なかろう。ど
ーとでも組めるのがC++だからね。
俺はインターフェースをくっ付けるって意味で純粋仮想関数一個だ
け持たせたクラスは割と使うな。C++屋は再利用が継承の主目的だ
と思ってる奴も多いから多重継承難しいと思ってる奴も多いけどな。
904 :
デフォルトの名無しさん :01/10/07 02:58
>>903 純粋仮想関数だけの抽象クラスを使ったオブザーバパターンは便利っす。
とりあえずこれ覚えただけでも設計しやすくなった。
レベル低すぎ
907 :
デフォルトの名無しさん :01/10/07 04:32
Delphiじゃ自然なんだけどね なんでそんなに難しく考えるんでしょか?(w
>709読め 難しいのではなく面倒なだけ。 新しい技術を学習・試行錯誤して習得するコストをかけるのが嫌なだけ。
でも面倒ってのはいかんよね。
遠いレスにはちゃんとリンク貼ってくれ>908
>>709
911 :
デフォルトの名無しさん :01/10/07 05:09
OO好きは余程抽象化が好きなのか、話の内容まで抽象的で、具体性に欠ける概念論ばかりです。 私の具体的アンケートに、回答してみてくれませんか? MFCでは、かなりのクラスがCObjectから派生していますが、これを好ましいと思いますか? もし好ましくないのなら、貴方ならどうやって、各クラスにシリアライズをサポートしますか?
912 :
デフォルトの名無しさん :01/10/07 05:10
>>911 かなりのクラスがCObjectから派生すると何か問題でもあるの?
913 :
デフォルトの名無しさん :01/10/07 05:15
シリアライズは普通言語・文法レヴェルでサポートするものです。 よってCObjectから派生する・しないに関わらずC++/MFCは糞です。
915 :
デフォルトの名無しさん :01/10/07 05:19
>>914 有用な意見、ありがとうございます。
参考になりました。
916 :
デフォルトの名無しさん :01/10/07 05:19
フツーとか言わないで理由を書け。ライブラリで問題ないなら 言語は小さい方が良い。
917 :
デフォルトの名無しさん :01/10/07 05:21
918 :
デフォルトの名無しさん :01/10/07 05:23
>>917 納得ではありません。
1つの意見として、参考になったと言ったのです。
919 :
デフォルトの名無しさん :01/10/07 05:23
CObjectから派生すると困るのか。困るとして何が困るのか具体的な意見を聞かせてください。 >否定派の方々
920 :
デフォルトの名無しさん :01/10/07 05:24
>言語は小さい方が良い。 ということはC++は間違いなく糞です。
921 :
デフォルトの名無しさん :01/10/07 05:32
>>920 今さら間違いなくなんて逝ってるドキュンをさらしアゲ
そもそもオブジェクト指向スレで C++の話題は完全にスレ違いです。 直ちにここから出て行きなさい。
923 :
デフォルトの名無しさん :01/10/07 05:37
>>916 914ではないが、多重継承をサポートしない言語の話でないか?
924 :
デフォルトの名無しさん :01/10/07 05:45
C++糞は、やめてもらうとして、私のアンケートは、 純粋にOOPの技術論ですよ。
好ましいと思います。 とりあえず、CObjectのポインタで保持しておけって言うプロトタイピング 的なコーディングが出来るから。 それに、多態生も実現できる。
926 :
デフォルトの名無しさん :01/10/07 06:02
>>924 ダメだと言ってる人はどんな理由でダメだと言ってるの?
それはつまりSTLはいらないということですね。
928 :
デフォルトの名無しさん :01/10/07 06:05
STLはオブジェクト指向と関係ないからね。そういう'世界' を強制しないところがC++の良いところでもあり、オブジェ クト志向言語としての致命的な欠陥でもある。
929 :
デフォルトの名無しさん :01/10/07 06:10
訂正。 stroustrup曰く、オブジェクト指向'も'サポートする言語か。
930 :
デフォルトの名無しさん :01/10/07 06:11
>>926 いくつか聞いていますが、私の意見ではないので、
それらの意見を持った人達の発言を、待ちたいと思います。
931 :
デフォルトの名無しさん :01/10/07 06:35
なお、賛成者のみの場合、OO設計とはそういうものだという、 結論になると思います。
stlがある今、CObjectの存在意義は薄い。 でもこれがあっても損は無い…かな? ダウンキャストは必要最低限に抑えたいと思っているので、 とりあえずCObjectのポインタでという組み方はちょっと。
934 :
デフォルトの名無しさん :01/10/07 13:50
親族クラスばっかりだと、近親相姦起こらない? 多重継承とかポインタや参照の 伝搬で。
C++ & OOPL == 0
=0
937 :
デフォルトの名無しさん :01/10/07 15:22
CObjectって多態のためにあるんじゃないの?? 確かにstl使えばすむような気がするけど stlでスタックってできたっけ? stl使ったこと無いからよくわからん テンプレートクラスとか使えばできるのかな・・・
938 :
デフォルトの名無しさん :01/10/07 17:05
ふと思った。 あるインターフェースの背後に置く実体を多様化させる、という観点で捉えると 次の三つは同類でありつつ微妙に違うという話になる気がする。 継承を使った多態=メソッドのセット単位での適合をコンパイル時に要求する。 ジェネリック型=メソッド単位での適合をコンパイル時に要求する。 型なし言語での多態=メソッド単位での適合を実行時に要求する。 だから何、とか言われても困るけど、こんな感じじゃない?
939 :
デフォルトの名無しさん :01/10/07 21:15
ほとんどのクラスでシリアライズが必要−>じゃ上位クラスでとやると、 各クラスの共通部分が上位クラスになり、どんどん多段階層になる。 これがOO的に当然だとするならば、OOに則したプログラムは、 階層の深い、わかりにくい物となる気がするが?
>>903 >両方知ってるぐらいの腕なら使っても問題なかろう。
>どーとでも組めるのがC++だからね。
多重継承するとき
C++ は安心して実装継承や菱形継承ができない。
多重継承派の人がいてうれしい。多重継承派はよく嫌われる。
941 :
デフォルトの名無しさん :01/10/07 23:43
Objectクラスなんてクラス宣言の 「{」に隠蔽しとけばいいじゃん。
942 :
デフォルトの名無しさん :01/10/07 23:57
>>939 >これがOO的に当然だとするならば、OOに則したプログラムは、
>階層の深い、わかりにくい物となる気がするが?
実際Smalltalkのクラスライブラリの初期の敷居の高さは割と
言われてることだと思うし、MFCなんかもある程度基底クラス
の役割が見えてこないとさっぱ理解できんだろう。基底クラス
が膨らめば膨らむほどこの敷居は高くなるが、一度学習を終え
てしまえば皆が同じ世界を共有するので再利用に非常に有効だ
しコードの可読性も高まるしで、かなりおいしいメリットもあ
る。その取捨選択は言語の設計者のポリシー次第で、C++はそ
の辺全部外注しちまったってとこだろうな。
943 :
デフォルトの名無しさん :01/10/07 23:58
再利用するまで そのOOP持つのかね?
945 :
デフォルトの名無しさん :01/10/08 01:51
>>942 数百万ステップの業務処理部分でも、学習さえしてしまえば、
可読性が高く修正等が容易かな?
946 :
デフォルトの名無しさん :01/10/08 01:53
>数百万ステップ どんな業務処理やねん。
947 :
デフォルトの名無しさん :01/10/08 02:00
>>946 某官庁系のシステムだけど、OS/2のサブシステム1つでも、
百万ステップ超えてるよ。
>>946 ステップあたりいくらで受注してるんだろうね。
949 :
デフォルトの名無しさん :01/10/08 02:01
あ、役所系は駄目ー。 賄賂渡して水増しソースとお金交換とかやってるから。
MFCのCStringは、シリアライズはCObjectに依存しない。 独立性が高いので、他のクラスとの多重継承もしやすい。 (只の文字列にしては重すぎるケドね)
952 :
デフォルトの名無しさん :01/10/08 02:46
多重継承はバグの温床 そんなのわざわざ使わなくたってプログラムは組めます
NGワード使用につき退場です。
954 :
デフォルトの名無しさん :01/10/08 04:54
>>938 >継承を使った多態=メソッドのセット単位での適合をコンパイル時に要求する
ってどういう意味でしょうか?
セット単位っていうのがわからないのですが
ちなみに、継承を使った場合C++,JAVAは実行時ですけど
時間があれば残り2つに関しても説明していただけるとうれしいです
955 :
デフォルトの名無しさん :01/10/08 05:12
>>952 もうちょっと詳しく説明してくれ。
特に多重継承がどのようなバグを引き起こすのか
解説キボン。
継承は、強烈なポリモーフィズムの必要性に基づくべき。 (強烈じゃなきゃやめとけって事。)
957 :
デフォルトの名無しさん :01/10/08 05:39
漏れは、CObjectからの巨大ツリーじゃなくて、3階層ぐらいでばらけてたら、もっと使い安かった気がするなー。
CObjectって名前、カコワルイ なんでただ、objectじゃいかんの?
object なんて一般的な単語をライブラリレベルで使われたら それはそれでいやなんでわ?
>CObjectって名前、カコワルイ MFCのクラスの命名規則がC+頭大文字の単語って決まってるから。
>>950 古いけどええ記事だな
オブジェクト指向で大規模な開発だと参加PG全員を一定レベル
以上に教育しておく事が必要だね
講師を呼んで全員に研修二日かける程度なら 後でおつりももらえていい感じかも
963 :
デフォルトの名無しさん :01/10/08 13:23
あんたの身の回りの現実に同情するよ
965 :
デフォルトの名無しさん :01/10/08 14:18
OO礼賛の提灯記事や書籍を真に受けて「勉強」しちゃった人は現実など関係無いのです。
OOスレは必ず揉めます。それは何故か?実は…
やっつけ仕事しかしとらん現場にいると、 OOが絵空ごとに見えるんだろうな。 すべてをOOで設計・解決するわけじゃあないが おいしいとこは、しっかりと使わせてもらってるよ。
968 :
デフォルトの名無しさん :01/10/08 14:53
現実=OOやOOP導入して失敗した例を体験、目撃してるのさ。
>>961 あれ読んで、PGの教育に問題があるなんて、
現実が見えてない。
どう考えても、もっと重要な問題があるだろ。
>>962 研修二日で、何か変わると思うのか?
明らかに現実を知らない。
>>964 俺の現実って何だ?
煽りでしか反論できない低脳。
>>965 俺はOO否定派じゃない。
>>966 結論のない、無意味な書き込みやめろ。
荒れる理由は、964-967みたいなのがいるからだ。
>>967 俺の現場って何だ?
煽りでしか反論できない低脳。
なぜ失敗したかの分析をした? 俺も何度か失敗したケースに立ち会ったが、 どうすればうまくいくのか、 何をしないのがうまくいくのか、 調べて、次にイカしたよ。 そういうノウハウをためてはじめて使えるもんだと思うがね。 たしかに、理論に夢中になってる連中を見ると、 現実をミロとも言いたくなる。 ミロ飲みてえな、久しぶりに。。
971 :
デフォルトの名無しさん :01/10/08 14:59
OO必要だって言ってる人と OO不要だっていってる人の 仕事のレベルが違うのでは?? 名前のところに年収でも書いてくれれば言いと思うけど
>>971 自分の発言に責任を持てない厨房じゃないなら、まずおまえが書け。
>963 消えろ。ウザい。
ていうか、そろそろ次スレ? (笑)
975 :
デフォルトの名無しさん :01/10/08 15:06
>>969 >
>>966 > 結論のない、無意味な書き込みやめろ。
> 荒れる理由は、964-967みたいなのがいるからだ。
何故964-967みたいなのがいるのか?実は…
>>973 出たー。
低脳の極み。
出ると思ったんだよなー。
おまえみたいな論理のないやつは、プログラマやめろ。
むいてないんだよ。
>>952 多重継承できる言語だとアダプタパターソが楽だよ。
この程度の内容なら次スレはマ板に立てろ
そろそろCObjectの話題に戻したら? せっかく設計思想の技術的な話しになって たのに。
980 :
デフォルトの名無しさん :01/10/08 15:23
どうにかして非技術的な話しかしない、 基地を排除できないものか
話がOOだから難しいと思われ モデルの話だから人によって流儀が違うことがある。 また、モデリングなんて必要ないという暴論も用意に口に出来る。 # CPUが必要ない、なんてことはありえない。 対象ずばりそのものじゃなくて射影(の流儀)について議論すると揉めることが多い。 例えば政治がその代表例。 ってな話がOOと関係あるかどうかでさえ揉めるだろう。(俺はあると思うのだが…)
>>979 CObjectの話題を今読み返しましたけど、なんか、やっぱり
つまんない話題ですね。
MFCがOOのすべてでもなかろに。
984 :
デフォルトの名無しさん :01/10/08 15:33
まずはOOスレがどうあるべきかについて語るスレを作りましょう。
986 :
デフォルトの名無しさん :01/10/08 15:36
アホかと、バカかと、
>>983 わしもMFC嫌いだから、興味ない。
非抽象的題材なのは評価できるが、もっと別のネタないの?
>>985 スレ立てお願い。
おれがやろうとすると、何故かスレッド立てすぎです・・といわれる。
全然立ててないのにさ!
989 :
デフォルトの名無しさん :01/10/08 15:40
1000!
990 :
デフォルトの名無しさん :01/10/08 15:41
>>988 無駄な上位概念を作るのは、悪いOOの例です。
>>991 988が欲しかったスレとは違うのでは???
993 :
デフォルトの名無しさん :01/10/08 15:45
SOROSORO IDO SHIMASYO
994 :
デフォルトの名無しさん :01/10/08 15:45
まあ963は立ち入り禁止ってことで
995 :
デフォルトの名無しさん :01/10/08 16:25
>>983 JavaベースにObjectクラスがありますが・・・
996 :
デフォルトの名無しさん :01/10/08 16:25
JAVAもベースに・・・です
てかC++以外のOOPLは大抵共通のObject基底クラスを持ってるでしょう? シリアライズのインターフェースも大抵Objectが持っている。 そこを「無駄な上位概念」とかわけわからんこという奴は、 C++のMFCとSTLだけでOOを語ろうとおもてるんではないかと 考えたわけで。 アホか、つまらんことぬかすな、と。
998 :
デフォルトの名無しさん :01/10/08 17:08
>997 >てかC++以外のOOPLは大抵共通のObject基底クラスを持ってるでしょう? だったらいいじゃん なぜそんなに否定的なの
1000 :
デフォルトの名無しさん :01/10/08 17:14
ここだ!1000番ゲットォォォォ!!  ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄ (´´ ∧∧ ) (´⌒(´ ⊂(゚Д゚⊂⌒`つ≡≡≡(´⌒;;;≡≡≡  ̄ ̄ (´⌒(´⌒;; ズザーーーーーッ
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。