オブジェクト指向スレ

このエントリーをはてなブックマークに追加
1 ：憂鬱な名無しさん：
・オブジェクト指向の有効性についての議論
・オブジェクト指向についての疑問、応答
・OOP言語、UML、分散オブジェクト、デザインパターン等

などなど、オブジェクト指向についてのスレッド。
2 ：関数型信者：01/09/24 05:20
OO のメリットってなんですか？
3 ：デフォルトの名無しさん：01/09/24 05:22
医師免許と同様、オブジェクト指向設計も、有資格者のみが行えるよう
になるらしい。ｳｿ
4 ：憂鬱な名無しさん：01/09/24 05:35
>>2
・プログラムの再利用がしやすい。
・変更が局所化されるので、仕様の拡張や変更に対応しやすい。
・プログラムの構造が把握しやすい。
・状態の管理に優れている。

とくに状態の管理という視点は関数型言語に対するアドバンテージだ
と思います。逆に関数型言語のOOに対するアドバンテージってなん
ですか？
5 ：デフォルトの名無しさん：01/09/24 05:39
関数型とOOはベクトルが違うので直接の比較は意味がないと思うなあ。
6 ：デフォルトの名無しさん：01/09/24 05:43
>>5
うむ、確かにベクトルが違うと比較は難しいな。
正反対の方向で進化したベクトルの双璧という感じがする。
しかし、どうしても比べたくなって来るのもまた事実。
7 ：　：01/09/24 05:47
>>4
＞・プログラムの再利用がしやすい。

再利用できた事の方が少ないが・・。
8 ：デフォルトの名無しさん：01/09/24 05:51
なんつーか、胡散臭いんだよねー。
設計が上手くないと、てんで使い物にならないんだろ？
それって実はオブジェクト指向自体に欠陥があるからじゃないか？
仕様変更に対応しやすいってのも疑問だな。設計を変える
と根本から作り直しだろ。設計のやり方もわかりにくい。
ただ騒がれてるから信者が増えただけのような気がするんだよな。
9 ：デフォルトの名無しさん：01/09/24 05:57
構造化できれば十分です。
10 ：デフォルトの名無しさん：01/09/24 05:59
関数型って、Lispとかのこと?
OOPだと、ポリモーフィズムができるけど、関数型でもできるの?
それともまったく違った方法論なの?
11 ：デフォルトの名無しさん：01/09/24 06:03
>>10
Lispはそもそも変数に型が無いから、ポインタと言わず
変数に何でも代入できる。
Haskellは型がある関数型言語だけど、型クラスの
仕組みがポリモーフィズムに対応すると思う。
12 ：デフォルトの名無しさん：01/09/24 06:04
＞設計が上手くないと、てんで使い物にならないんだろ？
＞設計を変えると根本から作り直しだろ。
OOがあってもなくても同じ。
13 ：デフォルトの名無しさん：01/09/24 06:05
>>8
うーん、その類の意見よく聞くけど
設計テキトーにやって何とかなる考え方ってプログラミングに限らずあるかなぁ・・・？
設計していく上で、うまくいく設計の指針みたいな物はやっぱり必要だと思うし。
OO詳しくないから結構テキトーに言ってるんだが、そんな気がする。
14 ：デフォルトの名無しさん：01/09/24 06:06
構造化が流行った時には、少なくともコーディングレベルでは
あっというまに広まったけど、オブジェクト指向は、なかなか
そうはならない。
オブジェクト指向って、一般ピープルにはむずかしすぎるんだよ。

オブジェクト指向、破綻説に一票。
15 ：デフォルトの名無しさん：01/09/24 06:12
構造化が広まったのはC言語の仕様のせい。
C++がグローバル変数とグローバル関数とパブリックなデータメンバを
使用できない言語仕様にしたらあっという間に広まっただろう。
16 ：デフォルトの名無しさん：01/09/24 06:18
構造化は無理すればBASICだろうが何だろうがある程度はできる。
やりやすい言語とやりにくい言語の違いはもちろんあるが、
かしこいプログラマであれば、ダイクストラが構造化を唱える以前から
無意識のうちに構造化していただろう。
でも、オブジェクト志向だとそうはいかない。
オブジェクト志向のほうが明らかにむずい。
17 ：デフォルトの名無しさん：01/09/24 06:19
>>15
>構造化が広まったのはC言語の仕様のせい。

それは違うだろ。
当時は、COBOLやFortranような言語でも、構造化の構文が
取り入れられたら、しっかり現場でも使われていた。

オブジェクト指向は、COBOLやFortranに取り入れられても
現場では広まらなかった。

本質的に難しいんだよ。オブジェクト指向は。
18 ：defaultの名無しさん：01/09/24 06:30
良くある風景

メソッドを整えても、俺しか使わない。
俺のクラスから派生などしない。
良く知りもしないクラスの関数を上書きするたび、
そのうち何かあるなと思う。
19 ：defaultの名無しさん：01/09/24 06:35
良くある風景２

構造化しないと、設計は無理。
オブジェクト指向だと、設計が面倒。
20 ：関数型信者：01/09/24 06:46
>>4
下の三つはわかるのですが、
OO だと再利用しやすくなるってのはなんででしょ？

あと2番目に挙げられていることは、要はカプセル化だと思うのですが、
それに関しては OOP言語でなくとも容易に出来ますよね。

> 逆に関数型言語のOOに対するアドバンテージってなんですか？
なんでしょうねぇ？

>>11
型クラスが無い ML でもポリモーフィズムと呼ばれるものはあるよね。
まあ、Haskell のほうが柔軟な気もするけど。

>>14-17
構造化は思考の平淡化って感じだしね。

その点、OO は問題を分析して何かを抽出し、そこから基礎を築き
その上にプログラムを築くみたいな感じ(ちょっと謎)だもんなぁ。
21 ：デフォルトの名無しさん：01/09/24 07:01
>>20
なんでしょうねぇ？で、関数型の信者務まるのかよ。
22 ：　：01/09/24 07:03
ＯＯＰのライブラリを丸暗記して、
真っ平らに並べたプログラム書いて、（意味判らない人は該当）
クラスは単なるサブルーチンに使ってるだけ。
でもってＯＯを理解したつもりになってるＯＯオタって多そう。
23 ：defaultの名無しさん：01/09/24 07:12
>>20
クラスライブラリ作るならまだしも、普通のアプリだとねぇ。
24 ：関数型信者：01/09/24 07:14
>>21
関数型言語が好きというだけで、
決して関数型言語への理解が深いわけではないのです。
スミマセンね、精進します。
25 ：デフォルトの名無しさん：01/09/24 07:22
>>20
ＯＯにのっとって設計したら　使う分にはもう極楽だよ
再利用性もとても良い　自分で設計して極楽鳥～
だけど設計と実装が地獄だyo
26 ：　：01/09/24 07:25
構造化なんてアセンブラもやってるよ。
つうかメモリにバラバラにデーター配置してたら何がなんだか
判らなくなる。
27 ：意味は無い：01/09/24 07:37
http://slashdot.jp/comments.pl?sid=01/09/22/109245&op=&threshold=0&commentsort=0&mode=nested&startat=&cid=23
28 ：defaultの名無しさん：01/09/24 07:40
誤解が無いように補足すると、構造化はどの言語でも必須で、オブジェクト指向時にも当然使用するでしょう。
（構造化の階層を、クラスの派生で補えるわけもない。）
両者を対峙するものとして比較したのではなく、必然性で比較したのです。
29 ：25：01/09/24 07:48
>OOP言語を使っても再利用可能なClass・設計の蓄積が無い分, 従来の言語と生産性は変わらず,
>むしろ不慣れな分だけ生産性が落ちるというのが現実です

クラス資産命だもの＞ＯＯ
言葉だけＯＯにしても無意味だyo
30 ：　：01/09/24 07:50
再利用性は一般にはない。
あるのは

１）データ操作や入出力の基本関係
２）同じ様な物を作ってる場合

だけ。
プログラムの内、アプリケーションの仕様依存部分が
特定のアプリケーション固有のものなら一般性はないから
再利用できない道理。
31 ：　：01/09/24 07:52
「Ａ社の納めたアプリをちょっと変えてＢ社にも売った。」
というのはＯＯの再利用性とは違う。
32 ：デフォルトの名無しさん：01/09/24 07:58
プログラミングに限らずどんな分野でもそうだが、
良かれと思って新技術を導入したらかえって以前よりも生産性が落ちることは珍しくない。
難し過ぎて使いこなせる人が少なければ、
理屈の上では理想的な技術であったとしても邪魔なだけ。
33 ：　：01/09/24 08:01
難しいせいじゃないよ、
理屈自体が宣伝する為に作られただけだから。
34 ：デフォルトの名無しさん：01/09/24 08:24
オブジェクト指向って何ですか？
まだプログラムについてよくわかってないのですが……
どんなものに使われているのかもわかりません
できるかぎり詳しく教えて欲しいです。
35 ：デフォルトの名無しさん：01/09/24 08:32
ここを見なさい。
でも、見てもわからんと思うよ。
http://yougo.ascii24.com/gh/07/000738.html
36 ：デフォルトの名無しさん：01/09/24 08:48
>34
動作部分は軽く作ってあとから定義しろってことです。
37 ：デフォルトの名無しさん：01/09/24 09:39
違うと思う。
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
オブジェクト指向なんて無視して、僕が言うとおり
何かするオブジェクトを作ったら動作部分は軽く作っておいてあとから継承したオブジェクトで定義すればいいんです。それが有効に使える技です。
あとは秘密です。
43 ：デフォルトの名無しさん：01/09/24 14:56
MFCがオブジェクト指向かというと　フレームの元になるから言いたくないけどさ

クラスライブラリ＝オブジェクト指向　じゃないかもしれないな　という線で
44 ：デフォルトの名無しさん：01/09/24 15:00
>34
どうやって実装しているかそのクラスを使う人に見えてはいけません。
あくまでも、開発者の視点ではなく、ユーザーの視点でクラスのメソッド等を決めなくてはいけないです。
45 ：　：01/09/24 15:34
>>44
＞どうやって実装しているかそのクラスを使う人に見えてはいけません。

Javaはそれやってるから糞言語なんだよねー。
見えてるというか「さあ見ろ！見ないと使えないぞ！」って構造。

ユーザーが使うクラスは　Ａだけなのに、使いたければ
継承元のクラスと、その継承元のクラスと、継承元のクラスと、継承元のクラスの
メソッド（メンバ関数）を参照してね。とかやってる。

