大型初始化列表的缺点？

Question

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

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

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

Answer 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;
}

Answer 2

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

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

Answer 3

这似乎是众所周知的反模式God object。 Wiki 引用：

在面向对象编程中，God 对象是一个知道太多或做太多事情的对象。< /a>

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

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

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

Answer 4

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

不管怎样：45 个数据成员听起来很多。你能将它们分组为如此聚合的对象吗？