<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

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

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

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

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

    使用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。看起來好像使用abstract class和interface沒有大的區(qū)別。

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

    解決方案一:

    簡單的在Door的定義中增加一個alarm方法,如下:

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


    或者

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


    那么具有報警功能的AlarmDoor的定義方式如下:

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


    或者

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


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

    解決方案二:

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

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

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

    如果我們對于問題領(lǐng)域的理解是:AlarmDoor在概念本質(zhì)上是Door,同時它有具有報警的功能。我們該如何來設(shè)計、實現(xiàn)來明確的反映出我們的意思呢?前面已經(jīng)說過,abstract class在Java語言中表示一種繼承關(guān)系,而繼承關(guān)系在本質(zhì)上是"is a"關(guān)系。所以對于Door這個概念,我們應(yīng)該使用abstarct class方式來定義。另外,AlarmDoor又具有報警功能,說明它又能夠完成報警概念中定義的行為,所以報警概念可以通過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() { … }
    }


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

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

    評論:
    # re: 接口和抽象類的區(qū)別(轉(zhuǎn)載) 2011-01-20 11:52 | 木弓視覺
    很復(fù)雜。我還停留在html。。。  回復(fù)  更多評論
      
    # re: 接口和抽象類的區(qū)別(轉(zhuǎn)載) 2011-05-21 01:06 | keezzm
    這是面相對象的隔離原則,即上述的Door和“報警器”并不能劃為同一類,Door的行為被抽象為open和close,但是報警并不是Door固有的行為,如果隨著時間的遷移,Door新增了報警行為,而在基類增加報警行為,這樣只要在我們需要增加新業(yè)務(wù)時,就會每次在原先的Door增加業(yè)務(wù)方法,這樣很有可能導(dǎo)致別的模塊對其的依賴而發(fā)生大幅度的修改,這必然導(dǎo)致代碼的難以維護。但是使用接口,我們就可以分離業(yè)務(wù),也就說這時我們可以抽象出兩種類(Door和Alarm),但由于抽象類不支持多繼承,而采用接口的卻相反,這樣我們就可以專注于這個實現(xiàn)類的具體實現(xiàn),但發(fā)生需求的變化時,而針對該實現(xiàn)類進行修改,或者增加新業(yè)務(wù)時,我們只需通過新增接口來擴充實現(xiàn)類,并替換掉原先的實現(xiàn)類來達到更換實現(xiàn),例如我們可以定義Door和Alarm來隔離這兩種業(yè)務(wù),并通過接口來封裝,然后通過AlarmDoor類來實現(xiàn)這兩個接口,當需求發(fā)生變更時,我們只需增加接口或者修改AlarmDoor類就行了,而無需對Door和Alarm進行修改,這樣便達到隔離的要求,并且還大大地降低各模塊之間的耦合度。(如有說錯請指正!)  回復(fù)  更多評論
      
    # re: 接口和抽象類的區(qū)別 2011-11-02 11:38 | gzakoa
    轉(zhuǎn)載了!  回復(fù)  更多評論
      
    # re: 接口和抽象類的區(qū)別 2011-11-02 11:38 | gzakoa
    (轉(zhuǎn)載)  回復(fù)  更多評論
      
    主站蜘蛛池模板: 国产一级一毛免费黄片| 四虎成人精品国产永久免费无码| 久久国产精品国产自线拍免费| 亚洲AV无码一区二区三区在线观看 | 巨胸喷奶水www永久免费| 亚洲欧洲国产成人综合在线观看| 免费无码一区二区| 亚洲国产精品一区二区九九| 一级毛片**免费看试看20分钟| 亚洲日本va午夜中文字幕久久| 国产精品午夜免费观看网站| 亚洲一区二区三区AV无码| 嫩草在线视频www免费看| 亚洲福利视频导航| 99久久免费看国产精品| 亚洲国产品综合人成综合网站| 在线观看av永久免费| 亚洲av无码专区在线电影| 亚洲国产精品碰碰| 一区二区三区无码视频免费福利| 亚洲av中文无码乱人伦在线播放| 91禁漫免费进入| 一本色道久久综合亚洲精品蜜桃冫 | 亚洲成色999久久网站| 免费看男女下面日出水来| 亚洲日本一线产区和二线 | 每天更新的免费av片在线观看 | 亚洲综合久久1区2区3区| 国产免费av片在线看| 美美女高清毛片视频黄的一免费 | 国产午夜亚洲精品理论片不卡| 国产真人无码作爱视频免费| 亚洲午夜在线一区| 免费在线看片网站| 一级做a爰全过程免费视频| 亚洲精品综合在线影院| 青青草原亚洲视频| 国产免费毛不卡片| 国产精品小视频免费无限app| 亚洲国产精品yw在线观看| 亚洲伊人久久综合中文成人网|