3

stream.BeginRead 操作に提供される状態オブジェクトとしてプライベート クラスのインスタンスを使用しています。(このクラスは、メイン ストリームの読み書きクラス専用です。)

public class MainClass
{
    // ...

    private class ResponseState
    {
        public IResponse response;
        public Stream stream;
        public byte[] buffer = new byte[1024];
    }
}

クラスへのアクセスは、フィールドを介して直接行われます。この場合、状態を保持するためだけに使用される場合でも、プロパティを介してクラスへのアクセスを本当に提供する必要がありますか?

他の人が何をしているかを知りたい。

4

5 に答える 5

5

C# 言語では必須ではありませんが、保守性の理由から、フィールドを直接公開しないことをお勧めします。代わりにプロパティを使用することをお勧めします。

StyleCop SA1401 : FieldsMustBePrivateを参照してください。

TypeName - FieldsMustBePrivate
CheckId - SA1401
カテゴリ - 保守性ルール

原因

C# クラス内のフィールドに、private 以外のアクセス修飾子があります。

ルールの説明

クラス内のフィールドに非プライベート アクセスが与えられると、常にこの規則違反が発生します。保守性の理由から、クラスの外部にフィールドを公開するためのメカニズムとして常にプロパティを使用する必要があり、フィールドは常にプライベート アクセスで宣言する必要があります。これにより、クラスのインターフェイスを変更せずに、プロパティの内部実装を時間の経過とともに変更できます。

C# 構造体内にあるフィールドは、任意のアクセス レベルを持つことができます。

違反を修正する方法

この規則違反を修正するには、フィールドをプライベートにし、プロパティを追加してフィールドをクラス外に公開します。

クラスが含まれているクラスの純粋な状態である場合は、メンバーを使用するクラス内にメンバーを直接配置することを検討できます。あなたのクラスが単なる状態以上のものである場合 (そして私はそうだと思います)、通常の保守規則に従う必要があります。

于 2011-01-02T13:50:32.040 に答える
2

カプセル化は、クラス内だけでなくクラス外でも役立ちます。よく知られているインターフェイス (つまり、プロパティ) を介してメンバーへのすべてのアクセスをファネリングすることにより、呼び出しコードを変更することなく、後でそのアクセスに関するロジックを追加する柔軟性が得られます。

やり過ぎのように思えるかもしれませんが、正直なところ、自動的に実装されたプロパティを考えると、プロパティを宣言するのは非常に簡単なので、先に進んでそのプロパティを使用して最大限の柔軟性を得ることができます。

于 2011-01-02T13:51:08.530 に答える
1

私の組織では、クラスがプライベートまたは内部であり、それがエンティティ クラスである場合、パブリック フィールドを使用してアクセスしていました。

ただし、C# 3.0 以降では自動プロパティを使用するため、常にプロパティを使用してプライベート フィールドにアクセスします。

とにかく、効果は同じです。私たちの場合は、コードをより読みやすくすることでした。

于 2011-01-02T13:51:30.880 に答える
0

私はちょうど一、二週間前にこれについて読んだばかりです。2つのキャンプがあります。私の先生がそう言ったので、大多数はあなたが財産を包む必要があると言っています。彼らは、プロパティに追加のロジックを追加する方が簡単であるか、保守しやすいか、その他の弱い理由があると言っています。もう 1 つの陣営は、自分たちを「真の OO 連中」と呼ぶ傾向があり、プロパティをまったく使用していない場合は間違っています (もちろんいくつかの例外はあります)。私が知る限り、あなたのケースは例外です。実際、それについて考えると、彼らはおそらくあなたが間違っていると言うでしょう:) ただ勝つことはできません. とにかく、セッターとゲッターに追加のロジックが必要でない限り、それらを使用する場合はラッピングを気にしないでください。何もせずにプログラムを遅くする理由。（どうやら彼らはどれだけ遅いかを測定することもできます）.

多くの MVVM を実行し、それらを必要とする INotifyPropertyChanged を実装する必要があるため、フィールドよりもプロパティを使用する傾向があります。あなたの場合、それらをプロパティでラップすることを心配する必要はありません。無意味な脂肪になります。しかし、プロパティが必要なクラスにある場合は、それらをラップして、そのクラスで同様のものを保持します。

結局それらをラップせず、後で必要になった場合は、Resharper を使用している場合は、右クリックでリファクタリング -> フィールドをカプセル化してプロパティをラップします。

于 2011-01-02T14:29:52.457 に答える
0

ベスト プラクティスは、他の型からアクセスできるすべてのメンバーにプロパティを使用することです。C# 3.0 の自動プロパティにより、これが非常に簡単になります。

于 2011-01-02T13:52:40.707 に答える