大型初始化列表的缺点？

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个数据成员。这通常表明你的班级做了太多事情，并且有太多单独的责任，这将使这个班级很难维持一段时间。

听起来你可能需要将你的类分成不同的功能块并让'controller'类委托给子类。这将大大降低代码的复杂性。

Answer 3

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

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

请找到一种方法来重新考虑您的设计，将神对象的成员分组为较小的结构和对象，并使用自己的初始化程序。

所以回答一个问题“大型初始化列表的缺点是什么？（比较小的一个）”可能是“它很大，所以可能是一个糟糕的风格。” >“

回答“大型初始化列表的缺点是什么？（与大型构造函数体相比）”可能是“ none ”，因为初始化最好在列表中完成，不是在体内，而是可读性和维护成本相同（对我来说）。

Answer 4

有些优化会失败，我怀疑内联这样的构造函数是行不通的。

无论哪种方式：45个数据成员听起来很多。你可以将它们分组为聚合对象吗？