Java8預設方法會破壞使用者的程式碼嗎

起初看來，預設方法為Java虛擬機器的指令集帶來了許多新的功能。最終，開發函式庫的人能夠在不帶來客戶端程式碼的相容性問題的情況下，升級API。使用 預設方法，任何實作庫介面的類別都會自動適應介面引入的預設方法。一旦使用者更新了他實現的類，就能夠很簡單地使用更有意義的方法來覆寫原有預設方法。更好的是， 使用者可以在覆寫方法時候，呼叫介面的預設實現，同時增加業務邏輯。

到現在為止，一切都是很好。但是，在創建介面的時候增加預設方法可能使得Java程式碼不相容。這個從下面的例子可以很容易弄清楚。我們假設一個庫需要它的一個介面的作為輸入：

interface SimpleInput {   void foo();   void bar(); }  abstract class SimpleInputAdapter implements SimpleInput {   @Override   public void bar() {     // some default behavior ...   } }

Java 8之前，類似於上面聯合使用一個介面和一個適配器類別的方式，是Java程式語言中非常常用的設計模式。此適配器通常由庫提供者提供，用於節省庫的使用者的某些操作。但是，如果採用介面的方式提供，就類似允許多重繼承了。

我們進一步假設一個使用者使用瞭如下的適配器：

class MyInput extends SimpleInputAdapter {   @Override   public void foo() {     // do something ...   }   @Override   public void bar() {     super.bar();     // do something additionally ...   } }

透過這種實作方式，我們最終可以和函式庫進行互動。注意我們是如何覆蓋bar方法，並為預設的實作增加額外的功能的。

如果將該函式庫移植到Java 8，會發生什麼事？首先，該庫很大可能性會廢棄適配器類，而使用預設方法提供該功能。最終，該接口的形式類似如下所示：

interface SimpleInput {   void foo();   default void bar() {     // some default behavior   } }

使用這個新的接口，使用者可以更新他的程式碼，採用預設方法來取代原來的適配器類別。透過使用介面代替適配器類別的***的結果是，該類別可以繼承 （extend）其它的類，而不是特定的適配器。現在我們進行實踐，移植MyInput類別使其使用預設方法。因為我們現在能繼承其它類別了，所以我們繼承一 個第三方的基礎類別。我們這裡不需要關心這個基礎類別的作用，我們可以假設這個對我們的功能是有意義的。

class MyInput extends ThirdPartyBaseClass implements SimpleInput {   @Override   public void foo() {     // do something ...   }   @Override   public void bar() {     SimpleInput.super.bar();     // do something additionally ...   } }

為了實作原始類別相似的功能，我們使用Java 8的新的語法來呼叫指定介面的預設方法。同時，將我們方法中的一些邏輯移到基礎類別中去。此時，你可能拍著我的肩膀說，這是非常好的重構！

我們相當成功的使用了該函式庫。但是，維護人員需要增加另一個介面來提供更多的功能。此介面被 ComplexInput 介面所代替，這個介面繼承自  SimpleInput 接口，並增加了新的方法。因為預設方法通常來說是可以很安全的添加的，因此，維護人員覆寫了 SimpleInput  的預設方法，提供了一個更好的預設方法。畢竟，這對於採用適配器類別的方式來說是很平常的事情。

interface ComplexInput extends SimpleInput {   void qux();   @Override   default void bar() {     SimpleInput.super.bar();     // so complex, we need to do more ...   } }

新的功能帶來了非常好的效果以至於維護 ThirdPartyBaseClass 的人也決定依賴該函式庫。為了完成這項工作，它在 ThirdPartyLibrary 中實作了 ComplexInput 介面。

但這對 MyInput 類別來說又意味著什麼呢？為了隱式的實作 ComplexInput 接口，可繼承  ThirdPartyBaseClass 類，但是呼叫 SimpleInput  的預設方法突然變成非法的了。結果，使用者的程式碼不能通過編譯。現在這種呼叫是被禁止的，因為Java認為這種在非直接子類別中呼叫父類別的父類別的方法是非法 的。你只能在 ComplexInput  中呼叫該預設方法，但是，這要求你顯示的在MyInput中實作該介面。對於庫的用戶來說，這種改變不是所預期的！

更奇怪的是，Java執行時卻不做這種限制。 JVM的校驗器是允許一個編譯好的類別去呼叫 SimpleInput::foo  方法的，即使該類別是透過繼承更新後的 ThirdPartyBaseClass，從而隱式的實作了ComplexClass。這種限制只存在於編譯器中。

以上是Java8預設方法會破壞使用者的程式碼嗎的詳細內容。更多資訊請關注PHP中文網其他相關文章！