真正实现“动态组装”的是多态配合清晰设计结构，而非流程控制；应通过统一方法声明与子类重写、策略模式注入、模板方法钩子及接口隔离等方式，让类型决定行为，避免if-else类型判断。
在面向对象基础练习中，“利用流程控制动态组装子类特有行为”这个说法容易引起误解——流程控制（如 if/else、switch、for）本身不是组装行为的工具，而是运行时做选择的手段；真正实现“动态组装”的，是多态配合清晰的设计结构。初学者常误以为写个 if (obj instanceof Dog) 就算“动态组装”，其实这只是临时判断，既破坏封装，又难以扩展。真正符合 OOP 基础目标的做法，是让类型决定行为，而不是靠条件语句硬编码分支。
用多态代替 if-else 判断类型
当你要对不同子类执行不同逻辑时，不要写：
if (animal instanceof Dog) {
((Dog) animal).fetch();
} else if (animal instanceof Bird) {
((Bird) animal).fly();
}这违背了开闭原则，每加一个子类就得改这里。正确做法是：
- 在父类或接口中声明统一方法（如
performSpecialAction()） - 每个子类重写该方法，封装自己的特有行为
- 外部只调用
animal.performSpecialAction()，由 JVM 自动分发到对应子类实现
这样新增 Cat 子类只需重写方法，无需修改原有判断逻辑。
用策略模式 + 构造参数注入可选行为
子类特有的行为不一定要塞进继承链，可以抽成独立策略类，通过构造或 setter 注入：
interface SpecialAction { void execute(); }
class FetchAction implements SpecialAction { public void execute() { System.out.println("Fetching..."); } }
class DigAction implements SpecialAction { public void execute() { System.out.println("Digging..."); } }
class Dog {
private SpecialAction action;
public Dog(SpecialAction action) { this.action = action; }
public void doSpecial() { if (action != null) action.execute(); }
}创建对象时决定行为：
Dog dog1 = new Dog(new FetchAction()); // 启用拾取 Dog dog2 = new Dog(new DigAction()); // 启用挖掘
行为变化发生在对象创建阶段，运行时调用干净统一，不依赖流程控制分支。
在模板方法中预留可插拔钩子
父类定义主流程，把子类差异点设计为可重写的方法（钩子），再用 protected 或 default 访问修饰符暴露：
abstract class Animal {
public final void hunt() {
approach(); // 模板方法固定步骤
strike(); // 固定步骤
afterHunt(); // 钩子方法，默认空，子类可选择重写
}
protected void approach() { /* 默认实现 */ }
protected void strike() { /* 默认实现 */ }
protected void afterHunt() { /* 空实现，留给子类扩展 */ }
}
class Dog extends Animal {
@Override protected void afterHunt() {
System.out.println("Dog shakes off dirt");
}
}hunt() 调用路径完全由类型决定，流程控制（顺序执行）只是骨架，行为组装靠继承体系完成，不靠外部 if。
用接口隔离可选能力，避免类型检查
把“特有行为”定义为独立接口，子类按需实现，使用者通过接口引用调用：
interface Fetchable { void fetch(); }
interface Flyable { void fly(); }
class Dog implements Fetchable { public void fetch() { ... } }
class Bird implements Flyable { public void fly() { ... } }
// 使用时：
if (animal instanceof Fetchable) {
((Fetchable) animal).fetch();
}虽然这里用了 instanceof，但它是安全的类型探测，且只出现在使用端（非核心逻辑）。更优做法是：在工厂或构建器中提前判断并包装，让上层代码始终面对明确接口，例如：
Optional<Fetchable> fetcher = getFetcher(animal); fetcher.ifPresent(Fetchable::fetch);
不复杂但容易忽略
