《Head First设计模式》中组合优于继承的鸭类场景疑问

嘿，这个问题问得特别戳中组合模式的核心困惑！我当初啃《Head First设计模式》的时候也卡在这里，给你一步步理清楚～

首先得复盘下继承方案的致命问题：
你想啊，要是直接在抽象Duck类里加Fly()方法，那橡胶鸭（RubberDuck）也得继承这个方法——但橡胶鸭根本不会飞啊！这就违反了现实逻辑，而且以后如果要改飞行行为（比如有的鸭子用翅膀飞，有的用火箭助推），你得挨个修改所有鸭子类的Fly()实现，代码重复不说，维护成本高到爆炸。

那组合模式到底是怎么解决问题的？核心就是把行为从鸭类中抽离出来，让鸭类「持有」行为，而不是「继承」行为。你之前看到的代码其实少了关键一步，我给你补全正确的实现逻辑：

1. 正确的组合模式代码结构 #

首先是飞行行为的接口和实现：

// 飞行行为的抽象接口
interface IFly {
    void fly();
}

// 会飞的实现
class Flyable implements IFly {
    @Override
    public void fly() {
        System.out.println("I'm flying with wings!");
    }
}

// 不会飞的实现
class NonFlyable implements IFly {
    @Override
    public void fly() {
        System.out.println("I can't fly at all...");
    }
}

然后是修改后的抽象Duck类——这里不再是继承飞行行为，而是组合（持有）一个飞行行为对象：

public abstract class Duck {
    // 组合飞行行为：把行为当成一个「组件」放在鸭类里
    protected IFly flyBehavior;

    public void swim() {
        System.out.println("All ducks swim the same way!");
    }

    public abstract void look();

    // 不自己实现飞行，而是委托给持有的行为对象
    public void performFly() {
        flyBehavior.fly();
    }

    // 可选：提供setter方法，允许动态修改飞行行为
    public void setFlyBehavior(IFly flyBehavior) {
        this.flyBehavior = flyBehavior;
    }
}

最后是具体鸭子类的实现，在构造时指定自己的飞行行为：

// 绿头鸭：天生会飞
public class MallardDuck extends Duck {
    public MallardDuck() {
        // 直接给flyBehavior赋值为会飞的实现
        this.flyBehavior = new Flyable();
    }

    @Override
    public void look() {
        System.out.println("I'm a colorful mallard duck with green head!");
    }
}

// 橡胶鸭：不会飞
public class RubberDuck extends Duck {
    public RubberDuck() {
        this.flyBehavior = new NonFlyable();
    }

    @Override
    public void look() {
        System.out.println("I'm a squeaky yellow rubber duck!");
    }
}

2. 你的疑问解答：怎么配置？组合到底解决了什么？ #

（1）如何根据鸭的类型配置飞行行为？ #

每个鸭子类的飞行特性是固定的（比如绿头鸭天生会飞，橡胶鸭不会），所以直接在子类的构造方法中初始化对应的飞行行为对象就可以了。如果遇到特殊情况（比如一只绿头鸭受伤了，暂时不能飞），还能通过setFlyBehavior()动态修改：

MallardDuck injuredDuck = new MallardDuck();
injuredDuck.performFly(); // 输出：I'm flying with wings!
// 受伤后改成不会飞
injuredDuck.setFlyBehavior(new NonFlyable());
injuredDuck.performFly(); // 输出：I can't fly at all...

这种动态调整的能力，是继承绝对做不到的——继承的行为是固定死的，子类一旦继承就只能重写，没法随时切换。

（2）组合到底解决了哪些问题？ #

• 消除不合逻辑的继承：橡胶鸭再也不用被迫继承它做不到的Fly()方法，完全符合现实逻辑。
• 遵循开闭原则：以后要加新的飞行行为（比如火箭助推飞RocketPoweredFly），只需要新增一个IFly的实现类，所有需要这个行为的鸭子类直接在构造时替换就行，不用修改任何现有鸭类的代码。
• 避免代码重复：如果有10种鸭子都会飞，不用在10个子类里重复写Fly()的实现，只需要都复用Flyable类的代码即可。
• 行为独立扩展：飞行行为可以单独迭代优化，比如给Flyable加个「滑翔」的逻辑，所有用Flyable的鸭子类都会自动获得这个能力，不用挨个修改。

说白了，组合模式把「鸭是什么」和「鸭能做什么」分开了——鸭的属性（比如外观、游泳）是它本身的，而飞行这种行为是可以替换的组件，这样代码的灵活性和可维护性直接拉满！

内容的提问来源于stack exchange，提问作者BishtDev