java面向对象编程是围绕class、new、this、super展开的具体机制；new强制绑定构造方法，this/super有严格作用域，多态需继承关系、父类引用指向子类对象、调用重写实例方法三者缺一不可。
Java面向对象编程不是一套抽象理论，而是围绕 class、new、this、super 这几个关键词展开的一系列具体约束和协作机制。理解不到位，写出来的代码就容易出现 NullPointerException、方法调用错乱、子类无法复用父类逻辑等问题。
类定义与实例化：为什么 new 后必须跟构造方法？
Java 中没有“直接创建对象”的语法糖；new 操作符强制绑定一个构造方法（哪怕是编译器自动生成的无参构造）。这决定了对象初始化的入口是明确且唯一的。
常见错误现象：
- 定义了带参数的构造方法后，忘记补上无参构造，导致 Spring 或 Jackson 反序列化失败
- 在构造方法里调用
this(...)或super(...)时位置不对（必须是第一行） - 在构造方法中启动线程或注册监听器，但此时对象尚未完全构建完成，引发竞态或空引用
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 若需支持反射或框架注入，显式声明
public MyClass() {} - 构造方法只做必要字段赋值和轻量级初始化；重逻辑移入
init()或使用工厂方法 - 避免在构造方法中调用可被子类重写的方法（
overridable method call in constructor）
this 和 super 的实际作用域边界
this 不只是“当前对象引用”，它还承担字段/方法消歧义、链式构造调用、作为参数传递等角色；super 则严格限定为访问父类中被覆盖（@Override）或隐藏（字段同名）的成员。
关键区别：
-
this.field访问的是当前类声明的字段（即使子类有同名字段也不会向上查找） -
super.method()调用的是父类版本的方法，但该方法内部若又调用了this.xxx()，仍会触发子类重写版本（动态绑定不变） -
super()只能在构造方法首行调用，且每个构造方法最多调用一次
典型陷阱：
class Parent {
String name = "parent";
void print() { System.out.println(name); }
}
class Child extends Parent {
String name = "child";
void print() { System.out.println(name); }
void test() {
System.out.println(this.name); // 输出 "child"
System.out.println(super.name); // 输出 "parent"
super.print(); // 输出 "child"（因为 print() 内部的 this.name 指向 Child 实例）
}
}
多态发生的三个硬性前提
Java 多态不是“写了 extends 就自动生效”，它依赖编译期类型（引用类型）和运行期类型（实际 new 的类型）分离这一机制。缺一不可。
必须同时满足：
- 存在继承或实现关系（
class A extends B或class C implements D） - 父类引用指向子类对象（
B obj = new A();） - 调用的是被子类重写（
@Override）的实例方法（非static、非private、非构造方法）
注意：
-
static方法看编译期类型（B.staticMethod()永远调用B中的版本） - 字段访问不具多态性（
obj.field总是取编译期类型的字段） - 泛型擦除后，
List<string></string>和List<integer></integer>在运行时都是List，无法靠类型参数实现多态分发
封装的本质不是“全加 private”，而是控制变更影响范围
把字段设为 private 只是手段，真正目标是让外部依赖不随内部实现细节变化而失效。很多团队误以为加了 getter/setter 就算封装好了，其实不然。
容易被忽略的点：
- 返回数组或集合时，若直接返回私有字段引用（如
return this.items;），外部可随意修改，破坏封装 - setter 中不做校验（如允许
setAge(-5)），等于把校验责任推给所有调用方 - getter 返回可变对象（如
Calendar、ArrayList）却不做防御性拷贝
改进做法：
- 集合类字段优先返回
Collections.unmodifiableList(...)或新副本 - 对基础类型参数做边界检查，并抛出
IllegalArgumentException - 考虑用 builder 模式替代大量 setter，尤其当对象状态需满足一致性约束时
真正难的从来不是记住“四大特性”名词，而是每次写 new、每次加 private、每次重写 toString() 时，脑子里是否清楚这个动作在内存布局、调用链路、生命周期上带来了什么连锁反应。
