隨筆-19  評(píng)論-128  文章-1  trackbacks-0
          從設(shè)計(jì)理念層面看abstract class和interface

          上面主要從語(yǔ)法定義和編程的角度論述了abstract class和interface的區(qū)別,這些層面的區(qū)別是比較低層次的、非本質(zhì)的。本小節(jié)將從另一個(gè)層面:abstract class和interface所反映出的設(shè)計(jì)理念,來(lái)分析一下二者的區(qū)別。作者認(rèn)為,從這個(gè)層面進(jìn)行分析才能理解二者概念的本質(zhì)所在。

          前面已經(jīng)提到過(guò),abstarct class在Java語(yǔ)言中體現(xiàn)了一種繼承關(guān)系,要想使得繼承關(guān)系合理,父類和派生類之間必須存在"is a"關(guān)系,即父類和派生類在概念本質(zhì)上應(yīng)該是相同的(參考文獻(xiàn)〔3〕中有關(guān)于"is a"關(guān)系的大篇幅深入的論述,有興趣的讀者可以參考)。對(duì)于interface 來(lái)說(shuō)則不然,并不要求interface的實(shí)現(xiàn)者和interface定義在概念本質(zhì)上是一致的,僅僅是實(shí)現(xiàn)了interface定義的契約而已。為了使論述便于理解,下面將通過(guò)一個(gè)簡(jiǎn)單的實(shí)例進(jìn)行說(shuō)明。

          考慮這樣一個(gè)例子,假設(shè)在我們的問(wèn)題領(lǐng)域中有一個(gè)關(guān)于Door的抽象概念,該Door具有執(zhí)行兩個(gè)動(dòng)作open和close,此時(shí)我們可以通過(guò)abstract class或者interface來(lái)定義一個(gè)表示該抽象概念的類型,定義方式分別如下所示:

          使用abstract class方式定義Door:

          abstract class Door {
          abstract void open();
          abstract void close();
          }


          使用interface方式定義Door:


          interface Door {
          void open();
          void close();
          }


          其他具體的Door類型可以extends使用abstract class方式定義的Door或者implements使用interface方式定義的Door。看起來(lái)好像使用abstract class和interface沒有大的區(qū)別。

          如果現(xiàn)在要求Door還要具有報(bào)警的功能。我們?cè)撊绾卧O(shè)計(jì)針對(duì)該例子的類結(jié)構(gòu)呢(在本例中,主要是為了展示abstract class和interface反映在設(shè)計(jì)理念上的區(qū)別,其他方面無(wú)關(guān)的問(wèn)題都做了簡(jiǎn)化或者忽略)?下面將羅列出可能的解決方案,并從設(shè)計(jì)理念層面對(duì)這些不同的方案進(jìn)行分析。

          解決方案一:

          簡(jiǎn)單的在Door的定義中增加一個(gè)alarm方法,如下:

          abstract class Door {
          abstract void open();
          abstract void close();
          abstract void alarm();
          }


          或者

          interface Door {
          void open();
          void close();
          void alarm();
          }


          那么具有報(bào)警功能的AlarmDoor的定義方式如下:

          class AlarmDoor extends Door {
          void open() { … }
          void close() { … }
          void alarm() { … }
          }


          或者

          class AlarmDoor implements Door {
          void open() { … }
          void close() { … }
          void alarm() { … }


          這種方法違反了面向?qū)ο笤O(shè)計(jì)中的一個(gè)核心原則ISP(Interface Segregation Priciple),在Door的定義中把Door概念本身固有的行為方法和另外一個(gè)概念"報(bào)警器"的行為方法混在了一起。這樣引起的一個(gè)問(wèn)題是那些僅僅依賴于Door這個(gè)概念的模塊會(huì)因?yàn)?報(bào)警器"這個(gè)概念的改變(比如:修改alarm方法的參數(shù))而改變,反之依然。

          解決方案二:

          既然open、close和alarm屬于兩個(gè)不同的概念,根據(jù)ISP原則應(yīng)該把它們分別定義在代表這兩個(gè)概念的抽象類中。定義方式有:這兩個(gè)概念都使用abstract class方式定義;兩個(gè)概念都使用interface方式定義;一個(gè)概念使用abstract class方式定義,另一個(gè)概念使用interface方式定義。

          顯然,由于Java語(yǔ)言不支持多重繼承,所以兩個(gè)概念都使用abstract class方式定義是不可行的。后面兩種方式都是可行的,但是對(duì)于它們的選擇卻反映出對(duì)于問(wèn)題領(lǐng)域中的概念本質(zhì)的理解、對(duì)于設(shè)計(jì)意圖的反映是否正確、合理。我們一一來(lái)分析、說(shuō)明。

          如果兩個(gè)概念都使用interface方式來(lái)定義,那么就反映出兩個(gè)問(wèn)題:1、我們可能沒有理解清楚問(wèn)題領(lǐng)域,AlarmDoor在概念本質(zhì)上到底是Door還是報(bào)警器?2、如果我們對(duì)于問(wèn)題領(lǐng)域的理解沒有問(wèn)題,比如:我們通過(guò)對(duì)于問(wèn)題領(lǐng)域的分析發(fā)現(xiàn)AlarmDoor在概念本質(zhì)上和Door是一致的,那么我們?cè)趯?shí)現(xiàn)時(shí)就沒有能夠正確的揭示我們的設(shè)計(jì)意圖,因?yàn)樵谶@兩個(gè)概念的定義上(均使用interface方式定義)反映不出上述含義。

          如果我們對(duì)于問(wèn)題領(lǐng)域的理解是:AlarmDoor在概念本質(zhì)上是Door,同時(shí)它有具有報(bào)警的功能。我們?cè)撊绾蝸?lái)設(shè)計(jì)、實(shí)現(xiàn)來(lái)明確的反映出我們的意思呢?前面已經(jīng)說(shuō)過(guò),abstract class在Java語(yǔ)言中表示一種繼承關(guān)系,而繼承關(guān)系在本質(zhì)上是"is a"關(guān)系。所以對(duì)于Door這個(gè)概念,我們應(yīng)該使用abstarct class方式來(lái)定義。另外,AlarmDoor又具有報(bào)警功能,說(shuō)明它又能夠完成報(bào)警概念中定義的行為,所以報(bào)警概念可以通過(guò)interface方式定義。如下所示:

          abstract class Door {
          abstract void open();
          abstract void close();
          }
          interface Alarm {
          void alarm();
          }
          class AlarmDoor extends Door implements Alarm {
          void open() { … }
          void close() { … }
          void alarm() { … }
          }


          這種實(shí)現(xiàn)方式基本上能夠明確的反映出我們對(duì)于問(wèn)題領(lǐng)域的理解,正確的揭示我們的設(shè)計(jì)意圖。其實(shí)abstract class表示的是"is a"關(guān)系,interface表示的是"like a"關(guān)系,大家在選擇時(shí)可以作為一個(gè)依據(jù),當(dāng)然這是建立在對(duì)問(wèn)題領(lǐng)域的理解上的,比如:如果我們認(rèn)為AlarmDoor在概念本質(zhì)上是報(bào)警器,同時(shí)又具有Door的功能,那么上述的定義方式就要反過(guò)來(lái)了。

          轉(zhuǎn)載人員-Nicholas
          posted on 2010-11-07 13:57 obpm 閱讀(574) 評(píng)論(4)  編輯  收藏 所屬分類: 架構(gòu)設(shè)計(jì)

          評(píng)論:
          # re: 接口和抽象類的區(qū)別(轉(zhuǎn)載) 2011-01-20 11:52 | 木弓視覺
          很復(fù)雜。我還停留在html。。。  回復(fù)  更多評(píng)論
            
          # re: 接口和抽象類的區(qū)別(轉(zhuǎn)載) 2011-05-21 01:06 | keezzm
          這是面相對(duì)象的隔離原則,即上述的Door和“報(bào)警器”并不能劃為同一類,Door的行為被抽象為open和close,但是報(bào)警并不是Door固有的行為,如果隨著時(shí)間的遷移,Door新增了報(bào)警行為,而在基類增加報(bào)警行為,這樣只要在我們需要增加新業(yè)務(wù)時(shí),就會(huì)每次在原先的Door增加業(yè)務(wù)方法,這樣很有可能導(dǎo)致別的模塊對(duì)其的依賴而發(fā)生大幅度的修改,這必然導(dǎo)致代碼的難以維護(hù)。但是使用接口,我們就可以分離業(yè)務(wù),也就說(shuō)這時(shí)我們可以抽象出兩種類(Door和Alarm),但由于抽象類不支持多繼承,而采用接口的卻相反,這樣我們就可以專注于這個(gè)實(shí)現(xiàn)類的具體實(shí)現(xiàn),但發(fā)生需求的變化時(shí),而針對(duì)該實(shí)現(xiàn)類進(jìn)行修改,或者增加新業(yè)務(wù)時(shí),我們只需通過(guò)新增接口來(lái)擴(kuò)充實(shí)現(xiàn)類,并替換掉原先的實(shí)現(xiàn)類來(lái)達(dá)到更換實(shí)現(xiàn),例如我們可以定義Door和Alarm來(lái)隔離這兩種業(yè)務(wù),并通過(guò)接口來(lái)封裝,然后通過(guò)AlarmDoor類來(lái)實(shí)現(xiàn)這兩個(gè)接口,當(dāng)需求發(fā)生變更時(shí),我們只需增加接口或者修改AlarmDoor類就行了,而無(wú)需對(duì)Door和Alarm進(jìn)行修改,這樣便達(dá)到隔離的要求,并且還大大地降低各模塊之間的耦合度。(如有說(shuō)錯(cuò)請(qǐng)指正!)  回復(fù)  更多評(píng)論
            
          # re: 接口和抽象類的區(qū)別 2011-11-02 11:38 | gzakoa
          轉(zhuǎn)載了!  回復(fù)  更多評(píng)論
            
          # re: 接口和抽象類的區(qū)別 2011-11-02 11:38 | gzakoa
          (轉(zhuǎn)載)  回復(fù)  更多評(píng)論
            
          主站蜘蛛池模板: 青川县| 孝感市| 丹棱县| 界首市| 长丰县| 康马县| 合山市| 黔西| 英吉沙县| 永济市| 右玉县| 南皮县| 巨鹿县| 安顺市| 西峡县| 铜山县| 和平县| 南皮县| 宁陵县| 高淳县| 苍溪县| 秀山| 定襄县| 保靖县| 玉门市| 汪清县| 浦城县| 宁德市| 荔浦县| 西昌市| 娱乐| 黔西| 丽江市| 房产| 尚志市| 新闻| 曲靖市| 九龙县| 中山市| 和林格尔县| 嵊州市|