工厂（方法）模式和对深/长链中其他方法或其他工厂的标注答案

【问题标题】：Factory (method) pattern and callouts to other methods or other factories in a deep/long chain工厂（方法）模式和对深/长链中其他方法或其他工厂的标注
【发布时间】：2020-03-05 17:19:44
【问题描述】：

在我的工作中有大量讨论什么是工厂模式。

主要讨论点是在创建对象的工厂中是否也可以通过其他工厂分支调用其子类的填充。

或者父工厂需要这些细节作为其构造函数的一部分作为参数以及其他数据？

工厂内可以调用其他工厂吗？还是一个工厂应该是自给自足的和完全独立的？

【问题讨论】：

有几种非常不同的工厂模式。如果您查看我的this answer，它将清除一些令人困惑的点并链接到一个更长的答案，该答案非常详细地描述了几个模式。
阅读该信息后，如果您能说出您所询问的工厂模式，并添加一些（伪）代码来演示导致您的工作出现分歧的替代方案，将会很有帮助。
是的，我们知道工厂模式的不同风格。然而，问题是工厂是否可能依赖于对象子类的分支。工厂可以依赖其他工厂方法还是应该（自给自足）独立？
如果不命名特定模式并举例说明（可能）不允许的情况，这个问题对我来说没有意义。这些模式有太多的混乱，无法简单地猜测一个。并且认为这个问题对所有口味都有一个答案的假设可能是不正确的。味道大相径庭。答案可能也一样。

标签： design-patterns factory factory-pattern anti-patterns factory-method

【解决方案1】：

这对我来说不是是或否问题，所以，它来了。

我认为在工厂内部调用工厂是可以的，但是，如果不考虑它可能带来的弊端，就无法做到这一点。工厂链越深，依赖性就越复杂。此外，它可能会影响可维护性和可测试性。

为了避免具体的依赖关系，您可能想要解耦它，应用SOLID 原则。它将带您进入一个完全灵活且可注射的工厂家庭。但是，如果没有 DI Container，它可能会变得很痛苦，而使用 DI Container，还应该考虑性能。

所以，简短的回答是是的，但是，您需要在灵活性、可维护性、可测试性和性能之间找到平衡。

拇指规则：如果确实需要，请创建结构，不要过度设计。

【讨论】：

问题没有提到 GoF 抽象工厂模式。
首先问题不是抽象工厂，而是简单的工厂对象创建模式。其次，这正是我自己的看法。在工作中，一个家伙制造了各种工厂，其链条深度高达 4-5 层，这使得一个松散的方向很快。我宁愿看到，你们有独立的、自给自足的工厂。
我听说有些人把这些深链工厂称为“魔法工厂”，而不是正面的。
好的@codingjoe，所以如果你澄清你所指的模式，我可以改写我的答案。因为它是一个“模式”，它应该在别处命名。 Factory 的另一个选项是Factory Method，是您要讨论的那个吗？
@wedersonSoares 是的，抱歉，我看不清楚。我指的是工厂方法。