类继承链不宜超过三层，两层清晰可控，三层需谨慎评估；应优先用接口定义契约、抽象类封装共性，组合优于继承，慎用protected与模板方法。
类继承链不宜超过三层
Java 中过度拉长继承链会显著增加维护成本，且容易违反里氏替换原则。当子类数量增多、行为差异变大时，extends 就不再是首选方案。
- 两层继承（如
Animal → Dog）清晰可控；三层（Animal → Mammal → Dog）需谨慎评估抽象粒度是否合理 - 一旦出现“为了复用而继承”或“子类需要屏蔽父类方法”，说明该用组合（
has-a）替代继承（is-a） - 接口 + 默认方法比抽象类更适合横向能力扩展，例如
Runnable、Comparable不参与继承体系却可被任意类实现
用接口定义契约，用抽象类封装共性
接口负责声明“能做什么”，抽象类负责实现“怎么做的一部分”。二者配合才能支撑可扩展的层次结构。
-
interface中只能有public abstract方法和public static final常量；Java 8+ 允许default和static方法，但不应承载核心业务逻辑 -
abstract class可含构造器、成员变量、protected方法、具体实现，适合抽取模板逻辑（如AbstractList的add()模板） - 避免让抽象类实现多个接口——这会模糊职责；应由具体子类按需实现接口，抽象类只专注纵向共性
组合优于继承：通过字段注入能力而非类继承
当需要动态切换行为、或同一类在不同场景下表现不同时，硬编码继承关系会迅速僵化。
- 把可变行为抽成接口（如
PaymentStrategy），在主类中持有一个private PaymentStrategy strategy字段 - 运行时通过构造器或 setter 注入不同实现（
new CreditCardStrategy()/new PayPalStrategy()），比写CreditCardPayment extends Payment更灵活 - 标准库中
ArrayList内部用Object[]数组而非继承数组，HashMap封装Node[]而非扩展它——这是组合的典型实践
慎用 protected 成员与模板方法模式
protected 是继承体系的“暴露面”，滥用会导致子类过度依赖父类内部实现细节，一旦父类重构就大面积报错。
Blender Geometry Nodes Script Generator
下载
生成Blender Python (bpy)脚本，该脚本使用node_groups API和GeometryNodeTree接口程序化地创建几何节点修改器树，用于参数化3D资产生成。
立即学习“Java免费学习笔记（深入）”；
- 模板方法（如
AbstractMap#put()调用抽象entrySet()）应只开放必要钩子，且每个钩子要有明确语义和文档说明 - 若子类需重写多个
protected方法才能正常工作，说明抽象类职责过重，应拆分或改用策略模式 - Java 9+ 模块系统下，
protected在跨模块继承时受限制，更需提前规划包结构与访问边界
// 示例：组合优于继承的典型写法
public class Order {
private PaymentStrategy paymentStrategy;
<pre class='brush:java;toolbar:false;'>public Order(PaymentStrategy strategy) {
this.paymentStrategy = strategy;
}
public void process() {
paymentStrategy.pay(); // 行为委托，不耦合具体实现
}}
public interface PaymentStrategy { void pay(); }
public class AlipayStrategy implements PaymentStrategy { public void pay() { / 支付宝逻辑 / } }
真正难的不是画出五层继承图，而是判断哪一层该停、哪个方法该抽成接口、哪段逻辑该从父类移进策略对象里。这些决策点往往藏在第一次修改子类却要动父类的时候。
