プロパティのデザイン
更新 : 2007 年 11 月
一般的に、メソッドは操作を表し、プロパティはデータを表します。プロパティはフィールドと同じように使用されるため、計算上複雑にしたり、副作用が生じたりしないようにする必要があります。プロパティのデザインの詳細については、「インデックス付きプロパティのデザイン」および「プロパティ変更通知イベント」を参照してください。
プロパティを適切にデザインするために役立つガイドラインを以下に示します。
呼び出し元がプロパティの値を変更できない場合は、読み取り専用プロパティを作成してください。
プロパティの種類の変わりやすさは、エンド ユーザーが変更できる内容に影響します。たとえば、読み取り/書き込みコレクションを返す読み取り専用プロパティを定義した場合、エンド ユーザーは、別のコレクションをプロパティに割り当てることはできませんが、コレクションの要素は変更できます。
設定専用プロパティは提供しないでください。
プロパティの getter を提供できない場合は、代わりに同じ機能を実装するメソッドを使用します。このメソッドの名前は、Set から始め、その後にプロパティ名を続けます。たとえば、AppDomain は、CachePath という設定専用プロパティの代わりに SetCachePath というメソッドを持ちます。
プロパティの getter による例外のスローを回避してください。
プロパティの getter は、実行前の状態を必要としない単純な操作にする必要があります。プロパティの getter で例外がスローされる可能性がある場合は、プロパティをメソッドとしてデザインし直すことを検討してください。ただし、これはインデクサには当てはまりません。インデクサは、引数が無効な場合に例外をスローできます。
プロパティ Set アクセス操作子による例外のスローは有効であり、許容されます。
Portions Copyright 2005 Microsoft Corporation.All rights reserved.
Portions Copyright Addison-Wesley Corporation.All rights reserved.
デザイン ガイドラインの詳細については、2005 年に Addison-Wesley から出版されている Krzysztof Cwalina、Brad Abrams 共著の『Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries』を参照してください。