-OOP限定-プログラム設計相談室
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/09/24(土) 16:35:590669デフォルトの名無しさん
2011/07/11(月) 20:26:18.53集約？←→継承
「OOPにおいて機能を再利用するためによく知られた二つの技法に、
クラス継承とオブジェクトコンポジショがある」という言い方。
インタフェースは広い意味ではオブジェクトの特性を定義したもの。
抽象クラスはそれに部分的な実装を与えたもの。
四つのうちから一つを選ぶようなものではないし、
四つ並べて語るようなものでもない。
0670デフォルトの名無しさん
2011/07/11(月) 20:35:42.37そのレベルの話で済むなら、>>665みたいな疑問は出て来ないんじゃないか。
何かしら、例が有った方が良いんじゃないかね。
0671667
2011/07/12(火) 17:29:18.58>>668
原則としてはこの説明がしっくり来るんですよね。
抽象概念に対して具象、あるいはその逆でもあれば抽象クラス、部品を持つようになっていれば集約、行為を追加したければインターフェース。
>>669
抽象度のレベルが違うのですか。
個人的には継承でなければ旨みが無いという状況でない限り、設計でも再利用でもオブジェクトコンポジションにしたくなるのです。
設計で継承しようとしたら、.NETのコントロール関連の仕組みに匹敵するプログラム的な仕組みを作らないと旨みがない気がしますし、
再利用で継承を利用しよう、という考えは割と最初に放棄してしまいます。
0672デフォルトの名無しさん
2011/07/12(火) 23:58:24.14抽象化クラスは、クラスであるためアクセス制御ができる。
やや変則的な話だけど、これを応用すると、ある抽象化クラスを
継承したクラスのオブジェクトのみしか参加できないネットワークを
構築することができる。
abstract class ChildNet
{
protected int abstract int privateValue();
protected int callPrivateValue(ChildNet group)
{
//子クラスは他の子クラスから値を抉り出す。
return group.privateValue();
}
}
これに加え、抽象化クラスなんで当然ネットワークに存在するオブジェクトに
義務を持たせる事が可能になる。
0673デフォルトの名無しさん
2011/07/13(水) 00:06:35.60他の子クラスが持ってる値を渡してやる必要はなくて、
自分で噛み砕いた値を自分の子に渡してやってもネットワークは成立するよ。
0674デフォルトの名無しさん
2011/07/14(木) 10:33:20.48もうこれはケースバイケースとしかいいようが無いような気が。
ただ、>>671の言うとおり、上手く抽象クラスがフィットするケースじゃない限り、
コンポジションで間に合うし、そのほうが無難な事が多い。
C++とかの例で言うと、継承の場合ヘッダ(.h)は *必ず* 抽象クラスのヘッダに依存するが、
コンポジションの場合、実装(.c)が部品のヘッダに依存しても、
コンポジションしたオブジェクトのヘッダは部品に依存させないようにできる。
部品の実装やインターフェースに変更が入っても全体を再コンパイルする必要はない。
抽象レベルでの話題であることは分かるんだけど、
結局これから実装するものは実装レベルでの話も考えないと依存しまくりになる。
C#とかの依存の話は詳しくないので識者がいたらPLZ。
0675デフォルトの名無しさん
2011/07/14(木) 12:56:49.20なんでもコンポジションって、オブジェクト指向っていうよりただのコンポーネント化だよね
0676デフォルトの名無しさん
2011/07/14(木) 13:21:09.21コンポジションオブジェクトのコンストラクタで部品の抽象ファクトリ渡すとかどうでもできるだろｗ
0677デフォルトの名無しさん
2011/07/14(木) 19:19:46.230678デフォルトの名無しさん
2011/07/14(木) 20:05:15.64それ続けていくと OOPの複雑さだけが協調されて インテリセンスが無いと手に負えないOOPの世界になるんでは？
まっ ツールがあるから使えという事も言えるが．．． チームプロジェクトの難易度が上がるような気がするが？
0679デフォルトの名無しさん
2011/07/14(木) 22:59:55.68実装を使い捨てにしてインタフェースを再利用すれば
多態性を持たせるのは十分だろ。
0680デフォルトの名無しさん
2011/07/16(土) 20:23:41.42>ツールがあるから使え
俺は正にこれ派だなあ
インテリセンス無しじゃ書く気がしない、とまでは言わんが
仕事としてはやりたくないレベル
0681デフォルトの名無しさん
2011/07/19(火) 00:23:35.70つまり
断＝入ってくる要らない物を断つ
捨＝家にずっとある要らない物を捨てる
離＝物への執着から離れる
これを
断＝今必要なない実装をやめる
捨＝使っていないクラスを破棄する
離＝既存クラスへの執着から離れる（見切りをつけ新規につくる）
いま必要なOOの実装だけを行い。
将来必要なるかもしれないと言って実装をしない。
あれは使うかもしれないとクラスやロジックを残さない。
とにかくシンプルに作る。これがOOの設計では一番。
0682デフォルトの名無しさん
2011/07/19(火) 18:19:02.300683デフォルトの名無しさん
2011/07/20(水) 08:52:51.030684デフォルトの名無しさん
2011/07/20(水) 09:30:13.800685デフォルトの名無しさん
2011/07/30(土) 11:35:29.22YAGNIの方が再発見かもしれない。
つまり真理とは古今東西、昔から変わらないということか。
0686デフォルトの名無しさん
2011/07/30(土) 22:28:00.22俺は泥縄と呼ぶことにする
0687デフォルトの名無しさん
2011/07/30(土) 23:54:27.92単なる消耗戦にならないか？
0688デフォルトの名無しさん
2011/07/31(日) 08:49:02.91一体何の話だよｗ
0689デフォルトの名無しさん
2011/07/31(日) 11:01:04.67戦術＝目の前の問題の解決/対処法。
既存プログラムを改修するときは、現実の問題に集中すればいいが
最初にベースとなるプログラムを作るときは、将来への対応も必要。
例え、９０％の労力が無駄になっても、戦術で行うにはそれ以上の労力が掛かる場合が多い。
よく経験するだろう、元の作りが悪いから修正しにくいとか
もし、ソフトが永遠につかわれたなら、そのコストが莫大になうぞ。
まっソフトの寿命なんて大半が５年もないが。
0690デフォルトの名無しさん
2011/07/31(日) 11:10:05.090691デフォルトの名無しさん
2011/07/31(日) 12:01:16.140692デフォルトの名無しさん
2011/07/31(日) 12:21:24.94目の前の現実と、将来への対応と言う意味で
戦略と戦術が俺のなかでは一番ピンときたから使った。
あきらかに俺の主観だな、別の言い方を考えるは。
0693デフォルトの名無しさん
2011/07/31(日) 13:27:08.50最後の行にはげしく同意
0694デフォルトの名無しさん
2011/07/31(日) 17:42:30.73無理にCのをC++に（better Cではなく）置き換えてるせいで
OOP原則？ナニそれ？
みたいなソース触った経験ある
0695デフォルトの名無しさん
2011/07/31(日) 18:11:53.17昔作った物は、10年超えても稼動し続ける （稼動し続けさせられる） 様なのが多かったとしても
これから新しく作る物は、そんなに長く稼動し続ける物はそう多く無い様な気はする。
0696デフォルトの名無しさん
2011/07/31(日) 18:24:47.150697デフォルトの名無しさん
2011/07/31(日) 18:43:30.06まあ確かになｗ
俺は、10年も前に出来た様なソフト （Webアプリ） の保守・アップデート案件で
ここ3年くらい専業テスターやってるけど、3年前と今年は丸々リファクタリングだわ。
0698デフォルトの名無しさん
2011/08/02(火) 07:38:46.350699デフォルトの名無しさん
2011/08/02(火) 09:38:35.61俺が五年前にフルスクラッチで書いたクラサバは、
今も各所で元気に稼動しております。
0700デフォルトの名無しさん
2011/08/04(木) 18:51:24.420701デフォルトの名無しさん
2011/08/04(木) 20:13:23.20減価償却が５年だからな、馬鹿な経営者はソフトを作り変える。
まっ仕事も増えるから批判もできんが。
0702デフォルトの名無しさん
2011/08/06(土) 20:07:16.41話が噛み合わないっつか，
「ブラックボックスでええんちゃうの？」 つても、
「モデル化できへん」とか
言い出すやからと仕事する羽目になったんだが
0703デフォルトの名無しさん
2011/08/06(土) 21:53:52.84入力と状態を引数に取って出力と次の状態を返す関数だよ、くらいでいいだろ
0704デフォルトの名無しさん
2011/08/07(日) 12:58:04.510705デフォルトの名無しさん
2011/08/07(日) 15:27:21.39ええんちゃうの(笑)
できへん(笑)
そんな気持ち悪い言葉を使っているから意志の疎通ができないのでは？
0706デフォルトの名無しさん
2011/08/16(火) 23:05:37.94関西なら関西弁が普通でしょ
0707デフォルトの名無しさん
2011/08/17(水) 19:39:41.33はどの派生クラスのメンバー関数が呼ばれてるのか分からなくて解析が
困難になるから困ると思う人は俺以外にもいるかいな。
0708デフォルトの名無しさん
2011/08/17(水) 20:17:45.78それは思うが、メソッドのコメントアウトで結構どうにでもなる。
0709デフォルトの名無しさん
2011/08/17(水) 22:49:57.19既存ソースを変更しない為だから、既存のソースを読む必要はない。（機能が分かればいい）
とは言っても、既存のソースを読まなければならなくなるのも現実だから
最低限トリッキーなコードは書かないぐらいの対応はすれば十分だと思う。
だいたい、読みやすい読みにくいは、その個人の技術力や経験に関係するから
誰にでも分かるよようなコードだと、初心者向けのコードになるけど、それは違うと思う。
0710デフォルトの名無しさん
2011/08/18(木) 02:08:14.230711デフォルトの名無しさん
2011/08/18(木) 03:53:24.03それはお前が馬鹿なだけｗ
ただ、あると便利なのは事実だな。
最近はポリモーフィズムとかで
メソッドの候補が複数あるとき、
ちゃんと候補を出してくれる。
0712デフォルトの名無しさん
2011/08/18(木) 21:42:40.72どんだけレベル低いんだよ。クラス図見ろよ
といいたいところだけど、ロクに設計されずドキュメントも起こさず
思いつくままにダラダラと派生クラス作成してる現場も沢山あるよな
と思った。
0713デフォルトの名無しさん
2011/08/18(木) 21:46:55.76だがしかし、簡単に想像はつくな。
チームでやっててアホな展開にどんどん突き進むような場合。
0714デフォルトの名無しさん
2011/09/08(木) 20:41:41.88じゃあおれはJIT
0715デフォルトの名無しさん
2011/09/11(日) 14:20:51.11間に生成クラスみたいなのをはさんだほうが良いでしょうか？
0716デフォルトの名無しさん
2011/09/11(日) 14:25:54.820717デフォルトの名無しさん
2011/09/11(日) 18:08:15.00そのまま扱う場合と、オブジェクトにマッピングして使う場合があると思いますが
（この場合のマッピングは、機能のラッピングではなくフィールドへのマッピングです）
どのような設計基準で使い分けるといいでしょうか？
0718デフォルトの名無しさん
2011/09/11(日) 18:20:22.54というのも最近の開発環境ではIDEを使うのが一般的で、
IDE上ならメンバ名の自動補完やヘルプを参照しやすいのでプログラミングし易いから
対してそのままSQL的にアクセスするのはメンバが不定/未定な場合に使うときがある
すっごく稀なのでヒューマンエラーをものともしないテスト以前の動作確認のときに使うかな
ただし個人的意見なのであまり参考にならないな
0719デフォルトの名無しさん
2011/09/12(月) 23:00:05.33レスポンスやスタックオーバーフローとかの問題でどうしても
そのままのデータを使用しないといけない時がありますよね。
開発の途中で問題が発生した場合など影響が大きいので
あらかじめ配慮してつくるべきなのかなと思っています。
0720デフォルトの名無しさん
2011/09/12(月) 23:58:24.90>ありがとうございます
いいぇ、私は何もしていません。自分自身で解決していると思います。
>data_d:array[0..10000000,0..30] of double
Integerの場合は、「data_d:array[0..10000000,0..60] of Integer」と定義しても大丈夫なんでしょうか？
>>312
>静的配列と動的配列はメモリ確保の方法が全く違うんだが
すみません、"全く違う"とはどう違うんでしょうか？教えて下さい。
>>313
>ローカル変数として確保しようとしてスタックオーバーフロー起こしただけだったりして
すみません、ローカル変数の確保がなぜ”スタック”オーバーフローになるのか、教えて下さい。
0721デフォルトの名無しさん
2011/09/13(火) 11:01:06.03スタック消費するならオーバーフローするのは当たり前な気がするが・・・？
0722デフォルトの名無しさん
2011/09/15(木) 00:28:47.64実体を持つstaticフィールドを1個だけもち、全てのインスタンスが、そのフィールドに問い合わせ
するようにしても同じじゃん。
classs Logger
{
private static LoggerCore core;
public Logger()
{
if( null == core ) core = new LoggerCore();
}
}
0723デフォルトの名無しさん
2011/09/18(日) 12:37:17.44何が便利なんだか、わからん。
ただ、LoggerでLoggerCoreの全てのメソッドを、いちいち委譲しなきゃならなくなった
だけなのでは？
0724デフォルトの名無しさん
2011/09/18(日) 13:30:35.43Core自体は処理をもたなくてもいいんだよ。
言語によっては構造体でいい。
あと、シングルトンで継承しない場合はともかく、
したほうが良い場合でも、staticメソッドを使う場合は
上手く継承できない。
更に言えば、コンストラクタでオブジェクトを生成するのを
前提としたインターフェースに対し、staticメソッドでオブジェクトを返す
シングルトンオブジェクトだけは特別扱いしなきゃならない。
object.exampleNew(Logger.class); //Singletonも他のクラスと同様に生成できるべき。
0725デフォルトの名無しさん
2011/09/18(日) 17:37:53.97new LoggerCore(); でインスタンスを生成されると困るから
Singletonにするのでは？
0726デフォルトの名無しさん
2011/09/18(日) 17:48:03.390727デフォルトの名無しさん
2011/09/18(日) 19:10:47.820728デフォルトの名無しさん
2011/09/18(日) 19:21:34.270729デフォルトの名無しさん
2011/09/18(日) 21:31:28.690730デフォルトの名無しさん
2011/09/18(日) 22:25:49.47「Coreが処理を持たない」って、データだけ持つの？それで隠蔽化できてるの？
あと、シングルトンであるべきか否かはクラスの責務で決まるはずだから、継承したら変わるのでは？
まぁ「コンストラクタでオブジェクトを生成〜」は分からんでもない。シングルトンオブジェクトを
ラップするクラスを作る必要があるので、確かにこれに似た状態になるな。
0731デフォルトの名無しさん
2011/09/18(日) 22:31:28.55>>726が実現できるのは、内部クラスを作れる言語だけだ。
0732デフォルトの名無しさん
2011/09/18(日) 22:31:59.86class Logger
{
private static class LogField
{
int data1;
int data2;
}
private static LogFiled core;
public Logger()
{
if( Logger.core == null )
{
Logger.core = new LogField();
//必要なら初期化
}
}
//他coreを操作するメンバー
}
0733デフォルトの名無しさん
2011/09/19(月) 03:18:31.74例となるクラス図が載ってるサイトありますか？
0734デフォルトの名無しさん
2011/09/19(月) 22:01:52.57確かにそれでもシングルトンにはなるけど、
new Logger()だと中身が共有されてるってことを想像しづらいから、staticメソッドを使うんだと思う。
0735デフォルトの名無しさん
2011/09/19(月) 23:23:58.980736デフォルトの名無しさん
2011/09/20(火) 11:49:03.57むしろシングルトンと通常のオブジェクトを
インターフェース的に区別する必用がある？
0737デフォルトの名無しさん
2011/09/22(木) 01:05:30.38すべてのクラスは引数なしのコンストラクタを持つべきって主張してるわけじゃないよね。
シングルトンなんて使わずにモノステートを使おうよって話？
例にあるLogger自体はシングルトンじゃないから、シングルトンの説明に使おうとするなら根本的に間違ってると思うけど。
0738デフォルトの名無しさん
2011/09/22(木) 09:47:13.61引数があるかどうかはどうでもいいんだけど、
他のオブジェクトとインターフェースは同一にすべきとは考えてる。
リフレクションとか使う既存のリソースを再利用できるからね。
シングルトンと違うってのは、staticメソッドを使わないから違うって事言ってるの?
それとも空のインスタンスが生成されるから機能面で違うといってるの?
0739デフォルトの名無しさん
2011/09/22(木) 09:57:37.36モノステートとはちょと違うね。
例では分かりづらいけど、全てインスタンスメソッドだから。
0740デフォルトの名無しさん
2011/09/22(木) 21:07:57.85>>733
PACパターン で画像検索
0741デフォルトの名無しさん
2011/09/22(木) 22:10:00.87なるほどねー。ググったらstaticメソッドだらけのクラスを
モノステートと呼んでる所があったから違うと思ったけど、
ググり直したら全部インスタンスメソッドのものを
モノステートと呼んでる所があった。
これからはモノステートを
調べる事にするわ。
0742デフォルトの名無しさん
2011/09/23(金) 00:15:41.36完全に monostate が singleton の上位みたいな感じだな
よっぽど継承を封じ込めたくてfinalも無いような環境か
アドレスレベルで比較して同一と判断しなきゃならない場合を除いて
基本的に monostate を使っとけばいい感じだな。
0743デフォルトの名無しさん
2011/09/24(土) 22:41:09.72state/strategyとFactoryMethod使うと
OOっぽさが6割増し位になるよね
0744デフォルトの名無しさん
2011/10/21(金) 10:34:03.120745デフォルトの名無しさん
2011/10/22(土) 19:39:25.14自販機とかの架空の例や、顧客どうのこうのといった大きな例じゃなく、
小さなアプリを UML の記述から始めて OOP で作って完成させる例がほしいです
解説する言語も、プログラミング言語も問いません
数独ソルバ程度の小さなアプリであれば数独ソルバでなくてもいいんですが、
数独ソルバの例だとありがたいです
0746デフォルトの名無しさん
2011/10/22(土) 23:05:57.480747デフォルトの名無しさん
2011/10/22(土) 23:37:24.78いや、宿題じゃなくて・・・
関数型言語スレで、関数型言語だとUMLは書かないのかという質問があって、
OOP と FP でアプリの作り方（完成までの道のり）にどれくらい違いがあるのか興味が沸いて、
比較してみようと思いました
それで、既に UML を使った OOP での例があるなら、
OOP の方はそれを拝借した方が手っ取り早いと思っただけです
無いのでしたら、自分で両方の言語で試してみます
0748デフォルトの名無しさん
2011/10/23(日) 01:28:31.63一般的なUMLベースのOOP入門という題材なら「いくらでも」ころがってる
目的と手段をはき違えているように見える
もしどうしても数独ソルバにこだわりたいのなら、宿題スレへ逝ケ
0749デフォルトの名無しさん
2011/10/23(日) 02:12:11.39「数独ソルバでなくてもいい」 >>745 で言いました
> 一般的なUMLベースのOOP入門という題材なら「いくらでも」ころがってる
UML を使ってゼロから設計してアプリケーションとして完成させている例が無いです
「いくらでも」と言うのなら 10 例くらいWebページを挙げてほしいです
UMLで図を描いて終わってるページや、ソースコードだけのページはありますが
数独ソルバなら、パラダイム間で設計手法を比較する例としては
登場すると思われるクラスの数も多すぎず少なすぎず、
またデータが入力されたら解の出力まで処理が一直線なので、
クラス全体の関係を比較的見通し安いと思ったからです
今のところ他にいい例が思い浮かびません
また、FP の方では数独ソルバを既にゼロから設計して完成させているので、
OOP の方でも同じ例の方が楽です（別の例なら FP の方でも新規に作る必要がある）
べつに拘っては無いので、何度も言いますが、数独ソルバでなくてもいいです
> 目的と手段をはき違えているように見える
目的は >>747 のとおり設計手法の比較で、手段は（今のところ）数独ソルバですけど
履き違えてるように見えたのですか？
0750デフォルトの名無しさん
2011/10/24(月) 18:00:43.900751デフォルトの名無しさん
2011/10/24(月) 19:13:45.03無理かどうかはどうでも良くて、そういうWebページがないかどうかです
いくらでもあるそうですけど・・・
0752デフォルトの名無しさん
2011/10/25(火) 08:10:57.02そういう題材でサンプルを作ろうという話がそもそもない、というのはあるかもよ。
調べてないから想像だけど。
試しに、軽く自分で設計してみたらどうか。
0753デフォルトの名無しさん
2011/10/25(火) 08:14:31.30http://twitter.com/asami224/statuses/128609304684134401
http://twitter.com/asami224/statuses/128609800404746240
0754デフォルトの名無しさん
2011/10/25(火) 18:35:52.68その軽く設計ってのを省けるなら省きたいって質問なんだと思う。
すでに数独ソルバで片方やっちまってるからOOP版があれば欲しい、
ないなら数独ソルバには拘らないからOOPで設計実装してるの何かない？ ってことだと思うんだが。
あとどうでもいいけどFPって聞くと見積りの方が先に出てきて変な感じだ。
0755デフォルトの名無しさん
2011/10/25(火) 19:22:22.53その数独ソルバってのがよく分からないんだけど、多分アルゴリズム系だよね？
題材自体が、責務でインタフェース切ってオブジェクトに分割して、という方法論と
合わない気がするなぁ。
それ以外でもいいということなら、なんか著名な書籍を一冊買ってくるとかの方が早いかも。
0756デフォルトの名無しさん
2011/10/25(火) 19:46:20.70もの凄く分かりやすい代弁ありがとうございます
私も３行で自分の発言をまとめられる人間になりたい
>>755
私にとってはアルゴリズム系という意味の方がよく分からないのですが・・・
トイブログラムとか実験プログラム、検証プログラムとかの類じゃなくて、
ユーザーが数独の初期配置を画面に入力し、解答ボタンを押すと、
その数独の解答が表示されるというアプリです
当然、問題自体が間違っていて解答が複数存在すれば複数表示されますし、
解無しなら解無しと表示されます
すいません、その「著名な書籍」を一冊教えていただきたいです
今まで買ったオブジェクト指向の入門書や方法論的な本、UMLの本などは、
使えるアプリケーションとして完成させるまでに至っていませんでした
コアの部分をサンプルや例題として使ってオブジェクト指向的に考えたり、
アプリの全体的な設計図をUMLで表す道筋を何かのサンプルで示す、
というものばかりで、どちらも解説は丁寧ですが、「ゼロから完成」が無いんです
Webページも上記のパターンのどちらかのしか私は見つけられませんでした
いくらでも転がっているそうですけど
自分で作ってもいいんですが、私のようなオブジェクト指向未熟者じゃなく
お手本となるようなページを探してましたが、無さそうなので、とりあえず諦め、
拙いなりに自分でゼロから作る事にします
ありがとうございました
0757デフォルトの名無しさん
2011/10/25(火) 19:48:48.01正しい意味を始めて知りました
0758デフォルトの名無しさん
2011/10/25(火) 19:50:58.75すいません、意味合ってました
これだから電子辞書は ヽ(｀Д´#)ﾉ ﾑｷｰ
0759デフォルトの名無しさん
2011/10/25(火) 21:33:15.74ああなるほど、そういう「アプリケーション」レベルの設計の話か。
残念ながら、俺も「あるなら教えて欲しい」という感じなので力にはなれそうもない。
ただ、どんな手法でもウェブ上で「アプリケーションを一から設計して〜」というサイトは見たことが無い。
「ウェブは暇人によって支えられている」とは誰かの言葉だが、そういうメディアじゃないんだろうな、ウェブは。
なので本で探した方が確率は高いとは思う。
0760デフォルトの名無しさん
2011/11/05(土) 22:40:44.92TDDやプロトタイピング等で、ソースコードを設計書代わりにしちまうしなあ
0761デフォルトの名無しさん
2011/11/17(木) 13:21:21.981マス１マスをオブジェクトにするとかあるな。
マスに当てはまる候補を格納したり、
マスに所属するグループ持たせたり、
グループをオブジェクトで表現したり、
枠の判定を多態で表したり。
0762デフォルトの名無しさん
2011/11/28(月) 11:52:55.15・ネコ亜目 Feliformia
・ネコ科 Felidae : ネコ類、18属37種
・イヌ亜目 Caniformia
・イヌ下目 Cynoidea
・イヌ科 Canidae : イヌとその類縁、10属35種
この分類納得行かないよなｗ
イヌ科の元がネコ目だなんてｗ
0763デフォルトの名無しさん
2011/11/28(月) 18:13:25.550764デフォルトの名無しさん
2012/01/12(木) 23:56:38.89オブジェクト指向的な考えからするとdynamic_cast同様あまり良い設計とは言えないものなのかな？
0765デフォルトの名無しさん
2012/01/13(金) 00:24:26.78プロセス超えるからわざわざ書いてるだけで
面倒なだけだと思うけど。
0766デフォルトの名無しさん
2012/01/13(金) 00:39:51.73dynamic_castだとインターフェース以外にも正常にキャストできるけどQueryInterfaceはそれを制限できる、とか
直接的な継承関係がなくてもインターフェースを継承しているメンバのアドレスを返すことで代替できる、とか
0767デフォルトの名無しさん
2012/01/13(金) 20:27:05.48どいうこと!?
0768デフォルトの名無しさん
2012/01/13(金) 20:40:14.84■ このスレッドは過去ログ倉庫に格納されています