另一种流行的语言如何在管理与Java / Java EE类似的复杂性时避免使用工厂模式？

工厂模式（或至少使用FactoryFactory..）是许多笑话的对接，例如此处。

除了具有冗长和“创造性”的名称（如RequestProcessorFactoryFactory.RequestProcessorFactory）之外，如果您必须使用Java / C ++进行编程并且有Abstract_factory_pattern的用例，那么工厂模式是否有根本上的错误？

另一种流行的语言（例如Ruby或Scala）如何在管理相似的复杂性时避免使用它呢？

我要问的原因是，在Java / Java EE生态系统的背景下，我看到的大多数批评都是工厂，但它们从未解释其他语言/框架如何解决它们。

您的问题被标记为“ Java”，这并不奇怪您为什么要嘲笑Factory模式：Java本身附带了打包好的该模式的滥用。

例如，尝试从文件加载XML文档并对其执行XPath查询。您只需要设置10行代码即可设置工厂和建造者：

DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = builderFactory.newDocumentBuilder(); 

Document xmlDocument = builder.parse(new FileInputStream("c:\\employees.xml"));
XPath xPath =  XPathFactory.newInstance().newXPath();

xPath.compile(expression).evaluate(xmlDocument);

我想知道设计此API的人是否曾经以开发人员的身份工作过，还是只是读书和扔东西而已。我了解他们只是不想自己编写一个解析器，而是将任务留给其他人，但它仍然使实现很丑陋。

由于您要问还有什么替代方法，因此在C＃中加载XML文件：

XDocument xml = XDocument.Load("c:\\employees.xml");
var nodes = xml.XPathSelectElements(expression);

我怀疑刚孵出的Java开发人员会看到Factory疯狂，并且认为这样做是可以的-如果自己创建Java的天才已经使用它们那么多。

工厂模式和其他任何模式都是工具，每种模式都适合特定的工作。如果将它们应用于工作，那么它们将不适合您使用，因此代码一定很丑陋。

人们常常误解正在发生的事情（包括许多笑声）。
并不是很多人（也许甚至大多数人）使用工厂模式本身就很糟糕。

毫无疑问，这源于编程（和模式）的教授方式。告诉小学生（通常称自己为“学生”）“使用模式Y创建X”，经过几次迭代后认为这是解决任何编程问题的方法。
因此，他们开始在学校中应用碰巧喜欢的特定模式来对抗任何事物，无论它是否合适。

不幸的是，其中包括大学教授，他们撰写有关软件设计的书。
最终的结果是我不得不维护这样一个系统，我对此非常不满意（这个人甚至拥有几本有关面向对象设计的书，以他的名字命名，并且在一家主要大学的CS系任教） ）。
它基于3层模式，每个层本身都是3层系统（必须解耦...）。在两侧的每组层之间的接口上，有一个工厂来生产将数据传输到另一层的对象，还有一个工厂来生产对象以将接收到的对象转换为属于接收层的对象。
对于每个工厂，都有一个抽象工厂（谁知道，工厂可能必须更改，然后您不希望必须更改调用代码...）。
整个混乱当然是完全没有记载的。

系统的数据库标准化为第5个正常形式（我不告诉你）。

该系统实质上只是一个通讯录，可用于记录和跟踪传入和传出的文档，它在C ++中具有100MB的代码库和50多个数据库表。使用直接连接到运行该软件的计算机的打印机，打印500个套用信将花费长达72小时。

这就是为什么人们嘲笑模式，尤其是人们一心一意地专注于一个特定的模式。

工厂具有许多优点，可以在某些情况下进行优雅的应用程序设计。一种是可以通过创建工厂来设置以后要创建的对象的属性，然后将该工厂移交给其他人。但是通常您实际上并不需要这样做。在这种情况下，使用Factory只会增加额外的复杂性，而实际上并没有给您任何回报。让我们以这个工厂为例：

WidgetFactory redWidgetFactory = new ColoredWidgetFactory(COLOR_RED);
Widget widget = redWidgetFactory.create();

Factory模式的一种替代方法是非常相似的Builder模式。主要区别在于，由工厂创建的对象的属性是在初始化工厂时设置的，而生成器是使用默认状态初始化的，而所有属性均在此后设置。

WidgetBuilder widgetBuilder = new WidgetBuilder();
widgetBuilder.setColor(COLOR_RED);
Widget widget = widgetBuilder.create();

但是当过度工程成为您的问题时，用制造商替换Factory可能不会带来太大的改善。

这两种模式中最简单的替代方法当然是使用带有new运算符的简单构造函数来创建对象实例：

Widget widget = new ColoredWidget(COLOR_RED);

但是，构造函数在大多数面向对象的语言中有一个关键的缺点：它们必须返回该确切类的对象，而不能返回子类型。

如果您需要在运行时选择子类型，但又不想为此创建一个全新的Builder或Factory类，则可以改用工厂方法。这是类的静态方法，该方法返回该类或其子类之一的新实例。不维护任何内部状态的工厂通常可以用这种工厂方法代替：

 Widget widget = Widget.createColoredWidget(COLOR_RED); // returns an object of class RedColoredWidget

Java 8中的新功能是方法引用，它使您可以像在无状态工厂中那样传递方法。方便地，任何接受方法引用的对象也将接受实现相同功能接口的任何对象，该对象也可以是具有内部状态的成熟Factory，因此，当您看到这样做的原因时，可以稍后轻松地引入它们。

在适当的情况下，几乎任何面向对象的语言都可以发现一种或另一种工厂。有时，您只是需要一种方法，可以根据一个简单的参数（如字符串）选择要创建哪种对象。

有些人太过分了，尝试构建代码，除在工厂内部外，无需调用构造函数。当您拥有工厂工厂时，事情开始变得荒谬。

当我学习Scala并且不了解Ruby时，给我留下了深刻的印象，但我相信这是完全一样的，因为该语言具有足够的表现力，程序员并不总是尝试将“管道”工作推向外部配置文件。在Scala中，您使用混合了特征的对象，而不是试图创建工厂工厂来将类以不同的配置连接在一起，而不是被诱惑。在语言中创建简单的DSL相对容易，这对于以Java过度设计的任务来说是很容易的。

而且，正如其他评论和答案所指出的那样，闭包和一流的功能消除了对许多模式的需求。因此，我相信随着C ++ 11和Java 8的广泛采用，许多反模式都将消失。

通常，这种趋势是Java程序被过度工程化[需要引用]。拥有许多工厂是过度设计的最常见症状之一。这就是为什么人们取笑那些。

特别是，Java在工厂中遇到的问题是在Java中a）构造函数不是函数，并且b）函数不是一等公民。

想象一下，您可以编写这样的内容（让它Function成为JRE的知名接口）

// Framework code
public Node buildTree(Function<BranchNode, Node, Node> branchNodeFactory) {
    Node current = nextNode();
    while (hasNextNode()) {
        current = branchNodeFactory.call(current, nextNode());
    }
    return current
}

// MyDataNode.java
public class MyBranchNode implements BranchNode {

    public MyBranchNode(Node left, Node right) { ... }
}

// Client code
Node root = buildTree(MyBranchNode::new);

参见，没有工厂接口或类。许多动态语言具有一流的功能。,，这在Java 7或更早版本中是不可能的（通过工厂实现相同的功能留给读者练习）。

因此，替代方案不是“使用不同的模式”，而是“使用具有更好对象模型的语言”或“不要过度设计简单问题”。