在 GoF 的工厂方法设计模式中，我可以看到 FactoryMethod() 方法不接受任何参数。我的理解是 FactoryMethod 应该传递一个将在 switch case 中使用的参数，然后根据 switch case 中的值，实例化不同的类对象并返回给调用者。我的问题总结如下：
1) 我是否应该按照 GoF 定义的方式实现工厂方法模式。我还指的是在 www.dofactory.com 上为工厂方法模式提供的 UML 图）。
2) 为什么GoF的工厂方法模式没有显示接受参数？
【问题讨论】：
标签： oop design-patterns
1) 我应该实现工厂方法吗 模式，完全相同的方式 由 GoF 定义。我也指 在 www.dofactory.com 上给出的 UML 图 工厂方法模式）。
做任何对你有意义的事情。模式只是指导方针，而不是绝对的自然法则。
不仅如此，GoF 中的模式并不全面。你会发现自己发现并实现了书中从未出现过，甚至没有名字的模式。这是一件好事。
2) 为什么是工厂方法模式 的 GoF 未显示接受参数？
工厂方法模式只是派生类的一个特殊实例。特别是，您有一个带有抽象方法的抽象类，以及实现该方法的任意数量的派生类。通常，这个实现的方法会返回一些其他类型的对象——这就是使它成为创建模式的原因。
因此，使用DoFactory.com 上的示例，类返回一组固定对象。原则上没有什么可以阻止用户将某些参数传递给工厂方法。
我的理解是 FactoryMethod 应该传递一个 将在 切换案例，然后根据 开关盒中的值，不同 类对象被实例化并且 返回给调用者。
如果这对您有意义，您当然可以这样实现。
【讨论】：
2) 为什么是工厂方法模式 的 GoF 未显示接受参数？
在面向对象编程中，您的方法应该做一件明确定义的事情。传递某种值来打开被称为“交替内聚”：相反，该方法应该分成多个方法，每种情况一个。例如：
createVeggie(veggieType)
会被拆分成
createBroccoli()
createCelery()
createCollaredGreens()
这使您的类接口更清晰，更容易修改，并改进编译时检查。
另外，请注意不要违反工厂方法的意图：它实际上是避免让调用代码知道创建了哪个对象。正如 Juliet 所说，您可以实现这样的东西，但它不再是 GoF 工厂方法，并且没有相同的优势。
【讨论】：