乍一看， 默認(rèn)方法為Java虛擬機(jī)的指令集帶來(lái)了一個(gè)很棒的新功能。 最后，庫(kù)開發(fā)人員能夠開發(fā)已建立的API，而不會(huì)對(duì)其用戶代碼造成不兼容性。 使用默認(rèn)方法，當(dāng)將新方法引入該接口時(shí)，任何實(shí)現(xiàn)庫(kù)接口的用戶類都會(huì)自動(dòng)采用默認(rèn)代碼。 而且，一旦用戶更新了他的實(shí)現(xiàn)類，他就可以使用對(duì)他的特定用例更有意義的東西來(lái)覆蓋默認(rèn)值。 更好的是，用戶可以從重寫的方法中調(diào)用接口的默認(rèn)實(shí)現(xiàn)，并在其周圍添加邏輯。

到目前為止，一切都很好。 但是，向已建立的接口添加默認(rèn)方法會(huì)使Java代碼無(wú)法編譯。 在查看示例時(shí)，這是最容易理解的。 讓我們假設(shè)一個(gè)庫(kù)需要其接口之一的類作為輸入：

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

在Java 8之前，接口和相應(yīng)適配器類的上述組合是Java編程語(yǔ)言中相當(dāng)普遍的模式。 圖書館供應(yīng)商通常會(huì)提供適配器，以節(jié)省圖書館用戶的鍵入時(shí)間。 但是，還額外提供了接口以允許多重繼承的近似。

讓我們進(jìn)一步假設(shè)用戶使用了此適配器：

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

通過(guò)此實(shí)現(xiàn)，用戶最終可以與庫(kù)進(jìn)行交互。 請(qǐng)注意，該實(shí)現(xiàn)如何覆蓋bar方法以向默認(rèn)實(shí)現(xiàn)添加一些功能。

那么，如果庫(kù)遷移到Java 8，會(huì)發(fā)生什么呢？ 首先，該庫(kù)很可能會(huì)棄用適配器類，并將功能移至默認(rèn)方法。 結(jié)果，該接口現(xiàn)在將如下所示：

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

使用此新界面，用戶可以更新其代碼以適應(yīng)默認(rèn)方法，而不必使用適配器類。 使用接口而不是適配器類的最大好處是能夠擴(kuò)展除特定適配器之外的另一個(gè)類。 讓我們付諸實(shí)踐，并遷移MyInput類以使用默認(rèn)方法。 因?yàn)槲覀儸F(xiàn)在可以擴(kuò)展另一個(gè)類，所以讓我們另外擴(kuò)展一些第三方基類。 這個(gè)基類的作用在這里并不特別相關(guān)，因此讓我們假設(shè)這對(duì)我們的用例有意義。

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

為了實(shí)現(xiàn)與原始類中類似的行為，我們利用Java 8的新語(yǔ)法來(lái)調(diào)用特定接口的默認(rèn)方法。 另外，我們將myMethod的邏輯移到了一些基類MyBase 。 拍拍我們的肩膀。 很好的重構(gòu)！

我們正在使用的庫(kù)取得了巨大的成功。 但是，維護(hù)人員需要添加另一個(gè)接口以提供更多功能。 此接口表示一個(gè)CompexInput ，它使用其他方法擴(kuò)展了SimpleInput 。 因?yàn)槟J(rèn)方法通常被認(rèn)為可以安全添加 ，所以維護(hù)者還重寫了SimpleInput的默認(rèn)方法，并添加了一些行為以提供更好的默認(rèn)值。 畢竟，在實(shí)現(xiàn)適配器類時(shí)，這樣做很普遍：

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

這項(xiàng)新功能非常強(qiáng)大，以至ThirdPartyBaseClass的維護(hù)者決定也依賴此庫(kù)。 為此，他為ThirdPartyLibrary實(shí)現(xiàn)了ComplexInput接口。

但這對(duì)MyInput類意味著什么？ 由于通過(guò)擴(kuò)展ThirdPartyBaseClass隱式實(shí)現(xiàn)ComplexInput ，調(diào)用SimpleInput的默認(rèn)方法突然變得非法。 結(jié)果，用戶的代碼不再編譯。 而且，由于Java認(rèn)為此調(diào)用與調(diào)用間接超類的super-super方法一樣是非法的，因此現(xiàn)在通常也禁止調(diào)用此方法。 相反，您可以調(diào)用默認(rèn)方法
ComplexInput類。 但是，這需要您首先在MyInput顯式實(shí)現(xiàn)此接口。 對(duì)于圖書館的用戶來(lái)說(shuō)，這種變化很有可能是出乎意料的！

奇怪的是，Java運(yùn)行時(shí)沒有進(jìn)行這種區(qū)分。 JVM的驗(yàn)證程序?qū)⒃试S已編譯的類調(diào)用SimpleInput::foo即使已加載的類在運(yùn)行時(shí)通過(guò)擴(kuò)展ThirdPartyBaseClass的更新版本隱式實(shí)現(xiàn)了ComplexClass 。 這里只有編譯器抱怨。

但是我們從中學(xué)到什么呢？ 簡(jiǎn)而言之，請(qǐng)確保不要在另一個(gè)接口中覆蓋默認(rèn)方法。 既不使用其他默認(rèn)方法，也不使用抽象方法。 通常，要小心使用默認(rèn)方法。 它們可以像Java的collection接口一樣輕松地簡(jiǎn)化已建立的API的演變，但它們本身卻很復(fù)雜，因?yàn)樗鼈冊(cè)试S執(zhí)行類型層次結(jié)構(gòu)中的方法調(diào)用。 在Java 7之前，您只需要通過(guò)遍歷線性類層次結(jié)構(gòu)來(lái)查找實(shí)際調(diào)用的代碼。 僅當(dāng)您確實(shí)覺得有必要時(shí)才添加這種復(fù)雜性。

翻譯自: https://www.javacodegeeks.com/2014/05/java-8-default-methods-can-break-your-users-code.html

總結(jié)

以上是生活随笔為你收集整理的Java 8默认方法可能会破坏您的（用户）代码的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。