プロパティとメソッド
https://stackoverflow.com/questions/601621
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
簡単な質問:(C# で) プロパティを使用することを決定するのはどのような場合ですか?また、メソッドを使用することを決定するのはどのような場合ですか?
私たちはこの議論に忙しいのですが、プロパティを使用すべきかメソッドを使用すべきかについて議論の余地がある領域がいくつか見つかりました。一例は次のとおりです。
public void SetLabel(string text)
{
Label.Text = text;
}
例では、 Label は ASPX ページ上のコントロールです。(この場合) これをメソッドにするかプロパティにするかを決定する原則はありますか。
最も一般的かつ包括的な回答を受け入れますが、これは私が挙げた例にも触れています。
解決
から プロパティとメソッドの選択 クラス ライブラリ開発のための設計ガイドラインのセクション:
一般に、メソッドはアクションを表し、プロパティはデータを表します。プロパティはフィールドと同様に使用することを目的としています。つまり、プロパティは計算が複雑であったり、副作用が発生したりするべきではありません。次のガイドラインに違反しない場合は、経験の浅い開発者にとってプロパティの方が使いやすいため、メソッドではなくプロパティの使用を検討してください。
他のヒント
はい、あなたがしているのが取得と設定だけであれば、プロパティを使用してください。
複数のデータメンバーに影響を与える可能性のある複雑なことをしている場合、メソッドがより適切です。または、ゲッターがパラメーターを取る場合、またはセッターが値パラメーター以上を受け取る場合。
中央には灰色の領域があり、線が少しぼやけている場合があります。厳格なルールはありません。また、プロパティまたはメソッドのどちらであるかについて、異なる人々が同意しない場合があります。重要なことは、（比較的）あなたのやり方（またはあなたのチームのやり方）と一致することです。
これらはほとんど交換可能ですが、プロパティは、実装が比較的「単純」であることをユーザーに通知します。ああ、構文は少しすっきりしています。
一般的に言って、私の哲学は、getまたはsetで始まり、0または1つのパラメーターを取る（それぞれ）メソッド名を書き始めると、それがプロパティの主要な候補になるということです。
オブジェクトの実際のプロパティを設定する場合は、プロパティを使用します。
タスク/機能を実行している場合は、メソッドを使用します。
例では、設定されている明確なプロパティです。
ただし、機能がAppendToLabelである場合は、メソッドを使用します。
プロパティは、オブジェクトにデータを注入または取得する方法です。クラス内の変数またはデータの抽象化を作成します。これらは、Javaのゲッターおよびセッターに類似しています。
メソッドは操作をカプセル化します。
一般に、プロパティを使用して単一ビットのデータ、または消費税などのクラスの小さな計算を公開します。これは、アイテムの数とショッピングカート内のコストから導き出されます。
操作を作成するときは、データベースからデータを取得するなどのメソッドを使用します。可動部分がある操作は、メソッドの候補です。
あなたのコード例では、クラスを含む外部でアクセスする必要がある場合、プロパティでラップします：
public Label Title
{
get{ return titleLabel;}
set{ titleLabel = value;}
}
テキストの設定：
Title.Text = "Properties vs Methods";
ラベルのTextプロパティのみを設定していた場合、次のようにします。
public string Title
{
get{ return titleLabel.Text;}
set{ titleLabel.Text = value;}
}
テキストの設定：
Title = "Properties vs Methods";
MSDNを検索すると、で参照が見つかりました。プロパティとメソッド：メソッドを作成するための優れたガイドラインを提供します：
- 操作は、
Object.ToStringなどの変換です。- 操作は十分に高価なので、通信したい キャッシュを検討する必要があるユーザー 結果。
- getアクセサーを使用してプロパティ値を取得すると、observableがあります 副作用。
- メンバーを連続して2回呼び出すと、異なる結果が生成されます。
- 実行の順序は重要です。型のプロパティは で設定および取得できる 注文。
- メンバーは静的ですが、変更可能な値を返します。
- メンバーは配列を返します。配列を返すプロパティは 非常に誤解を招く。通常は のコピーを返すために必要 ユーザーができないように内部配列 内部状態を変更します。これ、結合 ユーザーが簡単にできるという事実 インデックス付きプロパティであると仮定し、 効率の悪いコードになります。
プロパティは、オブジェクトの属性です。 メソッドはオブジェクトの動作です。
ラベルは属性であり、プロパティにする方が理にかなっています。
オブジェクト指向プログラミングに関しては、何が動作の一部であり、何が単なる属性であるかを明確に理解する必要があります。
車{色、モデル、ブランド}
車には色、モデル、ブランドの属性があるため、SetColorまたはSetModelメソッドを使用することは意味がありません。これは、Carに独自の色を設定するよう指示しないためです。
プロパティ/メソッドのケースを実際のオブジェクトにマッピングしたり、シンボリックな視点から見たりすると、混乱は本当になくなります。
名前だけを見る必要があります...＆quot; Property＆quot;。どういう意味ですか？辞書では多くの方法で定義されていますが、この場合は「本質的または特徴的な属性または物の品質」です。最適です。
アクションの目的について考えてください。実際、「本質的または独特の属性」を変更または取得していますか？この例では、関数を使用してテキストボックスのプロパティを設定しています。それはちょっとばかげているように思えますが、そうではありませんか？
プロパティは実際には関数です。これらはすべてgetXXX（）およびsetXXX（）にコンパイルされます。構文上の砂糖でそれらを隠すだけですが、プロセスに意味的な意味を提供するのは砂糖です。
属性などのプロパティについて考えます。車には多くの属性があります。色、MPG、モデルなど。すべてのプロパティが設定可能というわけではなく、一部は計算可能です。
一方、メソッドはアクションです。 GetColorはプロパティでなければなりません。 GetFile（）は関数でなければなりません。もう1つの経験則は、オブジェクトの状態を変更しない場合、関数でなければなりません。たとえば、CalculatePiToNthDigit（n）は関数である必要があります。これは、実際にアタッチされているMathオブジェクトの状態を変更しないためです。
これは少しひどい話かもしれませんが、実際には、オブジェクトが何であり、何を表すかを決定することになります。プロパティまたは関数のどちらであるかがわからない場合は、おそらくどちらでもかまいません。
1 パラメーターを指定した追加/設定メソッドのプロパティを使用することを好みます。パラメータがそれ以上の場合は、メソッドを使用します。
プロパティは単純なセットで、1つのライナーを取得する必要があります。それ以上は、メソッドに移動する必要があります。複雑なコードは常にメソッドに含める必要があります。
変数アクセス、つまり個々の変数の取得と設定、またはコントロール内のデータの取得と設定にのみプロパティを使用します。あらゆる種類のデータ操作が必要/実行されるとすぐに、メソッドを使用します。
プロパティの大きな利点は、デバッグ中にプロパティの値をVisual Studioで表示できることです。
プロパティは、Visual Studioのビジュアルデザイナでアクセスできるので、アクセスできれば本当に素晴らしいです。
使用するのは、単に設定して取得しているだけで、おそらくかなりの量のコードにアクセスしないいくつかの検証です。検証中に複雑なオブジェクトを作成するのは簡単ではないため注意してください。
他のすべてのメソッドが推奨される方法です。
セマンティクスだけではありません。不適切なプロパティの使用は、Visual Studioのビジュアルデザイナーで発生します。
たとえば、クラスのプロパティ内で設定値を取得していました。構成クラスは実際にファイルを開き、SQLクエリを実行してその構成の値を取得します。これにより、設定値の読み取りだけでなく（setterメソッドを介して）書き込みが行われるため、アプリケーションではなくVisual Studio自体によって構成ファイルが開かれ、ロックされるというアプリケーションで問題が発生しました。これを修正するには、メソッドに変更する必要がありました。
設計の問題として、プロパティはクラスオブジェクトのデータまたは属性を表しますが、メソッドはクラスオブジェクトのアクションまたは動作です。
.Netの世界では、プロパティの使用には他の意味があります：
- プロパティはデータバインディングで使用されますが、get_ / set_メソッドは使用されません。
- 自然なセリレーションのメカニズムとしてのXMLシリアル化ユーザープロパティ。
- プロパティには、 PropertyGrid コントロールとインターン ICustomTypeDescriptor 。カスタムライブラリを作成している場合に効果的に使用できます。
- プロパティは 属性 <によって制御されます/ a>、アスペクト指向ソフトウェアを設計するために賢く使用できます。
プロパティの使用に関する誤解（IMHO）：
- 小さな計算を公開するために使用： ControlDesigner.SelectionRules のgetブロックは72行になります!!
- 内部データ構造を公開するために使用：プロパティが内部データメンバーにマップされない場合でも、クラスの属性であれば、プロパティとして使用できます。 Viceversaは、クラスプロパティの属性が推奨されない場合でも、データメンバーのような配列を返します（代わりに、メソッドを使用してメンバーのディープコピーを返します）。
ここでの例では、ビジネス上の意味がより大きくなるように記述できます。
public String Title
{
set { Label.Text = text; }
}
- これらがすべて当てはまる場合、プロパティを使用します。 ゲッターは単純である必要があり、したがって例外をスローする可能性は低いです。これは、ネットワーク（またはデータベース）アクセスがないことを意味することに注意してください。どちらも失敗する可能性があるため、例外がスローされます。
- これらは互いに依存関係にあるべきではありません。これには、あるプロパティを設定し、それを別のプロパティに影響させることに注意してください。 （たとえば、FirstNameプロパティを設定すると、名前と姓のプロパティを構成する読み取り専用のFullNameプロパティに影響します。そのような依存関係を意味します）
- これらは任意の順序で設定可能である必要があります
- ゲッターには目に見える副作用はありません。このガイドラインは、プロパティでの遅延評価のいくつかの形式を排除しないことに注意してください。
- メソッドは常にすぐに返される必要があります。 （これにより、データベースアクセス呼び出し、Webサービス呼び出し、または他の同様の操作を行うプロパティが除外されることに注意してください。）
- メンバーが配列を返す場合、メソッドを使用します。
- ゲッターの繰り返し呼び出し（コードを介在させない）は、同じ値を返す必要があります。
-
セッターへの呼び出しを（同じ値で）繰り返しても、単一の呼び出しと違いはありません。
-
getは、内部データ構造への参照を返しません（項目23を参照）。メソッドはディープコピーを返すことができ、この問題を回避できます。
*重複する質問に対する回答から取得。
これは簡単です。
1：フィールドに保存する前にデータを検証する必要がある場合にプロパティを使用します。このように、プロパティはフィールドのカプセル化を提供します。フィールドをパブリックのままにする場合、エンドユーザーは、年齢が18歳を超えるなど、ビジネス要件に応じて有効または無効な値を割り当てることがあるため、値が対応するフィールドを格納する前に、その有効性を確認する必要があります。このようにして、プロパティはデータを表します。
2：データをパラメーターとして提供し、メソッドが提供された値に基づいて何らかの処理を行い、処理された値を出力として返すなど、何らかのアクションを実行する場合にメソッドを使用します。または、この計算によって一部のフィールドの値を変更したい場合。 ＆quot;このようにメソッドはアクションを表します＆quot;。
私はJavaから来て、しばらくget .. set ..メソッドを使用しました。
コードを書くとき、私は自分に尋ねません：「このデータへのアクセスは簡単ですか、それとも重いプロセスが必要ですか？」 物事は変化する可能性があるため（今日、このプロパティは簡単に取得できますが、明日には何らかのプロセスまたは重いプロセスが必要になる場合があります。）
今日、メソッドSetAge（int age）tomonrowがあります。また、生年月日を使用して年齢を計算するメソッドSetAge（date birthdate）もあります。
コンパイラがgetおよびsetのプロパティを変換することに非常に失望しましたが、Get ...およびSet ..メソッドを同じものとは見なしません。
