• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            遨游Code Sky

            共享今天Code Sky, 共創(chuàng)明天Code Sky!

            C++博客 首頁(yè) 新隨筆 聯(lián)系 聚合 管理
              12 Posts :: 0 Stories :: 5 Comments :: 0 Trackbacks

                    介紹一部分類(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)題。
            posted on 2007-09-29 16:51 劉遠(yuǎn)清 閱讀(487) 評(píng)論(1)  編輯 收藏 引用

            評(píng)論

            # re: [頂]設(shè)計(jì)C++類(lèi)和接口的原則 2007-10-01 00:14 lovedday
            用C++寫(xiě)出來(lái)的代碼又臭又長(zhǎng),就一個(gè)簡(jiǎn)單的接口與實(shí)現(xiàn)相分離的原則,也要搞這么多花招。  回復(fù)  更多評(píng)論
              


            只有注冊(cè)用戶(hù)登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問(wèn)   Chat2DB   管理


            偷偷做久久久久网站| 久久国产免费直播| 久久久av波多野一区二区| 国产产无码乱码精品久久鸭| 国产精品青草久久久久婷婷 | 国产午夜精品久久久久免费视| 久久婷婷五月综合国产尤物app| 久久国产乱子精品免费女| 久久99热这里只有精品国产 | 天堂久久天堂AV色综合| 99久久人妻无码精品系列| 久久国产精品视频| 97久久国产露脸精品国产| 久久亚洲美女精品国产精品| 91久久精品国产91性色也| 色欲综合久久中文字幕网| 久久久久久青草大香综合精品| 色综合久久无码中文字幕| 99久久国产免费福利| 久久久久国产精品熟女影院| 亚洲午夜福利精品久久| 国产成人精品久久综合| 久久人人爽人人爽人人片av高请| 久久婷婷五月综合色99啪ak| 91精品国产91久久久久久青草| 四虎国产精品成人免费久久| 久久国产成人| 久久精品视频免费| 狼狼综合久久久久综合网| 18禁黄久久久AAA片| 伊人久久大香线蕉精品不卡| 久久久91人妻无码精品蜜桃HD | 国产亚洲色婷婷久久99精品| 精品综合久久久久久97| 伊人久久大香线蕉成人| 久久国产AVJUST麻豆| 中文国产成人精品久久亚洲精品AⅤ无码精品 | 国产成人久久777777| 亚洲国产精品久久久久| 亚洲国产成人久久综合一 | 中文字幕无码久久人妻|