Question

我正在阅读Head First设计模式，反对继承的一点是它难以编写组合更灵活的行为。我无法完全理解它。请考虑以下类：

interface Flyable{
    void fly();
}
// Imagine this duck is exposed as a Spring bean named "mallardDuck" :
class MallardDuck implements Flyable {
    @Override
    public void fly() {
        System.out.println("Flying slowly");
    }
}
class IndianDuck {
    Flyable f;
    public void setF(Flyable f) {
        this.f = f;
    }
    public void fly() {
        f.fly();
    }       
}
// Imagine this duck is exposed as a Spring bean named "indianFlight" :
class FlyCautiously implements Flyable {
    @Override
    public void fly() {
        System.out.println("Flying cautiously");
    }
}

所以印度鸭使用遗传组成VS野鸭。考虑以下客户端：

public static void main(String[] args) {
    // Inheritance:
    Flyable f = (Flyable) context.getBean("mallardDuck"); // Use of Spring
    f.fly();

    // Composition
    IndianDuck d = new IndianDuck();
    Flyable f = (Flyable) context.getBean("indianFlight"); 
    d.setF(f);
    d.fly();
}

现在假设我希望两只鸭子能够以超快模式飞行，我需要进行以下的继承更改：

扩展MallardDuck并创建一个MallardSuperFastDuck。
在应用程序上下文中指向mallardDuck到MallardSuperFastDuck而不是MallardDuck。

对于作文，我需要几乎相同的步骤：

扩展Flyable并创建一个新的SuperFastFlyer（实现Flyable）
将indianFlight指向新对象SuperFastFlyer

我无法理解为什么继承在上述情况下不太灵活。我确信我错过了这一点，但是在考虑了太多之后我发布了这个。

有人可以解释我在这里缺少的东西吗？

另外 - 据说，你可以在运行时将行为联系起来。真？如果我完全需要新的行为 - 我必须编写一个新类，再次编译代码。所以这也是编译时间。

请解释。

由于

继承VS组成的灵活性

0 个答案: