高内聚低耦合：Java模块化设计与Spring实战

1. 高内聚低耦合的本质理解

我第一次真正理解高内聚低耦合的价值，是在维护一个遗留系统时。那个系统里有个3000多行的"万能类"，既处理用户登录又负责订单计算，还兼顾日志记录。每次修改登录逻辑都会意外影响订单功能，那种痛苦让我深刻意识到：软件设计不是炫技，而是为了让人能长期维护。

高内聚（High Cohesion）就像整理房间——把袜子放在衣柜抽屉，碗筷收进厨房橱柜。每个模块只做一件事，且把所有相关操作集中在一起。比如用户管理模块应该包含：

• 用户信息校验
• 密码加密存储
• 权限校验
• 会话管理

而低耦合（Low Coupling）则是给房间之间留出通道。两个模块交互时，应该像快递柜取件——只需要知道取件码（接口），不需要了解快递员如何分拣（实现细节）。在Java中常见的耦合形式包括：

• 继承耦合（父类修改影响所有子类）
• 全局变量耦合
• 直接依赖具体实现类

经验之谈：判断设计好坏有个简单方法——修改某个功能时，是否需要同时改动多个不相关的文件？如果需要，说明耦合度太高了。

2. 实现高内聚的实战策略

2.1 单一职责原则的落地

Spring Boot项目中常见的内聚问题就是Controller既处理HTTP协议转换又执行业务逻辑。我曾重构过一个订单接口，原始代码是这样的：

java复制@PostMapping("/order")
public ResponseEntity createOrder(@RequestBody OrderDTO dto) {
    // 参数校验
    if(dto.getItems() == null || dto.getItems().isEmpty()) {
        throw new IllegalArgumentException("订单项不能为空");
    }
    
    // 业务逻辑
    User user = userService.getCurrentUser();
    Inventory inventory = inventoryService.lockItems(dto.getItems());
    Order order = new Order();
    order.setUser(user);
    order.setItems(inventory.getItems());
    
    // 持久化
    orderRepository.save(order);
    
    // 发送事件
    eventPublisher.publish(new OrderCreatedEvent(order));
    
    return ResponseEntity.ok(order);
}

重构后的版本将职责拆分到不同层：

java复制// OrderController.java
@PostMapping("/order")
public ResponseEntity createOrder(@Valid