《編程絮語》之一

C#的語法脫胎于C++，因而保留了virtual關鍵字，可以定義一個虛方法（或虛屬性）。一個類的成員被定義為virtual，就意味著它在告訴自己的子類：我準備了一筆遺產，你可以全盤接受，也可以完全拒絕或者修改我的遺囑。顯然，虛方法授予子類的權利甚至大于抽象方法。子類面對抽象方法只有重寫（override）的權利，而對于虛方法，它還可以選擇完全繼承。

毫無疑問，虛方法破壞了對象的封裝性。如果不加約束的使用，會對調用方造成破壞，至少它有可能破壞子類與父類之間在外在行為上的一致性。因此，當我們在重寫虛方法時，務必要遵循Liskov替換原則。我們要保證對于調用方而言，子類對于父類是完全可以替換的。這里所謂的“替換”，是指子類不能破壞調用方對父類行為的期待。準確地說，子類在重寫父類的虛方法時，必須遵循調用該方法的前置條件與后置條件。這也是“契約式設計”的思想。最理想的狀態是讓使用對象甚至無法知道是否存在派生類[1]。即類的繼承體系對于調用者而言，必須體現外部接口的一致性，這樣才能做到調用者對派生類無知。

如果確實需要重寫父類的方法，最好的方式是擴展而不是修改。這實際上也是開放-封閉原則的體現。例如在Decorator模式中，我們重寫父類方法的目的，是為了實現對該方法的裝飾。Proxy模式的實現同樣如此。Michael C. Feathers對此給出的忠告是[2]：
1）盡可能避免重寫具體方法。
2）倘若真的重寫了某個具體方法，那么看看能否在重寫方法中調用被重寫的那個方法。

Feathers的忠告是針對Java語言，因為在C#中我們無法重寫具體方法，只能利用new關鍵字在子類中新建一個相同方法簽名的具體方法，而這樣的方法并不具備多態性。這里涉及到一個有趣的話題，是關于Java和C#的比較。在Java語言中，如果沒有添加任何關鍵字，則方法默認就是虛方法，任何子類都可以重寫它。C#則相反，它對虛方法給予了顯式的定義。Java語言的締造者顯然是“性本善”論者，他認為所有子類的實現者均抱著善意的態度來對待父類的方法，因而他賦予了子類相當程度的自由，但卻可能被別有用心者偷偷打開封裝的后門。如果確有非常重要的隱私防止被篡改，則可以利用final關鍵字來強制保護。C#語言的發明者則持有“性本惡”的論調，他惡意地揣測子類總是會不懷好意，所以提供了一套默認的強權，來保護父類的隱私。如果需要對子類開放，則明確地聲明為virtual，這就牢牢地把控制權攥緊在父類的手中。

C#保守的做法使得語言的特質更加安全(當然，Java會更加自由)，我們可以使用virtual的自由性，搭配方法的訪問限制，搭建一個安全合理的白盒框架。virtual關鍵字的含意本身就是面向子類的，所以，我們應該盡可能地將其放在protected方法中使用。如果該方法代表的行為確實需要公開給調用者，我們可以定義一個公開的具體方法，在其中調用一個受保護的虛方法。

在Template Method模式中，體現了C#這種劃分具體方法和虛方法的好處。Template Method模式要求子類只能部分地替換父類的實現，整個骨架則必須保持固定不變。在父類中，我們將模板方法定義為具體方法，將基本方法定義為抽象方法。模板方法規定了基本方法的調用順序，如果我們可以在子類中重寫模板方法，就可能破壞基本方法的調用順序，從而對整個策略造成影響。Strategy模式就不存在這個問題，因為它的策略是整體的。Template Method模式在模板方法中規定的骨架，實際上就是為調用者制訂的前置條件和后置條件。

有一種說法是不要在虛方法中訪問私有字段[3]。這存在一定的合理性。因為一旦我們在父類的虛方法中訪問了私有字段，那么在子類重寫該虛方法時，由于無法獲得父類的私有字段值，就可能會導致該字段值的缺失。但這種說法并不完全準確。一方面，我們認為Liskov替換原則主要是為了約束Is-A關系在行為上的一致性[4]，如果該字段對行為不會造成影響，則無大礙。另一方面，這也說明我們在重寫虛方法時，最佳實踐還是需要在重寫的同時，調用父類的虛方法，如Decorator模式的實現方式。

[1] Alan Shalloway, James R. Trott  Design Patterns Explained
[2] Michael C. Feathers  Working Effectively with Legacy Code
[3] Dino Esposito, Andrea Saltarello  Microsoft.NET Architecting Applications for the Enterprise
[4] Robert C. Martin Agile Software Development:Principles,Patterns and Practices