У моего работодателя принято использовать списки инициализации в конструкторе, потому что это более эффективно.
Однако я разрабатываю класс с 45 элементами данных, требующими инициализации. В соответствии с политикой это должно быть сделано в списке инициализации в конструкторе.
Помимо удобочитаемости, в чем недостаток большого списка инициализации?
Вы можете отформатировать список инициализаторов элементов по нескольким физическим строкам исходного кода, чтобы не возникало проблем с читабельностью.
Более серьезная проблема, очевидно, заключается в том, что у вас есть классы с 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;
}
Я думаю, что, возможно, стоит сделать шаг назад, чтобы понять, почему в вашем классе 45 элементов данных. Обычно это признак того, что ваш класс делает слишком много вещей и имеет слишком много отдельных обязанностей, из-за чего со временем этот класс будет очень сложно поддерживать.
Похоже, вам может понадобиться разбить свой класс на отдельные функциональные части и делегировать класс «контроллер» на подклассы. Это значительно уменьшит сложность вашего кода.
Похоже на хорошо известный антипаттерн God object. Цитата из вики:
Пожалуйста, найдите способ пересмотреть свой дизайн, чтобы сгруппировать элементы объекта бога в более мелкие структуры и объекты с их собственными процедурами инициализации.
Таким образом, ответом на вопрос "каковы недостатки большого списка инициализации? (по сравнению с маленьким списком)" может быть "Он большой, поэтому, возможно, это плохой стиль".
Ответом на вопрос "в чем недостаток большого списка инициализации? (по сравнению с большим телом конструктора)" может быть "нет", потому что инициализацию лучше выполнять в списке, а не в корпус, но читаемость и стоимость обслуживания те же (как по мне).
Некоторые оптимизации не пройдут, подозреваю, что инлайнинг такого конструктора не сработает.
В любом случае: 45 элементов данных звучат много. Можете ли вы сгруппировать их таким образом, агрегированные объекты?
