在我的雇主,政策是我们在构造函数中使用初始化列表,因为它更有效。
但是,我正在开发一个有45个数据成员需要初始化的类。根据策略,这必须在构造函数的初始化列表中完成。
除了可读性之外,大型初始化列表的缺点是什么?
答案 0 :(得分: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;
}
答案 1 :(得分:8)
我认为可能值得退一步了解为什么您的班级有45个数据成员。这通常表明你的班级做了太多事情,并且有太多单独的责任,这将使这个班级很难维持一段时间。
听起来你可能需要将你的类分成不同的功能块并让'controller'类委托给子类。这将大大降低代码的复杂性。
答案 2 :(得分:3)
这似乎是众所周知的反模式上帝对象。维基引文:
In object-oriented programming, a God object is an object that knows too much or does too much.
请找到一种方法来重新考虑您的设计,将神对象的成员分组为较小的结构和对象,并使用自己的初始化程序。
所以回答一个问题“大型初始化列表的缺点是什么?(比较小的一个)”可能是“它很大,所以可能是一个糟糕的风格。” >“
回答“大型初始化列表的缺点是什么?(与大型构造函数体相比)”可能是“ none ”,因为初始化最好在列表中完成,不是在体内,而是可读性和维护成本相同(对我来说)。
答案 3 :(得分:-1)
有些优化会失败,我怀疑内联这样的构造函数是行不通的。
无论哪种方式:45个数据成员听起来很多。你可以将它们分组为聚合对象吗?