介紹一部分類和接口的高質量設計的準則。這些準則不但應該保證設計并且實現的類或者接口本身有高質量代碼，而且更重要的是在工業領域應該盡可能的使代碼的更新和維護不影響客戶的活動，主要也就是保持二進制代碼兼容(binary compatibility)和源代碼兼容(source compatibility)。我希望這些準則能幫助剛從學校進入工業領域的朋友盡快適應更高標準的編程要求，盡快提升自己的設計能力。 

　　文中以C++類的設計為討論范圍。

　　總提

　　面向對象編程對于產出高質量，易維護的代碼是非常有幫助的。面向對象編程的概念構建于三個基本特征之上：封裝，繼承，多態。在C++中，class是面向對象編程概念的核心和具體形式。class通過私有成員體現“封裝”，通過直接繼承或者組合體現“繼承”，通過虛函數和動態綁定(dynamic binding)體現“多態”。class的設計質量直接決定了整個系統的質量。

　　從整體功能層面談class設計，有這么三條原則：

　　·單一功能原則(Single Responsibility Principle)

　　一個class就其整體應該只提供單一的服務。如果一個class提供多樣的服務，那么就應該把它拆分，反之，如果一個在概念上單一的功能卻由幾個class負責，這幾個class應該合并。

　　·開放/封閉原則(Open/Close Principle)

　　一個設計并實現好的class，應該對擴充的動作開放，而對修改的動作封閉。也就是說，這個class應該是允許擴充的，但不允許修改。如果需要功能上的擴充，一般來說應該通過添加新類實現，而不是修改原類的代碼。添加新類不單可以通過直接繼承，也可以通過組合。

　　·最小驚訝原理(Least Surprise Principle)

　　在重載函數，或者子類實現父類虛函數時，應該基本維持函數原來所期望的功能。比如：

以下是代碼片段： class Pet {  　public:  　　virtual Talk() = 0;  };  class Cat : public Pet {  　public:  　　void Talk() { cout << "miao"; }  };  class Dog : public Pet {  　public:  　　void Talk() { BiteOwner(); }  };

　　class Dog 在實現虛函數Talk的時候，沒有像我們期望的那樣輸出狗吠聲，而是咬起主人來了。這是應該避免的。

　　接口和實現

　　在系統中，觀察一個class有兩個角度，從外部或者用戶角度我們看到的是接口，從內部我們看到的是實現。因為系統肯定要不斷修改，因此實現免不了不停的變化，但是接口又被要求盡量保持穩定。這兩者的矛盾必須通過良好的設計盡量避免，基本原則就是將實現細節與接口隔離。下面列出幾條比較具體點的：

　　·接口的設計保持最小而完整

　　精簡接口函數個數，使每一個函數有代表性，函數功能恰好覆蓋class的職能。一個最小的接口可以使維護簡單，增加潛在的代碼重用性，減少客戶的迷惑，并且也可以縮小頭文件長度和編譯時間。當改進函數時，應該用類似函數名實現改進而保留原函數，代碼注釋里應該有相應的說明?？梢栽黾有潞瘮?，但不能刪除舊函數。

　　·成員變量應該都為私有

　　顯而易見，public變量破壞封裝性以及接口和實現的分離；protected變量也可能使客戶編寫繼承類而依賴于父類的實現細節。

　　·避免函數返回成員變量的指針或引用

　　這么做也會使客戶代碼依賴于實現細節。

　　·考慮是否禁用編譯器缺省產生的函數

　　這些函數包括：復制構造函數，賦值操作符(operator =)。如果我們不打算定義自己的版本而不禁用默認版本的話，可能使客戶代碼在不注意的情況下調用這些函數。當實現發生改動時就可能引起問題，比如class多了一個heap memory指針。如果我們允許對象拷貝，比較穩妥的方法是禁用它們，而定義一個專門的clone()函數。

　　兼容性(compatibility)

　　不用說，兼容性是非常重要的。Intel和Microsoft之所以如此成功，其中一個重要方面就是他們的產品，不管是硬件還是軟件，都做到了很好的兼容老產品。代碼的兼容也是如此。難以想象，如果客戶依賴于你的library產品，而要因為你的產品的更新而不斷的重寫他的代碼，他還會繼續用你的產品。

　　代碼兼容可以簡單分為二進制兼容和源代碼兼容。二進制兼容也就是說，客戶的已編譯代碼可以在不用重新編譯的情況下，直接使用你的不同版本的已編譯代碼。源代碼兼容就是，如果你的代碼更新了，客戶的代碼不需要修改，只需要重新編譯就可正常運行。在C++中，接口一般是由頭文件和library二進制代碼提供，因此，任何可能造成library代碼和舊的頭文件不一致的情況都可能破壞二進制兼容，因為客戶代碼必須和新的頭文件重新編譯一次。

　　因此，遵循幾條準則可以使你更輕松地解決兼容性問題：

　　·不改變類的大小或者改變成員變量的順序

　　包括幾個方面：不增加或減少成員變量；不修改成員變量類型；不改變成員變量的聲明順序；不改變虛函數的有無。顯而易見，增加或減少成員變量會改變類的大小，并且需要更新頭文件，從而可能造成與客戶代碼不兼容。類型的變化也可能引起類的大小的變化。成員變量的訪問一般是由編譯器按偏移量確定，順序如果改變，偏移量也就會改變，破壞了二進制兼容。至于虛函數的有無，決定是否存在虛函數表指針，也就影響了類的大小和成員變量的順序。

　　·不使用inline函數

　　inline函數聲明于頭文件中，并且被編譯于客戶代碼中，如果inline函數訪問了private成員，該成員又改變了順序，那么inline函數虛要被重新編譯，破壞了二進制兼容。

　　·接口函數不使用虛函數

　　虛函數的訪問和成員變量類似，是通過虛函數表中的偏移。虛函數順序的改變會影響偏移。因此，在條件允許時，應該避免使用public虛函數。比如：

以下是代碼片段： class Picture {  　public:  　　virtual void Draw();  };  　　應該改為  class Picture {  　public:  　　void Draw();  　private:  　　virtual void DoDraw();  };  void Picture::Draw()  {  　DoDraw();  }

　　·不改變接口函數的順序

　　在很多嵌入式系統中，鏈接庫通過輸出函數表(exported function table)暴露接口以節省空間。此時，對接口函數的訪問也是通過索引值進行，因此改變順序也會破壞兼容性。

　　·避免使用函數缺省參數

　　給函數形參設定缺省值可以方便客戶，但是可能破壞兼容。缺省值隨頭文件給出，缺省值的改變也就會引起兼容問題。