文章目录
一、什么是抽象层次一致性（SLAP）
抽象层次一致性（Single Level of Abstration Principle，SLAP），是和组合函数密切相关的一个原则。组合函数要求将一个大函数拆成多个子函数的组合，而SLAP要求函数体中的内容必须在同一个抽象层次上。
如果高层次抽象和底层细节杂糅在一起，就会显得凌乱，难以理解。
定义与来源：SLAP是ThoughtWorks的总监级咨询师Neal Ford在《卓有成效的程序员》一书中提出来的概念，其思想源自Kent Beck提出的组合方法模式（Composed Method Pattern，CMP）。该原则强调每个方法中的所有代码都应处于同一级抽象层次。
原理阐释：抽象层次与概念的内涵相关，内涵越小，抽象的特征越少，抽象的层次就越高，外延也越大，反之亦然。例如，“动物”比“狗”的抽象层次高，“狗”又比“哈士奇”的抽象层次高。SLAP要求在一个方法或模块中，不能同时包含高抽象层次的操作和底层细节操作。如果高层次抽象和底层细节杂糅在一起，会使代码凌乱，难以理解，增加系统的复杂性。
应用方法：在实际应用中，通常需要将业务处理的主要步骤放在公有函数中，以展示高抽象层次的逻辑，而将具体的实现细节封装在私有方法中。这样可以确保一个函数中的抽象处于同一水平，符合SLAP原则，构筑起代码结构的金字塔。
重要意义：遵循SLAP原则有助于减少混乱和降低理解成本，使代码更易于维护和扩展。它能让开发者更清晰地理解代码逻辑，也有助于团队成员之间的沟通，因为大家可以在同一抽象层次上交流代码功能和业务逻辑。
在分层架构中的体现：分层架构中也应遵循SLAP原则，保证同一层的组件处于同一个抽象层次。例如，经典三层架构中，上层关注用户的体验和交互，中层关注应用和业务逻辑，下层关注外部资源和设备，每一层都有其特定的抽象焦点，层内组件应保持抽象层次一致，以避免层间关系混乱。
二、违反SLAP原则的代码与重构
重构违反SLAP（抽象层次一致性）原则的代码，核心思路是将不同抽象层次的代码分离到各自的方法或类中，确保每个单元只处理同一层次的逻辑。以下是具体的重构方法和示例：
1、重构核心步骤
- 识别抽象层次：区分代码中的"做什么"（高层业务逻辑）和"怎么做"（底层实现细节）。
- 提取低层次细节：将底层操作（如IO、计算、SQL）抽离为独立的私有方法。
- 保留高层逻辑：让原方法只保留业务流程或策略选择等高层逻辑，通过调用提取的方法完成具体操作。
- 检查层次一致性：确保每个方法内的代码都处于同一抽象层次，避免跨层次混合。
示例1：重构混合业务与IO的代码
原问题代码（同一方法混合业务规则与文件操作）：
public class OrderProcessor {
// 违反SLAP：同一方法中混合多个抽象层次
public void processOrder(Order order) {
// 高抽象层次：业务规则判断
if (!order.isValid()) {
throw new InvalidOrderException("Order is invalid");
}
// 中抽象层次：流程步骤
order.calculateTotal();
// 低抽象层次：文件操作细节
try (FileWriter writer = new FileWriter("orders.txt", true);
BufferedWriter bw = new BufferedWriter(writer)) {
// 底层字符串拼接
String orderLine = order.getId() + "," +
order.getTotal() + "," +
new SimpleDateFormat("yyyy-MM-dd").format(new Date());
bw.write(orderLine);
bw.newLine();
} catch (IOException e) {
e.printStackTrace();
}
// 高抽象层次：业务操作
notifyCustomer(order);
}
private void notifyCustomer(Order order) {
// 实现省略
}
}
重构后代码（分离层次）：
public class OrderProcessor {
// 仅保留高层业务流程（同一抽象层次）
public void processOrder(Order order) {
validateOrder(order); // 高层：验证订单
calculateOrderTotal(order); // 高层：计算总价
saveOrderToFile(order); // 高层：保存订单（调用底层方法）
notifyCustomer(order); // 高层：通知客户
}
// 提取：订单验证（单一职责）
private void validateOrder(Order order) {
if (!order.isValid()) {
throw new InvalidOrderException("Order is invalid");
}
}
// 提取：计算总价（单一职责）
private void calculateOrderTotal(Order order) {
order.calculateTotal();
}
// 提取：文件保存细节（底层实现，独立层次）
private void saveOrderToFile(Order order) {
try (FileWriter writer = new FileWriter("orders.txt", true);
BufferedWriter bw = new BufferedWriter(writer)) {
String orderLine = buildOrderLine(order); // 进一步拆分字符串拼接
bw.write(orderLine);
bw.newLine();
} catch (IOException e) {
e.printStackTrace();
}
}
// 再提取：字符串拼接（更低层细节）
private String buildOrderLine(Order order) {
return order.getId() + "," +
order.getTotal() + "," +
new SimpleDateFormat("yyyy-MM-dd").format(new Date());
}
private void notifyCustomer(Order order) {
// 实现省略
}
}
改进点：
- 原方法仅保留业务流程的"骨架"，每个步骤通过方法调用实现。
- 文件IO、字符串拼接等底层细节被抽离到独立方法，与高层业务逻辑分离。
示例2：重构混合策略与算法的代码
原问题代码（策略选择与具体计算混合）：
public Statistics analyzeData(List<DataPoint> data, AnalysisType type) {
// 高抽象：策略选择
if (type == AnalysisType.BASIC) {
// 低抽象：具体计算（问题点）
double sum = 0;
int count = 0;
for (DataPoint point : data) {
if (point.getValue() != null) {
sum += point.getValue();
count++;
}
}
double average = sum / count;
return new Statistics(average, 0);
} else if (type == AnalysisType.ADVANCED) {
// 另一个低抽象计算（问题点）
// ... 具体实现 ...
}
// ...
}
重构后代码（分离策略与实现）：
public class DataAnalyzer {
// 仅保留高层策略选择（同一抽象层次）
public Statistics analyzeData(List<DataPoint> data, AnalysisType type) {
switch (type) {
case BASIC:
return calculateBasicStatistics(data); // 调用基础计算
case ADVANCED:
return calculateAdvancedStatistics(data); // 调用高级计算
default:
throw new IllegalArgumentException("Unknown analysis type");
}
}
// 提取：基础统计计算（底层实现）
private Statistics calculateBasicStatistics(List<DataPoint> data) {
double sum = 0;
int count = 0;
for (DataPoint point : data) {
if (point.getValue() != null) {
sum += point.getValue();
count++;
}
}
double average = sum / count;
return new Statistics(average, 0);
}
// 提取：高级统计计算（底层实现）
private Statistics calculateAdvancedStatistics(List<DataPoint> data) {
double sum = 0;
double sumOfSquares = 0;
int count = 0;
for (DataPoint point : data) {
if (point.getValue() != null) {
sum += point.getValue();
sumOfSquares += point.getValue() * point.getValue();
count++;
}
}
double average = sum / count;
double variance = (sumOfSquares / count) - (average * average);
return new Statistics(average, variance);
}
}
改进点：
- 原方法仅负责"选择策略"（高层逻辑），具体计算逻辑被抽离到独立方法。
- 每个计算方法只处理单一层次的细节（纯算法实现），与策略选择分离。
2、重构后的优势
- 可读性提升：开发者可先通过高层方法理解业务流程，再按需深入底层细节。
- 可维护性增强：修改底层实现（如更换文件格式、优化算法）时，无需改动高层逻辑。
- 复用性提高：抽离的底层方法可在其他场景复用（如
buildOrderLine可用于日志打印）。 - 测试便捷：底层方法可单独编写单元测试，无需依赖完整业务流程。
3、关键原则总结
- 单一层次：每个方法只说"同一层级的话"，避免在业务流程中穿插具体实现。
- 逐步下沉：通过多次提取方法，将细节"下沉"到更低层次，形成清晰的调用链。
- 命名辅助：方法名应体现其抽象层次（如
processOrder是高层，buildOrderLine是底层）。
通过这种方式，代码会形成类似"金字塔"的结构：顶层是业务流程，中层是步骤分解，底层是具体实现，每层职责明确且层次清晰。
三、实际开发中符合SLAP原则
以下是几个实际项目中遵循抽象层次层次一致性原则（SLAP）的代码示例，展示不同场景下如何保持单一抽象层次：
简单示例
抽象层次一致性（Single Level of Abstration Principle，SLAP），是和组合函数密切相关的一个原则。组合函数要求将一个大函数拆成多个子函数的组合，而SLAP要求函数体中的内容必须在同一个抽象层次上。如果高层次抽象和底层细节杂糅在一起，就会显得凌乱，难以理解。
function 高级(){ //1级目录
中级1();
中级2();
}
function 中级1(){ //2级目录-1
低级1();
低级2();
}
function 低级1(){ //正文内容
//处理
}
function 低级2(){ //正文内容
//处理
}
function 中级2(){ //2级目录-2
低级3();
}
function 低级3(){ //正文内容
//处理
}
比如，泡咖啡这个例子，将业务逻辑封装在子方法里面，而不是将部分业务逻辑放在主流程中：
public void makeCoffee(boolean isMilkCoffee, boolean isSweetTooth, CoffeeType type) {
//选择咖啡粉
pourCoffeePowder(type);
//加入沸水
pourWater();
//选择口味
flavor(isMilkCoffee, isSweetTooth);
//搅拌
stir();
}
private void flavor(boolean isMilkCoffee, boolean isSweetTooth) {
if (isMilkCoffee) {
pourMilk();
}
if (isSweetTooth) {
addSugar();
}
}
private void pourCoffeePowder(CoffeeType type) {
if (type == CAPPUCCINO) {
pourCappuccinoPowder();
}
else if (type == BLACK) {
pourBlackPowder();
}
else if (type == MOCHA) {
pourMochaPowder();
}
else if (type == LATTE) {
pourLattePowder();
}
else if (type == ESPRESSO) {
pourEspressoPowder();
}
}
示例1：电商订单处理服务（分层清晰的业务流程）
// 高层：订单服务（仅处理业务流程协调）
@Service
public class OrderService {
private final OrderValidator orderValidator;
private final InventoryManager inventoryManager;
private final PaymentProcessor paymentProcessor;
private final OrderRepository orderRepository;
private final NotificationService notificationService;
// 构造函数注入依赖（省略）
// 仅包含高层业务流程，所有步骤通过方法调用完成
public OrderResult processNewOrder(OrderRequest request) {
// 1. 验证订单合法性（高层步骤）
Order order = orderValidator.validateAndConvert(request);
// 2. 检查库存（高层步骤）
inventoryManager.checkAndReserveInventory(order);
// 3. 处理支付（高层步骤）
PaymentResult paymentResult = paymentProcessor.processPayment(order);
if (!paymentResult.isSuccessful()) {
return OrderResult.failed("Payment failed: " + paymentResult.getErrorMessage());
}
// 4. 保存订单（高层步骤）
Order savedOrder = orderRepository.save(order);
// 5. 发送通知（高层步骤）
notificationService.sendOrderConfirmation(savedOrder);
return OrderResult.success(savedOrder);
}
}
// 中层：库存管理（专注于库存领域逻辑）
@Service
public class InventoryManager {
private final InventoryRepository inventoryRepo;
private final InventoryReservationService reservationService;
// 仅处理库存相关的中层逻辑
public void checkAndReserveInventory(Order order) {
for (OrderItem item : order.getItems()) {
checkItemAvailability(item);
reserveItemQuantity(item);
}
}
private void checkItemAvailability(OrderItem item) {
// 检查库存是否充足的细节（中层实现）
if (inventoryRepo.getAvailableQuantity(item.getProductId()) < item.getQuantity()) {
throw new InsufficientInventoryException(item.getProductId());
}
}
private void reserveItemQuantity(OrderItem item) {
// 库存预留的细节（中层实现）
reservationService.createReservation(
item.getProductId(),
item.getQuantity(),
order.getId()
);
}
}
// 底层：数据库操作（仅处理SQL细节）
@Repository
public class JpaOrderRepository implements OrderRepository {
private final EntityManager entityManager;
@Override
public Order save(Order order) {
// 仅包含JPA操作细节（底层实现）
if (order.getId() == null) {
entityManager.persist(order);
return order;
} else {
return entityManager.merge(order);
}
}
}
符合SLAP的特点：
OrderService只负责业务流程的"是什么"（步骤协调），不包含任何实现细节InventoryManager专注于库存领域的中层逻辑，不涉及数据库或HTTP等底层技术- 数据访问层只处理SQL/JPA细节，不包含业务规则
示例2：API接口层（控制器与服务的层次分离）
// 高层：API控制器（仅处理HTTP层逻辑）
@RestController
@RequestMapping("/api/users")
public class UserController {
private final UserService userService;
private final UserResponseMapper responseMapper;
// 仅处理HTTP请求/响应相关逻辑（参数绑定、状态码、异常转换）
@PostMapping
public ResponseEntity<UserResponse> createUser(@Valid @RequestBody UserRequest request) {
User user = userService.createUser(request);
UserResponse response = responseMapper.toResponse(user);
return ResponseEntity.status(HttpStatus.CREATED).body(response);
}
@ExceptionHandler(EmailAlreadyExistsException.class)
public ResponseEntity<ErrorResponse> handleDuplicateEmail(EmailAlreadyExistsException e) {
ErrorResponse error = new ErrorResponse("DUPLICATE_EMAIL", e.getMessage());
return ResponseEntity.status(HttpStatus.CONFLICT).body(error);
}
}
// 中层：用户服务（处理领域逻辑）
@Service
public class UserService {
private final UserRepository userRepo;
private final PasswordEncoder passwordEncoder;
// 仅处理用户领域的核心逻辑（不涉及HTTP或数据库细节）
public User createUser(UserRequest request) {
validateEmailUniqueness(request.getEmail());
User user = new User();
user.setEmail(request.getEmail());
user.setName(request.getName());
user.setPasswordHash(encodePassword(request.getPassword()));
user.setCreatedAt(LocalDateTime.now());
return userRepo.save(user);
}
private void validateEmailUniqueness(String email) {
if (userRepo.existsByEmail(email)) {
throw new EmailAlreadyExistsException(email);
}
}
private String encodePassword(String rawPassword) {
return passwordEncoder.encode(rawPassword);
}
}
符合SLAP的特点：
- 控制器只处理HTTP协议相关逻辑（参数验证、响应封装、异常映射）
- 服务层专注于领域规则（邮箱唯一性校验、密码加密）
- 层次间通过简单对象（User、UserRequest）通信，避免跨层次依赖
示例3：工具类设计（单一层次的功能封装）
// 高层：文件处理工具（协调步骤）
public class DocumentProcessor {
private final TextExtractor textExtractor;
private final TextCleaner textCleaner;
private final KeywordAnalyzer keywordAnalyzer;
// 仅定义文档处理的流程步骤
public AnalysisResult analyzeDocument(File documentFile) {
String rawText = textExtractor.extractFromFile(documentFile);
String cleanedText = textCleaner.clean(rawText);
return keywordAnalyzer.analyze(cleanedText);
}
}
// 中层：文本提取器（专注于文本提取逻辑）
public class TextExtractor {
private final PdfExtractor pdfExtractor;
private final DocExtractor docExtractor;
// 仅处理文本提取的中层逻辑（判断文件类型、选择提取器）
public String extractFromFile(File file) {
String extension = getFileExtension(file);
if ("pdf".equals(extension)) {
return pdfExtractor.extractText(file);
} else if ("doc".equals(extension) || "docx".equals(extension)) {
return docExtractor.extractText(file);
} else {
throw new UnsupportedFileException("Unsupported file type: " + extension);
}
}
private String getFileExtension(File file) {
// 提取文件扩展名的细节
String name = file.getName();
int lastDotIndex = name.lastIndexOf('.');
return lastDotIndex == -1 ? "" : name.substring(lastDotIndex + 1).toLowerCase();
}
}
// 底层：PDF提取实现（仅处理PDF解析细节）
public class PdfExtractor {
// 仅包含PDF解析的底层技术细节
public String extractText(File pdfFile) {
try (PDDocument document = PDDocument.load(pdfFile)) {
PDFTextStripper stripper = new PDFTextStripper();
return stripper.getText(document);
} catch (IOException e) {
throw new DocumentProcessingException("Failed to extract PDF text", e);
}
}
}
符合SLAP的特点：
DocumentProcessor只定义"分析文档"的流程，不涉及具体文件格式TextExtractor专注于"如何选择提取策略"，不包含PDF/Word的具体解析代码PdfExtractor仅处理PDF解析的底层技术细节（使用PDF库API）
这些示例的共同设计特点
- 层次分明：每个类/方法只处理同一抽象层次的逻辑，形成"高层指挥-中层协调-底层执行"的结构
- 命名自解释：方法名反映其抽象层次（如
analyzeDocument是高层，extractText是中层） - 依赖注入：通过构造函数注入不同层次的组件，避免在高层代码中直接创建底层对象
- 逐步深入：理解代码时可从高层方法开始，按需深入到更低层次的实现细节
遵循SLAP原则的代码读起来像"故事叙述"——先了解整体流程，再深入具体细节，大大降低了理解成本。
示例4：Spring源码
在Spring中，做上下文初始化的核心类AbstractApplicationContext的refresh()函数为我们在遵循SLAP方面做了一个很好的示范。
@Override
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
// Prepare this context for refreshing.
prepareRefresh();
// Tell the subclass to refresh the internal bean factory.
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// Prepare the bean factory for use in this context.
prepareBeanFactory(beanFactory);
try {
// Allows post-processing of the bean factory in context subclasses.
postProcessBeanFactory(beanFactory);
// Invoke factory processors registered as beans in the context.
invokeBeanFactoryPostProcessors(beanFactory);
// Register bean processors that intercept bean creation.
registerBeanPostProcessors(beanFactory);
// Initialize message source for this context.
initMessageSource();
// Initialize event multicaster for this context.
initApplicationEventMulticaster();
// Initialize other special beans in specific context subclasses.
onRefresh();
// Check for listener beans and register them.
registerListeners();
// Instantiate all remaining (non-lazy-init) singletons.
finishBeanFactoryInitialization(beanFactory);
// Last step: publish corresponding event.
finishRefresh();
}
catch (BeansException ex) {
if (logger.isWarnEnabled()) {
logger.warn("Exception encountered during context initialization - " +
"cancelling refresh attempt: " + ex);
}
// Destroy already created singletons to avoid dangling resources.
destroyBeans();
// Reset 'active' flag.
cancelRefresh(ex);
// Propagate exception to caller.
throw ex;
}
finally {
// Reset common introspection caches in Spring's core, since we
// might not ever need metadata for singleton beans anymore...
resetCommonCaches();
}
}
}
试想，如果上面的代码逻辑不是这样写，而是平铺在refresh()函数中，结果会是怎样？
扫一扫
15
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
