12

OOD の単一責任の原則を尊重している場合でも、クラスが大きくなる場合があることに気付きました。メソッド内でメンバー変数に直接アクセスすると、グローバルな状態になっているように感じられ、現在のスコープに多くのものが存在する場合があります。現在動作しているメソッドを見るだけでは、現在のスコープでアクセス可能な個々の変数がどこから来たのかを判断することはできなくなりました。

最近友人と一緒に仕事をしていると、メンバー変数をパラメータとしてすべてのメソッドに渡すため、彼よりもはるかに冗長なコードを書いていることに気付きました。

これは悪い習慣ですか？

編集: 例:

class AddNumbers {
public:
    int a, b;
    // ...
    int addNumbers {
        // I could have called this without arguments like this:
        // return internalAlgorithmAddNumbers();
        // because the data needed to compute the result is in members.
        return internalAlgorithmAddNumbers(a,b);
    }

private:
    int internalAlgorithmAddNumbers(int sum1, int sum2) { return sum1+sum2; }
};
4

3 に答える 3

6

クラスにメンバー変数がある場合は、それらを使用します。パラメータを明示的に渡したい場合は、自由関数にしてください。メンバー変数を渡すと、コードが冗長になるだけでなく、人々の期待に反し、コードが理解しにくくなります。

クラスの全体的な目的は、暗黙的に渡された共有状態を持つ一連の関数を作成することです。これがやりたくない場合は、クラスを使用しないでください。

于 2012-08-04T17:35:39.537 に答える
3

はい、間違いなく悪い習慣です。私の観点からは、メンバー変数をメンバー関数に渡すことはまったく意味がありません。いくつかの欠点があります。

  1. コードの可読性を低下させる
  2. スタック上のパラメーターをコピーするためのパフォーマンスの観点からのコスト

最終的にメソッドを単純な関数に変換することは理にかなっているかもしれません。実際、パフォーマンスの観点からは、非メンバー関数への呼び出しは実際には高速です (このポインターを逆参照する必要はありません)。

編集：

あなたのコメントに答えてください。関数が明示的に渡されたいくつかのパラメーターのみを使用してそのジョブを実行でき、内部状態を必要としない場合、おそらくメンバー関数があると宣言する理由はありません。単純な C スタイルの関数呼び出しを使用して、パラメーターを渡します。

于 2012-08-04T17:38:25.197 に答える
2

私が最初に作成したものではないコードで大きなクラスを維持しなければならなかったので、問題を理解しています。C++ では、状態を変更しないメソッドを識別するのに役立つキーワード const があります。

void methodA() const;

これを使用すると、メソッドがオブジェクトの状態を変更する可能性があるかどうかを確認できるため、保守性が向上します。

この概念を持たない他の言語では、インスタンス変数の状態を参照渡しするか、変更を返すことによって変更するかを明確にすることを好みます。

this->mMemberVariable = this->someMethod();

それよりも

void someMethod()
{
   this->mMemberVariable = 1; // change object state but do so in non transparent way
}

これにより、コードの保守が容易になることが何年にもわたってわかってきました。

于 2014-10-12T15:20:23.373 に答える