【正文】 在抽象類中不能定義默認行為還存在另一個比較嚴重的問題，那就是可能會造成維護上的麻煩。因為如果后來想修改類的界面（一般通過 abstract class 或 interface來表示）以適應(yīng)新的情況（比如，添加新的方法或者給已用的方法中添加新的參數(shù)）時，就會非常的麻煩，可能要花費 很多的時間（對于派生類很多的情況，尤為如此）。但是如果界面是通 過 abstract class 來實現(xiàn)的，那么可能就只需要修改定義在 abstract class 中的默認行為就可以了。 同樣，如果不能在抽象類中定義默認行為，就會導(dǎo)致同樣的方法實現(xiàn)出現(xiàn)在該抽象類的每一個派生類中，違反了 one rule， one place 原則，造成代碼重復(fù)，同樣不利于以后的維護。因此，在 abstract class 和 interface 間進行選擇時要非常的小心。 從設(shè)計理念層面看 abstract class 和 interface 上面主要從語法定義和編程的角度論述了 abstract class 和 interface 的區(qū) 別，這些層面的區(qū)別是比較低層次的、非本質(zhì)的 。 本小節(jié)將從另一個層面： abstract class 和interface 所反映出的設(shè)計理念，來分析一下二者的區(qū)別。作者認為，從這個層面進行分析才能理解二者概念的本質(zhì)所在。 前面已經(jīng)提到過， abstract class 在 Java 語言中體現(xiàn)了一種繼承關(guān)系，要想使得繼承關(guān)系合理，父類和派生類之間必須存在 isa關(guān)系，即父類和派生類在概念本質(zhì)上應(yīng)該是相同的。對于 interface 來說則不然，并不要求 interface 的實現(xiàn)者和 interface定義在概念本質(zhì)上是一致的，僅僅是實現(xiàn)了 interface 定義的契約而已。為了使論述便于理解，下面將通過一個簡單的實例進行說明。 考慮這樣一個例子，假設(shè)在我們的問題領(lǐng)域中有一個關(guān)于 Door 的抽象概念，該Door 具有執(zhí)行兩個動作 open 和 close，此時我們可以通 過 abstract class 或者 interface來定義一個表示該抽象概念的類型 。 其他具體 的 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è)計理念層面對這些不同的方案進行分析。 這種方法違反了面向?qū)ο笤O(shè)計中的一個核心原 則 ISP(Interface Segregation Principle)，在 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 方式來定義，那么就反映出兩個問題： 我們可能沒有理解清楚問題領(lǐng)域， AlarmDoor 在概念本質(zhì)上到底是 Door 還是報警器？ 如果我們對于問題領(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ì)上是 isa關(guān)系。所以對于 Door 這個概念，我們應(yīng)該使用 abstract class 方式來定義。另外， AlarmDoor又具有報警功能，說明它又能夠完成報警概念中定義的行為，所以報警概念可以通過interface 方式定義。 這種實現(xiàn)方式基本上能夠明確的反映出我們對于問題領(lǐng)域的理解，正確的揭示我們的設(shè)計意圖。其實 abstract class 表示的是 isa關(guān)系， interface 表示的是 likea關(guān)系，大家在選擇時可以作為一個依據(jù)，當(dāng)然這是建立在對問題領(lǐng)域的理解上的，比如：如果我們認為 AlarmDoor 在概念本質(zhì)上是報警器，同時又具有 Door 的功能，那么上述的定義方式就要反過來了。 小結(jié) 1. abstract class 在 Java 語言中表示的是一種繼承關(guān)系，一個類只能使用一次繼承關(guān)系。但是，一個類卻可以實現(xiàn)多個 interface。 2. 在 abstract class 中可以有自己的數(shù)據(jù)成員，也可以有非 abstract 的成員方法，而在interface 中，只能夠有靜態(tài)的不能被修改的數(shù)據(jù)成員（也就是必須是 static final的，不過在 interface 中一般不定義數(shù)據(jù)成員），所有的成員方法都是 abstract 的。 3. abstract class 和 interface 所反映出的設(shè)計理念不同。其實 abstract class 表示的是isa關(guān)系， interface 表示的是 likea關(guān)系。 4. 實現(xiàn)抽象類和接口的類必須實現(xiàn)其中的所有方法。抽象類中可以有非抽象方法。接口中則不能有實現(xiàn)方法。 5. 接口中定義的變量默認是 public static final 型，且必須給其初值，所以實現(xiàn)類中不能重新定義，也不能改變其值。 6. 抽象類中的變量默認 是 friendly 型，其值可以在子類中重新定義，也可以重新賦值。 7. 接口中的方法默認都是 public abstract 類型的。 結(jié)論 abstract class 和 interface 是 Java 語言中的兩種定義抽象類的方式，它們之間有很大的相似性。但是對于它們的選擇卻又往往反映出對于問題領(lǐng)域中的概 念本質(zhì)的理解、對于設(shè)計意圖的反映是否正確、合理，因為它們表現(xiàn)了概念間的不同的關(guān)系（雖然都能夠?qū)崿F(xiàn)需求的功能）。這其實也是語言的一種的慣用法，希望讀者朋友能夠細細體會。 指導(dǎo)教師評語 該生外文翻譯的內(nèi)容與課題研究方向所涉及的技術(shù)，基本一致，翻譯的基本準(zhǔn)確，字數(shù)達到開題中對外文文獻的要求，格式比較規(guī)范。 指導(dǎo)教師簽名： 年 月 日 學(xué)院審核意見 年 月 日