通过封装、多态和职责分离将业务逻辑与代码结构对齐，用领域对象替代贫血模型，以Order.pay()为例实现内聚校验，利用DiscountStrategy多态消除条件分支，拆分大Service为小聚合如UserRegistration，通过方法名validateEligibilityForPromotion等表达业务意图，使代码具备可读性与扩展性。
在Java中通过面向对象编程（OOP）优化业务逻辑层，核心是让代码结构与现实业务场景对齐，提升可读性、可维护性和扩展性。关键不是堆砌设计模式，而是用类、方法、继承、多态等语言特性准确表达业务意图。
用领域对象代替贫血模型
很多项目中Service层操作的是简单的POJO或DTO，数据和行为分离，导致业务逻辑散落在各处。应将相关数据与行为封装到领域对象中，使其具备“生命力”。
例如订单状态变更，不要写成：
if ("UNPAID".equals(order.getStatus())) {
order.setStatus("PAID");
order.setPayTime(new Date());
}
而应封装进Order类：
立即学习“Java免费学习笔记（深入）”；
public class Order {
private String status;
public void pay() {
if (!canPay()) throw new IllegalStateException("不可支付");
this.status = "PAID";
this.payTime = new Date();
}
private boolean canPay() {
return "UNPAID".equals(status);
}
}
调用方只需写 order.pay()，语义清晰，状态校验内聚。
善用多态替代条件分支
面对不同类型的处理逻辑（如不同支付方式、审批流程），避免使用if-else或switch判断类型，而是通过继承和重写实现多态。
比如多种折扣策略：
interface DiscountStrategy {
BigDecimal apply(BigDecimal amount);
}
class FixedDiscount implements DiscountStrategy {
public BigDecimal apply(BigDecimal amount) {
return amount.subtract(BigDecimal.TEN);
}
}
class PercentageDiscount implements DiscountStrategy {
public BigDecimal apply(BigDecimal amount) {
return amount.multiply(new BigDecimal("0.9"));
}
}
业务层无需判断类型，直接调用 strategy.apply(amount)，新增策略不影响原有代码。
职责单一：拆分大Service为小聚合
一个UserService处理注册、登录、权限、通知，容易失控。按业务维度拆分为RegistrationService、LoginService、ProfileService等，每个类只关心一件事。
更进一步，可引入领域驱动设计（DDD）中的聚合根概念，控制边界和一致性。例如用户注册涉及创建账户、发邮件、记录日志，这些动作由RegistrationAggregate统一协调，对外暴露简洁接口：
public class UserRegistration {
public RegisteredUser register(RegistrationForm form) {
User user = userRepository.create(form.toUser());
emailService.sendWelcome(user.getEmail());
eventLogger.log("user_registered", user.getId());
return new RegisteredUser(user);
}
}
用方法名表达意图，而非注释
好的命名本身就是文档。避免写“处理用户信息”这种模糊注释，而是通过方法名体现业务动作：
- validateEligibilityForPromotion(user)
- revokeAccessUponTermination(employee)
- escalateUnresolvedTicket(ticket)
这些方法名读起来像业务规则描述，别人看调用链就能理解流程。
基本上就这些。OOP的本质是建模——把业务概念变成有行为的对象，让代码像业务说明书一样易懂。不复杂，但需要持续思考“这个逻辑属于谁”。
