所有工厂方法都应该公开吗？答案

【问题标题】：Should all factory methods be public?所有工厂方法都应该公开吗？
【发布时间】：2021-01-20 09:10:34
【问题描述】：

默认情况下所有工厂方法都应该是公共的

这有什么好的论据吗？我以前在使用工厂模式时从未偶然发现过这一点。

【问题讨论】：

我不知道 PHP，我可以说出我的看法，我的经验我有一些情况下只需要一些方法来进行一些本地操作，例如对于一个包中的 java，所以该方法可以是友好的（仅在包中可见）。或者也许在 C++ 中可以得到保护。我认为答案取决于语言以及您工厂的用例
问题是这个规则检查 all 工厂方法应该是公共的，我不知道为什么它们应该（独立于语言）。
我同意你的观点，我不认为所有的方法都需要公开，但如果我理解得很好，你链接它的存储库是一个框架，并且有一些内部规则。我不知道为什么，我认为从一般角度来看没有必要

【解决方案1】：

这条规则主要和Spryker SCOS Core开发有关。

Spryker OS 的这一部分是一个基于 PHP 的电子商务框架。由于它是一个框架，它旨在提供更好的定制和扩展能力。因此，关于工厂方法的开放可见性的严格规则支持用户完全控制工厂中每个模块中发生的依赖注入。

此规则也可用于目标高可定制性的常见 OSS 库。它意味着对定制业务逻辑“隐藏”的限制，并且需要工程师有意识地选择退出。在 Sprykers 案例中，合作伙伴网络将使用这种方法来提供高度可定制的集成模块。

对于典型的 PHP 项目用例，这条规则可能不太有用，甚至无用，与项目开发的保护性质大相径庭。

UPD：我们举个例子。 Order 可能是一个复杂的对象，包括多个依赖项，例如 Order Item。从一开始就可以访问所有部分使项目更容易并增强了可升级性：如果 Core 决定通过将可见性修饰符从受保护切换到公共来从外部访问工厂方法，则不会出现 BC 中断。因此可以安全地自定义工厂方法。

【讨论】：

嗯，如何通过公开所有方法来更多自定义？我不能完全理解这一点。我的观点是，如果规则至少允许受保护的方法，它不会减少它。
工厂作为通用基础设施的一部分在许多地方都可以使用（例如，Facades、Clients、Controllers）。将它们公开可确保所有工厂方法都可用。归根结底，工厂方法不仅可以在内部使用，而且可以在外部使用。在构建复杂模型时，包括创建多个实体允许独立使用粒子（例如，订单可以包括订单项目，独立使用订单项目的开放工厂方法对项目来说是一个有用的功能，即使它在核心中没有以这种方式使用）。

【解决方案2】：

看起来他们对“工厂”的定义只不过是一个特定类名的列表。

一般来说，工厂没有理由必须公开。请注意different factory patterns 在实现方面差异很大，您可能会看到太阳下的每个创建模式都被称为“工厂”。这个词本身太宽泛了，几乎没有任何意义。

【讨论】：