例子很簡單，依照之前的規則，可以畫出如下一幅圖。圖中圓形的末端表示封閉、中斷繼承鏈；菱形的末端表示開放、允許構建繼承鏈；類描述中的等式，表示從該類型的對象引用調用對應方法（等號左邊的斜體）時，實際執行的代碼體是在何處（等號右邊的正常字體）定義的。
其實，為了確認這裡描述出來的方法的繼承鏈，甚至都不需要實地運行此代碼。將代碼放在Visual Studio裡，使用“重構”（Refactor）菜單中的“重命名”（Rename）修改方法名稱，待完成後就會發現在方法繼承鏈的中斷處，自動修改符號名稱的動作也中止了。
補充
對於 this 關鍵字，上述的規則也適用。只需要將 this 依照當前的代碼上下文翻譯為對應的類型引用，就可以依照之前敘述的方法確定最終調用的代碼了。例如在C中的Foo1方法裡假如有這麼一條語句：“this.Foo2()”。當在外部運行“D.Foo2()”時，就會就會解析到“C.Foo1()”，這時，C.Foo1()方法的內部在解析“this.Foo2()”時就會解析到D.Foo2()。
對於 base 關鍵字，則比較簡單，只是在基類的方法（這裡“基類的方法”一詞，請參見“用詞約定”的第6條。）中找到同名方法，然後調用，不存在解析虛函數的過程。
對於被委托對象包裝的方法指針，在調用委托時，仍會按照上述規則解析到正確的方法。
本文示例中使用了“Foo”開頭的方法名，而這個習慣借鑒自一些別的文章。這裡是有個典故還是怎麼？
