viewpager默認界面

幾周前，我們詳細研究了默認方法 -Java 8中引入的一項功能，該功能允許為接口方法提供實現，即方法主體，從而定義接口中的行為。 引入此功能是為了實現接口演進 。

在JDK的上下文中，這意味著在不破壞所有代碼的情況下向接口添加新方法。 但是，盡管Java本身非常致力于保持向后兼容性，但其他項目并不一定要做到這一點。 如果愿意，他們可以以讓客戶更改其代碼為代價來發展其接口。

在Java 8之前，這經常涉及客戶端編譯錯誤，因此可以避免更改，否則客戶端必須一次性遷移。 使用默認方法，接口演變可以成為無錯誤的過程，在此過程中，客戶可以在版本之間留出時間來逐步更新其代碼。 這大大增加了開發接口的可行性，并使其成為常規的庫開發工具。

讓我們看一下如何添加，替換和刪除接口方法。 以后的文章將探討替換整個接口的方法。

總覽

該帖子首先定義了一些術語，然后介紹了添加，替換和刪除接口方法的方法。 它是從更改庫中界面的開發人員的角度編寫的。

我覺得該主題不需要示例，因此我沒有編寫任何示例。 如果您不同意并希望看到一些內容，請發表評論，并且-在時間允許的情況下-我會寫一些。

術語

接口具有實現和調用者 。 兩者都可以存在于庫中，在這種情況下，它們都稱為internal ，或者在客戶端代碼中稱為external 。 這總共增加了四種使用界面的類別。

根據接口的發展方式和存在的用途，必須采用不同的模式。 當然，如果既不存在外部實現也不存在外部調用者，則這些都不是必需的，因此本文的其余部分假定這些情況中至少有一種確實存在。

接口演變–方法

因此，讓我們看看如何在不破壞客戶端代碼的情況下添加，替換或刪除接口方法。

通常可以通過執行以下過程來實現：

新版本

該庫的新版本已發布，其中接口定義是過渡性的，并結合了舊的和新的所需輪廓。 默認方法可確保所有外部實現和調用仍然有效，并且在更新時不會出現編譯錯誤。

過渡

然后，客戶就有時間從舊大綱過渡到新大綱。 同樣，默認方法可確保適應的外部實現和調用有效，并且可以進行更改而不會產生編譯錯誤。

新版本

在新版本中，該庫刪除了舊輪廓的殘差。 鑒于客戶端明智地利用了自己的時間并進行了必要的更改，因此發布新版本不會導致編譯錯誤。

這個過程使客戶能夠按自己的時間表平穩地更新其代碼，這使得接口的開發比以前更加可行。

Johanna Pung在CC-BY-SA 3.0下為Wikimedia Deutschland 發布 。

在遵循以下詳細步驟時，請確保檢查何時更新了內部和外部實現以及何時允許內部和外部調用者使用所涉及的方法。 確保在您自己的代碼中遵循此過程，并為您的客戶正確記錄下來，以便他們知道何時執行操作。 Javadoc標簽@Deprecated和@apiNote是實現此目的的好方法。

通常，不必按該順序執行過渡內的步驟。 如果是，則明確指出。

如果您向客戶提供可以在其界面實現上運行的測試，則這些步驟中包含測試。

加

僅當存在外部接口實現時才需要此過程。 由于該方法是新方法，因此當然尚未調用，因此可以忽略這種情況。 區分是否可以提供合理的默認實現是有意義的。

存在合理的默認實現

新版本

• 為新方法定義測試
• 使用默認實現（通過測試）添加方法
• 內部呼叫者可以使用該方法
• 內部實現可以在必要時覆蓋該方法

過渡

• 外部呼叫者可以使用該方法
• 外部實現可以在必要時覆蓋該方法

無需執行任何操作，也不需要任何新版本。 這就是Java 8中添加的許多新的默認方法所發生的事情。

不存在合理的默認實現

新版本

