クラス継承は廃止すべき
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNG継承はインターフェースだけで。
0153デフォルトの名無しさん
NGNGお前友達いないだろう
教えてやらん、わりと著名な日本語のページにあるから必死こいて自分で探せ。
0154デフォルトの名無しさん
NGNGﾊﾀから見ると、
>教えてやらん、わりと著名な日本語のページにあるから必死こいて自分で探せ。
お前の方が友達いないんじゃないかと思うなあ。
0155デフォルトの名無しさん
NGNGは、なにいいたいのか良くわからん。
なんか良いアイデアあるなら、あっちのスレにも書いてね(♥
0156デフォルトの名無しさん
NGNG0157デフォルトの名無しさん
NGNGそれ>26は単なる笑えない冗談だろ。
見事釣られたわけだねｗ
0158デフォルトの名無しさん
NGNGstd::auto_ptr<IHoge> pHoge = new Hoge<HogeB>;
って感じで、ある枝のパターンを防げないって事を除けばtemplateでOKだと思う。
0159デフォルトの名無しさん
NGNGそれやってしまうと、クラス数が爆発して大変じゃないかなぁ？
クラスに対して、自動的にインタフェースを作ってくれる構文があれば便利なんだが。
class HogeA : __interface;としておくと、
std::auto_ptr< IHogeA > pHogeA( new HogeA );
って感じでIHogeAが出てきた時点で、言語レベルでHogeAから
インタフェースクラスIHogeAを準備してくれるとか。
0160デフォルトの名無しさん
NGNG追加説明
class HogeA : __interface, public IHoge, public OtherInterface{};
ってクラスがあれば、
std::auto_ptr<IHogeA> pHogeA( new HogeA );
としたときには、
class IHogeA : public IHoge, public OtherInterface{};
が自動的に作られるような構文があればなぁって事ね。
0161デフォルトの名無しさん
NGNGスレの内容に対して、その内容がどう絡んでいるのか判らないのだが・・・
余談
UMLって、初期はコミュニケーション言語的な使われ方だったと記憶してるんだが、
いつのまにかプロジェクト資料として残す設計言語って感じになってきてるよね・・・
以前の、不完全な使われ方だけど、設計の大筋が伝わるって頃の方が好きだったなぁ。
0162デフォルトの名無しさん
NGNGHogeに対してIHogeが必ず対で存在することを保障するなら、
管理は別に難しくないんじゃないかな。
まあ>>160みたいな構文があれば記述が楽になることは確かだと思う。
0163デフォルトの名無しさん
NGNG0164デフォルトの名無しさん
NGNGいみふめ。
昔はそーだったんですか。
あと、現在の方も？
今は、「プログラミング言語のソースを自動生成可能な設計データ」
と見なされつつあるのかと、思ってたあるよ。
0165デフォルトの名無しさん
NGNGまあ、クラス数が増えるだけで管理は可能ですね。
クラスのヘッダファイルに、コピペ使ってインタフェース専用クラスも用意すればいいか。
>>164
もちろん、設計データとしての側面も以前からあるけど、
より良い設計を実現する為のコミュニケーションツールとしての側面は
昔の方が強かったなぁっと思ったのですよ。
設計データ作成と称して、誰とも会話せずに黙々と図を書いてる人とか見ると、
なんか使い方がおかしくなってるんじゃないかなぁっと感じたり・・・歳か！？
0166デフォルトの名無しさん
NGNGまぁ大規模開発ではそういかないんだろうけど．
全体としてはソース，クラス，シーケンス，仕様(文書)などのシームレスなツールを所望するがいまだない．．．
0167デフォルトの名無しさん
NGNGなんか、ｽﾚの内容とはあまり関係のないUMLの話が出てきて謎なんだが、 >148 は
委譲ではなく集合の概念で継承を回避してはどうかという話だと思われ
0169デフォルトの名無しさん
NGNGはぃ？
0170デフォルトの名無しさん
NGNG継承自体のアンチ論が出ても不思議じゃないな
俺も派生の派生ってのだけは、絶対にやらないし
0171デフォルトの名無しさん
NGNGおぉ、随分古い記事引っ張り出してきたね。
たしか、プレi-αppLi時代 (ﾄﾞｷｭﾓx503i以前) の記事じゃなかったっけ。
0172デフォルトの名無しさん
NGNGクラス階層は２階層まで派、ですか。
こりゃまた厳しい。Interviewの中の人は、3階層まで派だっけ。
俺は、汎用クラスは結構深くてもおっけ(但し全部深いのは勘弁)派だなｗ
0173デフォルトの名無しさん
NGNGComposit？
0174デフォルトの名無しさん
NGNG基底＞派生＞派生だと、真ん中の派生クラスが何か気持ち悪いんだよ
お前は一体何したいの？みたいな気分になる
しかし例外的に抽象＞派生＞派生ならその嫌悪は無い
0175デフォルトの名無しさん
NGNGvoid hogeMethod(HogeClass hc){}
と定義しとくと、継承なしに
HogeClass hc = new HogeClass();
hc.hogeMethod();
とできるらしい
0176デフォルトの名無しさん
NGNG0177デフォルトの名無しさん
NGNG0178デフォルトの名無しさん
NGNG集合は言葉が正しくないな。集成 (Aggrigation) だわ
0179デフォルトの名無しさん
NGNG0180仕様書無しさん
NGNGなんで？
0181デフォルトの名無しさん
NGNGグルーコード書くのめんどくさくて嫌い
0182デフォルトの名無しさん
NGNGポリモフィズムを必要とするプログラムって、それでなくても組めるし
0183デフォルトの名無しさん
NGNGポリモルフィズムって、要するにパラメータでディスパッチができれば
いいだけのことだもんね。
そんなのCの頃だって関数ポインタテーブルでやってたしぃ。
0184デフォルトの名無しさん
NGNG何を当たり前の話しているんだ。
0185デフォルトの名無しさん
NGNG論点ずれてない？
実装継承はいろいろ問題があるからコンポジションにしようってのが
このスレの話の流れだと思うんだが。
0186デフォルトの名無しさん
NGNGおまえがずれてるだろ。
この話の流れは
>>1 全部コンポジションでいいじゃないか(問題提起)
-> ﾌﾟｯ勉強不足だな継承は必要なんだよ(大勢)
-> 雑談
-> >>182 >>1の考えはわかりやすくて好きだ(1に賛同する少数派)。
0187デフォルトの名無しさん
NGNGそもそも抽象化とは数多くあるクラスの共通の機能を抽出する行為なのに
プログラマがしなければならない思考の順序がプログラムの作成順序とは逆で
雑多なクラスを作る前に、共通機能を決めなければならない、
だからせっかく作ったライブラリが歪む事になる。
これが恩恵は少なく弊害は多い理由だと思う、
が、STLやらboostやら見ていると改善余地はあるかなと思ったりもする。
クラス継承は使わなくてもすむなら使わないに越した事はないが、言語機構的に無くされるとちと困る。
少なくともgotoが無いと困る程度には困る。
0188デフォルトの名無しさん
NGNG・抽象→基底（いやこれも派生だけどね）→派生
これが人が無理なく管理できる継承ネストの目安かと
0189デフォルトの名無しさん
NGNG>どうしても継承をしたいとなると、スーパークラスは派生クラスを作った後で決めたい
この案はいいな。
トリッキーでなく実現可能な言語ってあったりするの？
0190デフォルトの名無しさん
NGNG｢(抽象)基底クラスの抽出｣ってフレーズを、
聞いた事ありません？
0191デフォルトの名無しさん
NGNG0192デフォルトの名無しさん
NGNG0193デフォルトの名無しさん
NGNG言語に備わってないことを無理やりやるのは好きじゃないね。
特に委譲しまくりはめんどい。
何事もほどほどにバランスよく好き嫌いせずに使っとけ。
0194デフォルトの名無しさん
NGNGその実は
「俺の方法が１番、俺と同じようにやれ」
と言っているのと同じことだったりして。
おまえは「ひまわり」や「TTSネオ」も
バランスよく使っているのかと小一時間問い詰めたい。
0195デフォルトの名無しさん
NGNG0196デフォルトの名無しさん
NGNG0197デフォルトの名無しさん
NGNGつまり、「自分（の基準）が一番バランスが良い」という訳で。。。
0198０００&rlo;ｯﾟﾌ(´ゝ_,｀)&lro;
NGNG0199デフォルトの名無しさん
NGNG0200デフォルトの名無しさん
NGNG0201デフォルトの名無しさん
NGNG0202デフォルトの名無しさん
05/02/03 16:25:20残念!!
小３からやり直せー斬り!!
0203デフォルトの名無しさん
05/02/03 18:57:4202041
05/02/10 00:29:360205デフォルトの名無しさん
05/02/10 22:47:130206デフォルトの名無しさん
05/02/12 01:31:140207デフォルトの名無しさん
05/02/15 12:37:48>海面下730mの海底に達した｡
何が？
0208デフォルトの名無しさん
05/02/15 14:41:550209デフォルトの名無しさん
05/02/16 02:19:03泣きそう。
0210デフォルトの名無しさん
05/02/27 08:09:39確かに当面の面倒はないが、まったく関係ない余分な機能やらincludeファイルやらを抱え込むことに…
犬から猫を派生させたみたいになりそうなんですが、
実務だとこういう手段がとられることって結構あるんですか？
0211デフォルトの名無しさん
05/02/27 10:47:33ない。機能面から設計してる時点であぼーん。
0212デフォルトの名無しさん
05/02/28 10:35:18このように使われるから>>1みたいなのが出てくるってコトね
全く関係ない余分な機能やらってｵﾜｯﾄﾙ
0213211
05/02/28 14:41:22本当は機能面じゃなくて実装面って書きたかったのです。
0214デフォルトの名無しさん
05/03/08 01:37:34もし継承したいんなら、その共通する機能で別のくくりができるだろうから
それだけ切り出した方がまだイイと思うぞ。
つーか継承する必要なさそうな予感
安易な継承は、グダグダなソースを産む元
0215デフォルトの名無しさん
05/03/16 22:47:38javaそのものがアンチパターンのようだ
0216デフォルトの名無しさん
2005/03/30(水) 02:08:36アジャイルじゃねえよ。継承させろよ。適度に弁えて使うからさあ。
0217デフォルトの名無しさん
NGNG"Modifier Class Template"でググれ
0218デフォルトの名無しさん
2005/04/06(水) 19:35:380219デフォルトの名無しさん
2005/04/06(水) 22:00:08public: virtual void method() = 0;
};
class super_super : public inter {
public: virtual void method();
};
class super : public inter {
private: super_super *ss;
public super() : ss(new super_super) {}
public ~super() { delete ss; }
public: virtual void method() {
ss->method();
additional_process();
};
class self : public inter {
private: super *s;
public self() : s(new super) {}
public ~self() { delete s; }
public: virtual void method() {
s->method();
additional_process2();
};
interface継承だけで、2段階の実装継承を委譲で実現するとこんなかんじ
コンストラクター起動で、newが二回余分に走るｗ
method()呼んだときに余分に生じるポインタ参照はいくつだ？
効率的に終わってるよ
0220デフォルトの名無しさん
2005/04/07(木) 12:13:15■ このスレッドは過去ログ倉庫に格納されています