インスタンス変数を取得および設定するプロパティがある場合、通常は常にそのクラスの外部からプロパティを使用してアクセスします。
私の質問は、クラス内でも常にそうする必要がありますか? クラス内であっても、プロパティがある場合は常にプロパティを使用してきましたが、どちらが最も正しいのか、またその理由について、賛否両論を聞きたいと思います。
それとも、プロジェクトで使用されているコーディング標準の問題ですか?
インスタンス変数を取得および設定するプロパティがある場合、通常は常にそのクラスの外部からプロパティを使用してアクセスします。
私の質問は、クラス内でも常にそうする必要がありますか? クラス内であっても、プロパティがある場合は常にプロパティを使用してきましたが、どちらが最も正しいのか、またその理由について、賛否両論を聞きたいと思います。
それとも、プロジェクトで使用されているコーディング標準の問題ですか?
プロパティを介してローカル (クラス スコープ) 変数にアクセスするための強力な議論の 1 つは、クラスに抽象化のレベルを追加することです。そのフィールドの保存方法に関するロジックを変更しても、コードの残りの部分は影響を受けません。
たとえば、ローカル変数から子オブジェクトのプロパティ、データベース呼び出し、Web サービス呼び出し、クラスの静的プロパティなどに変更できます。変更を行うと、単一の変更ポイントであるプロパティが提供されます。クラスの残りの部分はすべてプロパティを使用するため、更新する必要はありません。
また、プロパティを使用すると、フィールドに直接アクセスする場所ごとに同じルールを適用する代わりに、プロパティの値にビジネス ルールを適用できます。繰り返しますが、カプセル化
自動プロパティの導入により、get/set でビジネス ルールを適用する必要がない限り、明示的にローカル変数を使用する理由がさらに少なくなります。
プロパティ セッター内に実装されたロジックを適用するかどうかによって異なります。そのため、ケースバイケースで決定する必要があります。
private フィールドに直接アクセスすると、そのフィールドがまさにあなたの言うとおりに設定されていることがわかります。
プロパティを通過すると、setter ロジックに従って値が設定されるため、そのフィールドに割り当てられた値に対して必要なビジネス ルールまたは検証を取得できます。
どちらかを行うことが「正しい」場合についてのルールを考え出すのはかなり難しいですが、私が従うと言う唯一のルールは、コンストラクターの初期化ではプロパティをほとんど使用しないということです。
はい、可能な限り、クラスの内部でプロパティを使用する必要があると思います。プロパティはより柔軟で、中央の場所でその値を検証するためのロジックを追加できます。
また、コンストラクターで強制的に実行するのではなく、プロパティが使用されるたびに (またはフィールドが使用されるすべての場所で) フィールドの初期化を遅らせることもできます。例:
class Test {
private int _checksum = -1;
private int Checksum {
get {
if (_checksum == -1)
_checksum = calculateChecksum();
return checksum;
}
}
}
通常、プロジェクトのコーディング標準に応じて、プライベート クラス属性の名前の前に「_」または「m」を使用します。(以下のように)
private int mVariable;
private int _Variable;
変数の前にあるもので、クラスの内部変数を扱っていることがすぐにわかります。その後、後でデバッグするときに、コードが内部のプライベート変数を扱っていることをすぐに認識して、調整を行うことができます。したがって、それは私にとって読みやすさに帰着します。
常にプロパティを使用します。いくつかの理由があります
純粋に好みだと思います。
ただし、自動プロパティのサポートにより、C# 3.0 ではプロパティをより多く使用していることに気付きました。
class Foo {
public string Value { get; set; }
public void Write() {
Console.Write(Value);
}
}