「pimpl」のすゝめ

普通のC++使い、銀天すばる @SubaruG

@yreeen そういう場合はデザインが悪いと解釈します。

普通のC++使い、銀天すばる @SubaruG

@yreeen っていうか、肥大化するとしても実装部分なので痛くも痒くもないというか。

ドクターねるねるねるね @DrNerunerunerun

@SubaruG 僕は実装もあんまり肥大化させたくないんですよね。コード内部のバグならまだしも、外部に原因があった場合とかをつきとめにくいです。

普通のC++使い、銀天すばる @SubaruG

継承を使った多態をクライアントコードで扱える程、僕の頭は賢くないので、実装部分はともかく、アプレケーションコードでは継承関係が一切出てこないようにしてますハイ。

ドクターねるねるねるね @DrNerunerunerun

例外使いたいよﾏﾏﾝ…

普通のC++使い、銀天すばる @SubaruG

s/アプレケーションコード/アプリケーションコード/

普通のC++使い、銀天すばる @SubaruG

@yreeen 外部に露出する面を増やしてるから外部原因のバグが生まれるのでは？

普通のC++使い、銀天すばる @SubaruG

継承による多態が強力で効率的なのは認めるんだけど、ちょっと強力すぎるというかなんというか。

ドクターねるねるねるね @DrNerunerunerun

@SubaruG あ、外部ってのはエンコーダが出力したファイルとかです。マルチメディア系のファイルは特に一部のエンコーダが仕様に準拠してないとかよくありまして。

ドクターねるねるねるね @DrNerunerunerun

このファイル形式ならこう、あれならこう…っていう条件分岐があるだけでデバッグが苦になるから不思議。

普通のC++使い、銀天すばる @SubaruG

@yreeen それだったら実装が大きいとか関係ないんじゃないですかね？

普通のC++使い、銀天すばる @SubaruG

内部実装として継承や多態を使うことは、たまにある。けど、それを露出させることはしない。理由は、実装が変わったときにクライアントコードも変えなきゃいけないから。

ドクターねるねるねるね @DrNerunerunerun

@SubaruG 変える必要ありますかね・・・？

普通のC++使い、銀天すばる @SubaruG

まーぶっちゃけ好みの問題ではある。

ドクターねるねるねるね @DrNerunerunerun

実装が大きいとデバッグ中にイラッとくる。特に動的にデバッグできない時が

普通のC++使い、銀天すばる @SubaruG

@yreeen 継承関係が変わったら変えなきゃダメでしょう。少なくとも。

普通のC++使い、銀天すばる @SubaruG

@yreeen 実装が大きいっていっても、その中で構造化は当然に行いますよね？

ドクターねるねるねるね @DrNerunerunerun

@SubaruG 行ってます。が、やっぱり分かれてたほうが見やすくて好きです。

普通のC++使い、銀天すばる @SubaruG

@yreeen ん？ 実装が大きい場合って、細かく分けて実装するんじゃないんですか？

ドクターねるねるねるね @DrNerunerunerun

継承による多態は内部の違いを外部に意識させないように使うもので、その内部の変化を外部で考えないといけないようなコードは設計が悪い…と思っちゃうんだよな。

普通のC++使い、銀天すばる @SubaruG

@yreeen それを「構造化」と表現したつもりなのですが。

ドクターねるねるねるね @DrNerunerunerun

@SubaruG クラスが完全に分かれてるほうが個人的に楽なんです。

ドクターねるねるねるね @DrNerunerunerun

言葉足らずだったorz

普通のC++使い、銀天すばる @SubaruG

@yreeen ですかー。いや僕も内部実装でクラス分けますし、その気持はわかります。

ドクターねるねるねるね @DrNerunerunerun

完全に　はおかしいな。同じインターフェースを継承した横のつながりになってるし