When to use get and set properties in C#

Question

我们什么时候应该在C＃中使用get和set属性？

Answer 1

Properties are probably what you're looking for if you decide you need get and set methods. For a decent discussion as to why you would, and why you wouldn't want to use properties check out Jon Skeet's Why Properties Matter .

One good reason for using properties as opposed to just exposing internal class data is obviously to protect that data. You can control access for individual attributes as well as validate data that is being set. You can also implement calculated properties to calculate values, this will appear no different than any other attribute to a user of your class.

Answer 2

According to the Property Usage Guidelines on MSDN:

• Use a property when the member is a logical data member. In the following member declarations, Name is a property because it is a logical member of the class.

• Use a method when:

  • The operation is a conversion, such as Object.ToString .
  • The operation is expensive enough that you want to communicate to the user that they should consider caching the result.
  • Obtaining a property value using the get accessor would have an observable side effect.
  • Calling the member twice in succession produces different results.
  • The order of execution is important. Note that a type's properties should be able to be set and retrieved in any order.
  • The member is static but returns a value that can be changed.
  • The member returns an array. Properties that return arrays can be very misleading. Usually it is necessary to return a copy of the internal array so that the user cannot change internal state. This, coupled with the fact that a user can easily assume it is an indexed property, leads to inefficient code. In the following code example, each call to the Methods property creates a copy of the array. As a result, 2n+1 copies of the array will be created in the following loop.

Answer 3

There are two separate (broadly speaking) reasons why you'd want to use properties instead of Get/Set methods:

1. You want the brevity of a field but wish to grant read-only access to the "outside", while readwrite-access to the "inside".
2. You want the brevity and connotation of a field, while secretly be able to enforce or manipulate things under the hood, such as:
   1. Requiring values within a certain range (during set).
   2. Automatically cleaning up or clamping certain values (during set).
   3. Updating (or deferring updating) other dependent data (during set).
   4. Avoiding a full calculation that would be necessary for the field, until the field is actually used (during get).
   5. Anything else that you otherwise would need to place within a method-proper but would prefer if the outside world still saw it as a field.