面向对象本身不支撑大型项目，真正支撑的是基于OOP衍生的设计原则、分层结构和协作契约；封装需结合访问控制、不可变性与副作用约束；接口定义能力契约，抽象类固化模板流程；优先组合而非深度继承；多态应避免运行时高频类型判断。
面向对象本身不支撑大型项目，它只是提供了一套组织代码的语法工具；真正支撑大型项目的，是基于 OOP 衍生出的设计原则、分层结构和协作契约——比如封装让模块边界清晰，继承与多态为扩展留出余地，而接口驱动的依赖倒置才是解耦关键。
封装如何避免“改一处崩全链”
封装不是简单加 private，而是通过访问控制 + 不可变性 + 明确的副作用约束，把状态变更关进笼子。大型项目里最常踩的坑是：暴露 public 字段或返回内部集合引用，导致外部直接修改破坏一致性。
- 用
private字段 +getter（必要时返回副本）代替public字段 - 集合类优先用
Collections.unmodifiableList()或ImmutableList.copyOf() - 构造函数做参数校验，避免创建非法状态对象（如
new Order(null)应抛IllegalArgumentException）
接口与抽象类在分层架构中的真实分工
接口不是为了“看起来像面向接口编程”，而是划定能力契约；抽象类不是为了代码复用，而是固化模板流程。在 Spring Boot 项目中，Repository 层用接口（如 JpaRepository<user long></user>），是因为实现可能切换 JPA / MyBatis / Mock；而 AbstractService 类封装通用事务、日志、空值处理，则是因为这些逻辑在所有业务服务中必须统一执行。
- 接口定义“能做什么”（
UserService.findActiveUsers()），不承诺怎么实现 - 抽象类定义“必须怎么做”（
AbstractCommandHandler.execute()强制日志埋点 + 异常转译） - 避免让接口承担状态（别在接口里加
default方法维护缓存或计数器）
为什么过度继承反而拖垮可维护性
深度继承链（Animal → Mammal → Carnivore → Lion）在教学示例里很美，在真实系统里极难调试。Spring 的 BeanFactory 继承体系有 7 层深，但它的扩展点几乎全靠组合（BeanPostProcessor）而非子类重写。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 优先用组合：把“会飞”“会游泳”抽成
Flyable/Swimmable接口，由类选择实现 - 继承仅用于表达“is-a”且语义稳定的关系（如
SQLException是Exception的一种） - IDE 中 Ctrl+Click 追踪一个方法调用，如果跳转路径超过 4 层，大概率该重构为策略模式
多态在运行时动态决策中的实际代价
多态本身开销极小，但滥用会导致 JIT 无法内联、类型检查频繁、分支预测失败。高频调用路径（如订单状态流转 order.process()）若依赖大量 instanceof 或反射判断类型，性能会明显下降。
- 用枚举 + 策略映射表替代长
if-else（Map<ordertype orderprocessor></ordertype>） - 避免在循环体内做
getClass().getSimpleName()这类反射操作 - 对延迟敏感场景（如风控实时拦截），考虑用
sealed class（Java 17+）限定子类范围，帮助 JVM 做优化
public sealed interface PaymentStrategy permits AlipayStrategy, WechatStrategy, CardStrategy {}
public final class AlipayStrategy implements PaymentStrategy {
public void pay(Order order) { /* ... */ }
}真正卡住大型项目进度的，往往不是语法会不会用，而是没想清楚“这个类到底该对谁负责、被谁依赖、在什么条件下可以安全替换”。OOP 的设计决策一旦落地，比数据库 schema 还难改——因为编译期检查不会告诉你哪段调用悄悄绕过了抽象层。
