业务需求的变化是软件开发中唯一不变的事情。对象行为如果被硬编码在方法内部，任何细微调整都可能牵动整个类甚至继承体系。面向对象编程的核心优势之一，就是通过抽象和多态将易变的行为隔离在可控边界内。Java语言提供了接口、抽象类、组合、函数式接口等多种机制，帮助开发者构建一个能够响应变化而不必频繁修改既有代码的对象行为体系。本文从行为抽象、状态管理、组合复用和行为参数化等层面，深入探讨如何在Java中落地面向变化的OOP思想。
一、把行为抽象为接口，让变化有清晰边界
在面向对象设计中，行为抽象通常从接口开始。接口定义一组操作契约，具体怎么执行由实现类决定。这样客户端只依赖接口，不依赖具体算法。比如支付场景，支付行为可能包含支付宝、微信、银行卡等多种方式，如果把它们都写进订单结算方法里，就会形成一长串if-else判断。更合理的方式是定义PaymentStrategy接口，让每种支付方式成为独立实现。订单类只持有一个PaymentStrategy引用，结算时调用pay方法。新增支付方式不需要修改订单类，只需要添加一个实现类，这符合开闭原则。
接口抽象让变化边界清晰，但要注意接口隔离原则。不要设计臃肿接口，避免实现类被迫实现不相关的方法。例如支付行为和退款行为可以拆成两个接口，由不同实现类按需组合。这样做虽然接口数量增多，但每个接口职责单一，调用方不会因为某个不相关方法的改动而受到影响。面向变化的本质，就是让每个可能变化的点都有独立的替换单元。
public interface PaymentStrategy {
void pay(BigDecimal amount);
}
public class AlipayStrategy implements PaymentStrategy {
@Override
public void pay(BigDecimal amount) {
System.out.println("支付宝支付：" + amount + " 元");
}
}
public class WechatPayStrategy implements PaymentStrategy {
@Override
public void pay(BigDecimal amount) {
System.out.println("微信支付：" + amount + " 元");
}
}
public class Order {
private final PaymentStrategy paymentStrategy;
public Order(PaymentStrategy paymentStrategy) {
this.paymentStrategy = paymentStrategy;
}
public void checkout(BigDecimal amount) {
paymentStrategy.pay(amount);
}
}
// 使用示例
Order order = new Order(new AlipayStrategy());
order.checkout(new BigDecimal("299.00"));
上面的代码中，Order类完全不需要知道支付宝或微信支付的具体实现，它只依赖PaymentStrategy接口。未来新增银行卡支付、积分支付等方式，只需添加新的实现类并在创建订单时传入，不会影响已有代码。这种把行为抽象成接口的方式，是构建健壮对象行为体系的第一步。
二、用状态模式管理内部状态与行为切换
有些对象的行为不是由客户端选择，而是由对象内部状态决定。比如订单有“待支付”“已支付”“已发货”“已完成”等状态，在不同状态下，同一个操作如“确认收货”的行为不同。如果使用大量if-else判断状态，代码会迅速膨胀，而且新增状态需要修改所有相关方法，容易遗漏分支。状态模式将每个状态封装成独立类，状态类实现共同的OrderState接口，上下文对象将请求委托给当前状态对象。状态对象在执行操作后可以切换上下文的下一个状态，从而实现状态转换的集中管理。
状态模式让每个状态的行为内聚在对应的状态类中，上下文只负责维护当前状态并转发请求。例如待支付状态下调用ship应该抛出异常，已支付状态下则可以正常发货。这种方式消除了跨方法的状态判断，新增状态时只需增加一个状态类，并在相关转换中设置新状态即可。
public interface OrderState {
void pay(OrderContext context);
void ship(OrderContext context);
void confirm(OrderContext context);
}
public class PendingState implements OrderState {
@Override
public void pay(OrderContext context) {
System.out.println("支付成功，订单状态变为已支付");
context.setState(new PaidState());
}
@Override
public void ship(OrderContext context) {
throw new IllegalStateException("待支付订单不能发货");
}
@Override
public void confirm(OrderContext context) {
throw new IllegalStateException("待支付订单不能确认收货");
}
}
public class PaidState implements OrderState {
@Override
public void pay(OrderContext context) {
throw new IllegalStateException("订单已支付，请勿重复支付");
}
@Override
public void ship(OrderContext context) {
System.out.println("发货成功，订单状态变为已发货");
context.setState(new ShippedState());
}
@Override
public void confirm(OrderContext context) {
throw new IllegalStateException("已支付订单不能确认收货");
}
}
public class OrderContext {
private OrderState state = new PendingState();
public void setState(OrderState state) {
this.state = state;
}
public void pay() {
state.pay(this);
}
public void ship() {
state.ship(this);
}
public void confirm() {
state.confirm(this);
}
}
状态模式与策略模式虽然结构相似，但存在本质区别。策略模式中客户端主动选择策略，对象通常不自己改变策略；状态模式中状态对象会根据内部逻辑推动上下文切换，客户端一般不直接指定下一个状态。状态模式把条件判断分散到各状态类中，虽然类变多，但每个状态的行为内聚，可读性和可维护性更好。对于状态数量固定且转换规则复杂的对象，状态模式能显著提升代码的健壮性。
三、组合优于继承，用委托拼装行为组件
继承是实现行为复用的一种方式，但过度继承会让子类与父类形成强耦合。父类的修改可能影响所有子类，而且Java只支持单继承，行为复用受限。组合则是将行为封装成独立组件，通过持有引用并委托调用，实现更灵活的复用。例如需要给服务类添加日志记录、性能统计、权限校验等横切行为，如果使用继承，每个服务都要继承某个基类，基类可能变得庞大；使用组合可以将这些行为拆成独立组件，按需装配。
组合的核心思路是让一个类实现某个接口，同时在内部持有另一个同类型接口的引用，把真正的业务逻辑委托给被包装的对象。这样可以像套娃一样一层层叠加行为，例如先记录日志、再校验权限、最后执行业务。每层只关注自己的职责，修改或增加新行为都不会影响到其他层。
public interface Executor {
void execute();
}
public class BusinessExecutor implements Executor {
@Override
public void execute() {
System.out.println("执行业务逻辑");
}
}
public class LoggingExecutor implements Executor {
private final Executor delegate;
public LoggingExecutor(Executor delegate) {
this.delegate = delegate;
}
@Override
public void execute() {
System.out.println("开始记录日志");
delegate.execute();
System.out.println("结束记录日志");
}
}
// 使用示例
Executor executor = new LoggingExecutor(new BusinessExecutor());
executor.execute();
实际开发中，组合通常配合依赖注入框架使用。开发者可以在配置文件中声明行为组件的装配顺序，运行时动态替换某个组件，而不需要修改任何Java代码。组合也让类更专注于单一职责，符合高内聚低耦合原则。当需求发生变化时，只需要新增一个装饰组件或者调整装配顺序，系统仍然保持稳定。
四、行为参数化与函数式接口的轻量实践
Java 8引入的Lambda表达式和函数式接口提供了一种更轻量的行为抽象方式。对于只包含一个抽象方法的接口，可以直接用Lambda传递行为，而不必为每个变化都创建一个实现类。比如集合过滤、排序、回调等场景，使用Predicate、Comparator、Consumer等标准函数式接口，可以让代码更简洁。
行为参数化的优势在于，它把变化的行为作为参数传入方法，方法本身保持稳定。例如一个通用的过滤方法可以接受任意条件，调用方根据需要传入不同的Predicate即可。这种方式特别适合逻辑简单但变化频繁的场景，避免了为每个条件都写一个策略类的繁琐。
public static <T> List<T> filter(List<T> list, Predicate<T> predicate) {
List<T> result = new ArrayList<>();
for (T item : list) {
if (predicate.test(item)) {
result.add(item);
}
}
return result;
}
// 使用示例
List<User> adults = filter(users, user -> user.getAge() >= 18);
函数式接口本质上是只有一个方法的策略接口，Lambda就是内联的策略实现。当策略逻辑非常简单时，不必新建类；当策略逻辑复杂、包含状态或需要复用并单独测试时，仍应使用具名实现类。选择的标准是看行为是否具有独立生命周期和复用价值。轻量变化用Lambda，重量变化用策略类，两者可以共存于同一个系统中。
五、不可变对象与防御性拷贝守护行为稳定性
对象行为能否稳定，除了恰当抽象，还取决于对象状态是否容易被意外修改。可变对象被共享时，某个调用方修改内部集合或日期字段，可能导致其他调用方观察到不一致状态，从而引发难以排查的行为异常。不可变对象在创建后状态不可改变，天然线程安全，行为可预测。Java中实现不可变类需要将类声明为final、字段为private final、不提供修改方法，并且确保引用类型字段在构造和访问时进行防御性拷贝。
public final class ImmutableUser {
private final String name;
private final List<String> roles;
public ImmutableUser(String name, List<String> roles) {
this.name = name;
this.roles = List.copyOf(roles);
}
public String getName() {
return name;
}
public List<String> getRoles() {
return roles;
}
}
上面的ImmutableUser构造时通过List.copyOf复制集合，外部传入的列表后续修改不会影响内部状态。返回角色列表时直接返回内部引用也没问题，因为List.copyOf返回的是不可变集合。如果字段是Date类型，构造时应使用new Date(date.getTime())，getter返回副本，避免可变日期被外部修改。
不可变设计让对象行为不受外部状态干扰，尤其适合作为缓存键、配置对象、值对象。它也强化了面向变化的能力，因为状态不会意外漂移，代码在并发环境下也能保持稳定。配合防御性拷贝，开发者可以放心地把对象共享给多个调用方，而不必担心行为被破坏。
六、总结
构建健壮的对象行为体系，本质上是把变化隔离在明确定义的边界内。接口抽象定义行为契约，状态模式管理内部转换，组合提供灵活复用，函数式接口轻量化行为参数，不可变设计确保状态稳定。这些技术并非孤立存在，通常需要组合使用。当业务变化来临时，开发者能够通过添加新实现、调整装配或传递新行为来响应，而不是修改已经稳定的核心逻辑。这是面向对象设计应对变化的核心思想，也是Java开发者提升代码质量的重要路径。