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

　　文中以C++類的設(shè)計為討論范圍。

　　總提

　　面向?qū)ο缶幊虒τ诋a(chǎn)出高質(zhì)量，易維護(hù)的代碼是非常有幫助的。面向?qū)ο缶幊痰母拍顦?gòu)建于三個基本特征之上：封裝，繼承，多態(tài)。在C++中，class是面向?qū)ο缶幊谈拍畹暮诵暮途唧w形式。class通過私有成員體現(xiàn)“封裝”，通過直接繼承或者組合體現(xiàn)“繼承”，通過虛函數(shù)和動態(tài)綁定(dynamic binding)體現(xiàn)“多態(tài)”。class的設(shè)計質(zhì)量直接決定了整個系統(tǒng)的質(zhì)量。

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

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

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

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

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

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

　　在重載函數(shù)，或者子類實(shí)現(xiàn)父類虛函數(shù)時，應(yīng)該基本維持函數(shù)原來所期望的功能。比如：

以下是代碼片段： 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 在實(shí)現(xiàn)虛函數(shù)Talk的時候，沒有像我們期望的那樣輸出狗吠聲，而是咬起主人來了。這是應(yīng)該避免的。

　　接口和實(shí)現(xiàn)

　　在系統(tǒng)中，觀察一個class有兩個角度，從外部或者用戶角度我們看到的是接口，從內(nèi)部我們看到的是實(shí)現(xiàn)。因?yàn)橄到y(tǒng)肯定要不斷修改，因此實(shí)現(xiàn)免不了不停的變化，但是接口又被要求盡量保持穩(wěn)定。這兩者的矛盾必須通過良好的設(shè)計盡量避免，基本原則就是將實(shí)現(xiàn)細(xì)節(jié)與接口隔離。下面列出幾條比較具體點(diǎn)的：

　　·接口的設(shè)計保持最小而完整

　　精簡接口函數(shù)個數(shù)，使每一個函數(shù)有代表性，函數(shù)功能恰好覆蓋class的職能。一個最小的接口可以使維護(hù)簡單，增加潛在的代碼重用性，減少客戶的迷惑，并且也可以縮小頭文件長度和編譯時間。當(dāng)改進(jìn)函數(shù)時，應(yīng)該用類似函數(shù)名實(shí)現(xiàn)改進(jìn)而保留原函數(shù)，代碼注釋里應(yīng)該有相應(yīng)的說明。可以增加新函數(shù)，但不能刪除舊函數(shù)。

　　·成員變量應(yīng)該都為私有

　　顯而易見，public變量破壞封裝性以及接口和實(shí)現(xiàn)的分離；protected變量也可能使客戶編寫繼承類而依賴于父類的實(shí)現(xiàn)細(xì)節(jié)。

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

　　這么做也會使客戶代碼依賴于實(shí)現(xiàn)細(xì)節(jié)。

　　·考慮是否禁用編譯器缺省產(chǎn)生的函數(shù)

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

　　兼容性(compatibility)

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

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

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

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

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

　　·不使用inline函數(shù)

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

　　·接口函數(shù)不使用虛函數(shù)

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

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

　　·不改變接口函數(shù)的順序

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

　　·避免使用函數(shù)缺省參數(shù)

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