ListBoxとかに流し込むとき、DisplayMemberに設定するのはフィールドじゃダメだった気がします。ゆー感じで、内部でリフレクションを使っているときにはプロパティだけOKっていうのが結構あったように思えます。これも一つの利点になると思います。プロパティの場合は、外部からはReadOnlyですが、内部からは書き換え可能ですよね。コンストラクタまで値を変更でき以後は値の変更が一切不可能。いう条件付きの読み取り専用。いう概念は存在しないでしたね。ListBoxとかに流し込むとき、DisplayMemberに設定するのはフィールドじゃダメだった気がします。プロパティだけOKっていうのが結構あったように思えます。あ、重要なのを忘れていました。(^^;それもどっかのスレで取り上げられていましたね。16:55:01)>>プロパティのReadOnlyとフィールドのReadOnlyは異なるので、>>これも一つの利点になると思います。>>プロパティの場合は、外部からはReadOnlyですが、内部からは書き換え可能ですよね。Setがなければ内部からも書き換えできませんよ。んぬねっとさんにフォロー頂いている通りです。内部からは直接フィールドを変更できるので書き換えることが可能、という意味です。>>これも一つの利点になると思います。>>プロパティの場合は、外部からはReadOnlyですが、内部からは書き換え可能ですよね。>>>>?>>Setがなければ内部からも書き換えできませんよ。んぬねっとさんにフォロー頂いている通りです。内部からは直接フィールドを変更できるので書き換えることが可能、という意味です。それは対応するフィールドを書き換えてるのであってプロパティを書き換えてるわけではないですよね。対応するフィールドを持たないプロパティもあるわけですし。さんは、フィールドとの対比という意味で書かれているのでしょう。さんは、フィールドとの対比という意味で書かれているのでしょう。最初の引き合いで書いてしまっていますから...いいえ。別にじゃんぬさんがいけないわけではないです。私がわかっているということも理解してくれてると思います。質問者・閲覧者が混乱する可能性があるかと思っただけです。21:08:32)たくさんの回答ありがとうございます。フィールドへの直接アクセスでなく、プロパティを経由する理由はエラーチェックなど、何らかの処理を経由できるから、ということですね。Propertyとする理由がいまいちよくわかりません。回答では、プロパティしか受け付けない処理(内部でリフレクション?)があるから、とありますがそういう処理にメソッドの返り値を渡すことはできないのでしょうか?よろしくお願いします。する理由がいまいちよくわかりません。理由はいろいろですデザイン上のものと他との兼ね合いと、その2者が大きな決定理由になります。値をGetしたときオブジェクトの状態が変わらないよう作ります。Getしたオブジェクトは取得元のオブジェクトと関連付けされてる場合があります。(ListBox.Itemsなど。)メソッドはそうとは限りません。GetXXXというメソッドの返り血は取得元のオブジェクトと関連付けされていないオブジェクトの場合が殆どです。他からプロパティであることを要請される場合はもちろんプロパティになります。いう処理にメソッドの返り値を渡すことはできないのでしょうか?例えば。ListBoxのDataSourceにコレクションや配列を指定した場合、コレクションの要素のプロパティ名をDisplayMemberに指定するとそのプロパティを使ってくれます。メソッドの返り血を表示したい場合、いくつかインターフェースを実装したりしないといけないので、めんどくさいです。00:27:33)C++ではずっとメンバ関数で処理していたので、VBの学習の際に疑問に思っていましたがプロパティを使用するメリットを理解できました。解決しました、解答ありがとうございました。