简单工厂使用策略模式

Question

我一直在学习设计模式，我觉得我有点困在一个没有任何答案页的练习中。

我已经使用策略模式来创建以下内容：http://i.imgur.com/5Lia4JD.png (减去setBehavior函数)

我需要用简单工厂来改进这个设计，因为目前，这两种行为都是通过以下代码实例化的(如示例所示)：

    public MallardDuck()
    { 
    setQuackBehavior(new Quack());
    setFlyBehavior(new FlyWithWings());
    }

这是不正确的，因为我们需要编程到一个接口，而不是一个实现。

我想要做的是制造两个不同的工厂，每个工厂处理一个特定的行为，但是当我进行设计时，我开始怀疑我的解决方案。用简单的工厂做这种事是正常的吗？

有人能把我推向正确的方向吗？

Answer 1

如果你在编程鸭子，那它就是个玩具例子。去做两个单独的简单工厂吧。一般规则是每个接口都有一个简单的工厂。您可以将所有简单的工厂放在一个类中，以使其不那么复杂。

具体类实例化其他具体类的缺点当然是对实现的危险耦合。如果实现细节发生了变化(是的，新的是琐碎的，但整个示例是微不足道的)，那么您的类知道信息也会发生变化。

你说得对，它不是在为接口编程。对实现细节了解较少的类更不受这些细节更改的影响，这是使用接口的全部要点。

Answer 2

如果您想避免具体策略和它们的主机之间的强耦合，您可以依赖一个工厂，它知道如何为给定类型的评价者实例化鸭子，而不是为每个类型拥有一个具体的类。

上面的设计可能更容易测试，但我认为您不应该太担心混凝土鸭子和它们使用的具体策略之间的耦合。

Answer 3

这是不正确的，因为我们需要编程到一个接口，而不是一个实现。

并且编程到接口，因为setQuackBehavior()以接口作为输入，而quack类将quack行为字段表示为接口，而不是实现。在代码中，一次使用实现类是正常的。在许多情况下，使用带有返回基于接口实例的方法的工厂是有用的，但在您的情况下，我不认为有兴趣。为什么您的庸医子类不应该知道所使用的具体行为？如果没有理由的话，那似乎没什么问题：

setQuackBehavior(new Quack());

使用没有附加价值的工厂可以毫无原因地给出复杂的代码。