実行時の型情報はいつ使用しますか？

Question

私は何かのさまざまなサブクラスと、それらのサブクラスのインスタンスで動作するアルゴリズムを持っていて、アルゴリズムの動作がインスタンスのサブクラスの種類によって多少異なる場合、これを行うための最も一般的なオブジェクト指向の方法です仮想メソッドを使用しています。

たとえば、サブクラスがDOMノードの場合、アルゴリズムが子ノードを挿入する場合、そのアルゴリズムは親ノードがDOM要素（子を持つことができる）かDOMテキストt）：insertChildrenメソッドは、DomNode基本クラスの仮想（抽象）であり、DomElementおよびDomTextサブクラスのそれぞれで異なって実装されます。

もう1つの可能性は、値を読み取ることができる共通のプロパティをインスタンスに与えることです。たとえば、アルゴリズムはDomNode基本クラスのnodeTypeプロパティを読み取ることがあります。別の例では、共通のパケットヘッダーを共有するネットワークパケットの種類（サブクラス）が異なる場合があり、パケットヘッダーを読み取ってそのパケットの種類を確認できます。

私には、多くの実行時型情報を使用していない：ネットドットで

Object.GetType方法をダウンキャストC＃の

で

• isとasキーワード
• C++のtypeid演算子

新しいアルゴリズムを追加するときmはサブクラスのタイプに依存しますが、クラス階層に新しい仮想メソッドを追加する傾向があります。

私の質問は、仮想関数の代わりに実行時型情報を使用するのが適切なのはいつですか？

Answer 1

他の方法はありません。仮想メソッドは常に優先されますが、使用できないことがあります。いくつかの理由がありますが、最も一般的なのは、あなたが作業したいクラスのソースコードを持っていないか、変更できないということです。これは、レガシーシステムやクローズドソースの商用ライブラリで作業する場合によく発生します。

.NETでは、プラグインのように新しいアセンブリを即座に読み込む必要があり、基本クラスがなく、ダックタイピングのようなものを使用する必要があります。

Answer 2

C++では、（ほとんどデザインの選択肢が劣る）不明瞭なケースの中で、RTTIはいわゆるmulti methodsを実装する方法です。

Answer 3

dynamic_cast <>私が正しく覚えていれば、RTTIに依存しています。いくつかのあいまいな外部インターフェイスは、オブジェクトがvoidポインター（何らかの理由でが発生する可能性があります）が渡されたときにRTTIに依存することもあります。

言われているように、私は10年間のプロC++のメンテナンス作業で野生でtypeof（）を見たことがありません。 （幸運にも。）

Answer 4

ランタイムタイプのチェックがOKの場合は、More Effective C＃を参照してください。

項目3。特殊アルゴリズムジェネリックアルゴリズム 実行時型チェックの使用

でジェネリックを簡単に再利用することができます。 新しいタイプ の新しいインスタンス化は、同様の機能を持つ を持つ新しいタイプを意味します。

コードが少ないので、これはすべて素晴らしいです。しかし、ときどき より一般的な意味は、具体的に の利点を取っていないが、明らかに優れたアルゴリズムである を明らかにしている。これにはC＃ の言語規則が適用されます。あなたが を認識するため すべてそれが取るに​​は、より大きな能力を持っている、と 型パラメータは、その後 に特定のコードことを書くとき、あなたのアルゴリズムは より効率的にすることができるということです。さらに、 が異なる制約 を指定する第2ジェネリック型を作成することが常に機能するとは限りません。一般的な のインスタンス化は、オブジェクトのコンパイル時タイプ と実行時タイプではない に基づいています。 に失敗した場合は、 の可能性があります。

たとえば、IEnumerable < T>で表されるアイテムのシーケンスに逆順列挙を提供するクラスを作成するとします。逆方向に列挙するには、リスト< T>のようなインデクサアクセスを持つ中間コレクションに項目をコピーして、インデクサアクセスを逆に使ってコレクションを列挙することができます。しかし、元のIEnumerableがIListの場合、それを利用して、より効果的な方法（中間のコレクションにコピーしないで）を提供して、アイテムを逆向きに反復するのはなぜでしょうか。だから、基本的には、我々が利用できる特殊なものですが、同じ動作（シーケンスを逆順に繰り返します）を提供します。

一般的に、実行時の型チェックを慎重に検討し、Liskov Substituion Principleに違反していないことを確認する必要があります。

Answer 5

イベントハンドラは通常、オブジェクトを共通の祖先にダウンキャストしているため、この構造体（「is」および「as」）はDelphi開発者にとって非常によく知られています。たとえば、イベントOnClickは、TButton、TListBox、またはその他のいずれであっても、オブジェクトのタイプに関係なく、唯一の引数Sender：TObjectを渡します。このオブジェクトに関する詳細を知りたければ、 "as"でアクセスする必要がありますが、例外を避けるために、以前は "is"でチェックすることができます。このダウンキャスティングにより、厳密なクラス型チェックでは不可能であった、オブジェクトとメソッドのデザイン型バインディングが可能になります。ユーザーがButtonやListBoxをクリックしても同じことをしたいと考えていますが、異なるプロトタイプの関数を提供している場合、同じプロシージャにバインドすることはできません。

より一般的な場合、オブジェクトは、たとえばオブジェクトが変更されたことを通知する関数を呼び出すことができます。しかし、それはあらかじめ、目的地を "個人的に"知っている可能性を残しています。これは、すべてのオブジェクトの最も一般的な祖先として自己を渡すことによって行います（Delphiの場合のTObject）