遵循面向对象设计原则的实际表现是类间关系可替换、可扩展、不耦合，如支付模块改动不影响订单等模块，新增支付方式只需新增类；核心是通过接口依赖、依赖注入、遵守里氏替换等实现solid落地。
什么是“遵循面向对象设计原则”的实际表现
不是写个 class 就算面向对象，而是让类与类之间的关系可替换、可扩展、不耦合。比如你改一个支付模块，不该牵连订单、用户、日志模块；加一种新支付方式（如 Apple Pay），不该动已有代码，只新增类即可。这背后是 SOLID 原则的落地，但别被术语吓住——它本质是「写人能轻松看懂、机器能安全扩改」的代码习惯。
用 interface 而不是 class 做依赖声明
常见错误：把具体实现类（如 AlipayService）直接写进业务逻辑里，导致后续加 WechatPayService 时必须改方法签名、if-else 判断、甚至单元测试全崩。
正确做法是先定义契约：
public interface PaymentService {
boolean pay(Order order, BigDecimal amount);
}
再让具体实现去实现它：
立即学习“Java免费学习笔记（深入）”；
public class AlipayService implements PaymentService { ... }
public class WechatPayService implements PaymentService { ... }
业务类只依赖接口：
public class OrderService {
private final PaymentService paymentService; // 不是 AlipayService！
public OrderService(PaymentService paymentService) {
this.paymentService = paymentService;
}
public void checkout(Order order) {
paymentService.pay(order, order.getTotal());
}
}
- 测试时可用
Mockito.mock(PaymentService.class)快速隔离 - 切换支付渠道只需改构造注入的对象，不碰业务逻辑行
- 违反这点，
Open/Closed Principle（开闭原则）就塌了一半
避免在构造函数里做重操作或强依赖初始化
典型反例：new DatabaseConnection()、loadConfigFromFile()、initHttpClient() 直接塞进构造函数。结果一 new 对象就可能抛 IOException 或阻塞线程，且无法 mock、无法控制生命周期。
更稳妥的做法：
- 构造函数只接收已创建好的依赖（即依赖注入），保持轻量、无副作用
- 耗时/异常风险操作移到
init()方法，由调用方显式触发（如 Spring 的@PostConstruct） - 若必须懒加载，用
Supplier<x></x>或Optional<x></x>包一层，推迟实例化时机
例如：
public class ReportGenerator {
private final Supplier<PdfRenderer> rendererSupplier;
public ReportGenerator(Supplier<PdfRenderer> rendererSupplier) {
this.rendererSupplier = rendererSupplier; // 不立即 new
}
public byte[] generate() {
PdfRenderer renderer = rendererSupplier.get(); // 真正需要时才创建
return renderer.render(data);
}
}
子类不应破坏父类的行为契约
这是 Liskov Substitution Principle（里氏替换原则）最常踩的坑。比如父类 CollectionUtils.isEmpty(List> list) 规定：传 null 返回 true；结果子类重写后对 null 抛 NullPointerException，上游所有调用立刻崩溃。
判断是否合规，看三点：
- 子类方法的参数范围不能比父类更窄（比如父类接受
Object，子类不能只接受String） - 子类方法的返回值类型不能比父类更宽（比如父类返回
List<user></user>，子类不能返回ArrayList<object></object>） - 子类不能在父类没声明异常的地方抛新异常，也不能取消父类声明的异常处理义务
更简单的方法：只要父类能跑通的单元测试，换成子类实例也必须全部通过。
真正难的不是记住五条原则名字，而是每次写 new、写 if、写 public void 时，多问一句：“以后有人要加另一种实现，得动我几行？会破谁的假设？”
