在Java项目开发里，业务逻辑层是承接上层请求和底层数据操作的核心部分，很多项目随着业务复杂度提升，会出现大量if-else嵌套、业务规则散落在不同方法里的问题，导致代码和业务实际含义脱节。通过OOP的特性优化业务逻辑层，能让代码结构和业务语义高度匹配，提升整体代码质量。
常见的业务逻辑层痛点
很多开发人员在写业务逻辑时，习惯把所有的业务判断和处理都放在一个Service类的一个方法里，比如订单处理的逻辑，可能会在一个方法里同时处理订单校验、优惠计算、库存扣减、状态更新等多个环节，代码可能变成下面这样：
public class OrderService {
public void processOrder(Order order) {
// 订单基础校验
if (order == null) {
throw new IllegalArgumentException("订单不能为空");
}
if (order.getAmount() <= 0) {
throw new IllegalArgumentException("订单金额不合法");
}
// 优惠计算
if ("VIP".equals(order.getUserType())) {
order.setAmount(order.getAmount() * 0.8);
} else if ("SVIP".equals(order.getUserType())) {
order.setAmount(order.getAmount() * 0.7);
}
// 库存扣减
if (order.getProductStock() < order.getQuantity()) {
throw new RuntimeException("库存不足");
}
// 更新订单状态
order.setStatus("PROCESSED");
// 后续其他逻辑...
}
}
这种写法的问题很明显，所有业务规则都耦合在一个方法里，后续如果要新增用户类型、修改优惠规则，都需要改动这个方法，很容易引入bug，而且其他人看代码的时候很难快速对应到具体的业务场景。
用封装提取业务概念
首先可以把业务里的核心概念封装成独立的类，比如订单本身可以封装更多和业务相关的校验逻辑，而不是把校验都放在Service里：
public class Order {
private String orderId;
private Double amount;
private String userType;
private Integer productStock;
private Integer quantity;
private String status;
// 构造方法、getter、setter省略
/**
* 订单基础校验逻辑，属于订单自身的业务规则
*/
public void validateBase() {
if (this.amount == null || this.amount <= 0) {
throw new IllegalArgumentException("订单金额不合法");
}
if (this.productStock < this.quantity) {
throw new RuntimeException("库存不足");
}
}
/**
* 计算优惠后的金额，不同用户类型的优惠规则属于订单自身的计算逻辑
*/
public void calculateDiscount() {
if ("VIP".equals(this.userType)) {
this.amount = this.amount * 0.8;
} else if ("SVIP".equals(this.userType)) {
this.amount = this.amount * 0.7;
}
}
public void markAsProcessed() {
this.status = "PROCESSED";
}
}
这样订单相关的业务规则都内聚在Order类里，Service层的代码就可以简化很多，只需要调用订单自身的方法即可，代码和业务语义的对应关系更清晰。
用多态消除条件判断
上面的优惠计算还是用了if-else判断用户类型，后续新增用户类型还是要改Order类的代码，这时候可以用多态来优化，把不同用户类型的优惠规则抽象成独立的策略类：
/**
* 优惠计算策略接口，对应业务里的优惠规则抽象
*/
public interface DiscountStrategy {
Double calculate(Double originalAmount);
}
/**
* 普通用户无优惠策略
*/
public class NormalUserDiscountStrategy implements DiscountStrategy {
@Override
public Double calculate(Double originalAmount) {
return originalAmount;
}
}
/**
* VIP用户8折策略
*/
public class VipUserDiscountStrategy implements DiscountStrategy {
@Override
public Double calculate(Double originalAmount) {
return originalAmount * 0.8;
}
}
/**
* SVIP用户7折策略
*/
public class SvipUserDiscountStrategy implements DiscountStrategy {
@Override
public Double calculate(Double originalAmount) {
return originalAmount * 0.7;
}
}
然后再增加一个策略工厂，根据用户输入的用户类型返回对应的策略，这样新增用户类型的时候只需要新增策略类，不需要修改原有代码：
public class DiscountStrategyFactory {
private static final Map<String, DiscountStrategy> STRATEGY_MAP = new HashMap<>();
static {
STRATEGY_MAP.put("NORMAL", new NormalUserDiscountStrategy());
STRATEGY_MAP.put("VIP", new VipUserDiscountStrategy());
STRATEGY_MAP.put("SVIP", new SvipUserDiscountStrategy());
}
public static DiscountStrategy getStrategy(String userType) {
return STRATEGY_MAP.getOrDefault(userType, new NormalUserDiscountStrategy());
}
}
这时候Order类的优惠计算方法就可以改成调用策略，消除了条件判断：
public class Order {
// 其他属性和方法省略
public void calculateDiscount() {
DiscountStrategy strategy = DiscountStrategyFactory.getStrategy(this.userType);
this.amount = strategy.calculate(this.amount);
}
}
优化后的Service层代码
经过上面的封装和多态优化，Service层的业务逻辑方法会变得非常简洁，每一行代码都对应一个明确的业务动作，和业务语义高度贴合：
public class OrderService {
public void processOrder(Order order) {
if (order == null) {
throw new IllegalArgumentException("订单不能为空");
}
// 订单基础校验
order.validateBase();
// 计算优惠
order.calculateDiscount();
// 标记订单为已处理
order.markAsProcessed();
// 后续可以调用数据层方法保存订单
}
}
这样的代码结构，开发人员看Service层的方法就能快速理解订单处理的整个业务流程，每个业务规则都放在对应的类里，后续修改或者新增业务规则的时候，影响范围很小，维护成本大幅降低。
总结优化要点
- 把业务里的核心概念封装成类，把属于该概念的属性和行为内聚到类里，避免业务规则散落在Service层
- 对于有多种实现方式的业务规则，用接口+多态的方式抽象，避免大量的条件判断，符合开闭原则
- Service层的方法尽量只做业务流程的编排，每个步骤都对应明确的业务动作，不要包含具体的业务规则实现
- 类的命名、方法命名尽量使用业务领域的术语，让代码读起来像业务文档，进一步贴合业务语义