ＳＵＮの設計者は単なるクラスヲタであってＯＯＰの設計をしていないと思う。
46 ：デフォルトの名無しさん：01/09/24 15:37
>45 まともなクラスライブラリって例えば何？
47 ：デフォルトの名無しさん：01/09/24 15:44
汎用的なクラスライブラリってデカイ割に使えないよね。
48 ：デフォルトの名無しさん：01/09/24 15:46
今時なんでもかんでも CObject から派生してるやつとかね(藁
49 ：　：01/09/24 15:47
>>46
マシ、というのであれば、ＭＦＣの方がマシ。
50 ：初期不良：01/09/24 15:48
>>46
BeOS の標準 IDE のクラスライブラリは使いやすかったなぁ
51 ：　　：01/09/24 15:49
>>48
激しく同意。
別に全てのクラスが一つの基本クラスから派生してなきゃいけない理由
なんか無い。
52 ：デフォルトの名無しさん：01/09/24 15:50
>>49
それはあなたが MFC に慣れているというだけじゃ？
Java はけっこうコダワリ OOP という気がする。

OOP という話なら、MFC は糞。
53 ：デフォルトの名無しさん：01/09/24 15:54
もはやアレだけど Metrowerks の PowerPlant はけっこう良いです。
そこかしこにこっそりデザインパターンもちりばめられている。
BeOS のそれとも似ているかも。
54 ：デフォルトの名無しさん：01/09/24 15:58
>別に全てのクラスが一つの基本クラスから派生してなきゃいけない理由
>なんか無い。
んなこたない。
言語仕様として基本クラスのないOOPLなんてC++くらいだよ。
55 ：デフォルトの名無しさん：01/09/24 16:01
MFCやったことないけど、CObjectて何？？全てはMFCのクラスだから基本のCObjectから派生するの？
56 ：デフォルトの名無しさん：01/09/24 16:04
＞言語仕様として基本クラスのないOOPLなんてC++くらいだよ。
C++ 自体は君が思っているほど OOP べったりな言語ではない。

それに静的な言語と動的な言語をごっちゃにするのもどうかと思ふ。
57 ：デフォルトの名無しさん：01/09/24 16:07
>>56
>C++ 自体は君が思っているほど OOP べったりな言語ではない。
そんなことは百も承知だがここはOOPスレだろ(藁

それに今時の言語は動的・静的の区別は
かなりあいまいになってきてるから
ごっちゃにしないのもどうかと思ふ。
58 ：　：01/09/24 16:10
>>52
ＭＦＣのSerializeとＪａｖａのSerializableの説明の比較をしてみよ。
ＭＦＣの方はそれ読んだだけで組めるけど、（ＭＳＤＮ）
Javaの方はあの説明だけでは（ＡＰＩドキュメント）
「結局自分で実装するのか？」（説明文が糞）
「どうやって実装するのか」（他のクラスの事だから？触れていない）
さっぱり判らんぞ。
59 ：56：01/09/24 16:11
>>57
生意気言ってすみませんでした。
よくわかんないんで、どのへんがあいまいになってるのか教えて下さい。
60 ：　：01/09/24 16:12
>>54
クラス原理主義者発見！
Ｏｂｊｅｃｔ基本クラスなぞＯＯとは関係無いぞ！
61 ：　：01/09/24 16:14
>>54
じゃあStringの基本クラスにCharクラス持ってきて使ってね 藁
62 ：デフォルトの名無しさん：01/09/24 16:17
>>58
それじゃ設計じゃなくてドキュメントの問題じゃん。
63 ：　：01/09/24 16:20
>>62
>>44を読もう。
64 ：デフォルトの名無しさん：01/09/24 16:28
結局、オブジェクト指向という思想は無視して、現実的で美味そうなところだけピックアップして使えってことだろ。
65 ：デフォルトの名無しさん：01/09/24 16:34
>>64
>>オブジェクト指向という思想
について解説お願い。無視するかどうか、知ってから考えたいので。
66 ：デフォルトの名無しさん：01/09/24 16:45
原子力発電は危険なので色々議論がかわされるが、いちいち危険なんか気にしてられないのでどんどん原子力使えってことです。
67 ：デフォルトの名無しさん：01/09/24 16:52
原子力発電は危険な面もあるので議論の対象となっているが、
作られた電気に区別はなく、利用者には区別のしようもないという事では？
68 ：66：01/09/24 16:52
原子力発電は危険なので色々議論がかわされるが、いちいち危険なんか気にしてられないのでどんどん原子力使って電気取ることだけ考えろってことです。
69 ：横レス：01/09/24 16:56
>>65
オブジェクトからオブジェクトにデーター渡すだけで必要な
プログラム動作が得られるような構造。

例：テキストエディタが作りたければ

KeyBoardObject　→データ→　DisplaｙObject

でエディタが完成する様に両方のオブジェクトをつくればいい。
DisplaｙObjectは他の入力（ムービーファイルやマウスドロップ）
にも対応す汎用性を持っていなくてはいけない。
70 ：　：01/09/24 16:58
にも対応す汎用性を持っていなくてはいけない。 　×
にも対応する汎用性を持っていたほうがいい。　　○
71 ：デフォルトの名無しさん：01/09/24 16:59
＞オブジェクトからオブジェクトにデーター渡すだけで
OOP的にはそうだがOO的には「オブジェクトにメッセージを送ることで」

この概念のレベルと実装のレベルがごっちゃにされやすい。
72 ：デフォルトの名無しさん：01/09/24 17:00
↑
...
73 ：66：01/09/24 17:01
>67
いや。
74 ：　：01/09/24 17:04
あーう「メッセージ」。
出ましたか。
出ましたね。
信者登場ですね。
75 ：　：01/09/24 17:07
設計レベルでストリーミングデータやファイルデーターを
「メッセージ」と呼ぶ奴いたら病気。
76 ：デフォルトの名無しさん：01/09/24 17:11
その心は。
77 ：65：01/09/24 17:18
>>66+67+68
「原子力発電」=オブジェクト指向テクニック、「議論」=思想、という
ことですか。
思想はいらないから、テクニックはどんどん使えということ。つまり、
OOPしろということですね。了解。
>>69
レスありがとうです。
今いち理解が及びませんが、勉強してみます。
78 ：　：01/09/24 17:19
一般のＯＯの解説ではメッセージの他にデーターの流れの説明してるのかな？
メッセージしか書いていないんじゃない？
79 ：デフォルトの名無しさん：01/09/24 17:21
>>74
OO信者だけど何か？
分析・設計段階ではメッセージでいいじゃん。
でもまあ、データ中心なプログラムとは相性が良くないね。
そういうのにはDFDでも使うべし。
80 ：デフォルトの名無しさん：01/09/24 17:28
OO否定してるのは、OOがよく理解できない馬鹿だろ。
理解できなかったら上手く使えるわけも無い。
そういうやつがOO使えるやつを批判して、OO使うなという。
なんのことはない、OO使えるやつの足を引っ張ってるんだよ。
OO否定するやつは世間に迷惑かけてる害虫なんだよ。
81 ：java厨房：01/09/24 17:29
>>71,75
メッセージは、オブジェクトのメソッドの呼び出しでしょ。
データ自体がメッセージなの?
82 ：デフォルトの名無しさん：01/09/24 17:34
>>81
データを包んだオブジェクトの参照がメッセージに乗って運ばれる。
83 ：　　：01/09/24 17:47
>>79
ＯＯのクラス図はＤＦＤだよ？
84 ：デフォルトの名無しさん：01/09/24 17:51
オブジェクト指向の話題＝＝揚げ足取り量産
85 ：デフォルトの名無しさん：01/09/24 17:51
OOのクラス図って何だ？
UMLの分析段階でのクラス図をDFD代わりに使うってのなら分かるが。
86 ：デフォルトの名無しさん：01/09/24 17:53
>>85
クラス間の継承関係と委譲関係を図にしたものじゃない？
OOPプログラムの仕様書に、それが無いと困ると思うが。
87 ：　：01/09/24 17:57
あ、ＭＵＬのクラス図の間違い。
88 ：デフォルトの名無しさん：01/09/24 17:58
なるほど。そういう流儀のクラス図なのか。
図というとUMLしか思い浮かばなかった。見聞が狭くてすまん。
89 ：デフォルトの名無しさん：01/09/24 18:00
すいません。OOとOOPってどう違うんですか？
90 ：　：01/09/24 18:08
ＯＯＰはオブジェクト指向言語
ＯＯはオブジェクト指向概念。

ＯＯＰはＯＯを元に作られた、という体裁を取っているけど、
本当はＯＯはＯＯＰの後から適当に作られたインチキ概念。
物理学でいうところの原理に相当するものが欲しかったんだろうね。
91 ：デフォルトの名無しさん：01/09/24 18:14
>>90 レスありがとうございました。違いはよくわかりました。
構造体が便利だから操作する関数も一緒に構造体にぶち込んだら
クラスができました！(･∀･)って感じですか？
違うでしょうね(^_^; すいません。
92 ：デフォルトの名無しさん：01/09/24 18:43
構造体にも関数定義できるよ
93 ：　：01/09/24 20:30
>>92
関数ポインタね。
94 ：デフォルトの名無しさん：01/09/24 20:35
関数ポインタテーブル領域が最低限必要>92
C++なら不要であれば自動削除される
95 ：デフォルトの名無しさん：01/09/25 00:34
>>90
OO はオブジェクト指向
OOP はオブジェクト指向プログラミング
OOPL がオブジェクト指向言語

じゃないの？
96 ：デフォルトの名無しさん：01/09/25 03:55
>>90
Simulaしらんの？
97 ：defaultの名無しさん：01/09/25 04:06
実際に設計してみれば、矛盾に気づくと思う。

継承重視で設計すれば、メンテナンスが楽？
仕様変更があったら、ソース変更した方が早いでしょ。
そもそも、オーバーライドだけじゃ対応できないし。
プログラムがわかりにくくなるだけ。

オブジェクト単位なら、汎用性がある？
共通サブでもないアプリに、汎用性は必要ない。
インターフェイス増やして、工数がかさむだけ。

クラスライブラリの場合、派生させて使用するのが前提だし、
汎用性が必要なのも当然。
しかしアプリの場合、そんな必要は元々無い。
98 ：デフォルトの名無しさん：01/09/25 04:18
>>97
仕様変更のときに普通にソース変更なんかやっていては、あちこちに
変更の影響が波及してバグが発生しやすくなるし、大変だよ。
オーバーライドで対応できないのはもともと分析が悪いか、根本的に大
きすぎる仕様変更があった場合だけで、別にオブジェクト指向が悪い
わけじゃない。
それに、オブジェクト指向分析は何も難しいことじゃなく、現実を
そっくりそのままシミュレーションするように考えればいいだけ。
逆にオブジェクト指向を使わないほうが、指針が無いだけにかえって
安心感が無いな。
アプリに汎用性が必要ないってのもおかしな議論で、万が一に備えて
万全を期すのがいいに決まってる。
99 ：デフォルトの名無しさん：01/09/25 04:25
オブジェクト指向の最大の弱点は、他人が保守する時に
その他人もオブジェクト指向の教養が無いと駄目なこと。
その意味で汎用性が無くなる。
100 ：　：01/09/25 04:27
仕様変更なんて当たり前。
ゆえにＯＯは机上の空論。

汎用性のあるアプリなんか作ってるのは安易な仕事やってるだけ。
101 ：デフォルトの名無しさん：01/09/25 04:27
ひゃく

ああ、まったく、どいつもこいつもお手軽症候群だ。
102 ：101：01/09/25 04:28
(T_T)
103 ：　：01/09/25 04:29
じゃあ、株価チャートの表示分析アプリと給与計算アプリで
再利用できるクラスを挙げてくれ。ｗ
104 ：デフォルトの名無しさん：01/09/25 04:30
>>100
意味がわからん。その当たり前の仕様変更に対応しやすいのが
オブジェクト指向。
そのために汎用性のあるコードを書くのは当然。
105 ：デフォルトの名無しさん：01/09/25 04:31
>>103
企業クラス、社員クラスetc.
106 ：１０３：01/09/25 04:32
設計段階では汎用になるはずだったコードなら書けるけどね。
無理無理。空論空論。
107 ：デフォルトの名無しさん：01/09/25 04:33
個々のアプリに汎用性があってもしゃーないやろ？
でも汎用性たっぷりのMFCとかのクラスライブラリを
ベースに(つまり再利用しまくって)作っとるでしょ？みんな。
108 ：デフォルトの名無しさん：01/09/25 04:33
>>106
根拠が抜け落ちてます。もうちょっと詳しく説明してくれないかな？
109 ：　：01/09/25 04:34
>>105
自社の給与計算に決まってるのに、請負いで他社の給与計算するの？

社員クラスと株価関係ないじゃん。
110 ：defaultの名無しさん：01/09/25 04:34
オブジェクト指向の分析は、現実の世界に即していない。
（継承と再利用に関わる部分。）
ＯＯＰ独自の考え方が必要だと感じる。
111 ：　：01/09/25 04:35
>>107
しょーもなー。
112 ：デフォルトの名無しさん：01/09/25 04:36
>>107
だから、ここでアプリに汎用性があるという言われ方してるのは
アプリに使われてるコードに汎用性があるってことだろ？
この板的にユーザーの視点じゃないだろうし。
113 ：　：01/09/25 04:36
ＯＯ礼賛してるのって、只のライブラリ厨が多い。
114 ：デフォルトの名無しさん：01/09/25 04:37
>>107
そんでもって、いつも使う社内用なり個人用なりの
クラスライブラリみたいなの持ってるでしょ？
再利用できとるやん。
115 ：デフォルトの名無しさん：01/09/25 04:38
>>109
株価チャートと給与計算は独立した二つのアプリじゃないのか？
何が言いたいのかわからん。
まさか、全く違う用途の二つのアプリで共通に使うクラスを
作れってことか？
それが作れないからって汎用性が無い等と言い出すのは
無理矢理な議論だな。
116 ：デフォルトの名無しさん：01/09/25 04:39
>>110
＞オブジェクト指向の分析は、現実の世界に即していない。
あたりまえ。
現実のレベルよりもっと抽象的なレベルで考えるだろ？
117 ：　：01/09/25 04:39
持ってないよ。
一般に使いまわしできないもん。

Ｃのファイル分けだと出来たけどね。
118 ：デフォルトの名無しさん：01/09/25 04:39
OOは先人が作ったデザインパターンを使えるのも大きいよ。
先人の知恵が労せず使える。
119 ：デフォルトの名無しさん：01/09/25 04:39
>>117
そらあんたに才能ないだけだわ。
120 ：　：01/09/25 04:40
>>116
(ﾟДﾟ)ﾊｧ!?
121 ：デフォルトの名無しさん：01/09/25 04:41
給与計算アプリで社員クラスがあれば、ある社員が昇進しても
その社員オブジェクトが所属する地位を変えるだけで簡単に
対応できる。
汎用性あるじゃん。
122 ：　：01/09/25 04:44
>>121
激しく勘違い。
これがＯＯ厨の正体か？
123 ：デフォルトの名無しさん：01/09/25 04:44
ていうか、ＯＯ否定派は何が言いたいのかわからん。
124 ：defaultの名無しさん：01/09/25 04:46
結局のところＯＯＰの効用とは、
カプセル化記述の美化と、派生と上書きによる
クラスライブラリのカスタマイズである。

クラスライブラリを作るような気持ちでアプリを作ると、
とんでもないことになる。
125 ：　：01/09/25 04:46
まあ。クラス礼賛してる奴はそれまで再利用性のあるプログラム
書けなかった人だろうね。
クラス導入で言語の助けを得て初めて再利用できるようになって
感激しているというところか。
126 ：デフォルトの名無しさん：01/09/25 04:47
>>124
クラスライブラリを作るつもりでアプリ作るのがＯＯＰなのか？
127 ：　：01/09/25 04:47
Ｊａｖａだと全然カプセルに見えませんが何か？
128 ：デフォルトの名無しさん：01/09/25 04:48
>>125
で、オブジェクト指向の欠点とは何でしょう？
129 ：デフォルトの名無しさん：01/09/25 04:50
>>125
じゃあ、あんたは普段再利用性の高いコードを書くために
どういった手法を使っている？
130 ：　：01/09/25 04:53
>>129
再利用性の高い仕事を貰う。ｗ
131 ：　：01/09/25 04:54

>>128
行きすぎると生産性を落とす。
132 ：デフォルトの名無しさん：01/09/25 04:55
>>130
なるほど、よくわかった。
133 ：デフォルトの名無しさん：01/09/25 04:55
>>131
行き過ぎなければいいんだね？
134 ：デフォルトの名無しさん：01/09/25 04:56
>>118
そして、デザインパターンを知らない他人がソースを
保守できなくなる。
135 ：defaultの名無しさん：01/09/25 04:57
>>126

ＯＯＰの概念の多くを、アプリに持ち込まない方がいいのではという意味。
クラスライブラリから派生させて使ってる程度が、ちょうどいい。
136 ：デフォルトの名無しさん：01/09/25 04:58
>>134
それは、Cを知らない他人がCのソースを
保守できないのと同じことではないんですか？
137 ：1：01/09/25 04:59
これカキコしてる奴誰だよ！↓
http://members.tripod.co.jp/bingo852/
138 ：デフォルトの名無しさん：01/09/25 05:00
>>136
Cとデザインパターンでは、使えるまでに必要な知識量が全然違う。
139 ：デフォルトの名無しさん：01/09/25 05:01
>>134
ようはあれか？
少年野球チームに突然西武の松坂が助っ人に現れて全力投球したのはいいが、
キャッチャーがボールをとれなくて負けてしまったって状況と同じ状況か？
140 ：デフォルトの名無しさん：01/09/25 05:05
>>137
何？ブラクラ？グロ画像？
141 ：デフォルトの名無しさん：01/09/25 05:05
>>138
たとえ C で OOP の概念をつかわずに書いてあったとしても、
そのシステム特有の概念(というかアーキテクチャ)を
理解しなければ保守できないんじゃないの？

で、デザインパターンなんかは、そういったアーキテクチャを
体系づけて再利用しようとするものでしょ？
142 ：デフォルトの名無しさん：01/09/25 05:06
>>140 エロだった
143 ：デフォルトの名無しさん：01/09/25 05:08
>クラスライブラリを作るつもりでアプリ作るのがＯＯＰなのか？

俺の認識なんだけど、違うと思う。一過性のアプリならＯＯじゃなくても
なんでもいい（らしい）。ただいろいろ作ってきて、構造が見えてきて
かつ、使いまわす時点になったら、ＯＯで構造を抽出して再利用を考えて
組むと後の生産性が上がる。
構造を見誤ればぐちゃぐちゃになる。ＯＯは難しいよ。
でも使わないわけにはいかない。
144 ：デフォルトの名無しさん：01/09/25 05:08
>>141
でもデザインパターンまでにたどり着くには、
C(もしくはJavaなど)やそのアーキテクチャは
必須でしょ。
その後、さらにC++やOOの知識などが必要になる
から、やっぱり保守要員は確保しづらくなる。
145 ：デフォルトの名無しさん：01/09/25 05:14
＞C(もしくはJavaなど)やそのアーキテクチャは
じゃなくって、作ったり保守する対象のシステムね
146 ：デフォ：01/09/25 05:15
オブジェクト指向は状態を管理する方法の1つの答え
状態の管理…俗っぽく言うと、変数の値の変化の管理
状態の変化をすべて監視･制御できるなら、すべてグローバル変数でよろしい
しかし、大規模になれば、または多人数で作るなら
さすがにその取り扱いは厳しくなってくる
そこで生まれたのが、OOの考え方
しかし、不完全である

…こういう意見が、一般的なのはわかるけど
じゃあ、何が不完全かっていうのが分からない
おそらく、理想系が想像できないから、比べられないためであろう
答えを教えてちょうだい＞OOな方々
147 ：デフォルトの名無しさん：01/09/25 05:25
おしまいですかね(笑
148 ：結論：01/09/25 05:25
ﾄﾞｷｭﾝな社内で使うな。
個人の趣味に使え。
149 ：デフォルトの名無しさん：01/09/25 05:27
これで双方納得
安らかに眠れるNE！
150 ：デフォルトの名無しさん：01/09/25 05:29
OOPの話ばかりだね。
OOAとOODはどうした？こちらにOOの優位性があるのではないのか？
151 ：ゆかり：01/09/25 05:33
あたしもう寝るね。
おやすみなさい☆
152 ：デフォルトの名無しさん：01/09/25 05:37
>>146
元から間違ってるぞ
153 ：103：01/09/25 05:47
>>143
激しく同意。
154 ：103：01/09/25 05:49
>>143
状態はオマケ。
データーフローが入ってない。
155 ：OO信者：01/09/25 06:02
>>146
ソフトウェアの開発にオブジェクトというメタファーを導入するのがオブジェクト指向。
オブジェクトにメッセージを送ると何らかの仕事をしてくれる、
このオブジェクト間のメッセージ通信でソフトウェアを構成するというモデル。
オブジェクトという単位を持ち出したことで、
処理の責務をソフトウェアの対象ドメインに由来させることができるわけ。
業務の概念とプログラムの概念を近づけることで、開発をしやすくしようというのが狙い。

例えば売上伝票のデータを整形するモジュールを作るとして、
伝票オブジェクトがあってプロパティを設定するのと、
denpyou_format関数にパラメータを渡すのとでは、
前者の方が分かりやすいはず。
（例がおかしいけどつっこまないで…）

クラスレベルでの再利用が難しいのは JavaBeans の何たらプロジェクトの失敗で明らか。
業務は業務によって激しくロジックが異なるので再利用を見越して作るのは至難。
今さかんなのは設計レベルでの概念の再利用/共有化。
つまりアーキテクチャパターンやデザインパターンなどのパターン技術というわけ。
156 ：デフォルトの名無しさん：01/09/25 06:32
>>8
オブジェクト指向は、再利用しやすい、設計がいい、仕様変更に耐えるものではないのです。
再利用しやすい、設計がいい、仕様変更に耐えるもに、「あなたが努力する」道を提供する技術なのです。
157 ：デフォルトの名無しさん：01/09/25 06:39
>>156
まだ言ってるよ。
158 ：デフォルトの名無しさん：01/09/25 08:48
こっちの話の方向が面白いと思うのだが？

-----------------------------------------------------
39 名前：デフォルトの名無しさん 投稿日：01/09/24 11:33
設計がタコだとどうしようもないというか
オブジェクト指向的アプローチからは手の出しようが無くなる
よね。

どんな設計がタコでもちゃんと動いてる部品があれば、そいつ
に手を加えず継承して後から再利用出来るようなOO言語というか
手法って確立出来ないかな
　windowsでいうサブクラス（メッセージフック）みたいにさ

-----------------------------------------------------
たしかに、親クラスに手を加えだしたらオブジェクト指向的とは言えないような感じがするよね
でもMFCやVCLだってクラスライブラリがバージョンアップしてるし
159 ：デフォルトの名無しさん：01/09/25 15:16
>>154
データはオブジェクトの属性でしかないと思うのだがどうよ。
データの流れを軽視しているという意味じゃなくて、
データが重要だからこそ、オブジェクトに責任を持って管理してもらうのだよ。
だからオブジェクトの振る舞いが主役になる。
160 ：デフォルトの名無しさん：01/09/25 15:34
例えば図書館があったとして、書籍の貸し出し記録というデータがあるとする。

来館者が自ら記録するようにし、記入漏れがないように来館者を教育するのが構造化。
誰がどういうときに記録するのか、データフローなどで管理する。
来館者は楽だけど、時々貸し出し記録が狂って本が無くなるので、
常により厳密な管理が求められる。

貸し出し窓口を設けて、窓口に問い合わせて書籍を借りるのがオブジェクト指向。
書籍の貸し出し記録へのアクセスは窓口の担当者のみがアクセスできる。
貸し出し記録は万全だけど、来館者は書籍へのアクセスを面倒だと感じる。
161 ：　：01/09/25 22:59
オブジェクト単体ではオブジェクト指向できないと思われ。
せめて二個ないと・・。
162 ：デフォルトの名無しさん：01/09/26 00:04
>>155
>>160
どちらの例もOOを有利に見せかけるためにでっち上げられたような気がする。
あと手続き（関数の中身というかアルゴリズム）をどうでもいいことのように
扱ってるOO本が多いような気がする。分析の際に言語考えるななんて無理。
163 ：デフォルトの名無しさん：01/09/26 00:13
オブジェクト指向の利点ってのは、図書館で言うなら
利用者が図書館のどこに目的の本があるか知らなくても
館員に持ってこさせれば済む、ってことじゃないのか。
164 ：OO信者：01/09/26 00:42
>>162
OOを使うと有利な場合には大いに使いましょうというだけ。
メソッドの中身をどう実装するかはそれほど重要でないのは確かだね。
設計したインターフェイス道理になっているかが重要。
リファクタリング本を読むと目から鱗かも。
165 ：デフォルトの名無しさん：01/09/26 00:45
叩かれそうなこと発言するが良い？
って、悪いって言われても言うけど（ぉ

過去の自分を振り返ってみて、VisualBasicって
かなり隠蔽がうまくいってるケースだと思うな。

自分でクラス（？）を変更できないのがイタイけど。
っていうか、もう使ってねーし＞VB
166 ：java厨房：01/09/26 01:13
非ＯＯ派の皆様へ。
言語は何を主に使用されていますか。
小生、java厨房なので、ＯＯしないと非効率的なのですが。
167 ：VBエキスパート：01/09/26 01:21
VBですがなにか？
OOなんて下水道みたいなもので、必要ではあるけど
普通の人はわざわざ関わらないものなのです。
汚水の処理は汚水に適した人間がやればよいのです。
168 ：デフォルトの名無しさん：01/09/26 01:23
>>167
warata
169 ：デフォルトの名無しさん：01/09/26 01:27
VB＝汚水
OO＝オアシス
170 ：デフォルトの名無しさん：01/09/26 01:30

プログラムかけないやつがOO分析ってありなの？
171 ：デフォルトの名無しさん：01/09/26 01:33
オブジェクト指向の考え方はありだと思うけど、
ただの構造体に関数が引っ付いたようなものの癖に
メソッドとかメッセージやり取りとかインターフェイスとか
偉そうなカタカナを使うのがむかつくのは俺だけか。
172 ：デフォルトの名無しさん：01/09/26 01:35
>>170
そういうことしてる奴を見かけたら
可及的すみやかに殺して刻んで海に捨てましょう。
173 ：非OO (!= 反OO)：01/09/26 01:36
>>171
お前だけだろ。
174 ：デフォルトの名無しさん：01/09/26 01:39
しかし分析段階では実装は気にしないんでしょ？
だったらプログラム書けなくてもいいのでは？
175 ：デフォルトの名無しさん：01/09/26 01:41
そもそもプログラムかけないやつが、分析できるだけの知識を持ってる
わけ無いだろ。プログラムできないやつが分析しようと思うことなんて
ないだろ。
原理的には可能かもしれないが、分析が上手く行ったかどうか自分で
体験できないから著しく不利。
176 ：デフォルトの名無しさん：01/09/26 01:43
OOPは既に「構造化よりは後、汎用プログラミングよりは前」つー意識なんだが…。
プロパティとメソッドで全て、の時代は終わってるんじゃないか？
もちろんOOの概念は汎用プログラミングのベースとして重要なんだけどさ。
177 ：java：01/09/26 01:49
>>176
汎用プログラミングって何ですか?
教えてください。
178 ：defaultの名無しさん：01/09/26 01:57
>>174
理論的にはその通り。しかし現実的ではない。
179 ：デフォ@146：01/09/26 02:31
なんとなく、テキト～に思いを巡らせてみたんだけど
以下の考え方に間違いがあったら指摘してちょうだい＞OOに詳しい人

オブジェクト
　任意の責任のもとにまとめられた状態と振る舞いの集まり
　振る舞いは状態の変化とともに行動が変わる
　オブジェクト間に許された行為は、ただ通信のみ

クラス
　オブジェクトの記述方法の1つで、オブジェクトの静的側面を示す
　クラスを用いなくても、オブジェクトの構築方法はある
　主に、振る舞いの制御に威力を発揮

で、オブジェクトの「責任」「状態」「振る舞い」の
3つのどれを中心に考えるかで、分析･設計方法が変わる

と思ってみたけど、あんま自身ないな…
しかし、「ただ通信のみ」ってところで、自分で書いててなんだが
カイジの8巻を思い出したｗ
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でごりごり書くのと速度もメモリ消費も同じにできるのもポイント。

まだ自分でもこなれてない手法なんで、いろいろ甘いのは勘弁。
181 ：180：01/09/26 02:40
C++だとコード部分のメモリ消費が大きくなりがち、ってのはあるな…。
182 ：デフォルトの名無しさん：01/09/26 02:48
マ板とは展開が違ってて面白い。

http://mentai.2ch.net/test/read.cgi?bbs=prog&key=995110531
183 ：デフォルトの名無しさん：01/09/26 02:50
>>180
アホ？
184 ：デフォルトの名無しさん：01/09/26 03:00
あ～、汎用プログラミングってジェネリック・プログラミングのことか。
「共通プログラミング」なんて訳してる本もありますよね。

ちなみに、構造化～、オブジェクト指向～、ジェネリック～は
どれが上、どれが下というもんでもないし、
それぞれ相反するものではないと思いますよ。
185 ：defaultの名無しさん：01/09/26 03:14
プログラムＡは、オブジェクトａｂｃｄｅから出来ています。

新たにプログラムＢを開発するときは、ａｅを流用し、
ｂを継承してｂ’を作り、ａｂ’ｅｆｇとなり、
新規開発はｆｇだけで済みました。

更にプログラムＣを開発するときは、ａｃ’ｆとなり、
プログラムを良く知らない新入社員でも、
開発できてしまいました。

プログラム資産を蓄積すれば、大抵のアプリケーションは、
既存のオブジェクトの組み合わせと、
継承によるカスタマイズだけで、出来てしまいます。
すばらしい！
186 ：デフォルトの名無しさん：01/09/26 03:16
>>180
LISPにとっては何をいまさらという感じだが。
187 ：デフォルトの名無しさん：01/09/26 03:18
>>185
モジュール化、実装隠蔽、差分実装、の３つの組み合わせでできることだよね。
これは必ずしもＯＯに特有の話じゃない。
・・・などと書いてみるテスト。
188 ：defaultの名無しさん：01/09/26 03:25
汎用プログラミングとは、メインフレームのプログラミング、
つまり、ＣＯＢＯＬやＰＬ／Ｉのプログラミングのことです。（嘘）

汎用プログラミングがジェネリックプログラミングなら、
Ｃ＋＋でいえばテンプレートですね。
189 ：デフォ@146：01/09/26 03:48
>>180この手の状態により振る舞いの変化しないものを書くには
Lispのような関数型言語（実際には、Lispはそうでもない）の方が強力だと思われる
>>146で述べた状態の管理の代表的なもう1つの解が関数型言語
自身では状態を持たないので振る舞いの変化もない
じゃあ、状態の変化をどう管理するかというと
ある「もの」の状態の変化の変遷を
例えば、すべてリスト状に書き下すことによって、管理したりする
　100から25,20,30の引き算とかは、100 - (25, 20, 30) => 25
しかし、こういう管理方法も不完全である
なぜかは、やっぱり、よく分からないので答えてください＞関数型言語の方々

オブジェクト指向、関数型、どちらも興味はあるのだが、
どちらも相容れないパラダイムなのかな…
190 ：デフォルトの名無しさん：01/09/26 03:52
C++のテンプレートは意味的にかなりイイセン行ってると思う
んだけど、言語全体から見たら、なんだかなあ・・って感じ。
191 ：デフォ@146：01/09/26 04:03
>>190あんまり、C++のテンプレートはよく知らないんだけど
あれって、明示的な型宣言のないRubyやLispやSmalltalkでは
明白で簡潔に書けるのに、C++では明示的な型宣言が存在するために
あえてああいう書き方でしか表せないパラダイムの1つ
…のような気がするんだけど
「どんな型でもいいよ～」っていう以外に効用ってあるの?

あと、>>189は、激しくスレ違いの予感…
192 ：defaultの名無しさん：01/09/26 04:07
ＯＯＰの目指す汎用的なプログラミングっていうのは、
>>185 みたいな感じだと思う。

>>188 は、ジェネリックプログラミングの説明です。
193 ：デフォルトの名無しさん：01/09/26 08:43
Modula-2とまでいかなくても　Delphiの前の(TP)＝オブジェクトパスカルの
モジュールレベルの方が今のOO言語の窮屈なクラスレベルより設計も実装も
再利用も楽だった気がするのは年寄りだからかな
194 ：デフォルトの名無しさん：01/09/26 10:00
>>171
そもそもメソッド、メッセージ、インターフェイスという単語は、
英語的には普通の単語過ぎてダサい感覚です。
シニカルに見えて鼻につくと思うのは日本人だけ。
（だから日本で流行らないんだろうなぁ）

メソッド→手順
メッセージ→伝言
インターフェイス→境界
オブジェクト→物体
クラス→種別
インスタンス→実体

なんてどうでしょうか。
195 ：デフォルトの名無しさん：01/09/26 10:22
>>192
>>185みたいなのは「差分プログラミング」っていうんじゃないの。
「ソフトウェアIC」なんていう私語もあったね。:-P
196 ：デフォルトの名無しさん：01/09/26 10:27
じゃ
　３目並べゲームをオブジェクト指向で表現してみてよ
　簡単すぎるならテトリスでもいいよ
197 ：デフォルトの名無しさん：01/09/26 10:34
>196
自分でやれ。
手番からなにからすべてクラスで定義した厳密バージョンと、
コード・設計が最もシンプルになるような最適バージョンの両方作ってみな。
もちろんプレイヤーは人間・CPU・ネットワーク越しすべてを透過的に扱えるように設計しろよ。

その程度なら厨房でも何とかこなせるし、良い勉強になるよ。
198 ：デフォルトの名無しさん：01/09/26 10:39
>>195
差分プログラミングなんて用語は始めて聞いたぞ。
ソースをコピペして一部を改造するという腐ったやり方のことか？
199 ：198：01/09/26 10:53
>>198
継承ベースのプログラミングのことだよ。
最近継承は人気ないけどね。
200 ：199：01/09/26 10:55
あ、間違えた。
199=195
201 ：196：01/09/26 10:58
いや俺は配列使ってメインでゴリゴリ書く方法しか思いつかんもんで・・・
202 ：デフォルトの名無しさん：01/09/26 11:23
身近なオブジェクト指向は会社組織そのものだったりする。
203 ：196ではないが：01/09/26 11:24
>>197
JDKのサンプルアプレット(TicTacToe.java)で300行ちょっとだね。
憂鬱本の魔方陣に納得できない漏れにはいい課題かも。ありがとう。
204 ：デフォルトの名無しさん：01/09/26 11:30
オブジェクト指向は複雑な物をシンプルにするのが得意。
すでにシンプルな物をよりシンプルにするのは苦手というか、効果が薄い。
そういうところはアルゴリズムにまかせたほうがいい。
有用な技術だけど、すべてにおいて効果を発揮する万能薬じゃないのだよ。

会社組織にたとえれば、２～３人の小さな組織で備品購買担当を決める意味があるのか。
こんな小さな組織で下手に担当を決めるとかえって窮屈になる。
だから３目並べやテトリスくらいでは、デメリットばかりが目立っていい例はあげられない。
しかし大きな組織になったら担当が必要になる。
１００人の社員が好き勝手に備品を買ってきたらえらいことになるし、
管理するのは大変だから担当を決めて、決済や稟議というメッセージを仲介し、
購入という操作や、予算という属性を隠蔽する必要が出てくる。
組織を知ればオブジェクト指向は見えてくる。
205 ：196：01/09/26 11:31
判りました。　ようはジム屋さんのツールって事ですね？
206 ：196：01/09/26 11:45
ああ、これで終ったら単なる煽りですね

　普段、MFC/VCLを【使う】事はやってましたが、
　いまひとつオブジェクト指向ってのが理解出来ないというか
　クラスライブラリっってGUI用で（TCのテキスト窓用のも類似として）
これはオブジェクト指向そのものとはちょっと違うんじゃないかと思ってました。
　COMを作るのにオブジェクト指向なんて概念は必要なくてインターフェースさえ
　決めればいいので、インターフェースを決めるのにオブジェクトやクラス（つまり
現実世界の物を抽象化）なんて考えてませんでしたから

つまりはオブジェクト指向のいうオブジェクトは業務系の用語だという事なら
理解出来ます
207 ：デフォルトの名無しさん：01/09/26 11:51
>>204
いいかげんその手の半端で不正確で
読み手をあらぬ方向へ誘導する説明を得意げにするのはやめろ。
何の役にもたたん。
208 ：デフォルトの名無しさん：01/09/26 12:05
>>175
>そもそもプログラムかけないやつが、分析できるだけの知識を持ってる
わけ無いだろ。プログラムできないやつが分析しようと思うことなんて
ないだろ。

ファウラーによると、「最高の分析者はそのドメインのスペシャリスト」だ
そうですけどね。でも確かに現実の顧客にモデリングを教えてやってもらう、
ってのは想像できません。

その前に自分がモデリングできなきゃいけない…あ、ファウラーみたいな
コンサルタントがついてるからできるのか。

>原理的には可能かもしれないが、分析が上手く行ったかどうか自分で
体験できないから著しく不利。

モデリングできたら、そのモデルを「実装」してみればいいのでは？
分析モデルでも動くモノはできるよね。
209 ：デフォルトの名無しさん：01/09/26 12:33
>>206
業務系や事務系の用語となぜ決めつけたのか知らないけど、
オブジェクト指向はゲーム開発だろうがなんだろうが使えるよ。
なんか堅苦しく考えすぎているような……。

TRadioButtonはラジオボタンを担当している。
ラジオボタンがラジオボタンである責任をTRadioButtonが負っている。
もしラジオボタンの表示が崩れたり、表示とチェックの状態が異なっていたりしたら、
それはTRadioButtonに問題があるからであり、TRadioButtonの責任だけを問えばいい。
当たり前のことだよね……。

フォームに６個のラジオボタンと、６個のチェックボックスがあるとする。
非オブジェクト指向なら、フォームを再描画するとき、
コンポーネントのテーブルを調べて、各ボックスの状態を調べて、
コンポーネントの種類に応じた描画関数を呼び出していくだろうか？

オブジェクト指向の場合、そのコンポーネントの正体は知らないまま、
フォームに張り付いているコンポーネントに対して再描画のメッセージを
送っていくだけで事足りる。コンポーネントの種類が増えても、
フォームの処理を返る必要はない。
これは各コンポーネントが、それぞれの役割りに責任を持っていることが保証されて
はじめて成り立つんだよ。
210 ：defaultの名無しさん@職場：01/09/26 12:57
誤解無きようにいっておきますが、
185 のすばらしいは、本当にそんなことが出来たら
すばらしいって意味ですよ。
211 ：　：01/09/26 13:54
オブジェクト指向はＧＵＩパーツでは成功しやすいよね。

ところで、ゲーム業界ではパックマンのころから、表示物体の事を
「オブジェクト」って呼んでたの知ってる？
212 ：デフォルトの名無しさん：01/09/26 14:08
>>207
オブジェクト指向アレルギーの典型的症状が現れています。
理解できないから理解しようとしない、
理解しようとしないから理解できないという悪循環に陥っていませんか。
213 ：潜伏中：01/09/26 15:07
>>211
> ところで、ゲーム業界ではパックマンのころから、表示物体の事を 「オブジェクト」って呼んでたの知ってる？
だって物体（実体）を表わすための汎用名詞じゃん :-)
コンピュータ言語で言うところの "object" とは別の意味だ。
214 ：潜伏中：01/09/26 15:10
>>211
> オブジェクト指向はＧＵＩパーツでは成功しやすいよね

それは単にユーザインターフェイスを構築する際はユーザの
取りうるアクションそれぞれに対して振る舞い(reaction)を
定義しなければならないから複雑化しやすく、複雑化した
モデルに対してはオブジェクト指向がよりよい手法であるから
ユーザインターフェイスに対してオブジェクト指向は成功しや
すい、ということでしょ。
215 ：196 ：01/09/26 15:16
>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のコンポーネントに部長や課長や西地区担当という名前を付けることを求めたりはしない。

データ＋メソッド構造をオブジェクトと呼んでもいいけど、それには但し書きが必要。
そのメソッドにはオブジェクトの一部としてデータを維持管理する責任があり、
その責任が負えないようならオブジェクトの構成要素とは呼べない。

ちなみに俺は組み込み系とゲーム系しか知らないから、
業務系、事務系、勘定系のことは知らん。
218 ：デフォルトの名無しさん：01/09/26 15:52
>>215
本当に理解したいなら、2ch で書いててもどうせ適切な説明は返ってこない（ここは
匿名で短いコメントを次々とつけていく形式だから、包括的な説明するには向かんメ
ディアだ）から「憂鬱なプログラマのための…」でも買ってきて読むことを勧めるが。

たんに煽りたいだけなら、止めないけど。

> 業務系や事務系の【金を取る為の】　用語なんだと理解すれば　色んな疑問が全部納得出来るんだ。
ＯＯはすでに「現場で」使われている技術だよ。看板だけ会って中身がない単なる用
語とは違う。

あとＯＯの真髄は、プログラミング言語よりもむしろ分析／設計段階にある。ＯＯで分
析／設計した結果を素直にコーディングするために必要な機能を取り入れた言語を
ＯＯＰＬ（オブジェクト指向プログラミング言語）と呼ぶわけだが、その言語の機能を
見てＯＯの全体像を知ろうとするのは、木を見て森を想像するのと同じぐらい難しい。

というわけで、まずはＯＯの分析／設計について調べるのがいいと思うぞ。
219 ：デフォルトの名無しさん：01/09/26 22:18
自分でクラス設計しようと思うとどこで切り分けるのが良いか
悩みますねぇ～。
実装方法も継承主体でいくのかオブジェクトコンポジションを
使ったほーがいいのかとか。
ＯＯの分析／設計の勉強をきちんとやったほうがいいんでしょうね。
220 ：サブジェクト志向言語：01/09/26 22:39
/******************/
/*表題を書けやｺﾞﾗｧ*/
/******************/
void hoge(void){
　　printf("表題が必要です");
}　　
221 ：　：01/09/26 23:00
読み返して見たけど、オブジェクト指向の失敗は
「オブジェクト指向を理解しているのは俺だけ」
「本当は難しくて抽象的でお前らなんかに理解できないんだよ」
みたいな厨房を大量に生んでしまった事のようだな。
222 ：デフォルトの名無しさん：01/09/26 23:07
自分はそれなりにオブジェクト指向を意識して、まあそこそこまとまったプログラミングが
できてるんじゃないかと思うけど、パーサ系(状態遷移とかのある)がどーもうまく
設計できなくて、変数いっぱい・関数長い・インデント深いと三拍子揃ったソースを
書いちゃってて今鬱…
誰かやり方知ってたらヒントでも教えてください。。
223 ：Delギコ：01/09/26 23:08
　∧ ∧ 　 　 ／￣￣￣￣￣￣￣￣￣
　( ﾟ∀ﾟ)　　＜　　>>221　藁夕
　 | つ[|lllll］).＼＿＿＿＿＿＿＿＿＿
～| 　 |
　 ∪∪
　ｵﾌﾞｼﾞｪｸﾄ志向のメインは単に構造体がメソッドをもてることだと思フ
224 ：　：01/09/26 23:18
>>222
とにかく、出来あがったら別ファイルにするなり（カプセル化）
して目に触れないようにすれば（隠蔽）ＯＫダ。
225 ：デフォルトの名無しさん：01/09/26 23:24
>>222
そんな極度に抽象的な処理をオブジェクト指向にする必要も無いと思うが。
226 ：222：01/09/26 23:42
>>224
んー。それはやってます。
ただカプセル化した中とはいえ、ネストの深いifとかはなんとかしたくて。
うーむ。

>>225
確かに、具体的にイメージできるもの(オブジェクト)があったほうが設計しやすいですよね。
227 ：デフォルトの名無しさん：01/09/27 00:01
今度は３勝０敗から４連敗するなよ。
228 ：デフォルトの名無しさん：01/09/27 00:31
まさか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 で回す。
それかテーブル駆動。
汚いと言われようが何しようが、
カプセル化してしまえば内部は好きかって。
231 ：デフォルトの名無しさん：01/09/27 00:53
非OO派の発言が、>>167 以降勢いがなくなったのが笑えた。
VBでもOOできるよーん。
232 ：デフォルトの名無しさん：01/09/27 00:59
>>231
VBの継承ができないという仕様はある意味潔い。
233 ：230：01/09/27 01:00
そうそう、おいらは全体的にはオブジェクティブ
細部は好き勝ってという手法が好きです。
あんまりオブジェクティブを徹底しすぎてもちょっとアレ。
234 ：　：01/09/27 01:14
>>233
同感。
Stringをオブジェクトにした奴は死んで欲しい。
235 ：　：01/09/27 01:16
やっぱしループ変数iとかもクラス作って使わないとね。
信者にふさわしい死に方をきぼんぬ。
236 ：デフォルトの名無しさん：01/09/27 01:17
>>234
ネタですか？
237 ：デフォルトの名無しさん：01/09/27 01:19
VBって継承できないのか。。。
238 ：230,233：01/09/27 01:19
>>234
ごめん、string を始めとする STL は大好き。(^^;
MFC の CString はやりすぎ。
239 ：デフォルトの名無しさん：01/09/27 01:20
VB,C++厨房はここから出て行け
240 ：　：01/09/27 01:22
それからStringはCharクラスを継承してないんで、原理原則に
従ってちゃんと継承して作りなおして、信者にふさわしい死を・・・。
241 ：230,233：01/09/27 01:22
オレのことかい？
242 ：デフォルトの名無しさん：01/09/27 01:24
>>235
1 to: 100 do: [: i | Transcript show: i ; cr.]
243 ：　：01/09/27 01:25
>>242
何語ですか？
244 ：デフォルトの名無しさん：01/09/27 01:27
>>243
Smalltalk だよ～。
1 というオブジェクトに to: do: というメッセージを送ってる。
こいつを受け取ると、1 は 100 まで数え上げて、
do: に与えられたクロージャをその都度呼び出す。
で、その際の現在の値が i に与えられる。
245 ：デフォルトの名無しさん：01/09/27 01:51
Smalltalk 知らない人には Transcript が最も謎だと思われ。(w
246 ：デフォルトの名無しさん：01/09/27 01:56
>>222
Design Pattern の Interpreter と State の組み合わせで
いけないかな。とはいえ、もう試しているけどうまくいかないから
書いているんだろうから、余計なお世話だな。
247 ：defaultの名無しさん：01/09/27 02:34
メンテナンスや再利用を意識した、機能単位のプログラム分割は、
（つまりはカプセル化）ＯＯＰ以前からやってること。
つまり、ＯＯレベルでは構造化に対してアドバンテージが低い。
ＯＯＰの構造化に対するアドバンテージは、継承にある。

ＯＯＰの継承で設計すると、抽象化による共通部分の
ベースクラスへの切り出しが必要だが、これが問題だ。
システム化というのは、現実の世界の処理を具体化し、
機能別に再構築する物だと思う。
にもかかわらず、派生によるメンテナンス性向上のために、
無理に抽象化することに意味があるのか？
（それ以前に、派生でメンテナンス性が向上するとは思えないが。）

また、今までカプセル化は、設計上の必要性で行ってきたのだが、
ＯＯＰだからと何でも細かくオブジェクト化し、
インターフェイスやメソッドを増加させるのはどうかと思う。
248 ：デフォルトの名無しさん：01/09/27 02:52
>>247
機能単位のプログラム分割とカプセル化は全然別物だと思うよ。
249 ：defaultの名無しさん：01/09/27 03:09
>>248
違う場合もありますが、全然別物ではありません。

共通サブルーチンや共通モジュールを、想像してください。
印刷サブルーチンは、各種パラメータにより、
内部の印刷モジュール（メソッド）を実行します。
コール元からすれば、直接メソッドを呼ぶのか、
パラメータを指定するのかの違いだけです。
250 ：デフォルトの名無しさん：01/09/27 03:16
>>249
同じ場合もありますが、別物なのが普通です。

例えば、クラスとインスタンスを例にあげて言えば、
インスタンスは複数あるのが普通だし、持ち運びもできる。
非ＯＯなモジュールの場合にはそういうことは考えない。
「もの」として持ち運んだり複製したりできることが重要。
251 ：デフォルトの名無しさん：01/09/27 03:22
http://www.ruby-lang.org/ja/compar.html
252 ：defaultの名無しさん：01/09/27 03:22
>>250
ＯＯレベルではの話です。
ＯＯＰレベルだと、その利点はありますね。
253 ：デフォルトの名無しさん：01/09/27 03:35
>>252
ＯＯ、ＯＯＰ、ＯＯＡ、ＯＯＤ、の使い分けがよく分かりませんです。
どういう基準で使い分けてますか？
254 ：defaultの名無しさん：01/09/27 03:50
>>253

ＯＯレベル、設計レベル（ＯＯＡ＋ＯＯＤ）。
ＯＯＰレベル、実装レベル。

設計レベルでは、データフローに対する
処理単位（クラス）で考え、同じデータフローを
個別データ単位（インスタンス）では考えない。
255 ：デフォルトの名無しさん：01/09/27 03:56
>>252
ＯＯ＝オブジェクト指向パラダイム
ＯＯＰ＝オブジェクト指向プログラム
ＯＯＡ＝オブジェクト指向分析
ＯＯＤ＝オブジェクト指向設計
で、カプセル化はＯＯとして（問題をオブジェクトとして見るために）
必要不可欠なキーワードで
構造化なんちゃらのモジュールとは一線を画していると思われますが。
256 ：デフォルトの名無しさん：01/09/27 03:59
249、252じゃないけど。

>>247
オブジェクト（役割単位での分割）とモジュール（機能単位での分割）は区別して考えないと。
モジュールは管理している属性が不明瞭だし、操作する対象も不明瞭のままです。
そこを明らかにすることに価値を見出すのがオブジェクト指向かと。

継承がＯＯの最大のメリットだというのはそのとおりだけど、
ＯＯ初心者にこれを説明しようとするから難しくなるのではないかと思います。
ポリモーフィズムとか、ある程度のデザパタが理解できるようにならないと
継承の本当の美味しさというのは掴めないし。
（>>223みたいなことを言っている奴もいるし）

だからまず、オブジェクト否定派には、オブジェクトとは何なのかという
至極当然のところから噛み砕いて説明したほうがいいと思いますよ。
257 ：デフォルトの名無しさん：01/09/27 04:01
>>254
それはすでにＯＯではなくフローモデルあたりだと思う。
258 ：デフォルトの名無しさん：01/09/27 04:04
>>247
> ＯＯＰの構造化に対するアドバンテージは、継承にある。
設計／実装段階の要は、むしろ「インスタンス間の相互作用」だと思うが。
継承も相互作用の一形態ではあるけど、むしろ特殊な例。
259 ：デフォルトの名無しさん：01/09/27 04:08
>>254
あまり一般的な分類だとは思えないなぁ。255 さんとかぶるけど、

ＯＯ＝オブジェクト指向：思想。ポリシー。対象を特に選ばない。
ＯＯＡ＝オブジェクト指向分析：ＯＯに基づいた問題領域の分析工程。
ＯＯＤ＝オブジェクト指向設計：ＯＯに基づいた(ソフトウェアの)設計工程。
ＯＯＰ＝オブジェクト指向プログラミング：ＯＯに基づいた実装工程。

クラスとかインスタンスという概念はＯＯでよく見られる一つのパターンであって
ＯＯＡやＯＯＤだからクラスでＯＯＰだったらインスタンスというのは変だよ。
プロトタイプベースの言語だったらクラスないし。
クラス間ならぬインスタンス間の関係を設計段階では扱わないかと言えばんなことないし。
260 ：defaultの名無しさん：01/09/27 04:16
すいません、ＯＯについて勝手な使い方をし、
混乱を招いてしまいました。

ＯＯのモジュール分割と、構造化の機能分割を
同じだとは言いいません。
ＯＯＡやＯＯＤでもたらされる恩恵は、既存の構造化で、
ある程度満たされていると言いたかったのです。

デザインパターンについても、企業内レベルでは
以前から標準化する努力がされています。

ではＯＯのアドバンテージは？
今まで存在しなかった、継承やポリモーフィズムに、
真のアドバンテージはあるでしょうか？

>>257
ＯＯＤ
261 ：デフォルトの名無しさん：01/09/27 04:19
>>260
何でもいいが、もう少しＯＯについて勉強してから意見を開陳した方が良い
と思われ。単語レベルで解釈が食い違っているようだと、さすがに議論にな
らないですよ。
262 ：defaultの名無しさん：01/09/27 04:23
>>261

ごもっともです。
263 ：デフォルトの名無しさん：01/09/27 04:26
>>260
まず、銀の弾丸的なものを期待する対象じゃないと思う。＜ＯＯ
んで、既存の手法に対する全く新規なアドバンテージもないと思う。
なら、何がいいのかというとトータルでは扱いやすいってこと。
むしろ既存の手法にあった色々な考え方を
カプセル化や継承なんていう基本語彙で表現しやすくしたのがでかい。
そもそもSimulaやSmalltalk-72にさかのぼればＯＯは古典の部類。
既存の手法とオーバーラップしてるのは自然なことじゃない？
大体プログラムなんて最後は全部機械語に落ちるわけで
どんな手法も目標機械語列へのリーチを短くする話でしかない。
その意味では十分なアドバンテージがあると思うよ。
264 ：defaultの名無しさん：01/09/27 04:31
>>263

私もそう思います。それがわかって必要な部分だけ
使用すればいいのですが、過度に使用しようとすると、
問題があると感じます。
265 ：defaultの名無しさん：01/09/27 04:37
クラスライブラリのような汎用的でないプログラムを、
実際に設計・開発した人で、継承やポリモーフィズムの
アドバンテージを、実感した人はいますか？
266 ：デフォルトの名無しさん：01/09/27 04:44
>>265
「クラスライブラリのようには汎用的でない」の間違いだよね？

重箱隅な突っ込みは置いといて、状況設定が不適切だと思う。
継承や多態が有効に機能するように、
限定的な範囲内であっても汎用性を意識して設計することが
ＯＯＰの有効性の重要なポイントになっているはず。
極端な話、「汎用性をもたせてはならない」という条件をつけたら
どの辺りでＯＯＰが役に立つのか想像がつかない。
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

私の場合、クラスライブラリのドキュメントクラスから
個別のフォーマットのクラスを派生させて、
そこ個別のクラスから、更に派生する構造はとりません。
共通部分は別クラスにし、クラスのメンバにします。
理由は、この方がわかりやすく、扱いやすいと感じるからです。
270 ：デフォルトの名無しさん：01/09/27 05:08
>>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

インターフェイスの共通化はクラスライブラリレベルで、
クラスメンバにしているのは実装部分です。
274 ：デフォルトの名無しさん：01/09/27 06:08
>>273
クラスライブラリで提供しているインターフェース以外は、自作のクラスの外に出さない、
ということですか？　なんか勘違いしてるような気がしますが（私が）
275 ：defaultの名無しさん：01/09/27 06:27
>>274

故意に共通のメソッドを作らなかったわけではなく、
（過去において）ほとんど必要性がなかったのです。
追加するメソッドに、クラスライブラリ以外のメソッドで、
汎用性な部分がなかった。

共通する処理部分や、共通するデータ部分はありましたが、
これらは別クラスにしました。
継承させた方がＯＯＰらしいのですが、
（少なくとも私は）必要性を感じませんでした。

まれには、共通するメソッドがあって、
継承を使用したこともありますが。
276 ：デフォルトの名無しさん：01/09/27 07:02
>>275
……。

黙ってこれを読め。
http://www2s.biglobe.ne.jp/~gkimoto/j/oop/part2/ch14_polymorphism.html

君はだいぶ勘違いしているようだから、さらっと流し読みしてはいけない。
間違った固定観念は全て捨てて、よく熟読すること。
277 ：defaultの名無しさん：01/09/27 07:31
ごめん、流し読みで勘弁して。（しかもトップページのみ。）

私がいいたかったのは、何が何でもＯＯの概念にそって、
継承やポリモーフィズムを使うことが、
わかりやすくもないし、メンテナンスし安くもないということ。

人間クラスと犬クラスを、どうしても継承させたがるのは
どうかと思う。
たとえＯＯの概念から外れても、別のクラスの方がわかりやすく、
メンテナンスしやすいこともある。
278 ：デフォルトの名無しさん：01/09/27 08:17
>>277
それじゃあさ、compositeパターンの活用例を挙げて、
そのメリットとデメリットを説明してみな。
説明する課程で理解が深まると思うから。
279 ：デフォルトの名無しさん：01/09/27 10:56
>>278
OOを一生懸命勉強してきたのはわかるけどさ
本を真に受けてOO最高じゃ話が進まないよ
まともなシステム開発したことある?
280 ：デフォルトの名無しさん：01/09/27 11:14
>>279
OOがまともなシステム開発に使われていないとでも？
281 ：デフォルトの名無しさん：01/09/27 11:25
277=279?
GoFパターンにケンカを売ろうという根性だけは認めるけど、
もっと勉強した方がいいね。
282 ：デフォルトの名無しさん：01/09/27 11:55
>>279
酷い事言うなー。今まで必死でやって来た事が、現実じゃ役に立たないなんて言われたら、儂なら泣いちゃうよ。
283 ：デフォルトの名無しさん：01/09/27 12:08
私は現場でＯＯ使ってるよ。
何でも継承にしようとするＯＯ信者は困りもんだが。
適度に使えばＯＯは有効だよ！
284 ：デフォルトの名無しさん：01/09/27 12:34
インヘリタンスにシフトウエイトした開発が、
最前線で破綻してるのは周知の事実
書籍を鵜呑みにする偽知識者以外は、みんな知っている
だからといって、OOPを否定しようという勘違い者は論外
285 ：デフォルトの名無しさん：01/09/27 13:05
OOPレベルでのメリットは型と実装の分離、それとポリモーフィズム。

void foo(A& bar) {
}

関数fooに渡されるbarは型Aのオブジェクトということだけわかっていれば、
barがどのクラス(実装)のインスタンスかを知らなくてもかまわない。

GoFのパターンも、型と実装の分離を前提にしているものがほとんど。
286 ：チーズはどこへ消えた？：01/09/27 13:06
>>279
へぇ、システムやアプリの開発経験があるんだ。
満足の設計ができた？
もっとうまい方法があるかもしれないと疑問に思わなかった？
ん？　そうか、現状に満足しているんだね。
君はすばらしいよ。それならもう僕からは何も言うことがないよ。
287 ：日曜プログラマ：01/09/27 13:20

>>285

つまり継承って事では？
288 ：OO信者：01/09/27 13:27
GoF本読めばOOPの神髄は継承になく、
適切な役割を持たせたオブジェクト同士の協調作業にあると分かる。
言語の機能に思考を縛られていてはいけないと思うな。

>>277
＞人間クラスと犬クラスを、どうしても継承させたがるのはどうかと思う。
例の粗を探すのではなく、例から概念を理解してほしい。
おそらくあなたは、「コードの把握しやすさ」は理解できても
「ソフトウェア構造の把握しやすさ」という概念は理解できていないのでは？

共通部分を括り出すだけでは自分用関数ライブラリと変わらない。
デザインパターンは、ソフトウェアを開発していると良く出くわす
*設計上*の問題とその解決法に名前を付けたもの。
名前があるおかげで、
「これはfactoryパターンでやるといいんでない？」「あ、なるほど」
というやりとりができる。
まあ、みんながパターンを知ってないと共通語彙として使えないから
まだまだ浸透するには時間がかかるだろうけどねえ。
289 ：OO信者：01/09/27 13:32
>>287
継承するために継承するわけじゃないよ。
多態性を実現するために継承する。
278さんが言っているようにcompositeパターンは良い例だと思う。
290 ：デフォルトの名無しさん：01/09/27 16:33
>>289
継承と書くときには、「インターフェースの継承」なのか「実装の継承」なのか
明記したほうが良い。混乱の元だから。
291 ：285：01/09/27 17:11
>>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
>>294 そんなやつばっかじゃねえって
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 そんなチンケなこといってるやつは真のプログラマーではない
301 ：デフォルトの名無しさん：01/09/27 21:23
むむ、真のプログラマーネタが解らない奴がいるとは……。
マジレスされると嫌味効果が薄れるからやめてくれ。
302 ：デフォルトの名無しさん：01/09/27 21:23
というよりオブジェクト指向がわからずに、
技術の進歩についていかれないだけだろ？
303 ：デフォルトの名無しさん：01/09/27 21:24
いいから、真のプログラマは汎用機で FORTRAN 使ってろよ。
元ネタは、これか？

本物のプログラマ
http://www.genpaku.org/realprogrammerj.html

なんにしろスレ違いだから、このへんでやめとけ＞真のプログラマー
304 ：デフォルトの名無しさん：01/09/27 21:30
>>302
>>303
あ～あ、やっちゃったよ。
305 ：デフォルトの名無しさん：01/09/27 21:40
ネタにマジレス、カコワルイね。
306 ：デフォルトの名無しさん：01/09/27 21:54
>>277
今ごろ気づいたけれど、別クラスのほうがわかりやすいって何？
継承したって、人間と犬と猫は別クラスであることにはかわりないじゃん。
共通部分は動物クラスにまとめられるから、同じ処理が犬や猫クラスに重複しないし。
メンテナンスしやすさ、わかりやすさ、どこをとっても継承したほうが上では？
継承を使わないで何がよいのかさっぱり解らないよ。
単に継承が理解できないから使わないと言っているようにしか聞こえない。
307 ：デフォルトの名無しさん：01/09/27 22:00
ポリモーフィズムが俺としては欠かせない
308 ：デフォルトの名無しさん：01/09/27 22:02
ポリモーフィズム使わないのに、
継承っていうのも、あまり俺は好きじゃない

継承するとメンテナンスしずらい気もする
もちろん､ポリモーフィズムのためなら関係ないが
309 ：デフォルトの名無しさん：01/09/27 22:32
人間と犬を抽象動物クラスから継承しないのは間抜けだろう。
だが、抽象動物クラスには「前足」があるのかそれとも「手」があるのか？なんてことを
考え出すと、手だか足だかは別クラスにして接続したほうがよさそうだ、と判るんではないかと。
310 ：　：01/09/28 00:36
ここにいる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
唐突ですが
真のオブジェクト指向言語は何ですか？
315 ：312：01/09/28 01:29
OO の目的は変化に対応しやすくすることだと思う。
おいらは OO はそれなりに好きだけど、原理主義ではないので
そのスジの人の意見は違うのかもしれんけど。
316 ：デフォルトの名無しさん：01/09/28 01:30
>>314
Self
317 ：デフォルトの名無しさん：01/09/28 01:39
>>314
Eiffel
318 ：デフォルトの名無しさん：01/09/28 01:39
>>313
「構造の再利用」はOOの目的ではなくデザインパターンの目的である、
と>>312は主張していると思われ。

しかしながらデザインパターンでもアダプタやデコレータの用に
既存のソースコードそのものを修正することなく再利用することを
目的とするものもある。

とはいえ、ほんとにまったく修正しないで再利用するのは現実には
結構難しいのは同意。
319 ：デフォルトの名無しさん：01/09/28 01:47
>>313
OOはコードの利用方法に適切に制約を設けることで可読性/保守性を高めます。
ってこれはOOの特徴と言うと語弊があるけど、デザインパターンってのは触らせる
部分と触らない部分をきっちり分けているわけでさーよ。
OOPLであれば、触らせないことを保証する為の仕組みが備わっているものが多い、とさ。
320 ：デフォ@どうなんすか？：01/09/28 01:47
そこも、以前から疑問に思ってたんだけど…
デザインパターンは別にOOに含まれるというものではないのですか？
321 ：デフォルトの名無しさん：01/09/28 01:52
「デザインパターン」といえばGoF本の物を指すことが多いからOOと関連付けられることが多いけど、
それはあくまで「OOにおける再利用のための」という部分を省略してそう呼んでいると考えれば?
広義にはOOじゃないデザインパターンというのも考えられるでしょ。
ま、前者の意味が浸透してるから「デザインパターン」->OOという図式を崩せはしないだろうけど。
322 ：defaultの名無しさん：01/09/28 01:54
>>306

必要ない場合には、クラスライブラリからの派生で止めておけば、
わかりやすく、メンテナンスしやすいという意味です。

４階層継承したアプリケーションの場合、
ＯＯのいうように最下層のオーバーライドで
メンテナンスが用意かというと、そうではない。
実際には、最上位クラスまでさかのぼって、ソースを見るんです。
クラスライブラリからの派生のみなら、メンテナンスは比較的容易です。

クラスライブラリからの派生だけでも、クラスライブラリレベルでは、
インターフェイスは統一されていますし、ポリモーフィズムも使えます。
それでもなおアプリケーション内で継承するのは、
あくまで追加する共通のメソッドがあり、ポリモーフィズムを、
追加したメソッドで使用する必要がある場合だと思います。
（業務で扱うオブジェクトを、対象を意識せずに使うことは、
あまりありません。）

ＯＯは絶対に良いものだから、ＯＯの概念に沿わせるために、
抽象化するのでは、ＯＯのためのＯＯになってしまいます。
323 ：デフォルトの名無しさん：01/09/28 02:06
>>322
クラスライブラリから派生せず、独自の階層を持つクラスは作らない、という
主張ですか？

たとえばドロー系のツールなら、そこで扱う「形状」を表現するために

class Shape {};
class Circle : public Shape {};
class Rect : public Shape {};
...

みたいなクラス階層を考えるのが普通だと思うんですが、どうしてるんでしょう？
324 ：322じゃないけど：01/09/28 02:10
＞必要ない場合には、クラスライブラリからの派生で止めておけば、
＞わかりやすく、メンテナンスしやすいという意味です。

に対して

＞クラスライブラリから派生せず、独自の階層を持つクラスは作らない、という
＞主張ですか？

なの？
325 ：デフォルトの名無しさん：01/09/28 02:14
インターフェイスベースプログラミング
http://www.microsoft.com/JAPAN/developer/library/jptech/TechArt/VTools/vb/vb6/ifacebased.htm

なんか良いことが書いてありそうなんだけど、
めんどくさくってインターフェースの利用に踏み切れない。
実体験としてインターフェースは重要ですか?
326 ：　：01/09/28 02:24
めんどくせー。

プログラムＡ　－＞　コネクタ　－＞プログラムＢ

でいいじゃんか。
327 ：1：01/09/28 02:46
その画像ならココ
http://www.f2.dion.ne.jp/~impact14/
328 ：ななしヘタぐらま：01/09/28 03:44
>>276
すごいー，このサイト，かなりわかりやすく説明が書いてありますね．
難しい事柄をこうやって易しく説明できる人って尊敬しちゃうな．

全てのプログラマー，必読！

いいページ教えてくれてありがとう＞ >>276さん
329 ：デフォルトの名無しさん：01/09/28 08:16
>>276
確かに。>>277は、全然読まなかったみたいだが、愚かな行為だったな。
330 ：デフォルトの名無しさん：01/09/28 08:56
なんかOO原理主義者って
OOを賞賛しない人を
馬鹿扱いすることでしか
反論できないのね

優越感に浸りたいのは
わかるけど
SEとしての決定的な資質に
かけてると思う
331 ：デフォルトの名無しさん：01/09/28 09:02
>>330
煽り厨房、逝って良し。
332 ：デフォルトの名無しさん：01/09/28 09:23
>>330
事実、ＯＯを否定するのは、おまえみたいなバカ。
自分が理解できないのを、ＯＯの欠陥のようにいう。
333 ：デフォルトの名無しさん：01/09/28 09:33
>>330

激しく同意。結局、OOの唯一の欠点は、アホには理解できない事。理解できないアホに、何をいっても無駄。
334 ：デフォルトの名無しさん：01/09/28 09:34
>>330　－＞　>>332　の間違い。
335 ：デフォルトの名無しさん：01/09/28 09:51
>>330
OOを理解した上でOOを批判するのであれば素直に読むけど、
OO批判のほとんどはOOを理解してないことが明らかだからね。
否定派を馬鹿扱いしているのではなく、
理解できない物を無闇に批判する人たちを馬鹿扱いしているだけだよ。
336 ：デフォルトの名無しさん：01/09/28 10:20
>>335
ＯＯの概念を使わない人を、ＯＯを理解できない人と決めつけるのは、どうか
と思うよ。デメリットから、あえて使ってない人も多いと思うし。反対意見に
も謙虚に耳を傾ければ、得られる物もあるんじゃないかな？

よけいなお世話だったかな？
337 ：デフォルトの名無しさん：01/09/28 10:26
>>336
なんか的外れというかなんというか…
ちゃんと読めよ
338 ：デフォルトの名無しさん：01/09/28 10:26
>>336
そもそも 335 は「ＯＯの概念を使わない人を、ＯＯを理解できない人と決めつけ」て
いないと思われ。
339 ：デフォルトの名無しさん：01/09/28 10:28
>>336
ここで叩かれてるのは明らかに理解してない
人ばかりだろ。
誰も決め付けてないよ。
340 ：デフォルトの名無しさん：01/09/28 10:42


日本では信仰の自由が保障されているのだよ。


オブジェクト指向原理主義者にとって、
その思想は正義なのだ。絶対なのだ。
疑問を抱くことも許されぬ、絶対不可侵の物なのだ。


その思想に沿わない設計をする奴は、
オブジェクト指向を理解できない馬鹿以外の
何者でもない。


ましてオブジェクト指向を批判する奴など、
悪その物に他ならない。
正義の制裁を加えるべき対象なのだ。


考えてもみよ。ユダヤ教を信じている人間に、
思想の矛盾を言ってなんになる。
信じている根拠を聞いてなんになる。


彼らにとって、教えに従わない人間は、
愚かな異教徒以外の何者でもない。
341 ：デフォルトの名無しさん：01/09/28 10:46
age 荒らしは放置でお願いします＞みなさん
342 ：デフォルトの名無しさん：01/09/28 10:48
だんだん2ちゃんねるらしくなってきたねぇ
343 ：デフォルトの名無しさん：01/09/28 11:02
>>340　信仰は自由なんでしょ。だったらいいじゃんほっとけば
344 ：デフォルトの名無しさん：01/09/28 11:06
相手が信じている物を非難すれば、怒るのは
当然だ。ＯＯとか以前に、人として間違って
いる。
345 ：クズは氏ね：01/09/28 11:12
ＯＯに文句つける奴は、クズばかりだな。おまえら愚民は、構造化使ってりゃいい
んだよ。ＯＯは、俺達選ばれた民だけ使いこなせるのさ。
346 ：デフォルトの名無しさん：01/09/28 11:17
ＯＯは馬鹿以外の特権ということで






－－－－－－－終了－－－－－－－
347 ：デフォルトの名無しさん：01/09/28 11:42
>>345
OOを使っている人が少数派だと思っている？
348 ：デフォルトの名無しさん：01/09/28 11:45
ＯＯな人たち気を悪くしないでね。犬クラスと猫クラスがあったらスーパーク
ラスに動物クラスがあって当然だってことがＯＯは正しいってとこからス
タートしているとおもう。だからそれ以外の考えはＯＯを理解してないってこ
とになるとおもう。デモそれってＯＯ的な考えをしない人＝ＯＯを理解してな
い人ってことでしょ。これだとＯＯのにそってない人がみんなＯＯを理解
してない人になるとおもう。ＯＯを理解している人はＯＯな人たちだけになっ
ちゃうとおもう。これっておかしいとおもう。
349 ：Ruby糞：01/09/28 11:53

>>>>348
御前みたいな低脳がOO語るのは10年早いんだよ
Rubyでもやってろ!
350 ：クズは氏ね：01/09/28 12:01
>>347
猿程度の知能があればＯＯは理解できる。しかしクズは別。ここにはクズが多すぎ
る。
351 ：デフォルトの名無しさん：01/09/28 12:03
何をいまさら
お前もくずの一員だと言うことを認識せよ
352 ：デフォルトの名無しさん：01/09/28 12:04
>>350
非OOP派も猿程度の知能はあると思うよ。たぶん(^^;
353 ：クズは氏ね：01/09/28 12:14
>>351
オマエモナー
354 ：デフォルトの名無しさん：01/09/28 12:34

今までの流れを
１　OO否定派
２　OO肯定・継承否定派
３　OO肯定・継承肯定派

と勝手に分類してみる

オレは今の所は２だが・・・
３は２まで罵ってしまうのが痛い
オブジェクト指向原理主義過激派（３）は穏健派（２）まで敵にしてしまい、
それを見た１は２と３の両方を嫌ってしまう

OOはとりあえずはカプセル化だけでいいのでは？
カプセル化のメリットは誰にでもすぐ分かるだろうし
オレ自身はカプセル化が最大のメリットだと思っている

継承や多態性はそのメリットが分かりにくいし、考えずにやると破綻しやすい
継承しなきゃOOじゃないというのはおかしいだろう
355 ：デフォルトの名無しさん：01/09/28 12:47
継承も多態もカプセル化もＯＯの本質ではない、と思うがどうか。
それらはＯＯのある特定のパターンの実現手段に過ぎない。
356 ：デフォルトの名無しさん：01/09/28 12:54
>>354
アンチャン、わかりやすいじゃねーか。おりゃこれでいくと、基本的には３だな。
趣味で作ってるプログラムは、バリバリ３だしな。仕事の大規模システムが４・５
階層だと、さすがにきついがな。
357 ：デフォルトの名無しさん：01/09/28 13:04
>>OOはとりあえずはカプセル化だけでいいのでは？

ﾅﾝﾃﾞ言語の進化を否定すんだ？そうすると殆どのクラスライブラリはなくなるし、
クラスを派生させて振る舞いの差分をコーディングするって当たり前の事が出来なくなるＹＯ！
継承には明確なメリットがあって、通常のOO言語仕様にあるのに。
358 ：デフォルトの名無しさん：01/09/28 13:05
>>354
つか、
主人「猫は「ニャー」と鳴け、犬は「ワン」と鳴け」
猫「ニャー」
犬「ワン」
猿「…」
ってのは OO じゃないだろ。
主人「鳴け」
猫「ニャー」
犬「ワン」
猿「キィキィ」
じゃないとダメ。
メッセージに対してオブジェクトが自分で振る舞いを決めるてこそ OO だろ。

「多態無しですが、自分は OO やってます」なんて意味無いし。
359 ：デフォルトの名無しさん：01/09/28 13:12
>>358
勘違いＯＯ派発見。
360 ：デフォルトの名無しさん：01/09/28 13:14
＞＞３５７
多重継承についてどう思いますか？
361 ：354：01/09/28 13:17
>357
継承が許されるのはクラスライブラリだけ、という考えもある
クラスライブラリはユーザー共有の知識なのでどこに実装があるのか皆知ってるが、
自作のクラスで継承を多用すると実装がどこにあるのか探すのが大変だろう
デバッグする時はなおさらだ。
そりゃクラスライブラリにもバグがあるけどさ・・・
362 ：デフォルトの名無しさん：01/09/28 13:20
>>357
与えられた道具は、必要なときに必要なだけ使えばよい。
常に使わなければならない訳ではない。と言いつつも、俺は3だ。
しかし、2については気持ちは分かる。1はどうかと思うが･･･

＃番号書くと立場が明確になって、良いんではないか?
363 ：デフォルトの名無しさん：01/09/28 13:36
>>348
機能を説明するためのサンプルに、十分なメリットがないと難癖つけていたのでは、
いつまでも機能を理解することはできないよ。
１０件のクイックソートの例を見て、ヒープソートの方が速いと言っているようなものだ。
その例が現実にはどのようなことに役立つのか、そこを自分でよく考えて欲しい。
もちろん適材適所で使うべきなのは言うまでもないことだよ。

継承否定派の人たちは、ポリモーフィズムを口にはしていても理解しているようには見えない。
オブジェクト指向でポリモーフィズムしないなんてナンセンスもいいとこ。
きちんと説明する必要があると思うんだけどね。
364 ：デフォルトの名無しさん：01/09/28 13:45
　犬と猫の上位に動物があれば便利ってのが、そもそもインチキく
せーんだよな。

　実際の仕事で、こんな概念的に整理できる単純ケースなんて、殆
ど無いからな。ましてや巨大プロジェクト全体を眺めたら、概念で
派生ツリー作ろうなんてのが、無理だとわかる。結局のところ、処
理を分析して、地道に共通部分を洗い出して行くしかない。

　どうもＯＯ原理主義派？？ってのは、机上の空論っぽいんだよな。
趣味でプログラム作ってる、只のオタクじゃないのか？
365 ：Delギコ：01/09/28 13:56
＞継承否定派の人たちは、ポリモーフィズムを口にはしていても理解しているようには見えない。
＞オブジェクト指向でポリモーフィズムしないなんてナンセンスもいいとこ。

　ｵﾚﾊ 2ﾐﾀｲ
　　　∧∧　　　／￣　>>363
＠＿(,,ﾟДﾟ)　＜　全部が全部理解してなくちゃ
⊂,,＿_つつ.　　＼＿ 開発しちゃいけないって事にならない？

クラスライブラリ開発者とクラスライブラリユーザーとを使い分けて
考えたらどうかなあ。クラスライブラリユーザーはポリモを理解してなくて
使いこなしていないだろうけど
OOの恩恵を受けてるわけだからそれでいいでしょ。

＞　犬と猫の上位に動物があれば便利ってのが、そもそもインチキく
＞せーんだよな。
クラスライブラリを作成するときには考慮する事は必須だけど

現実にｿﾌﾄ作っていく際に必要あれば上位の動物をつくるけど
犬、ﾈｺ、別にしても問題ない時は別々のままにしたりするよねー。

究極的な事言い始めたら
全部のクラスを原子クラスから分子クラス、固体/液体/気体クラス
と作らなきゃっいけないなんていうのはおかしいことなんだし。
366 ：364：01/09/28 13:56
>>363

> 機能を説明するためのサンプルに、十分なメリットがないと難癖つけていたのでは、
いつまでも機能を理解することはできないよ

　そういう高飛車な態度が反発されてんだよ。いい加減、自分だけ
分かってるような態度やめろよな。

　サンプルなんてものは、全く逆の結論をさもまことしやかに見せ
ることが出来ることぐらい、おまえでも分かるだろ？
367 ：通りすがり：01/09/28 14:09

OO原理主義者ってのは言い得て妙かも

(この言葉を広めましょう)

この人達って再利用とかわかりやすさとか

ほんとはどうでも良くって

OOの考え方に則ってプログラム作るのが

1番大事なんじゃない？

つまりはOOの原理が1番大事な人達
368 ：デフォルトの名無しさん：01/09/28 14:11
>>366

あんまりOOP派の株を下げるなよな。
369 ：357：01/09/28 14:18
>継承が許されるのはクラスライブラリだけ、という考えもある
考え方はあっても良い。だが、クラスライブラリを利用する人はそのクラスの派生による
差分コーディングで作ってるんだ。

>犬と猫の上位に動物があれば便利ってのが、そもそもインチキくせーんだよな。
クラスライブラリのクラスを継承後、振る舞いを差し替えるいう例。犬、猫、動物関係無し。
370 ：357：01/09/28 14:25
>巨大プロジェクト全体を眺めたら、
>概念で派生ツリー作ろうなんてのが、無理だとわかる。

クラスライブラリには派生ツリーがあるのを知らない？
クラスライブラリを使ったことあるなら、そのメリットわかるよＮＥ？
371 ：357：01/09/28 14:28
＞＞３５７多重継承についてどう思いますか？
自分は多重継承使ってないので、使っている人に聞いて下さい。

現在主流のOOPの限界は、単一継承か多重継承かにあるんでなく、
実行時の継承が有るか無いかだと思うけどね。（主流じゃない言語にあるらしい）
372 ：デフォルトの名無しさん：01/09/28 14:37
>>363
オブジェクト指向でポリモーフィズムしないなんてナンセンスもいいとこ。

うーん。
難しいところだね。
鳴けといえば、相手が何か解らなくても鳴く。
考えると良さそうだけど、現実の業務で犬か猫か解らない物に、
鳴けというケースは滅多にないからね。
上位クラスで扱う必要性があれば、便利だと思うけど。
犬と猫のインターフェイスがあまりに違うなら、継承による依存関係がない方が良いときもあるし。
時と場合によるね。

ポリモーフィズムを使わなくても、犬に鳴けといえばワンと鳴くし、猫に鳴けといえばニャーと鳴くしね。
当たり前だけど。
373 ：357：01/09/28 14:51
文章ごちゃごちゃ。結論無いので読んでメリット無いＹＯ！>>372
374 ：372：01/09/28 14:55
>>373
ごめんね、どっちつかずで。
375 ：小泉：01/09/28 15:13
なにやら、いろんな派閥があるようだが、派閥はいかんよ、派閥は！
376 ：デフォルトの名無しさん：01/09/28 15:23
俺はOO肯定･継承消極派だ。何百万ステップのシステムが
クラスライブラリもどきのツリーだったら怖い(^^;)
377 ：デフォルトの名無しさん：01/09/28 15:35
インフラが提供する共通クラスなんかは、ツリーになってるよ。
378 ：357：01/09/28 15:39
>俺はOO肯定･継承消極派だ。何百万ステップのシステムが

継承による差分コーディングにより、何百万ステップが激減するんじゃない。
ステップ減らせることを否定しちゃイカン。開発もメンテもステップが多いものは×。
379 ：357：01/09/28 15:42
書き方悪かった。
クラスライブラリを派生することにより、何百万ステップが激減のが分かりやすい。
自分が記述するコードを大型なクラスツリーにしなきゃならん、という思い込みが間違いだよね。
380 ：デフォルトの名無しさん：01/09/28 15:46
あとから、猿だのカバだの追加する可能性があると思った時に
動物クラスを作って継承させたらいい。
381 ：デフォルトの名無しさん：01/09/28 15:59
理論と実践の壁は大きい。普遍的なインターフェイスなど架空の花。
382 ：354：01/09/28 16:05
>379
クラスライブラリから派生するのはむしろ穏健派の考えでは？
それに関してはあまり否定はしない
問題なのは自分で抽象クラスを作って継承する場合

何度も言うがクラスライブラリを利用するのとそれ以外は全く別物
クラスライブラリのような継承ツリーがアプリの中にあったら困るでしょ
クラスライブラリは
・変更されることがなく
・ユーザーに共有の知識であり
・ソースを読む必要がなく
・デバッグする必要が無い
という点でアプリそのものとは全く異なる（もちろん、完全ではないが）
383 ：デフォルトの名無しさん：01/09/28 16:12
これって進化論の話？
人間クラスは
クロマニョンクラスとか
イクチオステガクラスとか
アミノ酸クラスとかから
派生させるべきって事？
結論は何なの？
384 ：357：01/09/28 16:14
354さん可愛そうですが、全部違ってます。全然OOP分かってない人ですね。

>・変更されることがなく
勝手に内部が変更されるから便利なの。
コンパイラのバージョンが上がったら、ドッキングプロパティが増えてたとか。

>・ユーザーに共有の知識であり
提供された時点では共通の振る舞いだが、派生で振る舞いを変えれるのが良いの。

>・ソースを読む必要がなく
派生して振る舞いを変えるには、該当メソッドを知らなければならないので読まなければならない

>・デバッグする必要が無い
？
385 ：デフォルトの名無しさん：01/09/28 16:18
結論はウザイ、消えろ>>383
386 ：デフォルトの名無しさん：01/09/28 16:18
>>357=２ちゃん牧場
387 ：sage：01/09/28 16:23
ＯＯの思想は間違っちゃいない。専門分野に特化した業務アプリを、汎用的な継承階層にまとめ上げるのが、神業的なだけ。
388 ：357：01/09/28 16:35
>専門分野に特化した業務アプリを、汎用的な継承階層にまとめ上げるのが、神業的なだけ。

そうでもないＹＯ！
ボトムアップで作っていく場合にも、関数よりクラスのが楽。
専門分野特化業務アプリって大型コードになるが、
クラスとメソッドの枠だけ作ってって、後から中身を作る方が、塗り絵みたいで、精神的に楽。
389 ：357：01/09/28 16:42
354さんのどこが違うかと言うと、、、
「クラスライブラリがアプリそのものとは全く異なる」という結論です。

アプリを一から書くのでなく、クラスライブラリからクラスとってきて、
動作の違う部分だけオーバーライドするって開発になるんです。
だから、出来上がったものは、継承ツリーがあってその上位層はクラスライブラリになってた、
って感じで等価になるんです。

そう出来上がってない場合は、
クラスをnewして外からプロパティセットしてメソッド呼んでと、、、
これでは、関数と変わりません。
390 ：357：01/09/28 16:44
関数と変わらない方法では、ステップが減らず、OOPのメリットはありません。
そういう開発方法とるのは、ブビ坊がCOMやActiveXを使い場合です。
COMは派生出来ないので仕方有りません。
391 ：デフォルトの名無しさん：01/09/28 16:45
そういえば構造化も昔は否定されてたよな…。
392 ：デフォルトの名無しさん：01/09/28 16:48
幾多の理論が生まれ、否定され、生き残るのはほんの僅か。
はたしてＯＯＰは？
393 ：357：01/09/28 16:51
OOPが消えたら、Win、Winアプリ、みんな消えるＹＯ！>>392
残るのは、汗で書かれた汎用機OSとLinuxカーネル位か。
X-WindowもC言語かなぁ。
394 ：素朴な疑問：01/09/28 16:55
いくつものシステムがこけてるのに、

継承否定派も含めめ、
これだけＯＯ信者が多いのは何故？
395 ：デフォルトの名無しさん：01/09/28 16:58
>>393
「汗で書かれた」＝「アセンブリ言語で書かれた」
「汗で書かれた」＝「血と汗と涙で書かれた」
396 ：デフォルトの名無しさん：01/09/28 16:59
>>394
悪い宗教とはそういうものです。
397 ：デフォルトの名無しさん：01/09/28 17:02
>>394
構造化設計のほうがこけている割合は圧倒的に多いと思うけどね。
クソ設計の泥沼に陥っている奴は誰だ？
398 ：素朴な疑問：01/09/28 17:03
>>396
なるほど。
日本の宗教人口は実人口の２倍っていいいますもんね。
教祖の金儲けのために踊らされてると知りつつも、

信じてしまうのが日本人なのか？
399 ：素朴な疑問：01/09/28 17:05
>>397

構造化については話を聞きませんが
、やはり悪い酒興のようですね
400 ：素朴な疑問：01/09/28 17:08
酒興ーー＞宗教
です
401 ：357：01/09/28 17:12
>いくつものシステムがこけてるのに、
あ、そうなの？初耳。言語は何よ。

>構造化については話を聞きませんが
構造化では出来上がるシステムが知れてる。

>、やはり悪い酒興のようですね
こういう人は汎用機に留まって、WinやLinux系に移行しない方が良いと思います。
別にそれを止めはしません。
402 ：357：01/09/28 17:14
こういう人は汎用機に留まって、
↓
汎用機COBOLに留まって、の方が分かりやすいですね。
403 ：素朴な疑問：01/09/28 17:15
>>401
すいません、構造化のことは
、まだ勉強していないのです。勉強不足ですいません。
404 ：デフォルトの名無しさん：01/09/28 17:19
http://www3.nikkeibp.co.jp/WAT2/970516/970516trein01.html
http://www3.nikkeibp.co.jp/WAT2/971212/971212trein01.html

OO がいけないわけじゃないじゃん…
405 ：デフォルトの名無しさん：01/09/28 17:22
> 構造化のことは、まだ勉強していないのです

…（閉口）
406 ：デフォルトの名無しさん：01/09/28 17:25
>>404
＞IBMイコールOOT（オブジェクト指向技術）と考えてもらって構わない
ｶ､ｶｺｲｲﾉｶﾅ？
407 ：357：01/09/28 17:29
それはSmalltalk技術者が居ない失敗でしょ>>404

OOPから失敗というのは間違い。
第三世代言語にクラスが追加されたのがOO言語。
例えば、C++使いながら、実はC関数っていう開発もあるし、
汎用機でJava使いながら、関数単位で、Javaのクラスをnewして、
コボラー人海戦術方式したり出来るし。

なんかOOP否定するのに必死みたいだが、OOP言語にも旧言語仕様は入ってるので。
408 ：404：01/09/28 17:35
>>407
否定しようとなんてしてないじゃん…
> OO がいけないわけじゃないじゃん…
って言ってるだけやん…
つか
> > いくつものシステムがこけてるのに、
> って、OO のせいじゃないやん
って言ってみたかっただけやん…
409 ：357：01/09/28 17:39
ごめんなさい、読み間違い。失敗例ね>>408

それから407に色々書いたけど、やっぱり関数セットを一杯書くより、
何でもクラスにしといてメソッドにしといた方が絶対楽。一回やれば分かるＹＯ！
410 ：OO信者：01/09/28 17:54
わざとかどうかひどい誤解をする人がいるようなので。

・継承できそうなら継承しなければならない→嘘
・現実世界の階層構造を必ず模倣しなければならない→嘘

開発するソフトウェアにとってのみ必要なクラス階層構造にする。
そのための指針が、
アナリシスパターンやアーキテクチャパターンやデザインパターン
などのパターン技術。（+プロセス技法)

継承はあくまで差分プログラミングと多態性を実現するための手段であって目的ではない。
411 ：357：01/09/28 17:59
賛成です>>410

>継承はあくまで差分プログラミングと多態性を実現するための手段であって目的ではない。

一旦、差分プログラミングと多態性になれると、
それが出来ない言語は鬱陶しくて、やってられなくなることを付け加えますです。
412 ：デフォルトの名無しさん：01/09/28 18:10
>>410
同意

> 開発するソフトウェアにとってのみ必要なクラス階層構造にする。
入門書だと、これが抜けてる場合が多い気がします。まずは犬と猫で、上位に動物クラスと
いうのは現実に則していて分かりやすいけど、実用的じゃない。

あくまで問題（ソフトウェア）の性質に合わせてクラスは抽出しないと。
413 ：デフォルトの名無しさん：01/09/28 18:28
>>410
意見には同意だけどＯＯの話じゃなくて開発技法一般の話だと思う。
要は教条主義に陥る奴は誰であれバカだよ、と。
414 ：デフォルトの名無しさん：01/09/28 18:36
>>410
ＯＯ信者にしては、だいぶ現実的な思想だな。
しかし、まだ詰めが甘い。
差分プログラミングや多態性は、最終目的ではない。

最終目的とは何かを考えてみよ。
対象のシステムにおいて、差分プログラミングと多態性が、最終目的に対して与えるメリットとデメリットを比較せよ。
それが即ち設計だ。
415 ：デフォルトの名無しさん：01/09/28 18:50
>>410
やっとまともな意見が出てきたって気がするよ
416 ：デフォルトの名無しさん：01/09/28 19:02
>>357が410に同意してどうするんだ？

357はもっとOO原理主義的に

・継承できそうなら継承しなければならない→真
・現実世界の階層構造を必ず模倣しなければならない→真

となってくれないと。
パターンという単語が出てきて逃げ腰か？>>357
417 ：354：01/09/28 19:11
>416
OO穏健派的には
・継承できそうだけど、継承したくない→真
・現実世界の階層構造を模倣できそうだけど、模倣したくない→真
ですね（藁
418 ：デフォルトの名無しさん：01/09/28 19:22
継承(上書･多態)は利点ばかりじゃないからね。
ケースバイケースでしょ。
419 ：ＯＯ道師範：01/09/28 19:31
俺様は必要性や可読性より、クラス階層の美意識を優先する。
それが俺様のＯＯ道美学じゃ。文句あるか！
420 ：デフォルトの名無しさん：01/09/28 19:45
害を与えないならいくらでもどうぞ。
421 ：デフォルトの名無しさん：01/09/28 19:46
>>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
>>424
mix-in的に使えば極楽。
426 ：荒らしではなくてテストです：01/09/28 20:59
あ
い
う
え
お
か
き
く
け
こ
さ
し
す
せ
そ
た
ち
つ
て
と
あ
い
う
え
お
か
き
く
け
こ
さ
し
す
せ
そ
た
ち
つ
て
と
427 ：426：01/09/28 21:03
テスト完了です。
ありがとうございました。
428 ：デフォルトの名無しさん：01/09/28 21:21
継承の階層が一枚岩的なものがいいか森のようなものがいいかは
言語によっても変わる気がする。
C++なら間違いなく後者だが
429 ：357：01/09/28 23:39
>357はもっとOO原理主義的に
>・継承できそうなら継承しなければならない→真
>・現実世界の階層構造を必ず模倣しなければならない→真

これは単なる馬鹿な意見ですね。
現実世界の階層構造は一意に決まっているものではありません。
現在主流のOO言語では不可能。不可能を目指してはいけません。
430 ：357：01/09/28 23:58
馬鹿な意見がでたおかげで、継承反対派との亀裂がわかりました。
継承賛成派・・・継承でステップを激減
継承反対派・・・現実世界の階層構造を必ず模倣しなければならない

なぜ反対派が、極論を言うか。継承が何か分かってないからです。

構造化の初期は同じことが言われたでしょう
構造化賛成派・・・関数でステップ激減
構造化反対派・・・「goto行番号」ならソース１つで良いのに．．．
　　　　手続き分割出来るって、出来るものは全て分割しろよ！
431 ：357：01/09/29 00:00
継承賛成派はメリット説明したんで、
反対派はそのメリットにそったクラスを一個でも作って検討してＹＯ！
432 ：デフォルトの名無しさん：01/09/29 00:38
OOがまともに理解できないプログラマやＳＥが多いのが日本のビジネスソフト
業界の弱さですね。西洋人はオブジェクト指向が出始めた頃から
ばりばりとＯＯプログラミングして、InterViewというフレームワークを作っていたの
だけど日本人はそれを真似するぐらいでしたね。日本人には向かない
のかもしれませんね。
433 ： ：01/09/29 00:45
フレームワークって単なる造語じゃん。
ＯＯ出る前からやってたよ。

F6-PageDown-F8->別ファイル-F9
434 ：デフォルトの名無しさん：01/09/29 00:45
>>432
> 日本のビジネスソフト業界
2チャンねらーの間違いでしょ
435 ：デフォルトの名無しさん：01/09/29 00:45
継承肯定派です。

>>430
なるほど……と一瞬思ったけど、ちょっと違うと思う。

継承賛成派は、使うところと使わないところを見極めた上で、
使うべきところではしっかり使うべきだと言っている。

継承反対派は、全てのケースで無理に使うとよくないと言っている。

つまり、どちらも全てのケースで継承を使うのは良くないと知っていて、
この点では実は同じことを言っている。
それではどこが違うのか。

賛成派は、使いどころの見極めについて具体的な方法論を持っていると思う。
そしてどうすると失敗するのかを明確にわかっている。
だから使うべきところなら迷わず使う。

しかし反対派は、どこで見極めるのか掴めてなくて、
失敗しないために、慎重になるという方法を選んでいる。
だから確固たる信念を持って使うべきという人がいると、
その人には慎重さが足りないと思ってしまう。
436 ：　：01/09/29 00:49
継承賛成派、反対派、穏健派という分け方に意義有り。
ＯＯはクラスなど無くても成立します。
437 ：　：01/09/29 00:50
異議ね
438 ：435：01/09/29 00:56
んで、オブジェクト指向の理解が浅い人に継承のメリットを語るとき、
失敗する可能性を恐れて継承の良さを半端に教えるのはよくない。
まず成功する場合のメリットをしっかり認識させた上で、
さらに失敗する可能性について教えるべきだと思う。
そうしないと、継承を恐れすぎて、身につかなくなってしまう。

さて、どうすればうまく継承できるのか。
何度か失敗してみるのがいちばん手っ取り早いけど、
学生が勉強しているならともかく、実務で作業しながら学ばないとしたら、
これはリスクが高すぎる（俺は実務で失敗して学んだけどね）。

やはりUMLなどのモデリング手法を学んだ上で、
十分な要求定義と分析を重ねるしかなさそう。
あとできる限りデザインパターンから設計を選ぶようにしないといけない。
でもこれをうまくやるにも、経験がものをいうんだよなぁ。

構造化設計の経験がある人にオブジェクト指向を教えるのは案外たやすい。
状態遷移とかERとかDFDとか、かなり似ているからね（つーかほとんどそのまんま）。
でも、構造化言語を使っただけで構造化設計をできた「つもり」になっている人に、
オブジェクト指向を教えるのは非常に難しい。
そういう意味で、構造化設計の経験者なら、オブジェクト指向でも
すぐにそれなりの設計ができると思うのだけど。
439 ：435：01/09/29 00:59
>>436
クラスや継承が無くてもOOが成立するというのは、間違っては無いですけど、
それは基礎的な話ですよね。
OOをベースにした膨大な技術の蓄積を享受するには、継承は避けられない。
440 ：357：01/09/29 01:04
>継承賛成派、反対派、穏健派という分け方に意義有り。
>ＯＯはクラスなど無くても成立します。

確かに現実世界には確固としたクラス階層というものは無いんだよね。
オブジェクトといえるものはあるが。
そういう意味で言うと、

>OO穏健派的には
>・現実世界の階層構造を模倣できそうだけど、模倣したくない→真

この人はまだ良く分かってない。
441 ：357：01/09/29 01:07
436は継承のこと言ってるんじゃなく、オブジェクトベースのoopを言ってる>>439

オブジェクトベースのoopでは、クラスが無くて、実行時に継承するそうです。
442 ：435：01/09/29 01:13
>>441
ほ～。そんなのがあるんですか。
知りませんでした。
443 ：357：01/09/29 01:15
進化ということを考えても、動物ツリーの下に犬、猫があるという説明よりも、
哺乳類の固体に、有る時期ウィルスがDNAを転写、又は紫外線があたって、
犬に分化したもの、猫に分化したものが出来たという方が現実味あるよね。
そうだと、実行時の継承の方が現実に近い。

だから、実は、動物、犬猫猿が変だって言ってた意見も分かるよね。
444 ：357：01/09/29 01:20
後、コンピュータウィルスがインターネットを駆け巡る状況を
シミュレーションする場合もオブジェクトベースのが記述しやすいかも。

ではお休みなさい。
445 ：435：01/09/29 01:24
>だから、実は、動物、犬猫猿が変だって言ってた意見も分かるよね。

いや、そこはわからない。
現実の世の中を完全に模倣することに、あまり意味は無い。

結局さ、所詮はソフトウェアに過ぎないわけよ。
ソフトウェアから見てオブジェクトが十分に抽象的なら、
必要以上に抽象化する必要は無いでしょ。

あるソフトでは動物クラスという抽象クラスが必要かもしれないし、
別のソフトでは不必要かもしれない。
そこは設計の都合次第。
446 ：名無しさん＠ＸＥｍａｃｓ：01/09/29 01:51
犬猫を例にとることが混乱の元になってると思われ。
447 ：デフォルトの名無しさん：01/09/29 01:51
>>445
禿同

抽象とか模倣とか、一部の人たちがやけに
難しいことを得意げに言ってるが、
それって実際役に立ってますか？

少なくとも自分の周りでは役に立ちそうにないね。
＞その蘊蓄。

純粋に設計し、純粋に組む。それが正道でしょ？
448 ：　：01/09/29 01:58
クラスライブラリをＯＯと混同してる人が居ます。
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
Java使いには馬鹿にされますが、JavaScriptがプロトタイプ型ですよね。
http://www.microsoft.com/japan/developer/scripting/default.htm?/japan/developer/scripting/jscript/doc/jsconcreatingownobjects.htm
WebComponentsってのがこれを使ってましたっけ?
452 ：　：01/09/29 02:28
>>49
JavaのAPIはクラス設計の抽象化に失敗していて、やたらにクラス増やしてますが
何か？
453 ：デフォルトの名無しさん：01/09/29 02:30
実装の継承の欠点が書いてあるから、これも読んでよ。
http://www.microsoft.com/JAPAN/developer/library/jptech/TechArt/VTools/vb/vb6/ifacebased.htm
MSDNだよ。ブラクラじゃないから。
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～については結構クラス数爆発の印象はありますね。でも、抽象化に失敗かと言うと逆で、
抽象化し過ぎたせいで、強力な柔軟性と引き換えに使いやすさ/分かりやすさを犠牲にした感はあります。
ま、それも抽象化に失敗といえるか(藁
457 ：デフォルトの名無しさん：01/09/29 07:00
OO否定派が、動物クラスまで必ず作るのがオブジェクト指向
だと勘違いしてるのでは。
458 ：デフォルトの名無しさん：01/09/29 07:28
>>457
うわべだけで理解したつもりになって
語る厨房は無視したらいい
ＯＯを無価値と思わせるのもそれはそれでいいではないか
459 ：デフォルトの名無しさん：01/09/29 11:02
>>457
>>458
君たちみたいな勘違い君がいると、我々ＯＯ派の見識が疑われ、不毛な議論に逆戻りだよ。
反ＯＯ派の為ではなく、まともなＯＯ派のために消えてくれ。
460 ：357：01/09/29 15:43
>クラスライブラリをＯＯと混同してる人が居ます。

こういう意見てどうしようも無いよね。説明してないヤツだし。
オブジェクト指向を否定する人達にクラスベースとオブジェクトベースと
同時に分からせることは出来るわけない。順をおって、クラスベースから説明しないと。
説明ということがどういうことか分からない学生君なら、ちょっかいかけなきゃ良いのに。
461 ：sage：01/09/29 15:55
こんなに突っ込みどころの多いスレ見逃してた。
二度目読み直し中。
462 ：デフォルトの名無しさん：01/09/29 18:15
>>459
オマエモナー
ＯＯを語りたがるやつほどＯＯを知らないことがほとんどだよ
ネット上のＤＱＮＯＯページのどれほど多いことか
463 ：デフォルトの名無しさん：01/09/29 18:36
オブジェクト指向とドキュメント・ビュー・アーキティクチャは明らかに矛盾しています。
だからＭＦＣは分かりづらい。
464 ：デフォルトの名無しさん：01/09/29 20:36
>>462
そういうのは、DQNではないOOページを作ってから言おうな。

せめてDQNじゃないページを紹介してみろよ。
読んでやるから。


どうでもいいが抽象論で満足してないで
現実にどういう場合にどういう継承を使ったとか言えばいいのにのお。

継承でクラス階層増やしまくって他人には使いにくい
意味不明なライブラリを自作して喜んでる奴が多そうだな
465 ：デフォルトの名無しさん：01/09/29 21:49
>>460
混同してる方が説明を要すると思うぞ。

クラスと００は全くの別物。
466 ：デフォルトの名無しさん：01/09/29 21:55
>>463
ドキュメント・ビュー・アーキティクチャなぞ常識。
だから別オブジェクトにしただけの話。
特にビューの方はパーツ化して使いまわしがしやすい。
十数年前、プログラム組み初めて（アセンブラ）直ぐに気付いて
取り入れたよ。
467 ：357：01/09/29 22:04
>混同してる方が説明を要すると思うぞ。
>クラスと００は全くの別物。

小学校一年では、地球から観測した太陽（天動説）を教えてから、
中学生で地動説になるんだろうが。
同じように、構造化プログラミングを教えるときは、
関数を作れって教えるが、それはoopでは間違いになる。

説明の途中でクラス説明したら駄目なのか？

氏ねや厨房。
468 ：　：01/09/29 22:16
クラス厨房の逆鱗に触れてしまった模様。
469 ：デフォルトの名無しさん：01/09/29 22:21
>>468
中身の無い議論に誘導するのはもう止めよう。
470 ：　：01/09/29 22:40
クラスとＯＯはてんぷらと中華料理ぐらい違う。
471 ：デフォルトの名無しさん：01/09/29 22:44
>>470
眺めてあれこれ言ってるより、さっさと食べて仕事しろってことだな。
472 ：357：01/09/29 22:46
中身が無いから名前が「」なんだ。コテハンを「」にしてやるよ。

>てんぷらと中華料理ぐらい違う
どっちも食べ物で共通項あるじゃないか。

クラスベースのoopではoo=クラス
オブジェクトベースのoopではoo=オブジェクト

だろ。「」は人に説明ということがデキンみたいだな。
学生というか中身の無いヤツというか。サヨナラ。
473 ：357：01/09/29 22:49
オブジェクトベースのoopの方がクラスベースより現実にあってることは説明しただろ。
「」は自分は全て知ってると悦に入ってるんだろうが、
しかし、オブジェクトベースでさえも通過点なんだ。技術とはそういうもの。
順を追って説明出来ないなら、会話に入らない方がみんなのため。
474 ：デフォルトの名無しさん：01/09/29 22:50
ＯＯ設計っていうけど、みんなホントに便利かい？
　ＧＵＩ周りは 出来合いのクラスライブラリ使うからＯＯ設計の出番無しさ

アプリケーションだとすぐに相互に依存しあってＯＯ設計だと
　再利用が逆に難しくなった経験しかないな。
　OCXはそのまま利用出来るならいいけどそうじゃなきゃ後になって
　どこを弄っていいか判らなくなる事多いし
　今迄手軽に再利用出来たのはDelphiコンポーネントだけだな

　しいてクラスが再利用出来た経験は、クラスライブラリをラップする
　関数用意しておいた時だな・・・・はは・・・・
　スクリプトを継承出来るような構造で書いてさ、結局文字列渡して
　実行する関数として使うだけなんてさ・・・ははは・・・・
475 ：憂鬱な名無しさん：01/09/29 23:05
どうも。1です。
私は実はオブジェクト指向でプログラム組んだことは無いんですが、
最近「憂鬱なプログラマのためのオブジェクト指向開発講座」や
メイヤーさんの「オブジェクト指向入門」等を読んで、オブジェクト
指向に感動したものです。
オブジェクト指向の分析設計のやり方が良くわからない、または、オブジェクト
指向の分析設計でうまく行くとは思えない人は前者の本を読んでみては
どうでしょうか？
誤解も解けて自信が湧いてくると思います。
私の名前もその本から取りました。
このスレにも「憂鬱な・・・」を読んでいると思われる人の発言がいくつか
ありました。

って、ちょっとスレの流れとはあまり関係ない話ですみません。
476 ：　：01/09/29 23:07
はあ・・・・。
477 ：デフォルトの名無しさん：01/09/29 23:21
このスレはケンカ腰なヤツが多くて笑えるね
478 ：デフォルトの名無しさん：01/09/29 23:22
どうもすいません。ありがとうございます。
479 ：デフォルトの名無しさん：01/09/29 23:23
>>477
そんなあなたにこのＨＰ
http://www2s.biglobe.ne.jp/~Beyond/amue/byan/guest/tetu/katsu01.html
480 ：デフォルトの名無しさん：01/09/29 23:33
俺はＯＯ派だけど、ここのＯＯ派には疑問を感じる。

差分プログラミングの柔軟性や、多態の便利さは、無条件で得られる物ではない。
実装の継承は依存を発生させ、オブジェクトの独立性を損なう。
インターフェイスの継承でさえ、現実には依存なしの設計は不可能に近い。
クラスの多段階層は実装の位置を不明確にし、メンテナンスやデバッグに弊害をもたらす。
これら支払わなければならない代償について、どうも理解できていないようだ。
481 ：デフォルトの名無しさん：01/09/29 23:40
平べったいクラス群は使えるのかな？
委譲しまくりのクラス思想もどうかと思うけど。群生の初期段階っぽい。
どうでもいいことだがＭＳの書くものはＯＯとは認めたくない。
あんなのはＯＯではあるまいに。病んだＯＯというか。
482 ：デフォルトの名無しさん：01/09/29 23:42
>>480

ＯＯ本には、そんな事書いてないからね。実際プログラミングした奴じゃないと、
わかららんよ。本に洗脳されて、わかったつもりの奴が多いから。
483 ：デフォルトの名無しさん：01/09/29 23:48
MFCクラス＞＞＞＞＞Ｊａｖａクラス
484 ：デフォルトの名無しさん：01/09/29 23:56
>>481
ＯＯＰのクラスライブラリって、どれもわかりづらくて、
使いにくいですよね？　たぶん、最も優秀な、最もＯＯに
精通した人達が、作ったと思うんですが？

そこで私が思うのは、作りが悪いのではなく、ＯＯで作る
と、ＯＯでの開発が向いていると思える汎用クラスライブ
ラリでさえ、ああなっちゃうのかなと。何かＯＯの限界が
見えたような気がしてしまうのです。
485 ：480：01/09/30 00:01
>>484
俺はそうは思わん。
このスレにも住み着いている、ＯＯオタクみたいのが作るから、継承オバケみたいになる。
多態の必要性等を十分吟味して作れば、もっとましな物が作れる。
486 ：デフォルトの名無しさん：01/09/30 00:05
>>485 Object Oriented Otaku ＯＯＯですね！←しょーもな
487 ：デフォルトの名無しさん：01/09/30 00:12
>>484
機能にムダがありすぎ
仕様がいいかげんすぎ
相互関係がしょぼすぎ
だからです
488 ：デフォルトの名無しさん：01/09/30 00:15
クラスの多段階性で実装位置がわかりにくくなる問題は
VCのクラスブラウザとかがあれば結構マシになる。
489 ：デフォルトの名無しさん：01/09/30 00:20
>>488
階層が深くて、何度もオーバーライドされてて、
オーバーライド中では上位クラスの実装もよんでて。
やっぱ探すの大変だよ。
490 ：デフォルトの名無しさん：01/09/30 01:06
>>489
上位クラスに、ツリー形式ですぐ飛べるようになってるから
随分マシだよ。
491 ：デフォルトの名無しさん：01/09/30 04:18
話は飛びますが、生産性のついて言うなら結論出てると思うね。
ＯＯＰで生産性上がるならＯＯＰ採用してる会社は利益率上がって
採用してない会社を駆逐してるはずだよ？
現実はなんかＯＯＰ採用してるとこの不振が目立つ・・・。

これが世の中の動きという奴。
492 ：デフォルトの名無しさん：01/09/30 04:42
採用することと使いこなせていることとは同義ではない。
更に、使いこなせないものに引きずられるのは
自分の使うべき道具を見切れていないその企業自身の問題でしかない。
ＯＯに限らず、ソフトウェア開発プロセスが流行った時代にも同じようなことはあった。
もちろん、だからと言って、ＯＯが有益である、と結論できるものでもない。
493 ：デフォルトの名無しさん：01/09/30 04:54
一つや二つの企業ならそう言えるかも知れませんが、全体的に生産性
上がってないのなら企業の問題ではありません。
ＯＯは使いこなすのが難しいっつう事でビジネスとしてのＯＯの評価は
終わってしまいます。
494 ：デフォルトの名無しさん：01/09/30 04:59
具体的な企業の名前や数と業績不振を示す指標を提示して
非ＯＯの場合の同様のデータと比較しなければ意味がない。
そういう具体的な話が持ち出せない限りは煽りと変わらない。
言っておくが、ＯＯを擁護したいわけではない。
495 ：こんなのは？：01/09/30 05:17
米インテリジェネシス社：Javaから逃げようとしたけど間に合わず
http://www.hotwired.co.jp/news/news/business/story/20010420103.html
496 ：デフォルトの名無しさん：01/09/30 05:27
そんな一社だけの例をあげられてもな、、、
その記事ではOOのことには触れられてなくて、実行速度が悪かった
としか書いてないし。
497 ：デフォルトの名無しさん：01/09/30 07:51
>>495
何百人いても無能が揃ってるとどうしようもないだろう
逆に十数名でもＯＯを武器に生産性を上げている企業も多い
ＡＩは専門家がいなければアホなものしか作れないしな

結局アホの集まりだったということだろう
498 ：デフォルトの名無しさん：01/09/30 08:00
>>497
４９５の話は、ＯＯとの因果関係が非常に不明瞭だけど、
失敗の原因を究明するときに、何でもアホだからとか馬鹿だからとか、
短絡思考過ぎると思うけど。
失敗原因の分析能力に欠ける上、何の発展性も改善も得られないよ。
499 ：デフォルトの名無しさん：01/09/30 08:06
>>498
同意
プロジェクトは、優秀な人材集めりゃ成功するわけ
じゃない
逆に一部の優秀な人材と、多数の凡人でも、十分成
功できる
むしろそれが出来ない方法論なら、方法論に問題が
あると認めざるおえない
500 ：デフォルトの名無しさん：01/09/30 10:39
>>491
それでは非オブジェクト指向言語がオブジェクト指向を
サポートしようとしている現状にはどう思われますか？
501 ：デフォルトの名無しさん：01/09/30 13:29
「DirectXはオブジェクト指向で作られてる」とか言い出しそう。
502 ：デフォルトの名無しさん：01/09/30 13:34
>>499
>むしろそれが出来ない方法論なら、方法論に問題が
>あると認めざるおえない

それは問題分析者がアホなんだよ
ＯＯにせよなんにせよ、プランを立ててから実行資源、条件を
綿密に計画しなきゃ意味がない。ＯＯはそれが特に顕著。
ふさわしい言語、解析は問題によりけり。それがわからないアホなら
どうしようもない救いもない。
なんでも方法論のせいにする前に、問題解析さえできていない
アホのほうがはるかに問題だろ。
503 ：デフォルトの名無しさん：01/09/30 13:37
ＯＯ採用会社の不振の統計なんか出てるような誰にでも判るような状況なら
皆逃げ出してるって。
504 ：デフォルトの名無しさん：01/09/30 13:42
「ＯＯで成功してる」とか言ってるのは競争の無いところの話ばかりじゃん。
ＷＩＮ用の店で売ってるようなソフトで成功してるところなんか無いんじゃない？
505 ：デフォルトの名無しさん：01/09/30 14:12
> ＷＩＮ用の店で売ってるようなソフト

アマですか？
506 ：デフォルトの名無しさん：01/09/30 15:09
銀の玉なぞない。
ただ最善を模索するのみ。
507 ：デフォルトの名無しさん：01/09/30 15:19
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実践してると言っても良いんだろうか・・・？

　要は運用次第って事でしょ。
共産主義という考え方があっても運用次第では旧ソの様になってしまう。
運用しずらい概念であるということなのかも。
511 ：あ：01/10/01 03:28
だから、結局　オブジェクト指向って何だよ？
512 ：デフォルトの名無しさん：01/10/01 03:29
もう、なんでもいいじゃん、このさい。(藁
513 ：512：01/10/01 03:30
ひゃっほう！５１２！
514 ：デフォルトの名無しさん：01/10/01 08:25
ああ、今わかった。
オブジェクト指向は計画経済、共産主義みたいなもんだ。
515 ：デフォルトの名無しさん：01/10/01 08:27
需要をピタリと予測できれば計画経済は成功するが、
予測に失敗すれば経済は破綻する。
516 ：デフォルトの名無しさん：01/10/01 08:29
ＯＯの設計も同じ。
つうことで>>510さんきゅー
517 ：デフォルトの名無しさん：01/10/01 08:45
技術としての　オブジェクト指向　は結局IOOPをどう上手に使うかって事でしょ？

営業用の「オブジェクト指向」があって、これはお仕事を貰う為の格好付けみたいなもんでしょ
518 ：357：01/10/01 10:56
>話は飛びますが、生産性のついて言うなら結論出てると思うね。
>ＯＯＰで生産性上がるならＯＯＰ採用してる会社は利益率上がって
>採用してない会社を駆逐してるはずだよ？
>現実はなんかＯＯＰ採用してるとこの不振が目立つ・・・。
>これが世の中の動きという奴。

これは一体どこの話なんだろう。OOPを取り入れない会社とOOP取り入れた会社の２種類に分かれる？
今、OOでない言語って、VBとCOBOL類（OO-COBOLは余り聞かない）しか無いよね。
どこの会社でも、VC++、DelphiVCL、Javaと取り入れている。
10年前のUNIX/プリプロセッサC++は取り入れてるところはあまり無かったようだが。
システム開発失敗事例というものは年に山ほどあって、その解決策としてクラスライブラリというのが一般的。
519 ：357：01/10/01 12:36
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の最大の陰謀ではないかとも思いたくなります．
520 ：　：01/10/01 13:56
http://www2.gihyo.co.jp/text.asp?ID=112
521 ：357：01/10/01 14:01
あー、わざと直リン控えてたのにぃ>>520
522 ：オフトピ：01/10/01 14:03
直リンしない奴 = アホ
523 ：354：01/10/01 14:22
357さんと共闘すべきか対立すべきか迷うYO!
自民党と共産党の間にいる民主党みたいだな（藁
誰が敵なのか分からん
524 ：357：01/10/01 14:33
僕、別に闘う気ないＹＯ！
自分が断言出来ることは断言して、会話の進行を加速したいだけ。
もし、自分の断言が間違ってたことが分かったら、それはそれで収穫だよ。
525 ：357：01/10/01 14:34
でも、なんとなく、オブジェクトベースのooの話が立ち上がった直後、
それをﾏﾀｰｸ理解しないスレが続いて、このスレ終焉した感じ。
526 ：デフォルトの名無しさん：01/10/01 16:23
終演したところで、取りあえず何で評判なのに
本屋で一度も見掛けたこと無いのかを教えてくれ。
「憂鬱なプログラマのためのオブジェクト指向なんちゃら」
え？絶版？
527 ：デフォルトの名無しさん：01/10/01 17:06
いや、今も売れてる。
528 ：285：01/10/01 17:13
>>526
それなりに技術書が置いてある本屋なら大概置いてあるけど。

526はどこに住んでるの？
529 ：508：01/10/01 17:53
>>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);
　}
};
533 ：532：01/10/01 19:36
（参照）→（下のコード参照）
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);
}
}
535 ：532：01/10/01 22:31
>>534
そかそか、了解です。
536 ：530：01/10/01 23:27
例が間違ってた。すみません。
class A extends Object { ... }
class B extends Object { ... }
class C extends A, B {}
AとBを通じて継承された2つのObjectは1つになる必要があります。
537 ：526：01/10/01 23:31
>>528
　広島。たまに大阪に出るから良い店教えてちょんまげ。
梅田のジュンク堂、紀伊国屋、旭屋やらまわったが見つけられなかった。
探し方ヘタなのかな・・・？
538 ：デフォルトの名無しさん：01/10/01 23:44
>>537
俺は技術書のために本屋をはしごするのに疲れた。
http://www.amazon.co.jp
2Chで評判の良い本はバシバシ買う。
539 ：526：01/10/01 23:54
俺も疲れるもんで題名分かってる本は通販するんだわ。
esBooksに頼んだのが運の尽きかしらんけど、
発注して5日後に本社にしか在庫ねぇってメール来て、
入荷したら又メールするって来たんだわ。
で、それからさらに5日経過してるが、未だにとどかん。
計10日も待たされる・・・。
esBooks
amazone
クロネコブックサービス
紀伊国屋
どこが一番在庫量豊富なんだろう
540 ：530：01/10/02 00:21
>>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
ライブラリに問題があれば新しいバージョンでそれを直せば良い。
Ｊａｖａにはそれが出来ない宿命があるから改良する度にクラスがごっそり増える。藁
542 ：デフォルトの名無しさん：01/10/02 01:22
>>541
意味不明
543 ：デフォ：01/10/02 04:33
オブジェクト指向って
いろいろボタンはついてるけど、説明書読まなきゃ何の事か分からない多機能リモコン
みたいなもんに感じる
544 ：354：01/10/02 08:40
>543
それは言語仕様について？　それともライブラリについて？
後者ならば確かに情報が多いが故に探すのが大変という、ネット社会にも
通じる議論になるが、過去の言語なら自作する必要のあったモノを利用できるのは
便利なはず。ただ、よく使うクラスをヘルプで特記してくれりゃ、とは思うが。
545 ：デフォルトの名無しさん：01/10/02 08:46
まあでも、OOに関係なく大きなライブラリになってくると　どっかで探すより作った方が早い
という分岐点があるように思うな。　
546 ：デフォルトの名無しさん：01/10/02 08:53
>>539
技術書ならcbook24が速い。即日発送だし。在庫もすぐ確認できる。
bk1も関東なら(?)today便で翌日には届くが、予約も併用しないと送料がかかる。
amazonは配送は上記に比べて遅いが注文後のキャンセルがwebだけでできるので安心。

憂鬱な～はかなりあちこちの本屋で売ってるな。
「憂鬱なプログラマのための」は小さく脇にあるだけで
オブジェクト指向～がでかいタイトル。
547 ：357：01/10/02 09:38
>オブジェクト指向って
>いろいろボタンはついてるけど、説明書読まなきゃ何の事か分からない多機能リモコン

これは、全くの勘違いですね。
関数ライブラリというものが、呼び出し手順仕様書を読まなきゃ何の事か分からない多機能リモコン。
例えば、一万近くあるWin32API。殆どがサンプルコードを読まなければ使えない。
oopではWin32APIのコールセットがメソッドに纏めてあるので、呼び出し手順を意識しない。
548 ：デフォルトの名無しさん：01/10/02 13:39
そうかな？
Win32APIはボタンが1万個ある単純なリモコンだと思うぞ。
OOライブラリはボタンの数を減らそうとして結果的に「多機能リモコン」
になってしまう。
関数は呼び出して返り値を使うことしか考えなくていいけど、クラスはいろいろと
考えなくてはならないことが多い。
#ちなみにだからOOはだめといってるわけじゃない
549 ：357：01/10/02 14:22
はぁ？
>Win32APIはボタンが1万個ある単純なリモコンだと思うぞ。
リモコンのボタン押す順番間違えたらエラーになるよ。

>関数は呼び出して返り値を使うことしか考えなくていいけど、クラスはいろいろと
意味不明。メソッド名で処理が分かるじゃない。
関数は一個じゃなくて複数あるものを、正しい順番で呼びださないと。
550 ：マジアドバイス：01/10/02 17:16
なあみんな、「憂鬱な～」よりも、メイヤーさんの「オブジェクト指向入門」を読もうよ。
551 ：357：01/10/02 17:46
読みたくなるように宣伝してよ>>550
552 ：デフォルトの名無しさん：01/10/02 17:49
>>548
あなたは病気です。
病名はNIHシンドローム。
http://www2u.biglobe.ne.jp/~kikucyt/e/ABC_Data/nihsyn.html
553 ：デフォルトの名無しさん：01/10/02 19:08
>>549
>リモコンのボタン押す順番間違えたらエラーになるよ。
でも押すだけだから「単純」だろ？使いやすいといった覚えはないぞ

>>関数は呼び出して返り値を使うことしか考えなくていいけど、クラスはいろいろと
>意味不明。メソッド名で処理が分かるじゃない。
>関数は一個じゃなくて複数あるものを、正しい順番で呼びださないと
よくわからん。正しい順番で呼ぶ関数を新たに作ればいいんじゃない？
それともコンストラクタとデストラクタが自動的に呼ばれるということ
いってるのか？
それが有効なのは同意するが、ゆえに高機能で使いこなすのが大変な
(そしてもちろん使いこなせれば役に立つ)高機能リモコンなのでは？
554 ：デフォルトの名無しさん：01/10/02 19:26
つーかリモコンと喩えたアホが悪い
555 ：デフォルトの名無しさん：01/10/02 19:33
>>553
単純　＝　簡単、　高機能　＝　使いこなすのが大変
という図式は、逆だよね。
同じことをするのに、
単純　＝　手間がかかる、　高機能　＝　簡単
が普通だよね。
556 ：デフォルトの名無しさん：01/10/02 19:42
>>555
人によると思うよ
　高機能なものは俺に取っては簡単ではない

　俺は記憶力が他人に比べて異常に悪い（一つプロジェクトが終ると
　前の事聞かれても全く覚えてないほどだ）だから
　単純で機能がはっきりわかるものを組み合わせられる仕掛けならいいけどさ

BASICのように MID/LEFT/RIGHTと高機能な関数があるよりは
　 while(*d++=*s++);　と基本タームを組み合わせる方が楽だ
557 ：デフォルトの名無しさん：01/10/02 20:37
>>556
関数によるアプローチが招く複雑さについてはメイヤーさんの本でも議論されとるぞい。
558 ：デフォルトの名無しさん：01/10/02 21:08
>>556
あんたはもうプログラマを辞めたほうが良いよ。
時代の変化についていけない哀れなC使いにしかみえん。
559 ：デフォルトの名無しさん：01/10/02 21:53
リモコンの例えはおかしいな。
オブジェクトはボタンがたくさんついているリモコンじゃないからな。
そもそも関数郡が単純なリモコンというたとえに無理がある。
オブジェクト＝高機能でもない。

関数ライブラリこそ高機能なひとつの機械。
クラスライブラリは単機能な機械の集合。

関数ライブラリを使いこなすにはかなりの習熟が必要。

クラスライブラリもある程度の習熟が必要だけど、
関数の数よりクラスの数のほうが少ないから、
探し出しやすい。
またクラスを見つけた後は、機能がシンプルだから
操作方法が推定しやすい。

もちろん高機能なクラスが混じっていたら使いづらくなる
ということは言うまでも無いが、
関数ライブラリは、個々の関数は単機能でも、
全体としてかなり高機能になってしまう。
だいたいクラスライブラリでも関数という単位はあるしね。
560 ：559：01/10/02 22:02
できのいい関数ライブラリはオブジェクト指向になっている。
オブジェクト指向に都合がいいことを言っていると思うかい？
いやいや、オブジェクト指向とは突然湧き出てきたものじゃない。
「よいプログラム設計を分析して得られた結果」がオブジェクト指向なんだよ。

むやみやたらに作ってもなかなか上手い設計にはならないし、
全てのプログラマーが経験で学ぶというのも限界がある。
だから過去の成功例や失敗例を分析して、
誰でも成功できるように導いてやるほうがいい。

オブジェクト指向が完全な答えかどうかはわからないけれど、
一つだけ確実に言えることは、オブジェクト指向を学んで損することは何もないということ。

だからよけいなアレルギーは捨てて欲しいなぁ。
561 ：559：01/10/02 22:16
オブジェクト指向はよく難しいと言われる。
難しい概念だから、良くない概念だと思ってしまいがちだし、
それを振り回している奴らは鼻持ちならないように見えるかもしれない。

しかしオブジェクト指向はプログラミングの方法論ではなく、
プログラム設計の方法論なのよ。（※OOPはOOの実現方法でしかない）

プログラミングができるようになっても、
うまく設計することがいかに難しいかは、
業務でプログラムしている人なら知っているでしょう。
それなら方法論がある程度難解になるのは
仕方がないということを悟るべき。

幸い、オブジェクト指向は、これまで生まれてきた
設計手法に比べて単純明快。
オブジェクトに仕事を委託しよう、
オブジェクトが作業する手段として関数と変数を所有させよう、
オブジェクトは契約を守ろう、というだけのもの。
（正確な表現じゃないけど、解りやすいでしょ？）
562 ：デフォルトの名無しさん：01/10/02 23:35
>>561
そして数百ページに及ぶ契約書を読まないと使えないのね。ｗ
563 ：デフォルトの名無しさん：01/10/02 23:39
>>559
＞関数の数よりクラスの数のほうが少ないから、
なにｺﾚ?
564 ：デフォルトの名無しさん：01/10/02 23:50
>>561
反ＯＯ派の人も、カプセル化の意義について、疑問を感じる人は少ないと思うけど。
焦点はやはり、上書と多態を得るための代償（継承）についてでしょ。
ＯＯ派の人も、そろそろ理解できたと思うけど。
565 ：564：01/10/02 23:52
リモコンの話はもうやめたら？
例が悪いよ。
566 ：デフォルトの名無しさん：01/10/02 23:53
やっぱ無印サブルーチンとクラスの併用が一番優れていると思う。
567 ：デフォルトの名無しさん：01/10/03 00:34
>>566
あなたが正解！！
オブジェクト指向の生産性は最悪なわけよ。
だから小さなクラスライブラリと強力な関数なの
568 ：564：01/10/03 00:54
派閥毎の対抗意識が強すぎて、現実的な話しになりづらい。
569 ：デフォルトの名無しさん：01/10/03 01:13
ドーデも良いがいまどきオブジェクト指向を理解していない奴がいるのか？
さっさと理解しておかないと職をなくすよ。
570 ：デフォルトの名無しさん：01/10/03 01:16
>>569 は世間を理解していなさそうだが（ｗ
571 ：357：01/10/03 01:22
>そして数百ページに及ぶ契約書を読まないと使えないのね。ｗ

winapiを使ってたころは、リファレンスヘルプを印刷しまくってコーディングし、
エラーや動作しない場合は、サンプルコードを沢山探し印刷して理解した。

クラスライブラリでは、該当クラス宣言した後は、メソッド、プロパティ一覧されるから、
適当な呼び出しで動作する。その動作でどんなapiが呼び出されたのか知りたい場合、
そのプログラムをデバッガで中に入るだけでapiコールが全て見えるため数分で作業が終る。

つまり　クラスライブラリ　＞　リファレンス＋サンプルコード
572 ：357：01/10/03 01:24
注意：クラスライブラリの下位では、apiをラップしたメソッドがあるので、apiを知りたい場合も余りない。
573 ：デフォルトの名無しさん：01/10/03 01:26
>>571
Javaの事を言ったつもりだった。
MFC＞＞＞＞＞＞JAVA
574 ：357：01/10/03 01:27
>＞関数の数よりクラスの数のほうが少ないから、
>なにｺﾚ?

win32apiは一万を超えているが、クラスはその１００分の１じゃないかな。

>焦点はやはり、上書と多態を得るための代償（継承）についてでしょ。
>ＯＯ派の人も、そろそろ理解できたと思うけど。

？
575 ：デフォルトの名無しさん：01/10/03 01:28
ちなみにJavaでクラスブラウザ使っても、訳判らんクラスと
訳判らんメソッドが大量に画面埋め尽くすだけだと思われ。
576 ：デフォルトの名無しさん：01/10/03 01:29
APIってそんなにあるのか？一万。
577 ：デフォルトの名無しさん：01/10/03 01:30
>>572
apiをクラスでラップされると、環境毎（処理系､言語毎）
に異なるクラスライブラリを把握しないといけない。
素直にDLLにアクセスでき、関数が見えていてくれた方が
良い場合が多い。もしくはCOMの様なインタフェース。
(COMの実装が良いとは言わない)
apiからは離れとけ>357
578 ：デフォルトの名無しさん：01/10/03 01:31
そんなことよりOOの学習コストの高さによる
厨房OOPerの氾濫が深刻な問題なのである。
579 ：デフォルトの名無しさん：01/10/03 01:35
せっかくOOを理解しても、協調作業でそれを生かせられないと意味ナインだよね。

OOへの理解度のギャップを埋め合わせるためのうまいやり方ないかなあ。
580 ：デフォルトの名無しさん：01/10/03 01:37
サブルーチンが欲しい時にはクラス邪魔。
Ｃ＋＋で全部クラスにする奴は逝って良し。
全部クラスにしないと使えないＯＯＰな死ね！

　　　　　｜｜｜｜｜　　 ＿＿＿＿＿＿＿＿＿＿＿＿＿_
　　　　　｜｜｜｜｜ ／＿＿＿＿＿＿＿＿＿＿＿＿＿／|
　　　　　　 ｜｜｜｜｜　 ＿＿＿＿＿＿＿＿＿＿＿　｜ ｜
　　　　　　　　｜｜｜｜｜　　　　　　　　　　　　　　　　| ｜ ｜
　　　　　　　　　　　 　｜｜ (* ﾟДﾟ)さん 投稿日：‐‐‐　|　|　｜
　　　　Λ　　 　 Λ　　 |　|氏ね！！　　　　　　　　　 　|　| 　|
　　　 /　 ＿＿/　　　 ｜｜クソ言語 が！！　　　　　　| ｜ ｜
　　 /uｕ　||||||||||||＼　｜｜クソスレ立てんな！　　　　|　|　｜
　　｜∪u　U 　　 　|　｜｜逝ってよし！！カス！！ ｜｜ ｜
　　 ＼＿ｕ＿＿_ ／　｜｜＿＿＿＿＿＿＿＿＿＿＿|　|／|
　　　／　　　　　＼　 ｜＿＿＿＿＿＿＿＿＿＿＿＿_／　｜
　　/　　　　　　　　＼｜　　　　　　　　Ａ：＝＝＝　　 　｜　／|＿_＿
　 ｜　　　　　　　　　　＼＿＿＿＿＿Ｂ：＝＝＝ ＿＿ |／　｜　　／）
　 ｜　　　　　 　　|＼　　＼①②③④⑤⑥⑦⑧⑨ー　 ／　／　／／
　 ｜　　　　　 　 ｜　＼ｕＵ　））□□□□□□□　　／ ／　 ／／
　　|　　　 　　　　　＼ 　　 ）））＿＿＿＿＿＿＿＿／／　　／／
　　|　　　 　　　　　　　＼　　―――――――――　　　／／
　　　　　　　　　　　　　　　――――――――――――
581 ：564：01/10/03 01:46
反ＯＯ派の人、ＯＯを全否定は無理があるんじゃない？
ＯＯ派の人も、ＯＯの欠点を指摘されると、相手の理解不足にすり替えるのはやめたら？
582 ：デフォルトの名無しさん：01/10/03 01:54
>>577
同意。
583 ：デフォルトの名無しさん：01/10/03 01:56
OOを使うべき場合、使うべきでない場合、を切り分けてみたらいかがかしら？
584 ：デフォルトの名無しさん：01/10/03 02:01
OO分かる人が問題切り分けを行うべきってこと？

まあ、それでもいいけど
585 ：デフォルトの名無しさん：01/10/03 02:04
>>584 は、なにか解釈がオカシイ・・
586 ：564：01/10/03 02:13
ＯＯは既存の方法論の延長線上にあるのだから、
全否定というのは無理だと思う。
反ＯＯ派の人は、まずこれを認識すべきでは？

ＯＯは方法論の最終形態ではないのだから、
欠点を全て否定するのは無理だと思う。
ＯＯ派の人は、まずこれを認識すべきでは？
587 ：デフォルトの名無しさん：01/10/03 02:16
>>586
ＯＯ派／反ＯＯ派って何？
きみ一人で言ってない？
588 ：デフォルトの名無しさん：01/10/03 02:23
他人を馬鹿にするのはタノシイのよ。日頃みんなに馬鹿にされてる人間でも、エラ
クなった気になれるでしょ。そういう人間には、何いってもムダ。
589 ：564：01/10/03 02:36
>>587
～～派というのは、正誤に関わらず、自分の気に入った結論へ、
話を持って行こうとする人のことです。
そういう人が、かなりいると感じたので。
590 ：デフォルトの名無しさん：01/10/03 02:39
>>589
つまり、あんたの事だな（ｗ
591 ：564：01/10/03 02:44
>>590
あなたの望みは、くだらない煽り合戦のようですね。
592 ：564：01/10/03 02:45
先が見えてきたので、もう寝ます。
593 ：デフォルトの名無しさん：01/10/03 02:48
>>592
両陣営とも、聞く耳なんて持ってないよ
今までのスレみれば、判りそうなもんだが
594 ：デフォルトの名無しさん：01/10/03 03:01
ＯＯなんて大したことね～よ。
高水準言語の常識、いまじゃあピンからキリまで使っている。
いまだにＯＯうんぬん言ってたら時代遅れになっちゃうぞ。
595 ：デフォルトの名無しさん：01/10/03 03:09
>>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
>そして数百ページに及ぶ契約書を読まないと使えないのね。ｗ

おまえは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の別々の機能を付加させたい場合も
考慮して設計を教えてくれるとありがたいのニャー
603 ：デフォルトの名無しさん：01/10/03 10:09
VCLはオブジェクト指向だって事でいいの？
VCLが　オブジェクト指向だという結論なら　オブジェクト指向マンセー


>>602
MyClassをMyClassChildは継承してるの？

継承してるなら MyClass+A+B+C+D をメンバーに持つクラスを作ればいいし
継承してないなら、MyClassとMyClassChildにインターフェースを被せて
インターフェイスメンバーとして持たせた新クラスを作ったら？
604 ：デフォルトの名無しさん：01/10/03 10:13
そうそう
　純粋オブジェクト志向派みたいなのが
　そういう場合は分析・設計段階が悪いみたいにのたまうんだよね >>602

プログラミング技術としては　フックで簡単に解決出来るならフックでやっつければいいと思うんだけどね
605 ：Delギコ：01/10/03 10:17
　　　 ∧∧　ﾌﾟﾊｰ
　　　(,, ﾟДﾟ) =3　＜　今日は寒いからｺｺｱ飲んだ
　　　/つ日 　　
　～（＿ __)