• 為新方法定義測試； 這些必須接受UnupportedOperationExceptions
• 添加方法：
  • 包括一個引發UnupportedOperationException的默認實現（通過測試）
  • @apiNote注釋文檔，默認實現將最終被刪除
• 在所有內部實現中覆蓋該方法

過渡

必須按該順序執行以下步驟：

• 外部實現必須重寫該方法
• 外部呼叫者可以使用該方法

新版本

• 測試不再接受UnupportedOperationExceptions
• 使方法抽象：
  • 刪除默認實現
  • 刪除@apiNote注釋
• 內部呼叫者可以使用該方法

勉強一致的默認實現允許外部實現逐漸更新。 請注意，在實際在內部或外部調用新方法之前，將更新所有實現。 因此，永遠不會發生UnupportedOperationException。

更換

在這種情況下，一種方法將被另一種方法替代。 這包括一種方法更改其簽名（例如，其名稱或參數數量）的情況，在這種情況下，新版本可以看作是替換舊版本。

當存在外部實現或外部調用者時，必須應用此模式。 僅在兩種方法在功能上等效時才起作用。 否則，就是添加一個功能并刪除另一個功能的情況。

新版本

• 為新方法定義測試
• 添加新方法：
  • 包括調用舊方法的默認實現
  • @apiNote注釋文檔，默認實現將最終被刪除
• 棄用舊方法：
  • 包括調用新方法的默認實現（旨在進行循環調用；如果存在默認實現，則可以保留）
  • @apiNote注釋文檔，默認實現將最終被刪除
  • @Deprecation評論文檔說明將使用新方法
• 內部實現會覆蓋新方法，而不是舊方法
• 內部調用者使用新方法代替舊方法

過渡

• 外部實現會覆蓋新方法，而不是舊方法
• 外部呼叫者使用新方法代替舊方法

新版本

• 使新方法抽象：
  • 刪除默認實現
  • 刪除@apiNote注釋
• 刪除舊方法

盡管循環調用看起來很有趣，但它們確保實現哪種方法都無關緊要。 但是，由于這兩種變體都有默認實現，因此，如果兩種實現均未實現，則編譯器不會產生錯誤。 不幸的是，這會產生無限循環，因此請確保將其指出給客戶。 如果您為他們的實現提供測試，或者他們編寫了自己的實現，則他們會立即意識到這一點。

去掉

刪除方法時，根據是否存在外部實現，可以應用不同的模式。

存在外部實現

新版本

• 方法的測試必須接受UnupportedOperationExceptions
• 棄用該方法：
  • 包括一個引發UnupportedOperationException的默認實現（通過更新的測試）
  • @Deprecation注釋文檔表明該方法最終將被刪除
  • @apiNote注釋文檔說明默認實現僅存在于逐步淘汰方法中
• 內部呼叫者停止使用該方法

過渡

必須按該順序執行以下步驟：

• 外部呼叫者停止使用該方法
• 該方法的外部實現已刪除

新版本

• 刪除方法

請注意，只有在不存在對該方法的更多調用之后，才刪除內部和外部實現。 因此，永遠不會發生UnupportedOperationException。

外部實現不存在

在這種情況下，定期棄用就足夠了。 僅出于完整性考慮而列出了這種情況。

新版本

• 用@Depreated棄用該方法
• 內部呼叫者停止使用該方法

過渡

• 外部呼叫者停止呼叫方法

新版本

• 刪除方法

反射

我們已經看到了如何通過添加，替換和刪除方法來實現界面演化：新的界面版本結合了舊的和新的輪廓，客戶端從前者過渡到后者，而最終版本則消除了舊輪廓的殘留物。 所涉及方法的默認實現確保客戶端代碼的舊版本和新版本都能正確編譯和運行。

翻譯自: https://www.javacodegeeks.com/2015/03/interface-evolution-with-default-methods-part-i-methods.html

viewpager默認界面

總結

以上是生活随笔為你收集整理的viewpager默认界面_使用默认方法的界面演变–第一部分：方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。