大きな初期化リストの欠点？

Question

私の雇用主は、より効率的であるため、コンストラクタで初期化リストを使用する方針です。

しかし、私は初期化を必要とする45体のデータメンバを持つクラスを開発しています。ポリシーに従って、コンストラクタの初期化リストでこれを行う必要があります。可読性以外

、何が大規模な初期化リストに不利だろうか？

Answer 1

読みやすさの問題があることがありませんので、あなたは、複数の物理ソース行を超えるメンバー初期化子リストの書式を設定することができます。

明らかに、45のデータメンバーを持つクラスがあるということです。このようなクラスでの作業を特に簡単にするものはありません。

---

AClass::AClass(type1 val1 
       , type2 val2 
       // ... 
       , type45 val45) 
: mem1(val1) 
, mem2(val2) 
// ... 
, mem45(val45) 
{ 
} 

私は読みにくく以上であると主張しない：私はそれはあなたのクラスは45人のデータメンバーを持っている理由を理解するためにバックステップを取る価値があるかもしれないと思う

AClass::AClass(type1 val1 
       , type2 val2 
       // ... 
       , type45 val45) 
{ 
    mem1 = val1; 
    mem2 = val2; 
    // ... 
    mem45 = val45; 
} 

Answer 2

。これは通常、あなたのクラスがあまりにも多くのことをしている兆候であり、時間が経つにつれてこのクラスを非常に維持することを非常に困難にする個別の責任が多すぎます。

あなたが個別の機能の部分にあなたのクラスを分割する必要があり、サブクラスに「コントローラのクラスのデリゲートを有していても良いようですね。これは、コードの複雑さを劇的に減らすことになります。

Answer 3

いくつかの最適化は失敗し、私はそのようなコンストラクタのインライン化が動作しないことを疑います。

いずれにしても、45人のデータメンバーが多く聞こえる。集約されたオブジェクトをグループ化できますか？

Answer 4

これはよく知られているアンチパターン神オブジェクトのように思えます。ウィキ引用：

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

、独自の初期化手順と小さい構造やオブジェクトに神のオブジェクトのグループメンバーにあなたのデザインを再考する方法を見つけてください。

そこで質問「何が大規模な初期化リストに不利だろうか？（小1との比較）」への答えは可能性があり、「これは、大規模なので、おそらくそれは悪いスタイルです。」

初期化のほうがボディではなくリスト内で行われるため、大きな初期化リスト（大規模なコンストラクタ本体と比較した場合のデメリット）は「なし」になる可能性があります。読みやすさとメンテナンスコストは同じです（私にとって）。