プライベートフィールドxプロパティのローカル使用に関するベストプラクティス
-
08-07-2019 - |
質問
クラス内にプライベートフィールドがあり、そのフィールドをパブリックプロパティに公開する場合、クラス内からどのフィールドを使用する必要がありますか?
以下は、私が見つけようとしているものの例です。 プライベートフィールド_Counterまたはプロパティカウンターを操作する必要がありますか?
公開クラステスト
Private _Counter As Integer
Public Property Counter() As Integer
Get
Return _Counter
End Get
Set(ByVal value As Integer)
_Counter = value
End Set
End Property
Private Sub Dosomething()
'What is the best practice?
'Direct access to private field or property?
'On SET
_Counter += 1
'OR
Me.Counter += 1
'On Get
Console.WriteLine(_Counter)
Console.WriteLine(Me.Counter)
End Sub
終了クラス
助けてくれてありがとう。 Edu
解決
私の意見では、パブリックアクセッサを内部で使用すると、カプセル化が過剰になり、コードが不鮮明になります。このようなアプローチでは、他の点では単純な操作がより複雑なロジックを含むアクセサーを呼び出すため、操作のコードを分析するのが難しくなります。
プログラミングの経験上、それが大いに役立つ状況はめったにありませんでした。代わりに、パブリックアクセサーと他の関数の両方で使用できる private アクセサーを作成してアクセスを抽象化するために、フィールドに直接アクセスすることを好みます。理由は、パブリックアクセサーに特別なロジックを追加する必要がある場合、内部アクセスのロジックが同じではない可能性があることです。
また、ほとんどの最新のIDE(Eclipseなど)では、プライベートフィールドへのすべての参照をすぐに確認でき、直接アクセスの代わりに関数を使用するようにコードをリファクタリングできます。
他のヒント
IMOでは、可能な限りプロパティアクセサーを使用する必要があります。これは、プロパティを持っているときに利用できる内部ロジックを心配する必要がないためです。
これが発生する良い例は、Linq DataContextのコードビハインドです。
これを確認してください...
[Column(Storage="_ReviewType", DbType="TinyInt NOT NULL")]
public byte ReviewType
{
get
{
return this._ReviewType;
}
set
{
if ((this._ReviewType != value))
{
this.OnReviewTypeChanging(value);
this.SendPropertyChanging();
this._ReviewType = value;
this.SendPropertyChanged("ReviewType");
this.OnReviewTypeChanged();
}
}
}
「セッター」のすべてのロジックに注意してください。
これが、フィールドIMOの代わりにプロパティを呼び出す練習に入ることが重要である理由です。
回答と提案をありがとう。
ここでのすべての提案と他の研究を検討した後、プライベートフィールドと評価者のこの状況では、個人的な選択の方が多いと思います。したがって、基本的に最も重要なことは、何を選択しても一貫性を保つことです。
それは言った;私の個人的なルールはこれに傾いています:
-
プライベートフィールドに直接アクセスします。
-
アクセサーにアクセスする場合は、キーワードMEを使用します。読みやすくするため
-
アクセサは、プライベートアクセスにも適用される重要なロジックロジックを実装する場合にのみ使用します。このように、アクセサーを使用しているのは、「他に何か」があるためだということがわかります
-
保護フィールドの使用は避けてください。派生クラスは常にアクセサを使用する必要があり、フィールドへの直接アクセスは絶対にしないでください。
ご意見をお聞かせください。
サイドノート:
この後、クラスレベルフィールドの新しいスコープが欠落していると思います。 “ Restricted”などのキーワードこのフィールドには、そのゲッター/セッターからのみアクセスできます。この方法では、常にプライベートフィールドに直接アクセスしますが、特定のフィールドがそのアクセサーによってのみアクセスできることを確認する必要がある場合は、プライベートを制限付きに変更します。 (" Restricted、RestrictedRead、RestrictedWrite"はどうですか?)
可能な限りプロパティを使用することを好みます。これにより、将来的には、プライベート変数を使用していたすべての場所を検索することなく、プロパティが返す/設定するものを変更できる柔軟性が得られます。
セッターで特定の操作を行っていないため、プライベートフィールドを使用します。
プロパティセッターを削除することもお勧めします。この方法では、指定されたメソッドDoSomething()によってカウンターの状態を強制的に設定することができます
状況に応じて、クラス上のフィールドの直接変更をプライベートにのみ許可するか、またはセマンティクスを変更に関連付ける何らかのメソッドを通じて許可することが望ましい場合があります。この方法では、特定の方法でのみ変更されたことを確認できるため、このクラスとその特定の値について簡単に推論できます。さらに、ある時点で、incrementingやintなどのアクションは、必要な追加の結果をもたらす可能性があり、その時点でメソッドを介してアクセスを公開する方が理にかなっています。
I 常にプロパティアクセサーを使用します。これは、将来ゲッターまたはセッターにロジックを追加しても安全であるためです。
フィールドに直接アクセスするだけでプロパティアクセサを呼び出すことによるパフォーマンスのオーバーヘッドが心配な場合は、しないでください。ほとんどのコンパイラはこの種のことをインライン化して、事実上同じパフォーマンスを提供します。少なくとも、フィールドに直接行くことで可能性があるために余分なナノ秒の時間が必要になることはほとんどありません。
プロパティアクセサに固執する方がよいのは、a)すべてのコードで非常に一貫性があり、メンテナンス性が向上し、b)ここで他の人から指摘された利点が得られるからです。
また、スコープの問題がない限り、通常は Me。
(または this。
)キーワードを追加しません(識別子を選択することで回避しようとしています)慎重に)。私の関数とサブルーチンはそれほど長くないため、ローカル(スタックベース)変数とクラスのメンバーのどちらで作業しているかわからないので、これで混乱することはありません。彼らが簡単に伝えるには長すぎたら、私はリファクタリングします。
オリジナルのポスターは正確です。
1)プライベートフィールドに直接アクセスします。
- リファクタリングが容易になります。
2)アクセサーにアクセスする場合は、キーワードMEを使用します。読みやすさを改善する
- 明示的にスコープをリストすることは、読者による思考を少なくする必要があります
3)アクセサーは、プライベートアクセスにも適用される重要なロジックロジックを実装する場合にのみ使用します。このように、アクセサーを使用しているのは、「他に何か」があるためです
- これがルール#1に違反する唯一の理由です。
4)保護フィールドの使用を避けます。派生クラスは常にアクセサーを使用する必要があり、フィールドに直接アクセスすることはありません。