Java面向对象三大特性是封装、继承、多态；封装强调隐藏实现细节并暴露有意义行为，而非仅用private+getter/setter；继承应严格遵循“is-a”关系，避免为复用而滥用；多态需通过统一接口和运行时动态绑定消除if-else类型判断。
Java 面向对象三大特性（封装、继承、多态）在面试中常被问“你遇到过哪些实际痛点？怎么解决的？”，这类题不考死记硬背，而是看是否真用过、是否理解设计意图。关键不是罗列概念，而是讲清场景、错误做法、改进逻辑和落地细节。
封装：别把 private + getter/setter 当成封装
很多候选人说“我用了 private 和 public 方法，就是封装了”。这其实是虚假封装——字段虽私有，但通过大量 getter/setter 暴露内部结构，外部代码仍能随意修改状态，破坏对象一致性。
- 真正封装的核心是：隐藏实现细节 + 暴露有意义的行为
- 比如 Student 类，不要暴露
setScore(int)让外部直接改分数；应提供takeExam(Exam exam)，由对象自己根据考试结果更新分数 - 优先用不可变对象（final 字段 + 无 setter）或防御性拷贝（如返回 List 的副本而非原引用）
继承：警惕“为了复用而继承”
面试官常问：“你什么时候用过继承？有没有后悔用继承？” 这是在考察是否识别出“is-a”关系被滥用。
- 典型反例：为复用
eat()、sleep()就让CarDriver、Teacher、Doctor都继承Person，结果Person一改，所有子类都受影响 - 更合理的解法是提取共性行为为接口（如
LivingBeing）或组合（如引入LifeRoutine类，各角色持有它） - 继承只用于清晰的、稳定的“是一种”关系（如
ArrayList是List，IOException是Exception）
多态：避免 instanceof 和 if-else 类型判断
如果代码里频繁出现 if (obj instanceof PaymentWechat) { ... } else if (obj instanceof PaymentAlipay) { ... }，说明多态没用到位，违反开闭原则。
立即学习“Java免费学习笔记（深入）”；
- 正确做法：定义统一接口（如
PaymentProcessor），每个支付方式实现自己的process() - 扩展新支付方式时，只需新增实现类，无需修改原有判断逻辑
- 配合工厂或策略模式（如 Spring 的
@Qualifier或 Dubbo 的 SPI）自动装配，让运行时决定调用哪个实现
结合真实场景组织回答
面试时用一句话带出背景，再聚焦一个具体问题。例如：
- “我们在重构订单状态流转时，原来用一堆 if-else 判断 status 字段来执行不同操作，每次加新状态都要改主逻辑。后来提取出
OrderState接口，每个状态（Created、Paid、Shipped）实现自己的handleEvent()，状态变更就委托给当前状态对象——这就是多态驱动的状态机。” - “早期用户实体暴露了所有字段的 setter，导致前端传参异常时业务层直接被污染。后来改成构造时全量初始化 + 只开放有限的业务方法（如
changePhone(VerificationCode)），把校验和副作用控制在类内部。”
