使代碼復雜易讀和理解的一件事是，方法內部的指令處于不同的抽象級別。

假設我們的應用程序僅允許登錄用戶查看其朋友的旅行。 如果用戶不是朋友，則不會顯示任何行程。

一個例子：

public List<Trip> tripsByFriend(User user, User loggedInUser) {return (user.friends().contains(loggedInUser)) ? userRepository.findTripsBy(user.id()): Collections.emptyList(); }

在上面的代碼中，方法主體中的所有指令處于不同的抽象級別。 我們有驗證友誼的指令，通過協(xié)作者獲取朋友旅行列表的指令以及返回空且不變的列表的低級Java API。 最重要的是，我們擁有商業(yè)行為本身。

現(xiàn)在讓我們看一下相同方法的重構版本：

public List<Trip> tripsByFriend(User user, User loggedInUser) {return (user.isFriendsWith(loggedInUser)) ? tripsBy(user): noTrips(); }private List<Trip> tripsBy(User user) {userRepository.findTripsBy(friend.id()); }private List<Trip> noTrips() {return Collections.emptyList(); }

在這個新版本中，我們將低級抽象提取到私有方法中，并且還將某些行為移至User類。 進行此更改后，所有指令都處于相同的抽象級別，從而使業(yè)務規(guī)則清晰明了。 現(xiàn)在，公共方法可以告訴我們一個故事，而無需擔心技術實施細節(jié)。 現(xiàn)在，代碼讀取時沒有任何顛簸：“如果用戶是已登錄用戶的朋友，則按用戶返回行程，否則不返回行程?！?

平衡抽象原理（BAP）

平衡抽象原理定義了按較高級別構造分組的所有代碼構造都應處于同一抽象級別。 這意味著：

• 方法中的所有指令應處于相同的抽象級別
• 類中的所有公共方法都應處于相同的抽象級別
• 包/命名空間中的所有類
• 父包/命名空間中的所有同級包/命名空間
• 所有模塊，子系統(tǒng)等

該原理也適用于測試-單個單元（方法，類，模塊，系統(tǒng)）的所有測試應處于相同的抽象級別。

BAP和SRP

符合“單一職責原則”的代碼也更有可能也符合“平衡抽象原則”。 但是，情況并非總是如此，相反的情況并非總是如此。

結論

為了獲得精心設計的代碼，我們需要考慮許多設計原則，我認為，平衡抽象原則（BAP）是SOLID原則和整個軟件設計中缺少的部分。

翻譯自: https://www.javacodegeeks.com/2015/03/balanced-abstraction-principle.html

總結

以上是生活随笔為你收集整理的平衡抽象原理的全部內容，希望文章能夠幫你解決所遇到的問題。

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