当初、この記事ではR＃とVS 2010でこの機能の比較分析を行いたいと考えていましたが、執筆中にVS 2010の呼び出し階層は批判（イベント、インターフェイス、クロージャなどでは機能しません）および例には耐えられないことが判明しました記事からはまったく有用で合理的なものを示していません。 したがって、R＃の呼び出し階層でできる興味深いことだけを説明します。
イベント
Foo
メソッド（ R＃-> Inspect-> Outgoing ）からの発信呼び出しを探してみましょう。
using System;
public class C2
{
public event EventHandler E = (sender, args) => Subscription_In_Initializer();
static void Subscription_In_Initializer()
{
}
void Foo()
{
E( this , EventArgs .Empty);
}
}
class C3
{
void Bar()
{
new C2().E += Subscription_In_Method;
}
void Subscription_In_Method( object sender, EventArgs e)
{
}
}
* This source code was highlighted with Source Code Highlighter .
結果は明白で理解しやすいものです。 R＃は、すべての
event E
サブスクリプションを安全に検索し、可能な呼び出しオプションとして表示します。 超自然的なものはありませんが、非常に快適です。
ジェネリック
簡単なコード例を考えてみましょう。
public abstract class Base<T>
{
public void Do(T value )
{
DoImplementation( value );
}
protected abstract void DoImplementation(T value );
}
public class Concrete1 : Base< int >
{
protected override void DoImplementation( int value )
{
}
}
public class Concrete2 : Base< string >
{
protected override void DoImplementation( string value )
{
}
}
* This source code was highlighted with Source Code Highlighter .
次に、
Base.Foo
からの発信呼び出しを
Base.Foo
ます。
すべてが明らかです。
次に、このような
Main
クラスを追加し、
Foo
からの発信呼び出しを探します。
class Main
{
void Foo()
{
Concrete2 c = null ; // null,
c.Do( "string" );
}
}
* This source code was highlighted with Source Code Highlighter .
Concrete1.DoImplementation
呼び出してください！ これは、R＃が型パラメーターを見て、
Base.Do
T->string
呼び出されると結論付けた
Base.Do
（結果の2行目を参照してください：
Base<string>.Do
-
string
は、特定の置換を持つメソッドを呼び出していることを示します）、それに応じて
Concrete1
フィルタリングしました、なぜなら 置換
T->int
使用して継承を使用します。
少し複雑ですが、Visitorパターンを使用したさらに重要な例です。
ConcreteVisitor1.VisitNode1
メソッドへの着信呼び出しを見つけます（ R＃-> Inspect-> Incoming Calls ）。 この例では、メソッド呼び出しに対して反対のように、すでに反対方向に進んでいることに注意してください。
public interface IVisitor<T>
{
void VisitNode1(T data);
}
class Node1
{
public void Accept<T>(IVisitor<T> v, T data)
{
v.VisitNode1(data);
}
}
public class ConcreteVisitor1 : IVisitor< int >
{
public void VisitNode1( int data)
{
}
}
public class ConcreteVisitor2 : IVisitor< string >
{
public void VisitNode1( string data)
{
}
}
public class C1
{
void Foo()
{
var v = new ConcreteVisitor1();
new Node1().Accept(v, 1);
}
void Foo2()
{
var v = new ConcreteVisitor2();
new Node1().Accept(v, "string" );
}
}
* This source code was highlighted with Source Code Highlighter .
結果は次のようになります。
ジェネリックビジターを通過しても、R＃は型パラメーターの置換に関する情報を失わず、
Foo2
メソッドからの余分な呼び出しを除外できました。 分岐階層と多数のジェネリック型を作成した場合、そのようなロジックは検索領域を劇的に削減できます。
コンストラクター
フィールドコンストラクターとイニシャライザーを使用した、やや人工的な例です。
Derived
クラスのコンストラクターからの発信呼び出しを探しています。
class Base
{
public Base()
{
Base_Bar();
}
void Base_Bar()
{
}
}
class Derived : Base
{
int _i = Foo();
public Derived()
{
Bar();
}
void Bar()
{
}
static int Foo()
{
return 0;
}
}
* This source code was highlighted with Source Code Highlighter .
繰り返しますが、異常なことは何もありません。 R＃は、基本コンストラクターへの暗黙的な呼び出しを忘れずに、呼び出しの自然な順序を単に表示します。 これにより、経験の浅い開発者がコードを理解する時間を大幅に節約でき、疲れた経験のある開発者に役立ちます。
値の追跡。 結論の代わりに。
おやつに。 メニューR＃-> Inpectを見ると、2つの非常に興味深い項目「Value Origin」と「Value Destination」があります。 これらの2つの関数は、Data Flow Analysysを実装しています。 どこから来たのか、変数やパラメータの値がどこに行くのかを追跡できます。 当然、DFAはコレクションとデリゲートで動作し（コレクションからアイテムが取得され、コレクションへのアクセスの検索に進むという事実を追跡します）、
NullReferenceException
原因を見つけるのに絶対に不可欠です。 残念ながら、これには多くのスクリーンショットと例が必要になるため、次の記事でこれについて詳しく説明しますが、今のところは、DFAを自分で試して、好きなものとそうでないものについて話すことができます。