這篇文章主要介紹“Java8默認方法會不會破壞用戶的代碼”，在日常操作中，相信很多人在Java8默認方法會不會破壞用戶的代碼問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Java8默認方法會不會破壞用戶的代碼”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

10年積累的成都網站建設、網站制作經驗，可以快速應對客戶對網站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網絡服務。我雖然不認識你，你也不認識我。但先網站制作后付款的網站建設流程，更有沙市免費網站建設讓你可以放心的選擇與我們合作。

起初看來，默認方法給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默認方法會不會破壞用戶的代碼”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注創新互聯網站，小編會繼續努力為大家帶來更多實用的文章！