VCLはクラスライブラなのでオブジェ指向っす。
オブジェ指向じゃないわけがないっす。

＞MyClassをMyClassChildは継承してるの？
名前の通りしてます。

イターフェースで実装すると
ソースが分離しませんか？

ソースコピペでインターフェース実装すればいいけど
それはソース分離を引き起こすという
ジレンマがあるような気がするのですが、、、勘違いかなあ。

いい方法論ってあるのっすか？
606 ：Delギコ：01/10/03 10:22
　　　　　 ∧∧　　　／￣￣￣￣￣￣￣￣￣￣￣
　＠' ― (,,ﾟДﾟ)つ ＜　>>604　そのとーり。禿げ同ヨ
　 　し― ∪　 　　　＼＿＿＿＿＿＿＿＿＿＿＿

設計が悪いとかノタマーないで欲しい。>>純オブ志派

フック・・・安全にフックorフック解除する仕組みがVCLに欲しい
607 ：603：01/10/03 10:28
こういう処理って何ていうか忘れたんだけど
　　MyClassで使いそうな公開部を全部 MyClassExにコピーして
その実装は全部　メンバーにした MyClassを呼ぶだけにしとけば
外からは MyClassExは MyClassとそっくりに見える訳ですよね？
（ただ is as ではハネラレルけど）

