为什么避免工厂模式的条件逻辑是好的？

Question

抽象工厂模式好处之一是避免工厂模式的条件逻辑。但是，这种方法占用更多的类，更多的代码，更多的单元测试，并且不会使代码既不更快也不可读，如代码类图或文档。那么，在这种情况下在Factory模式上没有条件逻辑有什么意义呢？

Answer 1

抽象工厂模式的好处不是避免条件逻辑，而是使调用工厂的代码更加抽象。

想象一下，代码属于软件体系结构中的一个非常抽象的层（例如，业务域层）。如果您使用Factory模式，其中涉及一个具体的Factory类，该类知道很多细节（例如，数据库的API，第三方框架/库的API），那么您的业务域层将取决于这些细节。这减少了重用该层的机会，因为每次重用该层时，这些细节都必须存在。从体系结构的角度来看，您确实不希望这种依赖性。

Answer 2

在OOP中，有一个通用的“目标”可以用多态性代替条件逻辑（if-else，switch等）。这通常涉及创建抽象类或接口以及从那里创建可能需要的对象范围。

好处是可以添加新的派生类，而无需添加新代码。典型的示例是不同的形状类（正方形，圆形，三角形等），它们均从基本Shape类派生。例如，每个新形状都提供自己的draw（）实现。

在Abstract Factory中也是如此，其目的是为组件或类似组件提供多个“对象集”。规范的（人为的）示例为应用程序在Windows，Mac，X Windows等环境下工作提供了正确的UI对象集。 这个想法是将正确的工厂对象传递给应用程序，并允许它创建目标环境所需的一组正确的UI对象集。

如果没有这种构造，则需要向应用程序传递一个参数，例如“ Windows”，并使用“可怕的”条件逻辑来确定使用Factory Methods创建的对象。

大多数人都会同意，如果“对象集”的数量很少且固定不变，那么请继续使用条件逻辑和工厂方法。但是，如果情况发生变化，那么您将面临代码更改。

如果使用Abstract Factory添加新的“对象集”，则只需创建Abstract Factory的新子类，而无需更改应用程序代码。在大型系统中，这是更具可读性和可扩展性的，备受关注的属性。

那是“在工厂模式中没有条件逻辑的要点”，但总是根据您自己的业务需求进行判断。