避免具有多个参数的构造函数

Question

所以我有一个工厂，它创建不同类别的对象。可能的类都是从抽象祖先派生出来的。工厂有一个配置文件(JSON语法)，并根据用户的配置决定要创建哪个类。

为此，工厂使用boost::property_tree进行JSON解析。他遍历ptree并决定要创建哪个具体对象。

但是，产品对象有许多字段(属性)。根据具体的类，对象大约有5-10个属性，将来可能会更多。

所以我不确定对象的构造函数应该是什么样子。我能想到两种解决方案：

1)产品的构造函数要求每个属性都作为参数，因此构造函数将以10+参数结束。这将是丑陋的，并导致长，不可读的代码行。但是，优势在于工厂可以解析JSON并使用正确的参数调用构造函数。产品类不需要知道它是由于JSON配置而创建的。它根本不需要知道有JSON或配置。

2)产品的构造函数只需要一个参数，即property_tree对象。然后，它可以解析所需的信息。如果配置中的am信息丢失或超出范围，那么每个产品类都可以做出正确的反应。工厂不需要知道这几种产品需要什么论据。工厂也不需要知道如何在配置错误的情况下作出反应。构造器接口统一，体积小。但是，作为一个缺点，产品需要从JSON中提取所需的信息，因此，它知道如何构造它。

我倾向于选择解决方案2)。然而，我不确定这是否是一个好的工厂模式。让产品知道它是用JSON配置创建的，这是错误的。另一方面，新产品可以很简单的介绍。

对此有什么看法吗？

Answer 1

我不会做选项2，因为那样的话，您将永远使用boost属性树解析来转换对象的构造。如果您对需要这么多参数的类感到满意，那么您应该对需要这么多参数的构造函数感到满意，这就是生命！

如果您的主要关注点是代码可读性，那么您可以使用构建器模式，它基本上是c++/java的权宜之计，因为没有命名的参数。你最终会得到这样的东西：

MyObject o = MyObject::Builder()
               .setParam1(val1)
               .setParam2(val2)
               .setParam3(val3)
             .build();

所以现在MyObject将有一个私有构造函数，它在Builder::build中被调用。好的一点是，这将是唯一需要调用具有10个参数的构造函数的地方。boost属性树工厂将使用构建器，随后如果您想直接或从另一个源构建MyObject，则需要遍历构建器。构建器基本上允许您在传递每个参数时明确命名它，因此它更易读。这显然增加了一些样板，所以您将不得不决定是否值得这样做，而不是仅仅调用混乱的构造函数，或者将现有的一些参数合并到结构中，等等。

https://en.wikipedia.org/wiki/Builder_pattern#C.2B.2B_示例

Answer 2

备选案文2几乎是正确的。

一种改进的备选方案2

创建一个“正面”类，它的任务是接受JSON结构对象并选择位并调用工厂构造器(S)。它把工厂生产的东西交给客户。

• 工厂完全不知道这样的JSON东西甚至存在。
• 客户不必知道工厂需要哪些特定位元。

基本上，“前端”是对两个胸部：说：“我和经过修改的客户打交道，这样工程师就不用了！我有人际交往的技能！”可怜的汤姆。如果他只说“我把客户和建筑脱钩，这个结果就是一个凝聚力很强的工厂”，他可能会保住他的工作。

太多的争论？

不是为了客户前端的交流。

前端工厂？如果不是10个参数，那么最好的方法是推迟解压缩，如果不是原来的JSON，那么就需要一些DTO。这比把JSON传递给工厂好吗？跟我说的一样。

我强烈考虑传递个别参数。坚持一个干净，有凝聚力的工厂的目标。避免@DavidPacker回答.的担忧

减轻“太多参数”的

• 工厂或类构造函数
  • 只使用特定类/对象构造的参数。
  • 默认参数
  • 可选参数
  • 命名参数

• 前端参数分组
  • 检查、计算、验证、设置等由上述构造函数签名指导的参数值。