これを使えばって事ですよ
608 ：Delギコ：01/10/03 10:30
　∩ ∩
　| ∪ |
　|　 ～
　|∧ ∧　　　／￣￣￣￣￣￣￣￣
　( ,,ﾟДﾟ)つ ＜　ｺﾉｻｲだからガンガン質問してやれ
　Ｕ　　　　　　＼＿＿＿＿＿＿＿＿
ﾏﾀﾁｶﾞｳ ｼﾂﾓｿ ﾃﾞﾌ、

継承継承をガンガン行なっていくと
SubClassの末端では
メソッドの山ができるはずですが
そういう所に問題はないのでしょうか？

継承すればするほど
永遠にpublicメソッドが増えていって収集つかなくなると思うのです。



デザパタ読んでいると、場合によってこういう実装するときがあるそうな。

クラス A
　メソッド　逝ってヨシ
　メソッド　似てヨシ
　メソッド　妬いてヨシ
　メソッド　句ってヨシ

クラスB
　メソッド　逝ってヨシ {(逝ってヨシの実装)　例外発生}


クラスＢから逝ってヨシメソッドを呼ぶと
呼ばれたくないから冷害を発生させるだけのメソッド。
こんなのを実装する意味があるですか？

項いう事を行なわなければならないのは
既存のＯＯ言語の問題点ではないかと思っているのですが
どう思います？
609 ：デフォルトの名無しさん：01/10/03 10:42
>>608　同意

