5

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

ただし、初期化が必要な 45 のデータ メンバーを持つクラスを開発しています。ポリシーに従って、これはコンストラクターの初期化リストで行う必要があります。

読みやすさ以外に、大きな初期化リストの欠点は何ですか?

4

4 に答える 4

8

クラスに45のデータメンバーがある理由を理解するために一歩下がる価値があると思います。これは通常、クラスが多くのことを行っていることを示しており、個別の責任が多すぎるため、このクラスを長期にわたって維持することが非常に困難になっています。

クラスを別々の機能部分に分割し、「コントローラー」クラスをサブクラスに委任する必要があるようです。これにより、コードの複雑さが大幅に軽減されます。

于 2012-02-09T18:42:57.993 に答える
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 に答える
3

よく知られているアンチパターンの神オブジェクトのようです。ウィキの引用:

オブジェクト指向プログラミングでは、神のオブジェクトは、あまりにも多くのことを知っているか、あまりにも多くのことを行うオブジェクトです。

神オブジェクトのメンバーをより小さな構造体と独自の初期化手順を持つオブジェクトにグループ化するように設計を再考する方法を見つけてください。

したがって、「(小さいものと比較して) 大きな初期化リストの欠点は何ですか?」という質問に対する答えは、「大きいので、スタイルが悪い可能性があります」となる可能性があります。

「大規模な初期化リストの欠点は何ですか? (大規模なコンストラクタ本体と比較して)」という質問に対する答えは、「none」である可能性があります。維持費は同じです（私と同じです）。

于 2012-02-09T18:59:29.200 に答える
-1

一部の最適化は失敗します。そのようなコンストラクターのインライン化は機能しないと思われます。

いずれにせよ：45のデータメンバーはたくさん聞こえます。それらをそのように集約されたオブジェクトにグループ化できますか？

于 2012-02-09T18:43:04.047 に答える