5

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

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

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

4

4 回答 4

8

您可以在多个物理源代码行上格式化成员初始值设定项列表，因此不必存在可读性问题。

更大的问题显然是你的类有 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;
}
于 2012-02-09T18:41:31.227 回答
8

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

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

于 2012-02-09T18:42:57.993 回答
3

这似乎是众所周知的反模式神物。维基引用：

在面向对象编程中，上帝对象是一个知道太多或做太多的对象。

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

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

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

于 2012-02-09T18:59:29.200 回答
-1

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

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

于 2012-02-09T18:43:04.047 回答