クラスB
　メソッド　逝ってヨシ ; アボーン;

で無視されるようになっていればいいかも
（アボーンは継承先でも有効だけど復活も可能にする）

いくらなんでも例外発生を実装するのはダサい
610 ：デフォルトの名無しさん：01/10/03 10:59
>>605
MyClassにABCDメソッドを追加すれば良い。既に継承しているのなら、考える余地
がないと思うが。何が言いたいのかわからん。
611 ：デフォルトの名無しさん：01/10/03 11:01
>>610 自分のライブラリなら普通そうだけど

他人のライブラリでソース無い場合は？
612 ：デフォルトの名無しさん：01/10/03 11:09
ようは既にあるのを組み合わせる技術は多少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もﾍﾞﾝﾘ部品として使いつづける)

MｙChildClassABCDを作る時には
どうしたらいいのか？

ってｺﾄを聞きたい。

MyClassExのソースをコピペして
MyClildClassExを作るのは簡単ですがバカバカしいでしょ。
今時ソースコピペなんてさ。
615 ：Delギコ：01/10/03 12:00
>>607さん。
デコレーションでしたっけ。

　　∧∧ 　　　 ／￣￣￣￣￣￣￣￣￣￣￣
　　(,,ﾟДﾟ)　　＜ ただ、既存のクラスライブラリ(VCL)を使ってると
　ヽ/つ且~~　　＼＿無理なんですよね・・・・・・
　 （__　_）
　　　　　ﾑｽﾞｶｼｲ ﾓﾝﾀﾞｲ

ここで「設計が悪い」なんて、
VCLより使いやすいクラスライブラリを作れる自信がないなら
言わないで欲しいニャ。


>>609さん。
　　∧∧ 　　　 ／￣ですよねー。
　　(,,ﾟДﾟ)　　＜ 　継承先クラスが継承元クラスのすべての
　ヽ/つ且~~　　＼＿メソドを実装する仕組み。が
　 （__　_） 　　　　　　なぜ当然のものとして受け入れられているのか・・・ﾈｺﾆｬわからない

　　　ただ、C++だと

　　　　　　クラスB
　　　　　　　メソッド　逝ってヨシ ; アボーン;

　　　の"アボーン"をマクロで例外発生するように
　　　書いておけといわれるかもしれないけど、
　　　言語レベルでその仕組みを(当然)実装するべきなんじゃないかと。
616 ：Delギコ：01/10/03 12:05
>>613さん
　　 ∧ ∧　　／￣ ありがとございます。
（∩(,,ﾟДﾟ)　＜　がんばって考えてみます。
⊂,,＿_つつ.　＼＿

　【ｲﾝﾌﾟﾘﾒﾝﾄして作る】の意味が　イマ３つ　くらいわからないっす。
617 ：デフォルトの名無しさん：01/10/03 12:13
>>615
607じゃないけど、
>継承先クラスが継承元クラスのすべてのメソドを実装する仕組み。が
>なぜ当然のものとして受け入れられているのか・・・ﾈｺﾆｬわからない
って言っても、もし選択的に継承できたら、ポリモーフィズムができな
いんじゃないの？
618 ：613：01/10/03 12:16
>>616
ごめん、Javaです。
インプリメント＝実装
インプリメントしてつくる、は単に、インプリメントする、と言うべき
でした。
619 ：Delギコ：01/10/03 12:25
> ここで「設計が悪い」なんて、
> VCLより使いやすいクラスライブラリを作れる自信がないなら
> 言わないで欲しいニャ。

ﾁﾄｲｲｽｷﾞﾀ
　　 ∧ ∧　　／￣
（∩(,,ﾟДﾟ)　＜　「設計が悪い」っていう言葉で
⊂,,＿_つつ.　＼＿思考停止しないで欲しいってｺﾄです。

どうやって設計しておくべきか。
どうやって改善するべきかを、考えてくださると、サイコーっす。

みなさんが知っているOO言語や
既存のクラスライブラリなどで
こういうことを解決されているものがあるのでしたら、

　　　　　　　　 ∧ ∧
　　　　　　　　 (,,ﾟДﾟ)　教えてチョーダイ　にゃー
　　　　　　　　/　つつ
　　　　　　 ⊂　　ﾉ
　　　　　　　／（/″


LISPで実行時にソースを読ませるｺﾄができるなら
簡単かもしれない...でもLISPは全く氏らん
620 ：Delギコ：01/10/03 12:26
　　　　　　　　 ∧ ∧ 　　>>617
　　　　　　　　 (ﾟДﾟ,,)　だって例外発生するだけならメソッドがないのといっしょじゃーん
　　　　　　　 ⊂ ⊂)
　　　　　　 ⊂　　ﾉ 　　そのメソドについてはポリモする必要がない場合だと
　　　　　　　／（/″ 　考えておくんなまし。(どこの方言？)
621 ：デフォルトの名無しさん：01/10/03 12:39
>>Delギコ
C++/Java/ObjectPascal といった言語に拘らなければ方法はあるけどねぇ。
こういう言語で書かれた既存の資産があるという状況じゃ難しいわな。
622 ：610：01/10/03 12:51
>>611
> 他人のライブラリでソース無い場合は？

だったらMyClassなんて名前つけるなよ。付き合いきれん。
623 ：Delギコ：01/10/03 13:01
＞C++/Java/ObjectPascal といった言語に拘らなければ方法はあるけどねぇ。

　　　　　　　それでもYOいから教えて教えて>>621
　　　　　　　　 ∧ ∧
　　　　　　　　 (,,ﾟДﾟ)　教えてくんないとダダこねるぞ(ｳｿ)
　　　　　　　　/　つつ
　　　　　　 ⊂　　ﾉ 　　smalltalkやO-Cなどでは実現できるのかしら？
　　　　　　　／（/″

　∧_∧ <<しーちゃん
　（*ﾟーﾟ）
C#でもいいです。

JavaかDelPascalかC#が何らかそういう進化をするとうれしい。
(C++の進化には気体しませんが)
624 ：Delギコ：01/10/03 13:04
　　　　　 ∧∧　　　／>>610
　＠' ― (,,ﾟДﾟ)つ ＜　　理解できないのを付き合いきれん
　 　し― ∪　 　　　＼　というのは、どうかと・・・
　611はｵﾚ ﾄ ﾁｶﾞｳｼ
625 ：617：01/10/03 13:10
>>620
前提として、なぜ子クラスで、親クラスにあるメソッドをなくしたいのか、という
点だけど、呼ばれるとまずいから、だよね。
であれば、呼ばれたら例外を投げるということで問題ないと思うけど。
コンパイル時にそれをチェックしたいということなら、javaの場合は、その
メソッド以外のpublicメソッドだけを含んだinterfaceを定義して、子クラス
はそれをインプリメントして、以後、子クラスのオブジェクトはそのinterface
の型として扱えばいいと思うけどね。
Delphiではどうやるのかな？
626 ：ななーし：01/10/03 13:16
>>Delギコ
デコレータパターソでそういうのはやるのでは？
ガイシュツか。

じゃ別の方法，
１）a,b,c,dの機能を実装したクラスA,B,C,Dをそれぞれ作る。
２）クラスA,B,C,Dのオブジェクトをメンバーに持ち委譲するための
メソッドを持つクラスmixA,mixB,mixC,mixDを作る。
３）MyClassとmixA～mixDを必要なだけ多重継承した新しいクラスMyClassExをつくる。
ってのは？
え？多重継承出来ないって？
627 ：デフォルトの名無しさん：01/10/03 13:31
多重継承の代わりにインターフェースでやればいいでしょ

というか　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さん
そうですそうです。そうできればいいです。

＞多重継承の代わりにインターフェースでやればいいでしょ
でもｲﾝﾀﾌｪｽは毎度毎度同じ実装しなきゃいけない気が…
ｿｰｽｺﾋﾟﾍﾟ???
629 ：627：01/10/03 13:46
ソースコピペって？　同じメソッド名　プロパティ名にする以上になにか必要なの？
630 ：626：01/10/03 13:53
>>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 には呼び出されたメソッドの名前、
　　　　// 呼び出しの引数、期待される戻り値の型などが含まれる。
　　}
} ;

これとリフレクションを組み合わせれば、委譲の実装がすげー楽になるような。
あ、もちろん、そういう風な言語が作れないかな、って話ね。
632 ：627：01/10/03 14:10
MyClassとかのメソッド置換（継承）が必要なければ

type
　IMyClassCtl = interface (IUnknown)
　　function Execute: Boolean;
　　// とか MyClassの制御に 必要な全部のメソッドを定義
　end;

後は
TMyClass = class(TOpenDialog,IMyClassCtl) end;
TMyChildClass = class(TSaveDialog,IMyClassCtl) end;
みたいに１行書くだけ

A,B,C,Dのメンバーに
var My: IMyClassCtl;
を持たせて
My:=TMyClass.Create(nil);
　とかでメンバー設定すればいいわけで

A,B,C,DがMyClassを使う為にMyClass側のメソッドの置換（継承）が必要なら、
継承が必要な部分をイベントにして
A,B,C,Dの全てが使えるにようにしてやればいいんじゃないの？
633 ：627：01/10/03 14:16
たとえば　A,B,Cの３つが Windowメッセージに割り込む必要があるのなら
OnMessageA/OnMessageB/OnMessageC と３つのプロパティを用意してやるって事ね

ただ、TMyClassを設計時に使いたいとか言い出したらメンドクサイ事になるけど
634 ：Delギコ：01/10/03 15:04
　∧ ∧　 　 ／￣￣￣￣￣￣￣
　(,,ﾟДﾟ)　＜　>>632-633すばらC.
　 | つつヾ 　＼＿＿＿＿＿＿＿
～| 　 | ﾊﾟﾁﾊﾟﾁ
　 ∪∪ 　ｱﾘｶﾞﾄｰ

実装しないとわからない所が出てきたのでｶﾞﾝﾊﾞﾃみます。
635 ：1：01/10/03 15:10
http://www5.justnet.ne.jp/~ttp/
636 ：デフォルトの名無しさん：01/10/03 15:18
>>619
>どうやって設計しておくべきか。
>どうやって改善するべきかを、考えてくださると、サイコーっす。

「この場合はこうだ」という明確な答えはない。
でも改善法なら教えられるぞ。

まず一つが状態遷移。継承がどうこう言う前に、オブジェクトがどのような状態をとるのか、
しっかり把握しないといけない。オブジェクトには状態がある。
内外から発生するイベントによって状態が変化するというモデルがある。
それをふまえた上でクラスを設計できるようになってないでしょ？
これについては憂鬱本が詳しいので参照して欲しい。

次に勉強すべきはデザインパターン。
今回のギコの例で言えば、Decorator、Facade、Mediator、Strategyなどのパターンが
応用できると思われるし、他のパターンも流用できるかもしれない。
どのパターンが適切かは状況にもよるし、設計者の好みにも依存するから、
ギコ自身が選択しなければならない。
とにかく新しいパターンを生み出す前に、過去のパターンをよく研究した方がいい。

