C# Property vs. Method Guidelines
Since C# provides the ability for developers to write both methods and properties, it may be difficult to understand the difference or to know when to use one or the other. Sometimes the decision to use one over the other isn’t completely clear. Fortunately there are plenty of resources available to help out.
A simple Google search on the topic will yields many results, however Microsoft has some pretty straightforward guidelines on the topic. To quote the linked guidelines, “class library designers often must decide between implementing a class member as a property or a method. In general, methods represent actions and properties represent data…”
Here are the basic guidelines to follow:
- Use a property when the member is a logical data member
- 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.
One example of this is something I’ve pointed out already for the
IEnumerable.Count() method. In the article I mentioned that calling
Count() on an
IEnumerable is an expensive call. The fact that it’s a method here indicates this. This is expensive because calling the method causes an iteration over the whole object to actually determine the count. Until that operation occurs, the count is not just simply access to known data. Instead, on a
List<T> there’s a
Count property and on an array there’s a
Length property. In these cases, the count/length are already know, so the properties just indicate access to know data.
Got anything to say? Go ahead and leave a comment!
- Using the DataSource Field with Sitecore Sublayouts
- Tame Your Sitecore Treelists
- Write to a Custom Sitecore Log with log4net
- Sitecore Upgrade Strategy
- Rendering Fully Qualified Sitecore URLs
- Sitecore Admin Pages Explained
- Managing CSS in the Sitecore Media Library
- Use Any() Instead of Count() To See if an IEnumerable Has Any Objects
- Sitecore Front-End Development Best Practices
- Scaling Sitecore Presentation Component Data Sources
- Performance tuning your Sitecore installation | Agile and ALM: Software development today on A Going Live Checklist for Sitecore Websites
- Imran Saleem on Sitecore Avanced Database Crawler Occasionally Provides Null Results
- Ty Cahill on Sitecore Front-End Development Best Practices
- Sitecore Managed Sites as Virtual Folders | Fire Breaks Ice on Sitecore Item and Field Names
- Krimos on Using the DataSource Field with Sitecore Sublayouts
- Aboo Bolaky
- Alex Shyba
- Anders Dreyer
- Brian Pedersen
- Christopher Wojciech
- Coffee => Coder => Code
- Dev Sitecored²
- Everything Web
- Image0.com blog
- John West
- Learn Sitecore
- Let's do Sitecore
- Mark van Aalst
- Matthew Kenny
- Molten Core
- Project Lifecycle
- Sean Kearney
- Sebastian Patten
- Sitecore Australia
- Sitecore Blog
- Sitecore Climber
- Sitecore Development
- Sitecore Gadgets
- The Client View
- The Sitecore Experience
- Web Content Management and Delivery