使用简单工厂的策略模式

Question

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

我已经使用策略模式创建了这个： http://i.imgur.com/5Lia4JD.png（减去duck中的setBehavior函数）

我需要使用简单工厂来改进此设计，因为目前，通过以下代码实例化了两种类型的行为（通过示例显示）：

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

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

我想做的是制作2个独立的工厂，每个工厂都处理一个特定的行为，但是当我进行设计时，我开始怀疑我的解决方案。用简单的工厂做这种事情是正常的吗？

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

Answer 1

如果你想避免具体策略和它们的主机之间的强耦合，你可能会依赖一个工厂，它知道如何使用适当的策略为给定类型的rater实例化Duck，而不是每种类型都有一个具体的类。

上述设计可能稍微有些可测试，但我认为你不应该太关注混凝土鸭子与他们使用的具体策略之间的耦合。

Answer 2

  

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

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

setQuackBehavior(new Quack());

使用没有附加值的工厂会给出一个复杂的代码而没有理由。

Answer 3

如果你正在编写Ducks，那么它无论如何都是一个玩具的例子。来吧，做两个单独的简单工厂。一般规则是每个接口的简单工厂。您可以将所有简单工厂放在一个类中，以减少它的复杂性。

实例化其他具体类的具体类的缺点当然是与实现的风险耦合。如果实现细节发生变化（是的，新的是微不足道的，但整个鸭子的例子很简单），那些知道这些信息的类也可能会发生变化。

你是对的，它没有编程到界面。对实现细节知之甚少的类更加不受这些细节的变化的影响，这是使用接口的全部要点。