そしてUML。設計の善し悪しを判断する最高の方法は現時点ではUMLを使うことだと思う。
目に見える形になることで頭の中が整理されるし、
オブジェクト同士の関連線を減らすという機械的な作業で設計を改善できるところがいい。
さらに他人でもクラスの設計が容易に把握できるようになり、
一人の考えではなく、大勢の意見を採り入れた設計ができるようになる。
言い換えれば、一人でコードをこねくり回しても限界があるということ。
637 ：デフォルトの名無しさん：01/10/03 15:41
>>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の設計時までを想定しているから
一人で落とし穴に落ちているだけかな…
639 ：デフォルトの名無しさん：01/10/03 17:59
Delギコって説明下手だったんだなぁ。
640 ：亀レススマソ：01/10/03 19:12
>>603
Adapterパターン？
641 ：617：01/10/03 20:34
>>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の限界ってことかな。
643 ：642：01/10/03 22:02
書いた後で気づいたけど、これは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パターンを使って誤魔化すしかないか。
多重継承できないんだからしょうがないよ。
644 ：デフォルトの名無しさん：01/10/03 23:40
(ﾜﾗﾀ
Delｳｻﾞ&ﾀﾞｻﾞ
せいぜい低レベルＯＯＰやってろ　お前にはその程度がお似合いだよ
645 ：デフォルトの名無しさん：01/10/04 01:01
まあ、あれだ。
何も継承してない「サブルーチン・ライブラリクラス」作って
何もかも詰め込んで委譲で実装。終了だな。
646 ：Delギコ：01/10/04 10:40
　∩ ∩
　| ∪ | 　ｺﾝﾊﾞﾝﾊ ｱﾒ ﾀﾞｯﾃヨ
　|　 ～
　| ∧ ∧　　／￣￣￣￣￣￣￣￣
　|( ,,ﾟДﾟ) ＜　おはようSUN
　Ｕ　Ｕ　　　＼＿＿＿＿＿＿＿＿

>>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ｬ偶黐鉗ゆ2g5ｩ・ｭ>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私槁ﾛPc�Zlﾚﾈｸ・\
ﾛｫL・Yﾂ�ﾕ・・ｭ・ﾉ5ｪﾆfｾ/ｪ %#K煙mxjJｵO<ｽ*・78=ｭｹｧｸﾆt杠<m智]ｱ`:ﾏ澵ｹ｡*ﾊ・ <
でd
+1ｸﾞｱVJﾀ',ｾBﾅJB\ｪ勧f・･ﾏﾋN%・Vrｹﾚe・Uｻｸ・P!Rｰ性ｧ]uﾕｷｳ云GｧS�*g: ・^H4ｿ ｲ
ｳ隆e\m純9Rﾒﾃ@・{鏸bi ・・~ﾔH垈ｽmｪﾌ|Kｴｄ・~QｯﾆﾍN・呼.nWｵ罔NﾞNﾗﾃﾓi&問
妺破ﾗ隨Nc・tﾅАJ・'ﾈkoﾋｼi儘∵ﾐx7ﾕFｾ蠕ｯ・sｽk^ﾗBﾖ?・~㊦ﾛwﾉ0Q%ﾙ6o假Afi
ｵｳぐ鏞;｡ＡﾉG6衞｡Yz朗鋠ﾏlBﾘ*)｣E・ｴｧｶ 達ﾕ髴神�ｨ%?,ﾛ鋤De
648 ： ：01/10/04 11:34
OOなプロジェクトで成功してるものって腐るほどありますよね。
KDE, WindowsはNT3.51から, BeOS（これはある意味失敗か）
qmailもOOな設計ゆえあのような形態になったそうです。
649 ：デフォルトの名無しさん：01/10/04 11:42
今、OOじゃないプロジェクトって、元COBOLERのJava開発とブビ坊しかないＹＯ！
650 ：デフォルトの名無しさん：01/10/04 13:08
>>649
HSPを忘れるな
プロジェクトと呼べる物をやってるやつがいるかどうかはあやしいが
651 ：デフォルトの名無しさん：01/10/04 16:49
忘れる前に、知らなかったＹＯ！
652 ：デフォルトの名無しさん：01/10/04 20:30
>>646

>>知ってると思うけど、VCLはCompositeパターンだぞ。
>え？どのあたりがですか？

TComponentがだよ…
それと、これを継承した全てのクラス。

>開発者にはあまり見えなくなっているのですかね。

丸見えだと思うが…
本当にVCLを使ったことあるの？
653 ：Delギコ：01/10/04 22:10
　　　,,'''~''~'∧,,∧ 　>>652
　～′,,,;;,, (,゜Д゜)
　　UU"　" U U
　　ｱｱ ｶﾙｼｳﾑﾌﾞｿｸ

ちゃんと説明したらどうヨ？
　＞Delギコ相談室スレ全部よんどけ。

・Compositeパターン
　容器と中身を同一視して再帰的構造を作る

って、TComponentのどこに再帰構造があるの？

　　 ∧∧ 　　　 ／￣￣￣￣￣￣￣￣￣￣￣
　　 (,,ﾟДﾟ)　　＜ 単なるあおりに反応してしまっただけかも。
　＠/つ且~~　　＼＿＿＿＿＿＿＿＿＿＿＿
　　（__　_） ｵﾚ ｶﾞｷ ﾀﾞﾅｰ
654 ：デフォルトの名無しさん：01/10/04 22:15
デザパタ本が糞なのか。読み手がアフォなのか。
たぶん後者だろう。
655 ：デフォルトの名無しさん：01/10/04 22:15
>>653
TComponent.Components
656 ：Delギコ：01/10/04 22:22
　 　|
電　| ｶｹﾞﾃﾞｺｿｺｿ ｲｯﾃﾔﾙ
　 　|∧ ∧
柱　|,,ﾟДﾟ)　＜ナナナ・・・るほど。
　　⊂　|
　 　| 　|　シカシ、普段ComponentsなんてFormでしか
　 　|∪ 　つかーねだろ。むしろControlsプロパの方が･･･
, '　,　;　'　;
ﾐｸﾞﾙｼｲｲｲﾜｹﾀﾞ
657 ：655：01/10/04 22:25
いや、きちんと説明したほうがいいか。
すぐわかるかと思ったんだけど、どうやら真性みたいだからな。

いいか、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を継承しているからなんだよ。

これでわかった？
それともサンプルプログラムでも書かないとわからないかい？
658 ：デフォルトの名無しさん：01/10/04 22:28
>>656
おお、前後してしまった。
わかってくれたようでなにより。

VCLはコンポーネントのリンクを維持するためにComponentsプロパティをフル活用しているよ。
Visual "Component" Library という名前はCompositeパターンに由来しているくらいだからね。
659 ：デフォルトの名無しさん：01/10/04 22:32
古勝用
660 ：デフォルトの名無しさん：01/10/05 01:17
http://piza.2ch.net/log2/infosys/kako/957/957179163.html
関連スレ
661 ：デフォルトの名無しさん：01/10/05 01:28
／￣￣￣￣￣￣￣￣￣￣￣￣￣
|　ありがとうございます。首相並に感動しました。
|　丁寧な解説でより理解できました。
|　ご親切な方ですね。
＼＿＿＿ 　＿＿＿＿＿＿＿＿＿
　　　　　　∨
♪　　 ∧ ∧　♪
　　　　(,,ﾟДﾟ).　　♪
　　 　 |つ[|lllll］).
　　 ～|　　|
　　　　Ｕ Ｕ 　ｳｰﾚｼ

真性とかイワンで～

ﾃﾞｻﾞﾊﾟﾀしらないでいたら
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
デザパタをありがたがっているような奴はクズ。
あれぐらいモデリングをしっかりすれば自分で考え出せるだろう。
デザパタの意義は、カタログにしたその取り組みにあるだけ。
666 ：デフォルトの名無しさん：01/10/05 06:06
デザパタをありがたがっているような奴はクズ。
あれぐらいモデリングをしっかりすれば自分で考え出せるだろう。
デザパタの意義は、カタログにしたその取り組みにあるだけ。
667 ：デフォルトの名無しさん：01/10/05 06:57
おいおい。あれを使える場面で当たり前のように考え出して使う奴は
天才だろ。時々考え出してしまうこともあるかもしれないが、
多くの状況では知ってなきゃ使わない類のもんだ。
初めて考え付くのが偉大なのに、知った後から「こんなもん簡単だ」
なんて思うのは当たり前。そんなこともわからないのは馬鹿の証拠。
668 ：Delギコ：01/10/05 09:53
>>デザパタをありがたがっているような奴はクズ。
>おいおい。あれを使える場面で当たり前のように考え出して使う奴は
>天才だろ。時々考え出してしまうこともあるかもしれないが、

　　 ∧ ∧　　　／￣
（∩(,,ﾟДﾟ)　＜　　よかった、ﾃﾞｻﾞﾊﾟ初心者だから
⊂,,＿_つつ.　　＼　変な意見を鵜呑みにするﾄｺだったよ。

今朝読んだFlyweightﾊﾟﾀｰﾝは自分で実装してたなあ。

＞デザパタ自体が有名になってまだ数年しかたってない)、
ﾌﾟﾛｸﾞﾗﾈｺ-になてからまだ数年しかたってないんですが…

>ComponentsがTComponent型だと気付いた瞬間に、「じゃあ再帰的に突っ込めるんだろうな？」と
>突っ込みをいれたくなる(そしてテストコードを書いてみる)のは、
>プログラマならデフォだろう。
デ・デフォなんですか？

> 抽象的なパターンを考えることと、
> 具体的なDelのComponentsを考えることとは、
> 似ているようで、微妙に違う。
ﾈｺにはまだまだだいぶ違うです

>もちろん両方を考えて、実は同じことを言っていると気付くことは
まだ、なかなか...その境地に達してないつーかニャー
669 ：デフォルトの名無しさん：01/10/05 18:42
>>667
表現はともかくとして>>666に私は賛成の立場です。
「利用する」より「考える」ことの方が重要と思います。デザパタを知る
ことでとても大切な事を考える事が疎かになるならばその先の成長は見込
めないと思います。利用する前になぜそれが必要なのかをじっくりと考え
られればまだ救われますが、それができる人もまた限りられたひとだろう
と思います。天才と簡単に言われていますが、天才というよりも、良い
デザインや実装をしようということに拘ったからこそ、デザパタが作られたので
あって天才だったから簡単に作り出したというわけではないという所が
肝かと思います。またデザパタを知ったからといって、それで簡単あるいは
優れた設計や実装ができる訳ではないと思います。それを知ってもさらに考える
事が必要ですから、その時に再度「考える」という事が問われます。そして
それを突き詰めて考え解決できるならば、デザパタも作り出せるだけの力が
付いていると思われますので、結局はデザパタを知ることよりも「考える力」
を付けることを重視した方が、先に繋がるでしょう。
670 ：デフォルトの名無しさん：01/10/05 18:48
>>669
急がば回れですね。う～ん。
確かにそういうことって多いよな～。学校教育ってもろそういう所
あるものね。問題解決能力を高める事が重要ってことね。
内容なくて、スマソ。
671 ：デフォルトの名無しさん：01/10/05 18:50
>>669 デザパタを通して,考える力を養えればよいわけですよね.
どういう関わりをすればそうなるのだろう.
672 ：デフォルトの名無しさん：01/10/05 19:01
>>669
なんか違くない？

>天才というよりも、良い
>デザインや実装をしようということに拘ったからこそ、デザパタが作られたので
>あって天才だったから簡単に作り出したというわけではないという所が
>肝かと思います。

>>667は、天才がデザインパターンを作ったとは言ってないよね。
いちいちデザパタを発明できるような天才はいないと言っているのでは。

デザインパターンがデザインを考える機会を削ぐという発想には反対。
アルゴリズムを学んだ人が新しいアルゴリズムを生み出せなくなったかというと、
そうでもないでしょう。むしろアルゴリズムに強い人は、
過去のアルゴリズムをよく知っている。
高速フーリエを知らない人がMP3を生み出せるとは思えないね。

アルゴリズムを教えると、アルゴリズムを考える力がなくなるから、
大学でアルゴリズムを教えない方がいいの？
それっておかしいよね。
アルゴリズムもデザインパターンも、基礎教育として教えるべきだと思う。
それで思考停止してしまう一万人は無視して、より深い指向ができる百万人を育てようよ。
673 ：デフォルトの名無しさん：01/10/05 19:28
>> 672

|アルゴリズムもデザインパターンも、基礎教育として教えるべきだと思う。

それはなぜですか？
674 ：デフォルトの名無しさん：01/10/05 19:34
というか>>666の逝ってることと
>>669の言ってることって全然違うだろ。

666みたいのを見ると、漫画初めて物語で観た
「コロンブスの卵」のエピソードを思い出す。
675 ：22：01/10/05 19:44
それは
http://www.max.hi-ho.ne.jp/%7Ehttp/
676 ：デフォルトの名無しさん：01/10/05 20:36
>>673
「情報工学を学ぶ学生の基礎教育として」という意味でした。
言葉足らずですいません。
677 ：デフォルトの名無しさん：01/10/05 20:51
>>676　僕もどちらかというとデザパタに縛られている人には危惧を
感じます。

情報工学を学んだとしても、優秀でない人はあまりその恩恵は受けて
いないようにおもわれます。ここでの優秀というのは問題を突き詰めて考え
られるかどうかという程度です。
逆に、情報工学を学んでいなくても、問題を突き詰めて考える人は
どんどん伸びるように思われますが、どうでしょう？
もちろん学者になろうというのであれば、そういった工学を学び
研究していくという道もあろうかと思いますが、現在の情報工学
は現場ではそれほど生きていないように感じます。
一般的によくみるのは、流行の技術を追い掛け、ちょっと人より
知っていることに優越感を感じそれに満足しているというパター
ンです。そして、そういう人に限ってプロジェクトにあれこれと
文脈を無視した意見をしプロジェクトを路頭に迷わせ、だめな
やつらだと愚痴をいってまた自己満足。そんな人、多くないでしょうか？
デザパタが出てくる前にもＯＯですぐれたシステムは作られていた
訳ですから必須項目とは思えません。
工学としてならう枯れたアルゴリズムとデザパタを同列に扱うとおっしゃるとおり、知っていた
方がよいという考えになると思いますが、そういったアルゴリズムは
帰納的なもので、
設計というのはそのつど問題に向き合い解決していくものではありますが
答えが一つとは限らない演繹的なものなので、同列に扱うのはどうかと
思います。
678 ：デフォルトの名無しさん：01/10/05 20:54
>>666の馬鹿発言が誤解されて、偉く立派な意見に様変わりしてるな。(藁
679 ：Delギコ：01/10/05 20:59
　∧ ∧　　　 ／￣￣￣￣￣￣￣￣￣
　(,,ﾟДﾟ)　　＜　　デザパタは設計を考え事を加速させる
　 | つ[|lllll］). ＼＿＿＿＿＿＿＿＿＿
～| 　 |
　 ∪∪
ｸﾗｽﾗｲﾌﾞﾗﾘを使っていただけで、なんでも作れると
思ってしまっていたけど
デザパタで深遠なるｵﾌﾞｼﾞｪ志向の扉を開けれた気がするよ。

＞デザインパターンがデザインを考える機会を削ぐという発想には反対。
そうそう。
機械を削ぐとはﾑｼﾛ逆。
ﾃﾞｻﾞｲﾝをより深く考えてﾃﾞｻﾞﾊﾟﾀを組み合わせたり
自分で新しいものを作る糧になるのでは？

>>672氏イイ！
でも、基礎教育で教えても
ﾌﾟﾛｸﾞﾗﾑが余り組めない人に役に立つかどうか…
680 ：デフォルトの名無しさん：01/10/05 21:01
>677
あんま論理的思考が得意ではなさそうだな。
大学も出てなさそうだな。
SEとコミュニケーションがうまく取れてなさそうだな。
ストレス溜まってそうだな。
681 ：デフォルトの名無しさん：01/10/05 21:02
デザパタに出てくるパターンそのものは大したことないだろう。
大抵のプログラマなら自分で同様の物を考え出して
過去に実際に使ってみたことがあるはず。
ただ、それをパターンという形に括りだして、分類して、
名前を付けて、ああいうカタログ本にまとめたことが偉い。
ノウハウは整理体系化されることでテクノロジーになる、そういうもんじゃない？
682 ：Delギコ：01/10/05 21:03
>>677氏
ﾃﾞｻﾞﾊﾟﾀに縛られるっていうのは
いっつも、forループも使わずにｲﾃﾚﾀしちゃう人っていう事でしょうか？
それはそれで確かに迷惑かも。

そもそも、ｲﾃﾚﾀだけは役に立たないと感じたけど。


> 一般的によくみるのは、流行の技術を追い掛け、ちょっと人より
> 知っていることに優越感を感じそれに満足しているというパター
> ンです。
　　　 　 　 ∧ ∧ 　／￣￣￣￣￣￣￣￣￣￣￣￣
～′￣￣(；ﾟДﾟ)＜　ｶﾞﾋﾞｰﾝ。折れかも。
　 UU￣￣ U U　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿

だけど、周りの人がちょっと(いや、かなり)知らないから
半年かかっても出来ない事を
ちょっと知ってて3日で出来たりしたらうれしいし
役に立つと思うんだけど…

例えばタブブラウザ作りたいって時に
ﾌﾞﾗｳｻﾞを1から作っちゃう人ばかりの中に
「IEのＡｃｔｉｖｅＸ使えばいいよ」
って言えるのって、だめ？

>>680氏
"だな"、多そうだな
683 ：デフォルトの名無しさん：01/10/05 21:07
>いっつも、forループも使わずにｲﾃﾚﾀしちゃう人っていう事でしょうか？
最近はfor使わずにイテレータ、foreachなんかを文法に組み込むのが流行りだね。
684 ：デフォルトの名無しさん：01/10/05 21:11
デザパタもいいけど、リファクタリングもイイ！
ＯＯマンセー
685 ：Delギコ：01/10/05 21:28
　∧ ∧ 　そこでﾘﾌｧｸﾀがでてくるとは
　(；ﾟДﾟ) 　おぬし、通よのぉ
　(|　　|つ
～|　　|
　 ∪∪

そうそう。ｲﾃﾚﾀを教科書どおりにバカ正直に実装されていたら
XPﾏﾝｾｰな折れとしては、ﾃﾞｻﾞﾊﾟﾀを知らなきゃ
ﾘﾌｧｸﾀﾘﾝｸﾞでシンプルなものを目指して
ブチ壊してたかもしれない。

今でもﾃﾞｻﾞﾊﾟﾀを読みこなせなければ(読み逃してしまったら)
ｲﾃﾚﾀはつぶしてしまうかもなあ。

要所要所でﾃﾞｻﾞｲﾝを考えたり、よりシンプルにしたり
その辺のバランス感覚って重要かもと思う。

＞最近はfor使わずにイテレータ、foreachなんかを文法に組み込むのが流行りだね。
foreach構文はいいですね。括弧ヨサゲ。ｸｰﾙですわ。
Delにも搭載されないかしら。
686 ：672：01/10/05 21:40
>>677
>一般的によくみるのは、流行の技術を追い掛け、ちょっと人より
>知っていることに優越感を感じそれに満足しているというパター
>ンです。そして、そういう人に限ってプロジェクトにあれこれと
>文脈を無視した意見をしプロジェクトを路頭に迷わせ、だめな
>やつらだと愚痴をいってまた自己満足。そんな人、多くないでしょうか？

これについて一言あります。

私は数年前に転職しました。
前の会社はOOに積極的で、デザインパターンもとりいれ、
社内で○○パターンと言えば誰でもわかる状態でした。
多くのプログラムがデザインパターンやＯＯを活用して作られていましたが、
プロジェクトが路頭に迷ったりすることはなく、
開発効率が高くて開発コストは非常に安く、
不具合発生件数もかなり少なかったのです（この会社がＯＯに走る前の状態と比較して）。
小さな会社でしたが、品質が高いとよく誉められたものです。

今は別の会社に転職しています。
ここではオブジェクト指向は誰も知りません。
デザインパターンと言ってもさっぱりです。
開発効率も悪いですし、不具合発生件数は非常に高く、
潜在的な不具合は表面化している数値よりはるかに高いと思います。
何度かオブジェクト指向を取り入れさせようと頑張ってきましたが、
自分が頑張ってもしょうがないことを悟っただけでした。
大きな会社ですが、品質が低いとよく叱責されます。

今の会社で、あなたの言う「自己満足クン」になっています。
はたして私は間違っているのでしょうか？
ただ本を読んで得た知識だけで言っているのならともかく、
私は前の会社で、それが役立つことを、身をもって知っているのです。
情報だけの頭でっかちではなく、実際に経験して効果をあげた実績があるのです。
画期的な効果をあげた経験を、理解されないという下らない理由で捨てるのですか？

オブジェクト指向もデザインパターンも、それほど難しい理論ではなく、
きちんと学習すれば必ず身につくと思います。
学習が思ったように進まないのは効果が疑われているからです。
疑いが学習の妨げになっています。
しかし自分の経験では効果があります。
そもそもオブジェクト指向は演繹ではなく帰納なのです。
687 ：デフォルトの名無しさん：01/10/05 21:53
>>672

いい経験も悪い経験もしているようですね。
会社の雰囲気って大きいですよね。一所懸命やってもそれが生かすことができない
ようじゃ自己満足クンになるしかないですね。でもがんばってくださいね。

|そもそもオブジェクト指向は演繹ではなく帰納なのです。

言い切るだけでなくて、この説明をしてください。
688 ：デフォルトの名無しさん：01/10/05 21:55
デザパタって
初心者にとっては過去のアイディアであって、
上級者にとっては、テクニカルタームなわけです
デザパタのおかげで、コードにイテレーターって書いてあれば
読むの楽ですよね
>最近はfor使わずにイテレータ、foreachなんかを文法に組み込むのが流行りだね
そうなんですか・・・
それはあまり好ましくないですね
世間一般で行われていることはレベルが低いといことでしょう
689 ：デフォルトの名無しさん：01/10/05 21:55
>>686

めずらしい転職のパターンだな。
前の会社のなにが不満だったの?
690 ：デフォルトの名無しさん：01/10/05 21:58
＞＞６８６

最初にいた会社とその後変わった会社では、作っているシステムは
同じだったんですか？

デザインパターンを使いＯＯを使うと品質が高くなるというその
理由は、なんですか？
そういう経験をしたという事を力をいれて説明されてもそうですか
しか意見をいえません。どういったことが影響して品質が高くなる
のかを述べてください。
どういう分析をされるかわかりませんが、ＯＯをしなくてもそれ以前
も現在の品質が高いものは作られたわけで、私にはＯＯをすれば単純
に品質が高まるという主旨のご意見には同意しかねます。
691 ：デフォルトの名無しさん：01/10/05 22:04
>690
2点質問。
・OOPを理解してますか？実際の開発に適用したことは？
・あたなが最も効率的に開発を行える言語・手法・パラダイムは？
692 ：デフォルトの名無しさん：01/10/05 22:04
>>690
OOじゃないプログラムって、いったいなに作ってんだ？
OO＆デザインパターンを使ったほうが、
設計フェーズで楽できるし、いいものができるのって当たり前だと思うけど
JAVAのライブラリー（デザパタならSWING)とか使ったことないのか？
普通のセンスなら、OOやデザパタの良さが理解できると思うが
693 ：デフォルトの名無しさん：01/10/05 22:04
>>690
そうね。
686の話は、
ＯＯしているかとかデザパタを知っているかとは、
違った所に、問題がありそうですね。そういう経験を単純に関係付け
するような奴がまともにＯＯをやっていたとは思えないのだが。（藁
694 ：デフォルトの名無しさん：01/10/05 22:05
ＯＯを取り入れれば、多くの場合生産性が上がるのはもはや常識だと思うが？
それなのに、せっかくＯＯを使ってる奴を自己満足扱いにして邪魔者扱いに
するのはいかがなものか。ＯＯ使わなくちゃいけないとまではいかなくても、
ＯＯ使うのは別に悪いわけでは無いじゃん。
明らかに周りが悪いだろ。
695 ：デフォルトの名無しさん：01/10/05 22:06
>>692

RubyにしてもC++にしても、ＯＯで設計実装されてないじゃない。
何いってんの。UNIXだってLinuxだって、そうだよ。
上げだしたら切りがない。
ＯＯしないと品質が上がらないなんて思っているようじゃ厨房ですね。（藁
696 ：デフォルトの名無しさん：01/10/05 22:09
>>694

生産性があがった所もあれば下がったところもあるのが常識です。
ＯＯをしなくても生産性が高い所もあったという事実もしって
おいた方がよいでしょう。
697 ：デフォルトの名無しさん：01/10/05 22:12
>695-696
お前らも論理に不自由そうだな(藁
698 ：デフォルトの名無しさん：01/10/05 22:12
なんかこのスレすげえいら立ちを感じる。
ＯＯしても品質が上がらない時があるとか、ＯＯをしなくても
素晴らしい品質のものを作ることが出来るとか、ＯＯに頼りすぎ
は良くないという話は認めるとするよ。
でも、それがなんでＯＯ知ってるのは自己満足の悪であると
いう話に発展するの？

むしろＯＯは多くの場合武器になると言うのに。
699 ：デフォルトの名無しさん：01/10/05 22:16
>>695
>ＯＯしないと品質が上がらないなんて
はて？
OOすると品質が上がると思うけど
>何いってんの。UNIXだってLinuxだって、そうだよ
一応、あれがC流のOOなんですが・・・
RUBYとC++はOOしてもしなくても大して変わらないのは
単純だから
コンパイラも作ったことないのか
ソース見たことないから、OOでコーディングしてるかは知らない
ただ､設計フェーズではOOです
700 ：デフォルトの名無しさん：01/10/05 22:17
>最近はfor使わずにイテレータ、foreachなんかを文法に組み込むのが流行りだね

ハァ？
701 ：デフォルトの名無しさん：01/10/05 22:17
>>696

COBOLなんて、ドメインによってはめちゃくて生産性も品質も高く
開発できますからね。生産性なんて部品的に使えるものが多ければ
高まりますからね。ＯＯかとかそうでないかというだけで、単純には
判断できないものだと思います。
どこに使うか、何に使うか、誰がつかうか、どのように使うかに
よって変わるものですね。

ＯＯをすればそうなるはずという机上論はわかるのですが、それが
実際に達成されるかどうかは別問題。そして、常識かどうかという
のを机上の話でしているのか、事例の話でしるのかを明確にして話
をしないといけないでしょうね。
702 ：デフォルトの名無しさん：01/10/05 22:19
おいおい、日本はそんなとこじゃないだろ。
OO叫んで袋叩きにあうのが、
ほとんどだよ。9割ぐらいそうだろ。
703 ：デフォルトの名無しさん：01/10/05 22:19
ちなみに、OOを理解してると勘違いしている
OOプログラマー多いです
とくにJAVAでは顕著です
OOの敷居は高いので、あまり見かけないと思うのですが
704 ：デフォルトの名無しさん：01/10/05 22:20
>>701 ,　>>702
賛成！
705 ：デフォルトの名無しさん：01/10/05 22:21
日本のプログラマは度窮鼠だからな。
706 ：デフォルトの名無しさん：01/10/05 22:23
>>699

|ソース見たことないから、OOでコーディングしてるかは知らない
|ただ､設計フェーズではOOです

おまえがRuby作ったわけじゃないのになんでわかるんだ。
ソースもみてもないのに。
ばーか。おまえみたいなのが、ＯＯ普及のじゃまをするんだよ。
707 ：デフォルトの名無しさん：01/10/05 22:24
確かに、COBOLで作るような簡単なプログラムでは
OO使うまでもないね

確かに､何人かで作る時に
馬鹿が混じるとOOどころじゃないね
有能なプログラマーだけが使えばいいと思う
そういうわけで､月収が１００万を超えてる場合に限り
OOを使っております
それでも馬鹿は混ざるんですが
708 ：デフォルトの名無しさん：01/10/05 22:24
ＯＯを理解してると勘違いするプログラマの方が
オブジェクト指向に見向きもしない向上心の無い
奴よりマシ。
経験をつめばいずれ気づくし。
709 ：デフォルトの名無しさん：01/10/05 22:28
>オブジェクト指向に見向きもしない向上心の無い奴
普通のリーマンコーダなんてこんなもんでしょ。
だって、今までの経験でこれからも惰性で開発できるんだから
わざわざ自腹で本何冊も買って勉強するなんてアホらしいよ。
710 ：デフォルトの名無しさん：01/10/05 22:28
リファクタリングだけは、ドキュソが混じってもある程度使える。
711 ：デフォルトの名無しさん：01/10/05 22:29
>>709
だから、普通のそういう奴はドキュソであり、最低ランクだな。
712 ：686：01/10/05 22:29
>>690

>デザインパターンを使いＯＯを使うと品質が高くなるというその
>理由は、なんですか？

私にはこれを演繹的に筋道立てて説明できません。

どういう経験を指して品質が高いと言っているのか、
ということであれば、前の会社がDelphiで開発しているような感覚であるのに対し、
今の会社ではWindows 16APIを直接操作しているような感覚です。

でもこの差を説明しようとすると、
どうしてオブジェクト指向が良いのかを証明しなくてはいけないかも？
713 ：デフォルトの名無しさん：01/10/05 22:30
>おまえがRuby作ったわけじゃないのになんでわかるんだ
コンパイラの本読んでみなよ
理由がわかるよ
って､ここ大学生少ないの？
714 ：デフォルトの名無しさん：01/10/05 22:32

>>708

大事なのは、顧客にとって質のあるものを作ることですね。
そう考えると、>>707 で書かれているような悪い環境では
ＯＯをすることよりも他の事に力をいれようと思う人もいる
訳です。現実主義の人、理想主義の人、保守主義の人など色々
といて多様です。どれがいい悪いというよりも、そういった人
達がいることを認め、とことん話をするしかないと思います。
場合によっては、ＯＯよりも構造化設計やCOBOLがいい場合も
あるのですから、何を使うのが顧客のためかという所を大切
にして話し合いをすることが何より大切と思います。
715 ：デフォルトの名無しさん：01/10/05 22:34
OO+デザパタは外国のオープンソースで導入出来ないんだから、
日本としては、いいチャンスなんだけどなぁ。
だれか仕切ってやればいいのに。
716 ：デフォルトの名無しさん：01/10/05 22:35
＞＞７１３
ムキになるな。お前がたいしたことないのはすでにわかってるんだから。
717 ：デフォルトの名無しさん：01/10/05 22:35
なんかOOPとアセンブラスレで同じ議論が進行してるのは気のせい？
718 ：デフォルトの名無しさん：01/10/05 22:39
>>680
お前の文章は、まったく論理的でないことを理解していっているのか？
本当に馬鹿だな。
719 ：713：01/10/05 22:39
たった３行でわかるなんて、すごいですね
720 ：686：01/10/05 22:46
なんかややこしいことになってきたなぁ。

OOの無い職場にOOを入れるのは大変で、
向上心のある人が何人かいても難しい。
パーツを一から作り上げないといけないし、
下手なパーツが積み重なって全体を壊すかもしれない。

ところがOOのある職場に、OOの経験が無い人を入れると、
それがオッサンでもすぐに馴染む。
上手くできているパーツを組み合わせるだけだから失敗しようがないし、
どういうパーツがいいパーツなのか、使うだけで勉強になる。

なんとかこの差を埋める方法は無いものかね。
いつの日かあの楽チン環境に戻りたいよ。
同じ事をするのに数倍の手間をかけていると思うと泣けてくる。
721 ：デフォルトの名無しさん：01/10/05 22:50
>>720
ソースコード盗んでくればよかったのに。(ｗ
722 ：デフォルトの名無しさん：01/10/05 22:51
転職するときに職場見せてもらって
そのとき机に積んである書籍の種類を確認するといいよ。

ボロボロになったK&R一冊とかって会社はやめといた方がいい。
723 ：686：01/10/05 22:52
>>720

盗んできたと思ったアーカイブの中には、
別のソースが入ってたんです……。
724 ：Delギコ：01/10/05 23:03
　　　∧∧　　　／今時OOがダメとかいう
（ ＿(,,ﾟДﾟ)　＜　アホが混じってるみたいだ。
⊂,,＿_つつ.　　＼＿
　嫌オブジェクト指向スレでも立ててやってくれよ。
　一向に、オブジェクト指向論議が進まなくない？

はじめから仕様が完璧に決まっているなら
OOでも非ＯＯでも品質は同じだろうけど

(多分、非OO派はこういう環境にいるんでしょ
　そんな環境ではコーダーとか言われかねないよ)

#COBOLで簡単なものを作るとか、言ってる人もいらっしゃるが
　それは違うぞ。仕事のやり方が、完璧な仕様を作ってからコードという
　システムになっているらしい。
　実際はウソッコだけど。


ＯＯすると仕様変更に非常に柔軟に対応できるようになる
現実のプロジェクトでは仕様変更が日常茶飯事、
特に、最近のプロジェクトは短納期という状況が多いですね。
それに短期間で対応できるOOが
結果的にＯＯは品質の高いものが作れるよ。

> ちなみに、OOを理解してると勘違いしている
> OOプログラマー多いです
> とくにJAVAでは顕著です
> OOの敷居は高いので、あまり見かけないと思うのですが
Javaの皮かぶったCOBOLerが多いですね。
話を聞いて、元コボラだったら気をつけましょう。

>>712
わかりやすいです。

>>723
ソースを盗むのではなく、ノウハウを盗もうよ。
725 ：デフォルトの名無しさん：01/10/05 23:08
Delギコ ｳｻﾞｲ。
もうすこしお勉強してから来てね。
726 ：Delギコ：01/10/05 23:14
　　 ∧＿∧　　／￣￣￣￣￣
　　（　´∀｀）＜　>>725　オマエモナー
　　（　　　　） 　＼＿＿＿＿＿
　　｜ ｜　|
　　（_＿）＿）


　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　∧∧　　　　＜ 　よーし、定番定番。
（ﾟДﾟ∧)_∧　　＼＿＿＿＿＿＿＿＿＿＿＿＿
（￣⊃ ´∀｀)
｜ ｜￣|￣
（_＿）＿）

　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　∧∧ﾊｯ!　　＜　なに見てんだｺﾞﾙｧ!!
（#ﾟДﾟ∧_∧　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿
（￣⊃ ´∀｀)
｜ ｜￣|￣
（_＿）＿）
727 ：686：01/10/05 23:25
>>724
ノウハウは持ってるよ。
実際、そのソースの多くは自分のソースだし、
他人のソースにもある程度自分の意見が含まれている。
だけどそれを会社に広めるのは別次元なの。

一人だけで踊ってもしょうがないのよ。
C++でやるぞ、Javaでやるぞと言っても、
「また自己満足クンが何か言っているよ」と思われるだけだし、
一人だけC++で書いたモジュールを混ぜるというわけにもいかないし。
一人だけでシステム全てをコーディングするのも非現実的だし。

今は１０年計画で若い人を育てることに血道を上げてます。
728 ：ｽﾚｽﾄｯﾊﾟｰDelギコ：01/10/05 23:31
　 ∧∧　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　(,,ﾟДﾟ)　＜　 ちょっと遊びすぎた。
Π￣￣￣|　＼　
|つゴメン ()　 　￣￣￣￣￣￣￣￣￣￣￣￣￣￣
| |＿＿＿.|
　　∪∪

話を修正
>>714
現実問題として、OO以外の開発って何でやっているのですか？
少なくともOO言語でやっているのなら
ちょっと優秀な人にある部分を任せたら
すぐにOOをしてくると思うのですが...場合によってはそれを否定するのですか？
　そんな状況、優秀な人、嫌気がさして辞めませんか？

そういう環境の究極的な解決方法としてXPというものがあります。
ペアプログラミングという方法論があって
それをしたら全員がOOをマスターするのは
人月的にみたら一瞬だと思いますが
どうしてそういうことをされないのでしょう？

>>720
よっぼど楽ならともかく
やめようよ、そういう会社は、
自分のキャリアを汚すだけにしかならないかもよ。

ﾌｷｮｳといえどもソフト業界は人手不足にあふれているさ。

> >オブジェクト指向に見向きもしない向上心の無い奴
> 普通のリーマンコーダなんてこんなもんでしょ。
> だって、今までの経験でこれからも惰性で開発できるんだから
> わざわざ自腹で本何冊も買って勉強するなんてアホらしいよ。
うーーーん、
職業意識とかは芽生えないか、な。

自分より年下の人間にバカにされたいか?
すぐに追い越されるぞ。
729 ：デフォルトの名無しさん：01/10/05 23:38
>>724

>今時OOがダメとかいう アホが混じってるみたいだ。

っていうのに現実感が感じられないのよ。
727のように、現場では、イタイ人間と紙一重なの。
そこから、責任者とチームを説得し、広めるのに
どれだけ苦労するのかわかる？

>>727

>１０年計画

遅いと思われ。出たほうが身のため。
10年後
前の会社にいた人間がどうなっているか想像してみて。
かけはなれてるだろ？
730 ：Delギコ：01/10/05 23:42
　 ∧∧　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　(,,ﾟДﾟ)　＜　>>727　大変よくわかります、その↓
Π￣↓←←←←←←←←←←←←←←←←←
|つ 境遇 ()　 　￣￣￣￣￣￣￣￣￣￣￣￣￣
| |＿＿＿.| >>729ﾜｶﾘﾏｽ
　　∪∪
うちの会社はOOを理解してない人はいなかったから
まあまあマシだったけど
変な非効率なやり方を修正しようとすると、つらいっすよね。

面と向かって、"あの人だめだなあ"
なんて同僚でもいいにくいし。

ついでいうと、下請けだったら
上の会社がわかってない所から発注だと
旧態依然とした無意味な納品のためだけの仕様書
とか書かされる。

なんでこの業界、デキナイ人間がデキル人間の足を
とことん引っ張るわけだ？
せめて、生産性の高い人の足はひっぱるなよ、ﾋﾄﾄｼﾃ

とか、おもうたり～～～

このスレで言う所のOO否定者はOOを理解してから否定している？
そうじゃないのなら、足はひっぱらないで。

クレと、ひっぱらないでクレ、そうしてクレ、と、小一時間問い詰めたィ・・・・(ﾈﾀ)


ま、ﾈｺの意見だから無視したい人はしちゃって許してね
731 ：デフォルトの名無しさん：01/10/05 23:59
>>730

> ま、ﾈｺの意見だから無視したい人はしちゃって許してね

公の場に書き込んだ以上、逃げはいかんよ、ﾋﾄﾄｼﾃ

とか、おもうたり～～～
732 ：686：01/10/06 00:09
>>728
>よっぼど楽ならともかく
>やめようよ、そういう会社は、
>自分のキャリアを汚すだけにしかならないかもよ。

>>729
>遅いと思われ。出たほうが身のため。
>10年後
>前の会社にいた人間がどうなっているか想像してみて。
>かけはなれてるだろ？

いや、そこまで悲観しているわけじゃない。
今の会社は良くも悪くも普通。
決して技術力で劣っているわけではなく、
むしろ部分的には見るべきところもあるし。

OOは、あると楽できるというポジティブなものであって、
無いと困るというネガティブなものじゃない。
OOできなきゃ仕事にならんということは無いからね。

あと今後の成長に関しても、そんなに悲観していない。
OOが身に付いていれば最近の技術はすぐ身に付く気がするんだ。
デザインパターンとかUMLとか出てきたけど、
OOは大筋ではもう１０年以上変わってなくて、
OOに関連する技術である限り水が染み込むように吸収できると思う。

もうここまで来ると、そうそう若い奴らには負けん。
733 ：デフォルトの名無しさん：01/10/06 00:12
>>732
失礼かと思いますが、貴殿の話は何か、現実味が感じられません。
話作ってません？
気のせいだったら、ごめんなさい。
734 ：デフォルトの名無しさん：01/10/06 00:27
かつて夢と未来への希望、人々の融和を志して語られた思想が有った。

計画経済、統制、言論弾圧、思想改造、プロパガンダ、異端査問。

それらがもたらした物は人々の望まないこうした物でしかなかった。

祭りは終わった。

だが、まだ祭りの終わりに気付かずに酔いつづける人が星を掴もうとしている。
735 ：デフォルトの名無しさん：01/10/06 00:27
すでにプログラム「技術」板じゃないよなぁ・・・。
736 ：686：01/10/06 00:30
>>733
全部事実だよ。作り話に見えるかなぁ。
>>730でもよくわかるって書いてあるし、
たぶんOOに傾倒している人なら
激しく同意してくれると思うのだけど。
737 ：奈々氏ギコ：01/10/06 00:31
ｺﾚﾃﾞﾄﾞｳｶﾅ>>731
　 ∧∧　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　(,,ﾟДﾟ)　＜　演繹的・・・えんえきてきって読むんだ…
Π￣￣￣|　＼ 　　　　　　　　　　　　　　　　　　　←
|つ奈々氏()　 　￣￣￣￣￣￣￣￣￣￣￣￣￣
| |＿＿＿.| 　ﾈｺ ﾆﾊ ｲﾐ ﾜｶﾗﾝ
　　∪∪ 　

>>732
もったいない。オバケが・・・・

　　δ　　　　　　δ 　　ｱﾅﾀﾉ ｷﾞｼﾞｭﾂ ﾓﾀ～ｲﾅｲ
♪　　 ∧ ∧　♪ 　　δ ﾓﾀ～ｲﾅｲ
　　　 （,,ﾟДﾟ)　　♪ 　　ｲﾅｲ ｲﾅｲ ﾊﾞｱ
　　 　 |つ[|lllll］).
　　～(　　/ 　　　　　δ
　　　　）,ノ
　　　 υ

でも、他の人より秀でていると
仕事も楽でいいかも、ですよね。
(これぞ人生の処世術)

＞そうそう若い奴らには負けん。
折れ、ﾌﾟﾛｸﾞﾗﾊｼﾞﾒﾃマル3年っす。

ネットで調べると後進からの追い上げは怖い。
738 ：デフォルトの名無しさん：01/10/06 00:37
厨房啓蒙ネタはマ板でないかい？
739 ：デフォルトの名無しさん：01/10/06 00:45
UnitテストってC言語でも出来るものなんでしょうか？
出来るならやり方を教えてほしいです。
740 ：デフォルトの名無しさん：01/10/06 00:49
できるよ。
山ほどAssert関数作ってtest関数実行すればよい。
特にフレームワークなんて作る必要ないけど、探せば幾つか見つかるよ。
741 ：デフォルトの名無しさん：01/10/06 00:58
UMLは複雑になりすぎ。
742 ：デフォルトの名無しさん：01/10/06 01:02
>>741
どの変が？
743 ：デフォルトの名無しさん：01/10/06 01:05
>>741
確かにRationalは頑張りすぎ。
UMLマンセーだったけど、最近の仕様追加にはうんざり。
使いたいところだけ使おう。
744 ：デフォルトの名無しさん：01/10/06 02:11
>>741
普通は、OMTで十分。
745 ：デフォルトの名無しさん：01/10/06 02:53
>>686
なんつうか。CだってOOPできるだろ。特に情報隠蔽やカプセル化
なんてまともなCプログラマならみんなやってると思う。

それより非効率な物を具体的に発見して、それの解決法を
提示したときになんでちゃんと納得させられないのか理解に苦しむ。
それができないのは
１・相手のプライドゆえ非効率を認めない。
２・相手が論理的思考が出来ない。
３・あなたが利点を人に説明できるほど理解していない。
４・そもそも(その状況では)利点がない。
５・説得する気なんかない
からじゃない？
１なら納得はさせているのだからあとは対人スキルの問題。
２ならほんとのドキュソ。OOPとかそういう問題以前。
ただ２と３は紙一重だから謙虚に考えたほうがいいと思う。
そして一生懸命説明しているうちに実は４だってことがよくある。
５ならまさに自己満足君だ
746 ：デフォルトの名無しさん：01/10/06 03:00
>>745
激しく同意。
ＯＯＰが出てからカプセル化、隠蔽、シリアライズ初めて知った
奴の方がＤＱＮ。
747 ：デフォルトの名無しさん：01/10/06 03:08
はぁ？気ティが現れた>>745,746

C言語で隠蔽された関数ってどうやって作るの？
C言語で派生後のクラスからアクセス出来ない変数どうやって作るの？
748 ：デフォルトの名無しさん：01/10/06 03:09
>>747
擬似的なものは十分作れるよ。
それに、隠蔽や継承＝ＯＯという考え方自体がキティ。
sage
749 ：デフォルトの名無しさん：01/10/06 03:14
>なんてまともなCプログラマならみんなやってると思う。

>擬似的なものは十分作れるよ。

「みんなやってると思う」の直後に「擬似的なもの」ってのはやめてよ。恥ずかしいＹＯ！
750 ：デフォルトの名無しさん：01/10/06 03:17
>それに、隠蔽や継承＝ＯＯという考え方自体がキティ。

>なんつうか。CだってOOPできるだろ。特に情報隠蔽やカプセル化

自分で言ってること分かってないでしょ！
751 ：デフォルトの名無しさん：01/10/06 03:21
>>750
745-746 != 748
ちなみに俺は 748。
745,746 はＯＯＰ自体はＣでも
可能(というか言語に依存するもんじゃない)で、
実際、ＯＯＰの要素技術として代表的な隠蔽その他もろもろは
Ｃでも実装できるし、その程度なら誰でも把握してるもんだろ、
という意味に取った。
外してるか？
752 ：デフォルトの名無しさん：01/10/06 03:29
>>745
情報隠蔽やカプセル化は手段であって
OOPと直接的な関連は無いぞ。
753 ：デフォルトの名無しさん：01/10/06 03:29
全然「擬似」じゃないんだが・・・。
754 ：デフォルトの名無しさん：01/10/06 03:36
＞＞７４７
勉強足りないね。最近はOO言語から入る人が多いから仕方ないの
かもしれないね。でも、知ったかぶりはかっこ悪いよ。
OO言語は、OOがしやすい言語だよ。C言語でＯＯするには、
X toolkit を勉強してみよう。クラス(Widget)を設計するのは
とっても面倒だけど、隠蔽も継承もできるぞ。
755 ：デフォルトの名無しさん：01/10/06 03:38
Ｃ言語でもOOできるが、ただオブジェクトがメッセージで交信するというレベルではなく、
OOらしい設計しようとか、ちゃんとデザパタしようとかするとめちゃくちゃ難しいよ。
仮想関数を活用しようとすると複雑度が危険なくらい増す。

特に非OOなコードがたくさん混じっている状況でOOするのは不可能に近い。
かろうじて自分だけが作ったモジュールだけがOOできるものの、
他のモジュールへのアクセスはやはり非OOにならざるを得ず、
Ｃではラッパーを作るのも厳しい。
756 ：デフォルトの名無しさん：01/10/06 03:40
>Ｃでも実装できるし、その程度なら誰でも把握してるもんだろ、
>という意味に取った。 外してるか？

自分でアクセスしないことにしたから隠蔽っていうのは隠蔽じゃないんだ。
大型開発で一人の人間が規則を破ったら終り。また、デグレしやすい。
それに対して、コードでprivateって宣言すれば外からアクセス出来ない、こういうのを隠蔽という。

外してるということを分かって貰えましたか？
757 ：デフォルトの名無しさん：01/10/06 03:40
OOを知らないくせに隠蔽とかの言葉だけを知っている奴は、
関数やデータや定数を無闇に隠蔽してしまうので困る。
758 ：デフォルトの名無しさん：01/10/06 03:42
>OO言語は、OOがしやすい言語だよ。C言語でＯＯするには、
>X toolkit を勉強してみよう。クラス(Widget)を設計するのは
>とっても面倒だけど、隠蔽も継承もできるぞ。

面倒なことはあなたがやって下さい。自分は嫌です。
759 ：デフォルトの名無しさん：01/10/06 03:42
「Cでもできる」からOOPLいらないって主張なの？
OOするのなら最初からC++とかのOOPL使ったほうがいいんじゃないの？
760 ：デフォルトの名無しさん：01/10/06 03:43
>OOを知らないくせに隠蔽とかの言葉だけを知っている奴は、
>関数やデータや定数を無闇に隠蔽してしまうので困る。

自分が知らないんだろ。宣言をprivateからpublicに移動するだけじゃん。
761 ：748：01/10/06 03:44
>>756
よほど凝ったことをしなければアクセスできないようにすることはできるけど？
例えば、Windows の API にはおなじみの HANDLE。
HANDLE が指す対象のメモリ上の実データは隠蔽されている。
これじゃ不十分かい？
762 ：デフォルトの名無しさん：01/10/06 03:46
>>761
やっぱりOOがわかってないと思われ。
763 ：748：01/10/06 03:48
>>762
む。そう言われると少しカチンと来るな。
俺にしてみれば Windows API のデザインは
一応ＯＯの原則に則っていると思っている。
実データの隠蔽やカプセル化、継承などもある程度成立している。
この考え方のどのあたりがダメなのか説明してくれ。
764 ：デフォルトの名無しさん：01/10/06 03:48
不十分とか十分という問題ではない>>761

クラスにすると明らかに幾つもメリットがあるんです。
それは、このスレで出てるから読んでみて。
765 ：デフォルトの名無しさん：01/10/06 03:50
>>762
Handleはオブジェクトへの参照だろ。
ＣでＯＯする場合の常套手段だよ。

しかし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
例えば↓>>763
http://piza2.2ch.net/test/read.cgi/tech/1001275287/571
768 ：748：01/10/06 03:52
>>764
ん？
別にＣでも書けるんだからクラスなんて要らないよとか書いた覚えはないぞ。
ＯＯＰとＯＯＰＬとを混同するのはよくないという視点で書いただけ。
Ｃ＋＋処理系が手元にあったらＣでＯＯしたりなんかしないって。
769 ：748：01/10/06 03:53
>>765
だからぁ、俺はＣで十分だなんて言ってないってば・・・。
できないことはないよ、何故ならＯＯＰとＯＯＰＬは違うから、
と、そう言いたいだけ。
770 ：デフォルトの名無しさん：01/10/06 03:56
>ＯＯＰとＯＯＰＬとを混同するのはよくないという視点で書いただけ。

頭おかしいね。
無限の時間と全てのコードを頭に入れることが出来るんなら、ＯＯＰＬ以外でＯＯＰすれば良いだろう。
プログラミングは有限な中でやるもんだからね。

>Ｃ＋＋処理系が手元にあったらＣでＯＯしたりなんかしないって。

はやく手に入れろよ。
771 ：デフォルトの名無しさん：01/10/06 03:57
ＯＯＰＬは、単にＯＯ的記述が綺麗に出来るだけ。
ＯＯの概念の多くは、ＯＯＰＬが登場する以前から、
まともなプログラマならやっていた。
ＯＯＰＬいらないって主張なの？とか、ボケは勘弁。
772 ：オリジナルギコ：01/10/06 03:59
>できないことはないよ、何故ならＯＯＰとＯＯＰＬは違うから、
>と、そう言いたいだけ。

　　　　　　∧ ∧　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣
～′￣￣( ﾟДﾟ)＜　逝ってよし！
　UU￣￣　U U　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
773 ：748：01/10/06 03:59
>>770
ＯＯＰとＯＯＰＬは違う、というのは、
ＯＯＰＬはＯＯＰの実現手段に過ぎず、
その具体化である(個々の)ＯＯＰＬとＯＯＰは１対１対応しない、ということ。
だから、あるＯＯＰＬで提示されているＯＯＰのモデルが
ＯＯＰの全てのモデルを代表することはないし、
あるＯＯＰＬや、非ＯＯＰなプログラミング言語でも
ＯＯＰを実践することはできる。
そういう基本を言ってるだけ。
仕事はＣ＋＋でやってるよ。変な煽り入れないでくれ。
774 ：デフォルトの名無しさん：01/10/06 04:01
もうお前のボケレスは要らない>>771
775 ：748：01/10/06 04:01
>>773
ちょっと書き間違えた。
>あるＯＯＰＬや、非ＯＯＰなプログラミング言語でも
>ＯＯＰを実践することはできる。
以下のように訂正。
>異なったＯＯＰのモデルに基づくＯＯＰＬや、
>非ＯＯＰなプログラミング言語でも
>ＯＯＰを実践することはできる。
776 ：デフォルトの名無しさん：01/10/06 04:03
だからもうﾚｽ要らないって>>775
777 ：デフォルトの名無しさん：01/10/06 04:04
>>766
いや、そうじゃなくて,
昔からプログラマが自分で発見していたような技術をＯＯＰ出てから
「教えられて」初めて知って「時代に付いて行けないの何の」と
興奮して、「新知識」を振りかざしてる奴が滑稽だっつうの。

ＯＯので述べられているような事は自分で発見していて当然。
教えられて初めて判るような人は才能ないんじゃない？つう事だ。
778 ：デフォルトの名無しさん：01/10/06 04:04
>>773
ＯＯＰＬしか知らない人達には、理解しづらい話だと思う。
この世代の人達って、実務でまともな設計経験も無いと思うし。
779 ：748：01/10/06 04:05
>>776
ＯＯＰと個々別々のＯＯＰＬを切り離して考えるべき、
というのは電波な意見なわけ？
そこんところ納得できないんだよ～。
780 ：デフォルトの名無しさん：01/10/06 04:06
>>774
俺は今日初めて書いたんだよ。
781 ：デフォルトの名無しさん：01/10/06 04:06
>昔からプログラマが自分で発見していたような技術をＯＯＰ出てから
>「教えられて」初めて知って「時代に付いて行けないの何の」と
>興奮して、「新知識」を振りかざしてる奴が滑稽だっつうの。

それに対して、自分も興奮して意見振りかざしてるんでわ？
スレと関係無い分、もっと醜いよ。
782 ：デフォルトの名無しさん：01/10/06 04:07
>>748
今ここには非OOPLでOOPできないなんて言っている奴は居ないのでは。
非OOPLで十分にOOPができるとする主張に異議があるのでは。
みんなそれは難しいと思っているのでは。
783 ：748：01/10/06 04:08
電波扱いされるのもイタいので実例を挙げてみる。

Java/ObjectPacal：多重継承なしのクラスベース。
C++：多重継承ありのクラスベース。
JavaScript：プロトタイプベース。

もしＣ＋＋しか知らなければ
多重継承ありでクラスあり＝ＯＯＰだと思うかもしれないけれど、
それはＣ＋＋に特有のＯＯＰのモデルであって、
他のＯＯＰＬでは通用しない。
こういう意味で、区別が必要だと言ってるの。
784 ：デフォルトの名無しさん：01/10/06 04:09
>ＯＯＰと個々別々のＯＯＰＬを切り離して考えるべき、
>というのは電波な意見なわけ？

別スレでやって下さい。ＯＯＰについてＯＯＰＬで説明してるスレなんで。
なぜＯＯＰＬで説明するかというと、動物-猿,犬,猫では現実味が無いという意見が出たから。
785 ：748：01/10/06 04:10
>>784
そりゃ失礼。
786 ：デフォルトの名無しさん：01/10/06 04:10
クラス邪魔。継承いらない。
787 ：デフォルトの名無しさん：01/10/06 04:11
>多重継承ありでクラスあり＝ＯＯＰだと思うかもしれないけれど、
>それはＣ＋＋に特有のＯＯＰのモデルであって、
>他のＯＯＰＬでは通用しない。
>こういう意味で、区別が必要だと言ってるの。

がいしゅつです。クラスベースのoop対オブジェクトベースのoopのレスを参照して下さい。
788 ：デフォルトの名無しさん：01/10/06 04:11
>>782
俺は748じゃないが、勘違いしてるのはどっちか、読み返してみれば分かると思うが。
論点のすり替えは感心せんな。
789 ：748：01/10/06 04:17
>>787
このスレで最初に「プロトタイプ」という単語使ったの実は俺。
ガイシュツなのにあんまり区別されてないなぁと思ったので出てきたの。
でもこれで引っ込みます。つか寝ます。
790 ：デフォルトの名無しさん：01/10/06 04:17
良くわからないんだがHANDLEを使えばデータの隠蔽？？
OOした事になるの？
791 ：デフォルトの名無しさん：01/10/06 04:18
>>790
ボケは不要だっての。
792 ：デフォルトの名無しさん：01/10/06 04:21
コンポーネント指向ってどうよ？
793 ：デフォルトの名無しさん：01/10/06 04:23
>>790
うむ、OOを知らない人には信じられないかもしれないけれど、
例えばファイルハンドルはオブジェクトへの参照だ。
fopenはファイルオブジェクトのコンストラクタで、fcloseはデストラクタ。
ファイルハンドルを引数に取る標準関数は全てメンバ変数。

ファイルハンドルの先がファイルなのかデバイスなのか隠蔽されているし、
シークポインタも隠蔽されていて、ファイルハンドルに内緒で勝手に変更することは
できず、fseekメソッドでメッセージを送らないといけない。
794 ：デフォルトの名無しさん：01/10/06 04:24
>>792
簡単に高機能が実現できるが、提供されていない機能の実現には限界がある。
ソースでも公開してくれれば、話は別だが。
795 ：デフォルトの名無しさん：01/10/06 04:24
継承がアホな概念の訳。
例えばファイル操作。
最下層ではopenだのcloseだのとよりハード寄りのコードを書くけど
上位層ではこういったファイル操作を意識せずファイル名を与えるだけで
読み書きできるように作る。
（何時までもファイル操作の度にopen,closeやっていたとしたらそいつは
プログラマーの才能無し）
上位層は下位層でやっているような手続きを全く意識させない作りにするのが
正しい設計である。
ＯＯＰＬの継承は下位層の手続きを丸ごと持ってくるというアホな発明なんで
全然意味無し。
アホＰＧを量産するだけ。
796 ：793：01/10/06 04:24
間違えた。
↓
ファイルハンドルを引数に取る標準関数は全てメンバ「関数」。
797 ：デフォルトの名無しさん：01/10/06 04:25
しょーもない議論だ。
798 ：デフォルトの名無しさん：01/10/06 04:27
>>795
恥ずかしいから出てこなくていいよ。
799 ：デフォルトの名無しさん：01/10/06 04:28
>>794
いちおうコンポーネント自作できるぞ。
継承して機能拡張もある程度はできる。
ソースが公開されるならばいいのか。
800 ：デフォルトの名無しさん：01/10/06 04:31
800いただき
801 ：デフォルトの名無しさん：01/10/06 04:31
>>799
たとえば君が、何らかのエディットコンポーネントで、
エディタプログラムを作るとしよう。
おそらくコンポーネントの機能拡張の限界に、
すぐにぶち当たるだろう。
802 ：デフォルトの名無しさん：01/10/06 04:32
>>795
それは、File クラスの実装レイヤーの上に
インタプリタみたいなもののレイヤーを載せて、
最上層のレイヤーでは ReadTextFromFile( "filename.txt") ;
みたいな書き方をするべきだという話？
803 ：デフォルトの名無しさん：01/10/06 04:32
>>795
やっぱりわかってない・・・。
804 ：800：01/10/06 04:36
完璧にＯＯを理解している人ってこの板の何％なんだろう？
中途半端に理解して勉強を止めると>>795みたいになってしまうんだろうな。
私も気をつけよう。
805 ：デフォルトの名無しさん：01/10/06 04:39
つーか>>795はオブジェクトとは何なのかという
根本から理解できてないね。
半端も何も理解度０％では？
806 ：デフォルトの名無しさん：01/10/06 04:40
この板が日本の技術力を底上げしていたりして。
807 ：800：01/10/06 04:45
>>806
いや>>795のような方が居る限りはまだまだだめでしょう。
808 ：800：01/10/06 04:50
などと言っている私のようなヒッキーが幅を利かせているようでは
プログラマ板も大したことはありません。
809 ：デフォルトの名無しさん：01/10/06 04:50
>>808
そしてここはプログラマ板ではない。
810 ：800：01/10/06 05:00
オブジェクト指向の仕様を編み出した人間でもなし。
だからといってオブジェクト指向の新しい言語をつくるわけでもなし。
ただオブジェクト指向の枠組みを無視するアホと押し合いしているだけ。

コンポーネント指向は融通が利かなくてもそこは重箱の隅
コンポーネントを組み合わせて生産的になったほうがいいのでは？
811 ：デフォルトの名無しさん：01/10/06 05:01
このスレ面白いね
厨君は勘違いしてるようだけどＯＯはＣより古い技術なんだよ
実はＣはＯＯの影響を受けている。面白いから本探して読んでみてね
812 ：デフォルトの名無しさん：01/10/06 05:04
>>810
ＯＯについてもそうだが、欠点を指摘すると、
すぐ全否定者扱いしてくる奴がいる。（わざとか？）
大抵の物には、利点と欠点がある。
813 ：デフォルトの名無しさん：01/10/06 05:09
個人的には継承は便利だと思うんだけど。
あまり評判良くないみたいね。
814 ：800：01/10/06 05:12
>>812
新しい言語を作る人ならば
欠点をついたからにはそれを直そうとする。
しかしそうでないならば、蟻の一穴から全否定を狙っている。
もしくは欠点をついて喜んでいるだけのひねくれ者です。
815 ：デフォルトの名無しさん：01/10/06 05:13
そういえばSmalltalkって結構古い言語だったよね。
816 ：デフォルトの名無しさん：01/10/06 05:14
>>814
話にもならんな。
俺はコンポーネント指向は、簡単に高機能が実現できると、初めから言っている。
欠点を認めないなら、盲目的な信者だ。
817 ：800：01/10/06 05:18
>>816
欠点を認めた上でそれは重箱の隅といっているのです。
機能拡張ができずどうしても必要なものは
コンポーネントを自作すればいい。
それはオブジェクトを自作するのと労力は変わらない。
818 ：デフォルトの名無しさん：01/10/06 05:20
>>817
> コンポーネントを自作すればいい。
> それはオブジェクトを自作するのと労力は変わらない。
禿しく胴衣。
819 ：800：01/10/06 05:21
>>813
私は継承は最小限にしています。
しかし継承にメリットがある場合はどんどん使います。

>>815
まともなオブジェクト指向の最初の言語？使ったことないので知らない。
820 ：デフォルトの名無しさん：01/10/06 05:22
>>817
結局、欠点を指摘したら、全否定者扱いされて当然って意見だろ。
やっぱり、話しにならん。
821 ：デフォルトの名無しさん：01/10/06 05:24
>>818
同意も何も、それしかないだろ。
822 ：800：01/10/06 05:26
あたりまえ過ぎて議論にもならない。さよなら
823 ：デフォルトの名無しさん：01/10/06 05:26
オブジェクト指向がソフトウェアの技術史における
最後にして最上の技術ならば問題ないんでしょうけれどね。
そうでない限りは、次に出てくる技術によって解決されるだろう
何らかの問題を抱えているはずです。
僕は現状のオブジェクト指向やオブジェクト指向プログラミング言語には
建設的なダメだしをすべきところが沢山あると思います。
皆さんは、オブジェクト指向は至高にして最後の技術だと思われますか：）？
824 ：818：01/10/06 05:28
>>821
いや、コンポーネント指向ってオブジェクト指向に包含されてる概念だと
思ったもので。
825 ：デフォルトの名無しさん：01/10/06 05:31
mix-inを文法的にサポートしてくれるOOPLきぼんぬ。
826 ：デフォルトの名無しさん：01/10/06 05:32
>>824
> コンポーネントを自作すればいい。
の方じゃなくて、
> それはオブジェクトを自作するのと労力は変わらない。
の方に要旨があるって事かな？
827 ：800：01/10/06 05:34
>>823
至高ではないです。
私のようなヒッキーにもオブジェクト指向を超えるアイディアが幾つかあります。
私の出る幕などなく、近々そういう新言語が現れると信じています。
828 ：デフォルトの名無しさん：01/10/06 05:35
>>825
mix-inぐらいなら、多重継承が出来る言語なら実現できるよ。
自分でやる分にはこれで問題ないんだけどねー。
829 ：デフォルトの名無しさん：01/10/06 05:35
>>827
どういうアイディアなの？
830 ：824：01/10/06 05:36
>>826
そうそう。
オブジェクト指向でうまく設計されたライブラリが豊富になれば、
末端部分ではコンポーネント指向的に必然的になってくると思いましたです。
831 ：デフォルトの名無しさん：01/10/06 05:37
>>820
欠点がよく理解していないためにそう見えるとしたら
やっぱり荒れるね
理解度は人さまざまなものだし
832 ：デフォルトの名無しさん：01/10/06 05:41
オブジェクト指向を否定すると、デザインパターンをはじめとする
オブジェクト指向で提唱されてる技術を使うのが非常に厳しくなって
くるじゃん。
分析設計の方法を適用するのが難しいし、オブジェクト指向的なこと
をC言語でやるのも厳しいし、リファクタリングの方法も限られてくる。
そこまで不便な思いをしてオブジェクト指向を使わないことにする
気も起きない。ＯＯさえ導入すれば楽になる。
ＯＯ否定してる人をみると「そんな自ら厳しい道を選ばんでも・・・」と思う。
833 ：825：01/10/06 05:41
自分も多重継承でやるんですが、インターフェースと実装は継承するけど
デフォルトではメンバ変数がサブクラスから見えなくなる「mix-in継承」って
構文があってもいいかなと。
834 ：デフォルトの名無しさん：01/10/06 05:43
>>833
はぁ？なんでそれがmix-inなの？
835 ：デフォルトの名無しさん：01/10/06 05:50
mix-inってのは、多重継承するときに、

部品(mix-inクラス)＋本体（一つまで）→　新しい本体

というパターンしか許さないってやつでしょ？
836 ：デフォルトの名無しさん：01/10/06 05:51
>>832
ＯＯ否定してる人ってのは、ＯＯを全肯定しない人の事じゃないのか？
だとしたら、俺も含まれるな。
837 ：825：01/10/06 05:51
う。ちとオレがmix-inを誤解してるかもしれないんだけど、
普通に実装継承するクラスとmix-inするクラスを構文を見た時に
わかるようにしてあれば見やすいかナット。
838 ：デフォルトの名無しさん：01/10/06 05:53
>>836
全否定とか部分否定とかじゃなくて、ＯＯを使わない人のこと。
839 ：デフォルトの名無しさん：01/10/06 05:54
>>837
なるほど。それは言えるね。
今のところコメントを使うという手ぐらいしかないかな。
840 ：825：01/10/06 05:57
つづき。
で、単に多重継承するとメンバ変数の名前がぶつかったりするのがイヤ～
なので、mix-inするクラスに関してはメンバ変数へのアクセスを自動的に
制限してくれたらええのかも、と思いつきでいってみました。スマソ。
841 ：デフォルトの名無しさん：01/10/06 05:58
>>838
現実問題、ＯＯの全ての概念を使わないのは、不可能なんじゃないか？
842 ：デフォルトの名無しさん：01/10/06 06:06
>>841
そんな極端な話じゃない。
843 ：デフォルトの名無しさん：01/10/06 06:10
オブジェクト指向やろうとしたら、多態性とか、継承とか、クラスとか
は必然的に使うことになる。
それらを全部使わないとＯＯ出来ない場合が出てくるからね。
そういう主要概念のレベルではそれらが全部合わさってＯＯでしょう。

確かに継承は、それと同等のことを別の方法でやる言語も存在するけど、結局
同等のことをやっている。
844 ：デフォルトの名無しさん：01/10/06 06:14
>>842
>>843
よく分からんが、ＯＯを使わない人（ＯＯ否定の人）の定義は、
継承・多態・クラスを全て使わない人って事で良いのか？
845 ：デフォルトの名無しさん：01/10/06 06:16
>>844
いや、だから、それら主要概念を一部でも使わない人。
846 ：デフォルトの名無しさん：01/10/06 06:17
>>845
継承・多態・クラス・その他主要概念の、
１つでも使わない人って事で良いのか？
847 ：デフォルトの名無しさん：01/10/06 06:18
それと同等なことを別のものでやってる人なんかはＯＯ否定から除くよ。
クラスと同じようなことをクラスの無い言語でやってる人とか。
848 ：デフォルトの名無しさん：01/10/06 06:18
>>846
だからそうだって･･･
849 ：デフォルトの名無しさん：01/10/06 06:19
>>847
俺は多重継承が嫌いだが、俺はＯＯ否定者か？
850 ：デフォルトの名無しさん：01/10/06 06:20
>>849
違う。君重箱のすみつつき好きだね。
851 ：デフォルトの名無しさん：01/10/06 06:23
>>850
いや、俺はまじめだ。
> 全否定とか部分否定とかじゃなくて、ＯＯを使わない人のこと。
> いや、だから、それら主要概念を一部でも使わない人。
いろいろ個人で基準が違うようで、マジで良くわからん。
852 ：デフォルトの名無しさん：01/10/06 06:24
>>851
ていうか、ＯＯ使う人と使わない人っていったら大体わかるでしょ。
それで良いじゃん。何でこだわってるの？
853 ：デフォルトの名無しさん：01/10/06 06:24
グレーゾーンならグレーゾーンでも良い。
そういう人は意見の対象から除くってことだね。
854 ：デフォルトの名無しさん：01/10/06 06:26
>>852
俺はよくＯＯ否定者扱いされるが、今の基準じゃ、ＯＯ否定者じゃないぞ。
855 ：デフォルトの名無しさん：01/10/06 06:27
>>854
じゃあグレーゾーンですね。良かったね。
856 ：デフォルトの名無しさん：01/10/06 06:29
これからは、ＯＯ否定者扱いする前に、自分の基準と照らし合わせて欲しいな。
857 ：デフォルトの名無しさん：01/10/06 06:33
>>856
誰がどこでお前のこと否定者扱いしたのかもわからないのに、
勝手にぐちんなよ。（ｗ
否定者扱いされるんだったら多重継承以外にも嫌いなものが
あるんじゃないのか？
858 ：デフォルトの名無しさん：01/10/06 06:37
>>857
君の基準では、何が嫌いだと否定者扱いするんだい？
859 ：デフォルトの名無しさん：01/10/06 06:44
ところで、コンポーネント指向って何？
860 ：とおりすがり：01/10/06 06:47
たぶん>>858はOO否定者ではないが、OOの技能、知識をひけらかす
タイプのプログラマに出会って嫌気がさし、「OO嫌い」になったのでは
なかろか？
マ板向きのテーマかな？
861 ：デフォルトの名無しさん：01/10/06 06:49
>>859
検索で調べろよ。
>>860
だったら、話の流れを遮るような、うざい質問してないで
どうどうと何か主張したら良い。858はアホじゃないのか。
862 ：デフォルトの名無しさん：01/10/06 06:59
これじゃ技術話じゃなくて宗教論争だ。
sage
863 ：デフォルトの名無しさん：01/10/06 07:01
>>860
俺をＯＯ嫌い（ＯＯ否定者）にするなよ。

>>861
アホだのＯＯ否定者だの、話と関係ない事で因縁つけてくる奴がいるから、
ＯＯの技術的な問題点一つ、まともに議論できないんだよ。
864 ：とおりすがり：01/10/06 07:05
せっかくだから
>ＯＯの技術的な問題点
↑ここに話題を戻してみては。
865 ：デフォルトの名無しさん：01/10/06 07:07
>>863
話と関係の無いこと言い出したのはお前だろ。
せっかくOOの話をしてるところに、突然否定者の基準とは何だって
わけのわからん質問しやがって。何の意図があるのかちゃんと言えよ。
回りくどいんだよ。
OO否定者だと因縁つけられるのが気に入らなかったなら、
質問してるひまにはじめからそう言えよ。
866 ：デフォルトの名無しさん：01/10/06 07:10
>>865
きちんとした根拠があるなら、無下に非難も出来まい。
だから先に、基準を聞いたんだよ。

出かける準備があるから、これ以上書き込んでも返事は夜だぞ。
867 ：デフォルトの名無しさん：01/10/06 07:13
>>866
だったら、「きちんとした根拠があるならいいが、否定者と
決め付けるのはだめだ」ってはじめから言えよ。
お前逝っていいよ。
868 ：デフォルトの名無しさん：01/10/06 07:14
結局なんだったんだ・・・。
何を批判してたんだろう・・・？？
869 ：デフォルトの名無しさん：01/10/06 07:15
>>868
確かに、まわりくどすぎ。
870 ：デフォルトの名無しさん：01/10/06 07:17
>C言語はOOの影響を受けているって書いた人
詳しい情報求む
なんかおもしろそう
関数ポインタって落ちじゃないよね?
でも、基本的にはSystem370とかを意識してたんじゃなかったけ?

ファイルアクセスに関していってる人は
普通に実行時ポリモーフィズムがわかってないみたいだけど...
実行時ポリモーフィズムってどの程度の人が使いこなしてるのか知りたいね
実行時ポリモーフィズムを使う手段として継承は便利だよ
だからOOL好きだな
特にJAVAはいいね

多重継承はうまく使うとすごく便利
でも、普通に使うと終ってる
まあ、JAVAのインターフェースと単一継承みたいな感じでしか
設計しなくなってしまったけど....
たくさん覚えないと使えないC++
たくさん知ってないと使いこなせないJAVA(ライブラリの話じゃないですよ)
皆さんはどっち派ですか?
871 ：デフォルトの名無しさん：01/10/06 07:21
単一継承しかない言語ってＣ++で多重継承するようなケースで
どうやって対処するんでしょうか？
872 ：デフォルトの名無しさん：01/10/06 07:42
>>871
http://www.tetras.co.jp/yada/j_java_int_r.htm
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
あほか、話の流れを見てないのか！
ＯＯＰＬの話だよ。
糞信者が！　レッテル貼り、揚げ足取りしかできんのか？
876 ：デフォルトの名無しさん：01/10/06 11:55
>>875
いや、基本的に下位層の実装をそのまま持ってくるのを
継承って言わないか？
インターフェイスの継承もあるが。
OOPLの問題か？
それ以前に、>>795は、継承がアホだといってるが
何がアホなのか良くわからん。
877 ：875：01/10/06 11:57
と書いてみたが、
>>804,805,807は open～close並べてるクチだなｗ
878 ：デフォルトの名無しさん：01/10/06 11:58
>>876
継承やクラスはＯＯとは関係無い。
879 ：デフォルトの名無しさん：01/10/06 12:06
プログラマーには２種類あり。
常に上位構造の構築を意識しながら書く奴と
ライブラリ層をベタベタ並べてるだけの奴。
後者に構造の話をしても大抵通じない。
そういうのがＯＯＰＬ覚えると只のクラスマニアになるだけ。
上位構造は一般に複数の構造の上位の構造を持っているもの。
880 ：デフォルトの名無しさん：01/10/06 12:44
>javaでは、継承も隠蔽も、多態を実現するための手段に思えてくるくらい、
>多態しないでプログラムってできない気がする。そこがいい。
だけど、javaプログラマーってポリモーフィズム使えない人多い（笑）
多態ってほんとに便利だと思う
Javaのストリームに感激
SWINGは作りこみ方がマニアックだと思う
そう考えると、マイクロソフトって人件費けちってた以外は
考えられない
881 ：デフォルトの名無しさん：01/10/06 12:49
(ﾟДﾟ)ﾊｧ!? サンの手先ですか？　
882 ：デフォルトの名無しさん：01/10/06 13:01
感激とかマニアックなんて技術的に批判しようのない表現されてもねえ・・・。

他人にはＪａｖａを薦めておきながら自分は逃げる準備をしてたり。
883 ：デフォルトの名無しさん：01/10/06 14:22
少し議論（と発言者）が錯綜していてなんともいえませんが、
自分もOOPL覚えたての頃はクラスライブラリをべたべたと利用する
だけで、いわゆる「open~closeを並べる」タイプだったです。
でもしばらくしてからプログラムしている内容をオブジェクトに切り
分けて、そのオブジェクト間のメッセージのやりとりという観点から
自前でクラス階層を構築する、という作業をしてみると以前よりずっと
実際の問題に近いレベルでプログラムを構造化（？）できるなあ、と
感じるようになりました。
openだとかcloseだとかは自分のつくったクラスのもっと具体的な名前
のメソッドのなかに隠されて外からはすぐに見えなくなると思うのですが。
ですから、>>795の

> ＯＯＰＬの継承は下位層の手続きを丸ごと持ってくるというアホな発明

という感想はそもそも継承の使い方を間違って理解している気がします。
884 ：デフォルトの名無しさん：01/10/06 14:35
> ＯＯＰＬの継承は下位層の手続きを丸ごと持ってくるというアホな発明
継承では、下位層という風には考えないよね、普通。逆に上位でしょ。
つまり、「隠蔽したい下位層」を継承するという考え方ではない。
隠蔽したい実装はサブクラスで行う。上位では、共通したインターフェイス
を考える、ということ。
885 ：デフォルトの名無しさん：01/10/06 14:52
インターフェースの奴隷。
886 ：デフォルトの名無しさん：01/10/06 15:01
丸ごと持ってくるとなぜアホになるのかわからん。
887 ：デフォルトの名無しさん：01/10/06 15:04
>>885
他人のつくったクラスライブラリのインターフェースが不十分で
言語的にはインターフェース継承、多重継承ができず、単一継承
のみの場合には、「インターフェースの奴隷」と呼んでいい状態
が発生するような気もしますが、少なくともインターフェース継
承ができれば、なんぼでも回避する方策があるよーな気がします。
888 ：デフォルトの名無しさん：01/10/06 15:42
>>887
>他人のつくったクラスライブラリのインターフェースが不十分
その場合、インターフェイスを変換(および追加)するクラスを
用意してやれぱいいんじゃない。単一継承でもできるとおもう
けど。
889 ：デフォルトの名無しさん：01/10/06 15:54
ねえねえ、永続化をリレーショナルDBで行うときって、
どういうクラスを作るものなの?
DBのテーブル = クラス、フィールド = プロパティって感じでいいのかな。
となると、フィールドをプロパティに代入するのはどのクラスが担当するの?
そのクラスにはselectメソッドやらupdateメソッドやらつければいいのかしらん。
890 ：デフォルトの名無しさん：01/10/06 15:56
単一クラスのインスタンスの永続化ならそれでもいいんじゃない。
でも任意のクラスを扱うんだったらAsStringみたいに
一つの文字列(内部はXML見たいなのにして)で扱うとか。
891 ：デフォルトの名無しさん：01/10/06 15:57
テーブルがクラス？
892 ：889：01/10/06 16:50
あ、まちがえた。レコード = クラスです。
テーブル = コレクションクラス?
893 ：デフォルトの名無しさん：01/10/06 17:13
>>887
デザパタにあったね
アダプターだっけ？
894 ：デフォルトの名無しさん：01/10/06 17:37
>>884
結構鋭い指摘かも。
最上位がObjectクラスで最下位がアプリケーションのクラス？
ＯＯＰは奴隷用言語？
895 ：デフォルトの名無しさん：01/10/06 18:08
プログラム構造の上下とクラスの上下が逆か。
ここらへんがＯＯＰの欠点かもね。
ＤＱＮＰＧ大量生産の予感・・・。
896 ：>：01/10/06 18:09
ｵﾏｴﾓﾅ
897 ：デフォルトの名無しさん：01/10/06 20:04
>プログラム構造の上下とクラスの上下が逆か。
多分、君のプログラムの設計は、ハードに密着したところからスタートするんだろうね。
でも、プログラムの目的を見失わずに、最下位から這い登ってくるのって、大変だろうね。
898 ：デフォルトの名無しさん：01/10/06 22:06
>>897
いや、トップダウンだよ？
899 ：デフォルトの名無しさん：01/10/06 22:36
ＯＯＰにそんなに詳しくないけど、業務で使ってる漏れの感想は。

コンポーネントの責務とインタフェースの仕様さえしっかりしていれば、
どんな言語を使おうがプログラミングはなんとでもなる。
つーか、それができていない仕様で仕事まわされて泣く事が多い。

オブジェクト指向（つーかクラス図）は責務やインタフェースが分析・設計とも
ビジュアル化しやすくてよいと思ってる。
クラス図読める人が相手なら話もしやすいし。
900 ：デフォルトの名無しさん：01/10/06 23:38
今だ！９００番ゲットォォｫｫ！！
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ
901 ：デフォルトの名無しさん：01/10/06 23:55
>>900
擦れたテロよ
902 ：530：01/10/07 00:59
Eiffel, Sather つかってるときは多重継承派。
C++ つかってるときは多重継承きらい。
903 ：デフォルトの名無しさん：01/10/07 01:30
>>902
>C++ つかってるときは多重継承きらい。

両方知ってるぐらいの腕なら多重継承使っても問題なかろう。ど
ーとでも組めるのがC++だからね。

俺はインターフェースをくっ付けるって意味で純粋仮想関数一個だ
け持たせたクラスは割と使うな。C++屋は再利用が継承の主目的だ
と思ってる奴も多いから多重継承難しいと思ってる奴も多いけどな。
904 ：デフォルトの名無しさん：01/10/07 02:58
>>903
純粋仮想関数だけの抽象クラスを使ったオブザーバパターンは便利っす。
とりあえずこれ覚えただけでも設計しやすくなった。
905 ：デフォルトの名無しさん：01/10/07 03:20
レベル低すぎ
906 ：デフォルトの名無しさん：01/10/07 04:03
>>905

禿げ同!
907 ：デフォルトの名無しさん：01/10/07 04:32
Delphiじゃ自然なんだけどね

なんでそんなに難しく考えるんでしょか？（ｗ
908 ：デフォルトの名無しさん：01/10/07 04:37
>709読め
難しいのではなく面倒なだけ。
新しい技術を学習・試行錯誤して習得するコストをかけるのが嫌なだけ。
909 ：デフォルトの名無しさん：01/10/07 04:44
でも面倒ってのはいかんよね。
910 ：デフォルトの名無しさん：01/10/07 04:47
遠いレスにはちゃんとリンク貼ってくれ>908
>>709
911 ：デフォルトの名無しさん：01/10/07 05:09
ＯＯ好きは余程抽象化が好きなのか、話の内容まで抽象的で、具体性に欠ける概念論ばかりです。
私の具体的アンケートに、回答してみてくれませんか？

ＭＦＣでは、かなりのクラスがＣＯｂｊｅｃｔから派生していますが、これを好ましいと思いますか？
もし好ましくないのなら、貴方ならどうやって、各クラスにシリアライズをサポートしますか？
912 ：デフォルトの名無しさん：01/10/07 05:10
>>911
かなりのクラスがCObjectから派生すると何か問題でもあるの？
913 ：デフォルトの名無しさん：01/10/07 05:15
>>912
貴方の意見を聞かせてください。
914 ：デフォルトの名無しさん：01/10/07 05:17
シリアライズは普通言語・文法レヴェルでサポートするものです。
よってCObjectから派生する・しないに関わらずC++/MFCは糞です。
915 ：デフォルトの名無しさん：01/10/07 05:19
>>914
有用な意見、ありがとうございます。
参考になりました。
916 ：デフォルトの名無しさん：01/10/07 05:19
フツーとか言わないで理由を書け。ライブラリで問題ないなら
言語は小さい方が良い。
917 ：デフォルトの名無しさん：01/10/07 05:21
>>915
ﾊｧ？よくあんな理由で納得できるな。
918 ：デフォルトの名無しさん：01/10/07 05:23
>>917
納得ではありません。
１つの意見として、参考になったと言ったのです。
919 ：デフォルトの名無しさん：01/10/07 05:23
CObjectから派生すると困るのか。困るとして何が困るのか具体的な意見を聞かせてください。
＞否定派の方々
920 ：デフォルトの名無しさん：01/10/07 05:24
>言語は小さい方が良い。
ということはC++は間違いなく糞です。
921 ：デフォルトの名無しさん：01/10/07 05:32
>>920
今さら間違いなくなんて逝ってるﾄﾞｷｭﾝをさらしｱｹﾞ
922 ：デフォルトの名無しさん：01/10/07 05:34
そもそもオブジェクト指向スレで
C++の話題は完全にスレ違いです。
直ちにここから出て行きなさい。
923 ：デフォルトの名無しさん：01/10/07 05:37
>>916
914ではないが、多重継承をサポートしない言語の話でないか？
924 ：デフォルトの名無しさん：01/10/07 05:45
Ｃ＋＋糞は、やめてもらうとして、私のアンケートは、
純粋にＯＯＰの技術論ですよ。
925 ：デフォルトの名無しさん：01/10/07 05:58
好ましいと思います。
とりあえず、CObjectのポインタで保持しておけって言うプロトタイピング
的なコーディングが出来るから。
それに、多態生も実現できる。
926 ：デフォルトの名無しさん：01/10/07 06:02
>>924
ダメだと言ってる人はどんな理由でダメだと言ってるの？
927 ：デフォルトの名無しさん：01/10/07 06:02
それはつまり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
なお、賛成者のみの場合、ＯＯ設計とはそういうものだという、
結論になると思います。
932 ：デフォルトの名無しさん：01/10/07 06:39
否定派は結局>>919の質問に答えられないのか？
933 ：デフォルトの名無しさん：01/10/07 08:07
stlがある今､CObjectの存在意義は薄い。
でもこれがあっても損は無い…かな？

ダウンキャストは必要最低限に抑えたいと思っているので､
とりあえずCObjectのポインタでという組み方はちょっと。
934 ：デフォルトの名無しさん：01/10/07 13:50
親族クラスばっかりだと、近親相姦起こらない？　多重継承とかポインタや参照の
伝搬で。
935 ：デフォルトの名無しさん：01/10/07 14:04
C++ & OOPL == 0　
936 ：デフォルトの名無しさん：01/10/07 14:57
=0
937 ：デフォルトの名無しさん：01/10/07 15:22
CObjectって多態のためにあるんじゃないの？？
確かにstl使えばすむような気がするけど
stlでスタックってできたっけ？
stl使ったこと無いからよくわからん
テンプレートクラスとか使えばできるのかな・・・
938 ：デフォルトの名無しさん：01/10/07 17:05
ふと思った。
あるインターフェースの背後に置く実体を多様化させる、という観点で捉えると
次の三つは同類でありつつ微妙に違うという話になる気がする。

継承を使った多態＝メソッドのセット単位での適合をコンパイル時に要求する。
ジェネリック型＝メソッド単位での適合をコンパイル時に要求する。
型なし言語での多態＝メソッド単位での適合を実行時に要求する。

だから何、とか言われても困るけど、こんな感じじゃない？
939 ：デフォルトの名無しさん：01/10/07 21:15
ほとんどのクラスでシリアライズが必要－＞じゃ上位クラスでとやると、
各クラスの共通部分が上位クラスになり、どんどん多段階層になる。
これがＯＯ的に当然だとするならば、ＯＯに則したプログラムは、
階層の深い、わかりにくい物となる気がするが？
940 ：902：01/10/07 23:16
>>903
>両方知ってるぐらいの腕なら使っても問題なかろう。
>どーとでも組めるのがC++だからね。

多重継承するとき
C++ は安心して実装継承や菱形継承ができない。

多重継承派の人がいてうれしい。多重継承派はよく嫌われる。
941 ：デフォルトの名無しさん：01/10/07 23:43
Objectクラスなんてクラス宣言の　「{」に隠蔽しとけばいいじゃん。
942 ：デフォルトの名無しさん：01/10/07 23:57
>>939
>これがＯＯ的に当然だとするならば、ＯＯに則したプログラムは、
>階層の深い、わかりにくい物となる気がするが？

実際Smalltalkのクラスライブラリの初期の敷居の高さは割と
言われてることだと思うし、MFCなんかもある程度基底クラス
の役割が見えてこないとさっぱ理解できんだろう。基底クラス
が膨らめば膨らむほどこの敷居は高くなるが、一度学習を終え
てしまえば皆が同じ世界を共有するので再利用に非常に有効だ
しコードの可読性も高まるしで、かなりおいしいメリットもあ
る。その取捨選択は言語の設計者のポリシー次第で、C++はそ
の辺全部外注しちまったってとこだろうな。
943 ：デフォルトの名無しさん：01/10/07 23:58
再利用するまで　そのＯＯＰ持つのかね？
944 ：デフォルトの名無しさん：01/10/08 01:24
>>928

うーんこう思ってる人多いなあ……
945 ：デフォルトの名無しさん：01/10/08 01:51
>>942
数百万ステップの業務処理部分でも、学習さえしてしまえば、
可読性が高く修正等が容易かな？
946 ：デフォルトの名無しさん：01/10/08 01:53
＞数百万ステップ
どんな業務処理やねん。
947 ：デフォルトの名無しさん：01/10/08 02:00
>>946
某官庁系のシステムだけど、OS/2のサブシステム1つでも、
百万ステップ超えてるよ。
948 ：デフォルトの名無しさん：01/10/08 02:01
>>946
ステップあたりいくらで受注してるんだろうね。
949 ：デフォルトの名無しさん：01/10/08 02:01
あ、役所系は駄目ー。
賄賂渡して水増しソースとお金交換とかやってるから。
950 ：IBM：01/10/08 02:04
Smalltalkを使った大規模開発ならまかせなさい
http://www3.nikkeibp.co.jp/WAT2/971212/971212trein01.html
951 ：デフォルトの名無しさん：01/10/08 02:28
MFCのCStringは、ｼﾘｱﾗｲｽﾞはCObjectに依存しない。
独立性が高いので、他のｸﾗｽとの多重継承もしやすい。
(只の文字列にしては重すぎるｹﾄﾞね)
952 ：デフォルトの名無しさん：01/10/08 02:46
多重継承はバグの温床

そんなのわざわざ使わなくたってプログラムは組めます
953 ：>952：01/10/08 02:48
NGワード使用につき退場です。
954 ：デフォルトの名無しさん：01/10/08 04:54
>>938
>継承を使った多態＝メソッドのセット単位での適合をコンパイル時に要求する
ってどういう意味でしょうか？
セット単位っていうのがわからないのですが
ちなみに､継承を使った場合C++,JAVAは実行時ですけど
時間があれば残り２つに関しても説明していただけるとうれしいです
955 ：デフォルトの名無しさん：01/10/08 05:12
>>952
もうちょっと詳しく説明してくれ。
特に多重継承がどのようなバグを引き起こすのか
解説ｷﾎﾞﾝ。
956 ：デフォルトの名無しさん：01/10/08 05:25
継承は、強烈なポリモーフィズムの必要性に基づくべき。
(強烈じゃなきゃやめとけって事。)
957 ：デフォルトの名無しさん：01/10/08 05:39
漏れは、CObjectからの巨大ツリーじゃなくて、3階層ぐらいでばらけてたら、もっと使い安かった気がするなー。
958 ：デフォルトの名無しさん：01/10/08 06:02
CObjectって名前、ｶｺﾜﾙｲ
なんでただ、objectじゃいかんの？
959 ：デフォルトの名無しさん：01/10/08 06:09
object なんて一般的な単語をライブラリレベルで使われたら
それはそれでいやなんでわ？
960 ：デフォルトの名無しさん：01/10/08 11:41
>CObjectって名前、ｶｺﾜﾙｲ
MFCのクラスの命名規則がC+頭大文字の単語って決まってるから。
961 ：デフォルトの名無しさん：01/10/08 12:58
>>950
古いけどええ記事だな
オブジェクト指向で大規模な開発だと参加PG全員を一定レベル
以上に教育しておく事が必要だね
962 ：デフォルトの名無しさん：01/10/08 13:09
講師を呼んで全員に研修二日かける程度なら
後でおつりももらえていい感じかも
963 ：デフォルトの名無しさん：01/10/08 13:23
>>961-962
あんた、現実が見えてないよ
964 ：デフォルトの名無しさん：01/10/08 13:42
あんたの身の回りの現実に同情するよ
965 ：デフォルトの名無しさん：01/10/08 14:18

ＯＯ礼賛の提灯記事や書籍を真に受けて「勉強」しちゃった人は現実など関係無いのです。
966 ：デフォルトの名無しさん：01/10/08 14:33
OOスレは必ず揉めます。それは何故か？実は…
967 ：デフォルトの名無しさん：01/10/08 14:39
やっつけ仕事しかしとらん現場にいると、
OOが絵空ごとに見えるんだろうな。

すべてをOOで設計・解決するわけじゃあないが
おいしいとこは、しっかりと使わせてもらってるよ。
968 ：デフォルトの名無しさん：01/10/08 14:53
現実＝ＯＯやＯＯＰ導入して失敗した例を体験、目撃してるのさ。
969 ：963：01/10/08 14:58
>>961
あれ読んで、ＰＧの教育に問題があるなんて、
現実が見えてない。
どう考えても、もっと重要な問題があるだろ。
>>962
研修二日で、何か変わると思うのか？
明らかに現実を知らない。
>>964
俺の現実って何だ？
煽りでしか反論できない低脳。
>>965
俺はＯＯ否定派じゃない。
>>966
結論のない、無意味な書き込みやめろ。
荒れる理由は、964-967みたいなのがいるからだ。
>>967
俺の現場って何だ？
煽りでしか反論できない低脳。
970 ：sage：01/10/08 14:58
なぜ失敗したかの分析をした？

俺も何度か失敗したケースに立ち会ったが、
どうすればうまくいくのか、
何をしないのがうまくいくのか、
調べて、次にイカしたよ。

そういうノウハウをためてはじめて使えるもんだと思うがね。
たしかに、理論に夢中になってる連中を見ると、
現実をミロとも言いたくなる。

ミロ飲みてえな、久しぶりに。。
971 ：デフォルトの名無しさん：01/10/08 14:59
OO必要だって言ってる人と
OO不要だっていってる人の
仕事のレベルが違うのでは？？
名前のところに年収でも書いてくれれば言いと思うけど
972 ：963：01/10/08 15:04
>>971
自分の発言に責任を持てない厨房じゃないなら、まずおまえが書け。
973 ：デフォルトの名無しさん：01/10/08 15:04
>963 消えろ。ウザい。
974 ：デフォルトの名無しさん：01/10/08 15:05
ていうか、そろそろ次スレ? （笑）
975 ：デフォルトの名無しさん：01/10/08 15:06
>>969
> >>966
> 結論のない、無意味な書き込みやめろ。
> 荒れる理由は、964-967みたいなのがいるからだ。

何故964-967みたいなのがいるのか？実は…
976 ：963：01/10/08 15:06
>>973
出たー。
低脳の極み。
出ると思ったんだよなー。
おまえみたいな論理のないやつは、プログラマやめろ。
むいてないんだよ。
977 ：デフォルトの名無しさん：01/10/08 15:10
>>952
多重継承できる言語だとアダプタパターソが楽だよ。
978 ：デフォルトの名無しさん：01/10/08 15:10
この程度の内容なら次スレはマ板に立てろ
979 ：デフォルトの名無しさん：01/10/08 15:13
そろそろCObjectの話題に戻したら？　せっかく設計思想の技術的な話しになって
たのに。
980 ：デフォルトの名無しさん：01/10/08 15:23
>>974
>>978
このまま消滅させるのも一興かと･･･
981 ：デフォルトの名無しさん：01/10/08 15:24
どうにかして非技術的な話しかしない、
基地を排除できないものか
982 ：デフォルトの名無しさん：01/10/08 15:28
話がOOだから難しいと思われ

モデルの話だから人によって流儀が違うことがある。
また、モデリングなんて必要ないという暴論も用意に口に出来る。
# CPUが必要ない、なんてことはありえない。

対象ずばりそのものじゃなくて射影(の流儀)について議論すると揉めることが多い。
例えば政治がその代表例。

ってな話がOOと関係あるかどうかでさえ揉めるだろう。(俺はあると思うのだが…)
983 ：デフォルトの名無しさん：01/10/08 15:32
>>979
CObjectの話題を今読み返しましたけど、なんか、やっぱり
つまんない話題ですね。
MFCがOOのすべてでもなかろに。
984 ：デフォルトの名無しさん：01/10/08 15:33
>>982
具体的個別事例で議論すべきでは？
985 ：デフォルトの名無しさん：01/10/08 15:34
まずはOOスレがどうあるべきかについて語るスレを作りましょう。
986 ：デフォルトの名無しさん：01/10/08 15:36
アホかと、バカかと、
987 ：デフォルトの名無しさん：01/10/08 15:37
>>983

わしもMFC嫌いだから、興味ない。
非抽象的題材なのは評価できるが、もっと別のネタないの？
988 ：デフォルトの名無しさん：01/10/08 15:37
>>985
スレ立てお願い。
おれがやろうとすると、何故かスレッド立てすぎです・・といわれる。
全然立ててないのにさ！
989 ：デフォルトの名無しさん：01/10/08 15:40
１０００！
990 ：デフォルトの名無しさん：01/10/08 15:41
>>988
無駄な上位概念を作るのは、悪いＯＯの例です。
991 ：立てたよ：01/10/08 15:42
オブジェクト指向　Part2
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1002523282
992 ：デフォルトの名無しさん：01/10/08 15:43
>>991
988が欲しかったスレとは違うのでは？？？
993 ：デフォルトの名無しさん：01/10/08 15:45
ＳＯＲＯＳＯＲＯ　ＩＤＯ　ＳＨＩＭＡＳＹＯ
994 ：デフォルトの名無しさん：01/10/08 15:45
まあ963は立ち入り禁止ってことで
995 ：デフォルトの名無しさん：01/10/08 16:25
＞＞９８３
JavaベースにObjectクラスがありますが・・・
996 ：デフォルトの名無しさん：01/10/08 16:25
JAVAもベースに・・・です
997 ：983：01/10/08 17:01
てかC++以外のOOPLは大抵共通のObject基底クラスを持ってるでしょう？
シリアライズのインターフェースも大抵Objectが持っている。
そこを「無駄な上位概念」とかわけわからんこという奴は、
C++のMFCとSTLだけでOOを語ろうとおもてるんではないかと
考えたわけで。
アホか、つまらんことぬかすな、と。
998 ：デフォルトの名無しさん：01/10/08 17:08
>>997
偏見の固まりだな。
999 ：デフォルトの名無しさん：01/10/08 17:08
>997
>てかC++以外のOOPLは大抵共通のObject基底クラスを持ってるでしょう？
だったらいいじゃん
なぜそんなに否定的なの
1000 ：デフォルトの名無しさん：01/10/08 17:14
ここだ！1000番ゲットォォｫｫ！！
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。