在Java项目里，需求变更往往是检验代码结构的试金石。一个支付模块起初只支持支付宝，后来要加微信、银联，如果每次改动都在主流程里加if-else，很快会失控。面向对象设计原则（OOP设计原则）解决的就是这类问题：让类、接口、继承和组合之间的关系更加稳定，使新增功能通过扩展而不是修改来实现。下面结合Java语言特性，拆解这些原则在真实业务中的用法。

一、单一职责与开闭原则：从订单类拆分到策略扩展

单一职责原则（SRP）要求一个类只负责一件事。比如订单服务类如果同时处理校验、库存扣减、优惠计算、短信通知，任何环节调整都可能影响其他逻辑。可以拆分为OrderValidator、InventoryService、DiscountCalculator、NotificationService，每个类只依赖自己需要的资源。这样修改优惠算法时，订单主流程不需要重新测试库存部分。

拆分后还更容易满足开闭原则（OCP）。开闭原则要求对扩展开放，对修改关闭。以折扣策略为例，如果直接在订单总价计算里写死多种优惠分支，新增一种满减就需要修改原有代码。正确做法是抽象出DiscountStrategy接口，每种优惠实现一个类。Java的接口天然支持多态，配合工厂或Spring的@Autowired列表注入，可以在不修改调用方的情况下加入新策略。

public interface DiscountStrategy {
    BigDecimal apply(Order order);
}
public class FullReductionDiscount implements DiscountStrategy {
    public BigDecimal apply(Order order) {
        // 满300减50示例
        if (order.getTotalAmount().compareTo(new BigDecimal("300")) >= 0) {
            return order.getTotalAmount().subtract(new BigDecimal("50"));
        }
        return order.getTotalAmount();
    }
}

使用时可以通过List<DiscountStrategy>注入所有实现，按条件筛选，无需改动主流程。这种设计让单一职责与开闭原则互相配合：每个策略类职责单一，新增策略不影响已有代码。

二、依赖倒置与接口隔离：从抽象出接口到依赖注入

依赖倒置原则（DIP）强调高层模块不应该依赖低层模块，两者都应该依赖抽象。在Java中意味着尽量依赖接口或抽象类，而不是具体实现类。一个典型反例是订单服务直接new AliPayService()，后续接入微信支付就得改代码。正确做法是定义PaymentService接口，订单服务只持有该接口引用，由Spring容器注入具体实现。Spring的依赖注入机制天然支持这一原则，通过@Autowired或构造器注入即可切换支付渠道。

接口隔离原则（ISP）提醒我们不要设计胖接口。如果一个UserService接口里既有注册登录方法，又有报表导出、权限同步等无关方法，实现类不得不实现所有方法，哪怕很多方法抛UnsupportedOperationException。应该按客户端需求拆分成AuthService、UserReportService、PermissionSyncService等更小的接口。这样调用方只依赖自己关心的方法，降低耦合。

public interface AuthService {
    User login(String username, String password);
    void logout(String token);
}
public interface PermissionSyncService {
    void syncUserRole(Long userId, List<String> roles);
}

接口隔离与依赖倒置结合时，要注意接口粒度不是越细越好。过细的接口会导致类数量膨胀、调用关系复杂。通常以业务能力边界为划分依据，一个接口对应一个稳定的业务概念。

三、里氏替换与合成复用：继承的正确姿势

里氏替换原则（LSP）指出，子类必须能够替换父类并且行为不变。Java中继承虽然方便，但很容易违反LSP。比如Rectangle类有setWidth和setHeight方法，如果Square继承Rectangle并重写这两个方法使宽高始终相等，那么使用Rectangle的代码在传入Square时可能得到意外结果。典型场景是断言长宽独立变化，正方形无法满足。因此更好的做法是让Square不继承Rectangle，而是实现一个共同的Shape接口。

合成复用原则（CRP）进一步建议优先使用对象组合而不是类继承。组合可以动态地改变行为，降低类之间的耦合。例如一个Duck类不应该通过继承Flyable基类获得飞行能力，而应该持有FlyBehavior接口引用，通过构造器或setter注入不同的飞行实现。这样可以在运行时改变飞行方式，也避免了继承层次过深带来的脆弱基类问题。

public interface FlyBehavior {
    void fly();
}
public class FlyWithWings implements FlyBehavior {
    public void fly() {
        System.out.println("用翅膀飞行");
    }
}
public class Duck {
    private FlyBehavior flyBehavior;
    public Duck(FlyBehavior flyBehavior) {
        this.flyBehavior = flyBehavior;
    }
    public void performFly() {
        flyBehavior.fly();
    }
}

实际开发中，如果两个类之间是明确的“is-a”关系且父类设计稳定，继承依然可用；如果只是为了复用代码，组合更安全。Java只支持单继承，组合也能突破这个限制。

四、迪米特法则与设计模式落地

迪米特法则（LoD）也叫最少知识原则，要求一个对象尽量少地了解其他对象。常见违反场景是链式调用order.getUser().getAddress().getCity()，当前类直接穿透多个对象。可以改为在Order类中提供getCity()方法，内部委托给User和Address。这样调用方只与Order直接交互，降低了耦合。不过要注意，过度封装也可能导致类方法过多，需要权衡。

设计模式是这些原则的典型落地方式。策略模式对应开闭原则，观察者模式体现了依赖倒置和单一职责，模板方法模式在父类中定义算法骨架，子类实现具体步骤。以订单状态机为例，可以使用状态模式让每个状态类职责单一，新增状态只需增加类，不用修改原有状态逻辑。这些模式背后都是同一套设计原则在起作用。

public interface OrderState {
    void pay(Order order);
    void ship(Order order);
}
public class PendingPaymentState implements OrderState {
    public void pay(Order order) {
        order.setState(new PaidState());
        System.out.println("支付成功");
    }
    public void ship(Order order) {
        throw new IllegalStateException("未支付订单不能发货");
    }
}

在代码评审中，可以建立一套检查清单：类是否只有一个变化原因；新增功能是否需要修改既有类；高层模块是否依赖抽象；接口是否包含无关方法；子类替换父类后是否产生意外行为；是否过度使用继承而忽略组合；是否存在深层链式调用。逐条对照，就能快速定位设计问题。