我有一个包含方法和复杂数据结构的Product类。我将有8种类型的产品仅在数据结构的内容上有所不同，没有别的。在我的应用程序中，我需要为8种产品中的每一种创建一个实例，并且存在的产品类型在运行时不会改变。工厂设计模式VS构造器
什么是最好的方法，为什么？
A）类产品有8个子类。这些子类中的每一个仅定义构造函数。在每个构造函数中，为该类型的产品正确创建数据结构。 B）工厂类有8个子类。这八个类别中的每一个都是一个混凝土工厂。类产品没有子类。每个具体工厂通过创建适当的数据结构并将其作为参数传递给类Product的构造函数来创建特定类型的产品。
我一直在评论工厂设计模式的优点，我无法看到，对于这种特殊情况，B中的任何优势都超过A.我错过了什么吗？
我会带着A的变体，加上也许是一个工厂类。工厂的目的是创建具有在接口类中定义的方法的类，使得工厂创建的对象的使用者不知道他们正在处理的是什么类型的对象，而只知道接口。工厂自己知道要创建什么类型的对象。
如果在某个特定时间对于创建什么类型的产品有某种类型的逻辑，为8个实现IProduct接口的产品实现一个工厂，并实现工厂内创建什么类型产品的逻辑。
我试图完全理解你的建议：那么你如何让应用程序向工厂指定它需要的产品类型？通过传递某种论点？如果是这样，那么为什么应用程序不知道产品子类时，它反而需要知道传递给工厂的参数类型......是不是一样呢？ – CesarPim
不，我建议你将一个参数传递给工厂，但我不知道你的情况是什么样的参数。例如，我在一个实例中有一个Factory模式，它为各种类型的提要提供XML解析，并为您提供根消息。它可能是一个Atom Feed或一个SOAP Web服务，但工厂需要这个URL，并根据它的URL来简单地知道给出的解析器类型。例如， –
可能是产品的名称。或其条码。编程为接口而不是特定类型的对象只是一种更好的做法。 –
我相信在工厂设计模式中，您可以从单个工厂创建不同子类的对象。请参见下面的示例 -
使用与工厂设计模式的子类的做法是对于所提到的情况下更好的选择。根据我的。
如果我理解正确，你的答案是建议像@ kevin-hirst一样回答。所以我的问题是：工厂如何知道要创建什么产品？如果我们必须传递某种产品“名称”，那么它意味着应用程序必须知道产品名称。这不像知道产品子类那样糟糕吗？ – CesarPim
通过工厂创建类的新对象时，我相信您需要知道要构建的类的名称或任何显着特征。否则，你如何创建特定类的对象？工厂无法自行了解它。 一旦对象被创建，工厂将返回具有父类引用的特定对象。这一步之后系统不需要知道子类。 – EngineeredBrain
你提到 - 我将有8种类型的不同之处仅在数据结构的内容产品，没有别的...。这意味着状态和方法与不同的内容相同。基于这一点，我认为这清楚地表明这些不是亚类，而是同一类别的实例。我认为代码将只包含一个产品类和8个实例。工厂绝对不是必需的，它将是不必要的代码。
是的你是对的，它有8个实例，而不是8个子类更有意义。但问题是创建8种不同的数据结构是复杂的，我不希望客户端应用程序必须知道如何去做。所以构建逻辑可以在两个地方之一：无论是在工厂（我的职位的选项B）或产品的构造函数（在这种情况下需要8个不同的构造函数，这导致8个子类，即选项A我的帖子）。 – CesarPim
在这种情况下，构建器模式可能很有用@CesarPim。它不需要子类。如果您的数据结构具有组合（以及相应应用的方法），则复合模式也可以应用。你应该更新你的问题来指定你的8个数据结构的细节。 – Fuhrmanator
我从来没有见过一个工厂被分类。它会有每种类型的方法。但是，如果需要静态的Product对象集合，Factory更多用于在运行时创建这些对象 –
您的意思是像Factory一样使用返回8个产品的集合的方法？如果它返回一个集合而不是单个对象，它会被认为是正确的工厂设计模式吗？ – CesarPim
“我将有8种类型的产品仅在数据结构的内容上有所不同，没有别的。”什么是数据结构？如果它只是一个聚合（例如，数组，链表等），那么你不需要8个子类。 – Fuhrmanator