使代码复杂易读和理解的一件事是，方法内部的指令处于不同的抽象级别。

假设我们的应用程序仅允许登录用户查看其朋友的旅行。 如果用户不是朋友，则不会显示任何行程。

一个例子：

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

在上面的代码中，方法主体中的所有指令处于不同的抽象级别。 我们有验证友谊的指令，通过协作者获取朋友旅行列表的指令以及返回空且不变的列表的低级Java API。 最重要的是，我们拥有商业行为本身。

现在让我们看一下相同方法的重构版本：

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类。 进行此更改后，所有指令都处于相同的抽象级别，从而使业务规则清晰明了。 现在，公共方法可以告诉我们一个故事，而无需担心技术实施细节。 现在，代码读取时没有任何颠簸：“如果用户是已登录用户的朋友，则按用户返回行程，否则不返回行程。”

平衡抽象原理（BAP）

平衡抽象原理定义了按较高级别构造分组的所有代码构造都应处于同一抽象级别。 这意味着：

• 方法中的所有指令应处于相同的抽象级别
• 类中的所有公共方法都应处于相同的抽象级别
• 包/命名空间中的所有类
• 父包/命名空间中的所有同级包/命名空间
• 所有模块，子系统等

该原理也适用于测试-单个单元（方法，类，模块，系统）的所有测试应处于相同的抽象级别。

BAP和SRP

符合“单一职责原则”的代码也更有可能也符合“平衡抽象原则”。 但是，情况并非总是如此，相反的情况并非总是如此。

结论

为了获得精心设计的代码，我们需要考虑许多设计原则，我认为，平衡抽象原则（BAP）是SOLID原则和整个软件设计中缺少的部分。

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