通过

C# : Property vs. field

  • 项目

Recently there was an email-thread in the internal C# group on the usage of property vs. field.

 

The question raised was in case a class implements properties, is it still ok to go ahead and access the field directly from other methods of the same class. The thread also covered when it is ok to add properties.

This is a decision we take everyday when writing code. Some great people pitched in to give there opinion. The outcome is something like this

  1. In case you are designing a class library and the consumer is not under your control then add properties for all public fields to prepare for future needs to add checks to field access
  2. In case you can version (change) the client code as well, do not add properties just because its good, or because you think you might need functionality of checks, lazy loading in the future. In case you do not need these features right-away allow clients to directly use fields. With the new refactoring features of VS2005 changing all references to the field to properties is a non-issue.
  3. With the above two filtering you are sure that once you have a property its definitely going to do some additional work and so only use the property from everywhere (including methods from same class).

Comments

  • Anonymous
    September 21, 2005
    May I propose an aditional step?

    2a. In case there might be a scenario where V1.x DataBinding to your class makes sense, add properties as V1.x DataBinding does not work with fields on Custom Objects, only with properties (don't know yet how this is in V2)

    And what was the outcome on the question raised? Is it still ok to go ahead and access the field directly from other methods of the same class?

  • Anonymous
    September 21, 2005
    See the third point. Eliminate properties based on 1 and 2. In case there is a property use it from the ALL other methods

  • Anonymous
    September 22, 2005
    The comment has been removed

  • Anonymous
    September 22, 2005
    The comment has been removed

  • Anonymous
    September 22, 2005
    The comment has been removed

  • Anonymous
    October 04, 2005
    Here's my blog post about this issue:

    http://blogs.msdn.com/ericgu/archive/2005/09/19/471327.aspx

  • Anonymous
    November 23, 2005
    What about performance considerations? Are there any ? Is there significant performance benefits in using fields directly rather than calling the get / set functions ?

  • Anonymous
    November 23, 2005
    Since get.set functions will be inlined, I don't think there'd be any perf hit in using them. However, I didn't profile to see the diff

  • Anonymous
    February 13, 2007
    The comment has been removed

  • Anonymous
    December 04, 2007
    Yeah. The insistance on properties everywhere was nonsense. Properties are intended to agument fields by allowing side-effects. Consequently, they  are suppose to be interchangable. In fact, the distinction between fields and functions is also nonsense. Anyways, the limitation that properties have of not allowing direct a reference/pointer to it is an oversight that should have been corrected by now (delegates!); perhaps in C# v3.6.

  • Anonymous
    March 16, 2009
    Properties are not always inlined. The first time the property is invoked is like any other method and much more slower than fields. All the performances test using loops of several million of iterations that you can see all over Internet do not take in consideration that fact. On the other hand with properties you can not do this: Funtion(ref C.Property); or C.Property.x = value; Properties are usefull in some ways, but I am with George, the insistend¡ce to be used everywhere is nonsense.