大型初始化列表的缺点？答案

【问题标题】：Disadvantage to Large Initialization List?大型初始化列表的缺点？
【发布时间】：2012-02-10 12:52:02
【问题描述】：

在我的雇主处，我们在构造函数中使用初始化列表是一项政策，因为它更有效。

但是，我正在开发一个有 45 个需要初始化的数据成员的类。根据政策，这必须在构造函数的初始化列表中完成。

除了可读性之外，大型初始化列表还有什么缺点？

【问题讨论】：

除了可读性？除了可能出错，我什么都想不出来。
提示：如果您有 45 个成员属性，您可能没有适当地划分职责。

标签： c++ initialization-list

【解决方案1】：

您可以在多个物理源代码行上格式化成员初始化器列表，这样就不会出现可读性问题。

更大的问题显然是你的类有 45 个数据成员。没有什么能让使用这些类变得特别容易。

AClass::AClass( type1 val1
              , type2 val2
              // ...
              , type45 val45 )
: mem1( val1 )
, mem2( val2 )
// ...
, mem45( val45 )
{
}

我认为可读性不亚于：

AClass::AClass( type1 val1
              , type2 val2
              // ...
              , type45 val45 )
{
    mem1 = val1;
    mem2 = val2;
     // ...
    mem45 = val45;
}

【讨论】：

【解决方案2】：

我认为可能值得退后一步来了解为什么您的类有 45 个数据成员。这通常表明您的班级正在做太多事情，并且有太多单独的职责，这将使这个班级随着时间的推移很难维护。

听起来您可能需要将您的类分解为单独的功能部分，并将“控制器”类委托给子类。这将大大降低代码的复杂性。

【讨论】：

【解决方案3】：

这似乎是众所周知的反模式上帝对象。维基引用：

In object-oriented programming, a God object is an object that knows too much or does too much.

请找到一种方法来重新考虑您的设计，将上帝对象的成员分组为更小的结构和具有自己初始化过程的对象。

因此，对于“大型初始化列表有什么缺点？（与小型初始化列表相比）”这个问题的答案可能是“它很大，所以它可能是一种不好的样式。"

对于“大型初始化列表有什么缺点？（与大型构造函数体相比）”这个问题的答案可能是“none”，因为初始化最好在列表中完成，不是在正文中，但可读性和维护成本相同（对我而言）。

【讨论】：

这部分回答了关于大型初始化列表的缺点的问题？
这部分说，“如果你有很大的初始化列表，那么那就是个问题。”

【解决方案4】：

一些优化会失败，我怀疑这样的构造函数内联不起作用。

无论哪种方式：45 个数据成员听起来很多。你能把它们分组这么聚合的对象吗？

【讨论】：

为什么他们会因为初始化列表而失败，而不是没有初始化列表（你可以将这些初始化复制到正文中）？