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

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

　　總提

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

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

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

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

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

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

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

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

以下是代碼片段： 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的時(shí)候，沒(méi)有像我們期望的那樣輸出狗吠聲，而是咬起主人來(lái)了。這是應(yīng)該避免的。

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

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

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

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

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

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

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

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

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

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

　　兼容性(compatibility)

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

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

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

　　·不改變類(lèi)的大小或者改變成員變量的順序

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

　　·不使用inline函數(shù)

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

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

　　虛函數(shù)的訪問(wèn)和成員變量類(lèi)似，是通過(guò)虛函數(shù)表中的偏移。虛函數(shù)順序的改變會(huì)影響偏移。因此，在條件允許時(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)中，鏈接庫(kù)通過(guò)輸出函數(shù)表(exported function table)暴露接口以節(jié)省空間。此時(shí)，對(duì)接口函數(shù)的訪問(wèn)也是通過(guò)索引值進(jìn)行，因此改變順序也會(huì)破壞兼容性。

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

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