Properites vs. Methods…


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">It is an age old debate… we have
some href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp">fairly
good guidelines, but they certainly leave room for improvement. style="mso-spacerun: yes">  style="mso-spacerun: yes"> Today at a WinFX API review (for some
cool stuff that didn’t make it out in the PDC drop) we had the debate again…
 Today the APIs look
like: />


style="MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"> style="FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"> style="mso-spacerun: yes">       
public style="COLOR: navy">DateTime
GetDisconnectTime();


style="MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"> style="FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"> style="mso-spacerun: yes">       
public style="COLOR: navy">TimeSpan GetIdleTime();


style="MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"> style="FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"> style="mso-spacerun: yes">       
public style="COLOR: navy">DateTime GetLogonTime();


style="MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"> style="FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"> style="mso-spacerun: yes">       
public SessionStates
GetSessionStates();


style="MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"> style="FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"> style="mso-spacerun: yes">       
public style="COLOR: navy">WindowsIdentity
GetUserInformation();


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">My knee jerk is to make these
properties…


style="MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"> style="FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"> style="mso-spacerun: yes">       
public style="COLOR: navy">DateTime DisconnectTime {get;
}


style="MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"> style="FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"> style="mso-spacerun: yes">       
public style="COLOR: navy">TimeSpan IdleTime {get; }


style="MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"> style="FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"> style="mso-spacerun: yes">       
public style="COLOR: navy">DateTime LogonTime {get; }


style="MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"> style="FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"> style="mso-spacerun: yes">       
public SessionStates SessionStates {get;
}


style="MARGIN: 0in 0in 0pt; mso-layout-grid-align: none"> style="FONT-SIZE: 9pt; FONT-FAMILY: 'Courier New'"> style="mso-spacerun: yes">       
public style="COLOR: navy">WindowsIdentity UserInformation {get;
}


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> style="mso-spacerun: yes"> the problem… well, the calls
*could* be cross machine…. My worry is if they are cross machine making
these guys properties will lead people to write inefficient code (and therefore
bring down the wrath of Rico)…


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> href="http://pitofdespair.20m.com/">Pit of Despair:


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">void Button_Click (object sender,
EventArgs arg) {


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> style="mso-spacerun: yes">     label.Text =
s.UserInformation.Name;


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">}


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">//Problem: You get the nice little
“(Not Responding)” title until the network call completes


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> href="http://blogs.gotdotnet.com/BradA/PermaLink.aspx/b7a0cf5c-a283-4f95-a508-819102d2feae">Pit
of Success:


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">void Button_Click (object sender,
EventArgs arg) {


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> style="mso-spacerun: yes">     label.Text =
s.GetUserInformation().Name;


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">}


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">//Now, that looks like it is doing
something that could be expensive. style="mso-spacerun: yes"> A good code review might very well catch
the fact that this really needs to be done asynchronously. style="mso-spacerun: yes"> The API design leads the user in the
right direction.


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">So, my question for you… Based on
this very limited data I have given you, what should we do here? style="mso-spacerun: yes"> Go for properties and hope for the best,
or error on the safe side and use methods, something
else?

Comments (57)

  1. Ryan says:

    I agree that the Get() methods here don’t look right if you have such a thing as properties (I’m in Java land but I dabble with C#).

    However, having just the property name makes it look like a public member variable and people won’t know that it could be doing some computation under the hood. And over a network? Ouch, that leans me over to leaving them as Get…() methods. But I’m a cautious person. 🙂

    But what kind of precedent will you be setting by doing that? Is this the death of properties in new WinFX APIs just to always be on the "safe" side? Smart .NET programmers will know that properties *can* have tough work in them and should be asynchronous over a network but recent Java converts may Intellisense the property and have no clue. Definitely a tough call.

  2. Marius says:

    I would go with functions on this case. Another, somehow related, problem is with error handling. I have never ever seen error handling code for getting a propertie’s value. Mostly an assert…
    Ryan… have you seen any code in which properties are called async ??!!!!

  3. Ian Ringrose says:

    Could you get MSDEV to display a "$" sign next to any method or property that has a high cost? Put a tooltip on the "$" to explain the cost….

  4. Anonymous says:

    I’d say properties – with some addition to the documentation. After all if it’s cross-machine then the dev using it should know that. If the devs don’t know the architecture thet’re programming against then they’ll have problems anyway.
    Is that too callous of me?

  5. Jakub Skopal says:

    I’d personally agree with Martin Fowler’s opinion, that no interface should be taken as it is and made available via remoting without first testing for speed and granularity…
    Particularry, there’s Remoting Facade pattern…
    http://www.martinfowler.com/eaaCatalog/remoteFacade.html

  6. milbertus says:

    I also think that they should be properties, with a warning in the documentation that if this property is used over a network, that things might stop responding for a while.

  7. Methods.

    I prefer to type 5 more characters when using them than to be aware that the call is expensive, explain that to my programmers, document it, etc.

    If you use properties I guarantee you an MSDN article saying ‘How to write apps using this API’.

  8. There are a lot of answers to this one. First of all, properties are just eye-candy for the generated get_PropertyName, set_PropertyName. So in essence, this approach doesn’t deviate all that much from the Java approach (getters/setters).
    If you have a VB background and are used to "old-school" APIs (DAO, RDO, ADO, MSMQ, MTS/COM+ and ASP Object Model), properties are local and don’t do much more than input validation, value retrieval and storage(IMHO).

    The right answer here is "It depends". If you are sure that you are going cross machine for each call, I’d go for Jakub’s solution. Ofcourse, if you always need the latest info (on the other side), maybe the getters look better.

    Should the fact that an operation is expensive be expressed by using either properties or methods to denote fast vs. slow? Should the fact that an operation’s data is location dependant be expressed by using either properties or methods to denote local vs. remote?

  9. Rick Childress says:

    The whole reason Brad and Co. are doing these API reviews is so that the API makes _as much sense as possible_ at first glance. I typically think of methods as calls that do something (like getting some information over the network) and I think of properties as getting some information that is attached to my object (in memory, or close to it).

    As for the RT!M suggestions, many more people will scroll through the intellisense dropdown and say ‘hey, this looks like what I want’ and continue on their merry way than will read the docs.

    Methods +1

  10. David L says:

    And now for something completely different…

    I’d like to see more design guidelines on exception management, both generation and handling. The Design Guidelines cover some (not all) of the cases about generating exceptions but does not provide much help on design patterns for consumers of exceptions. Where should it be handled? What should be handled and what should not? When should exceptions be wrapped and rethrown? What about unhandled exception handlers? What about exception handling across process and machine boundaries (soap related, remoting, etc)? What about handling exceptions within finally blocks? At appdomain shutdown? When a ThreadAbort has been raised? Within a Dispose method? Within a finalizer? When dealing with COM and interop? etc etc.

    IMO, this is a very complex topic that has been inadequately handled. Brad, is there anything in the pipeline to address this topic?

  11. John Cavnar-Johnson says:

    I’ll be the contrarian here and say that both approaches are wrong because they are too granular. This API should expose a single method that returns a structure with all the elements relating to a single object (presumably some sort of user account). The caller gets a complete set of information back from the single call and then has property-like access to each of the members. This is especially appropriate for this object as it appears that these are essentially read-only properties, but I would argue even when you mix in some read/write properties the burden of doing an explicit "commit" operation (update values in the structure and then pass the structure back to the object) is worth it because encourages the appropriate mental model on the part of the client coder.

  12. Nicole Calinoiu says:

    You didn’t mention what part(s) of the API are under consideration wrt this issue, but your "well, the calls *could* be cross machine" comment suggests that you suspect that most usage will probably not cross machine boundaries. If this is the case, the API should be designed in such a way as to facilitate the more common local usage scenario. If designed this way, the question really becomes one of who should provide the remoting facade. I’m guessing that, in most cases, you’ll actually be needing it within Microsoft long before ISVs might even start asking for it and, as long as you need to write it, you might as well save the rest of us the trouble…

    The other side of the coin is communicating if/when remoting costs should be considered. I’m not sure I really like the suggestion of adding it to the intellisense information. Most developers spend relatively little time working on remoting scenarios, and the remoting cost flag would be an unnecessary distraction the rest of the time. It might also be quite confusing for junior coders.

    Personally, I would much rather that remoting concerns be included in the docs, but not in the main topic pages (again, relatively few developers spend most of their time working on remoting scenarios). Instead, a "remoting issues" associated topic, similar to the "Specifics" link in the old VB and VBA docs, might be more helpful. If sufficiently prominent, its mere presense would be an indicator that there are associated remoting issues to be considered or an existing remoting facade to be used.

  13. Brian Tyler says:

    I’ll throw out a completely different view – location transparency is often a very bad idea.

    It is a tough line to walk between making an API easy to use and remembering that developing good software requires effort. I think the goal should be that the developer should not need to worry about the details of the remoting, but that is very different from not realizing that it is happening in the first place.

    I can’t say for this specific example how this would apply because I don’t know what the object is where these methods are defined. But I would ask “what is the API call to get that object?”. That may be the real source of the answer.

  14. I also would favor Properties + Documentation. The performance information reminds me of the Thread Safety section in the FCL reference for each class. Certainly the potential gotcha’s for thread safety are as critical as performance issues. However you would never prefix your thread safe methods with ThreadSafe…

    You have docs in the overview page for each class principally because you have a rather consistent pattern of only having thread safe static methods. Performance, while just as important, is much more variable. Therefore an optional performance section for each method/property would be useful. It would even be nice to add it to XML Documentation. Sticking to properties avoids having to endlessly split hairs and reduces extensions to VB’s *My* classes 🙂

  15. Tone Engel says:

    A vote for methods.

    Properties should be reserved for side-effect free, efficient data retrieval. Anything else, do a little more typing and make and remind yourself that you deserve what you get for calling an API method without reading the documentation.

    Its wrong to say a property is just eye candy for a method. The tools won’t let you do the same thing with each. And the tools make their own assumptions about what they can do with them.

    One specific example: The Visual Studio debugger will call a properties getter many times a second if you have it expanded in a locals or autos pane. It will never call an objects methods.

    I think the Visual Studio developers got this just right. If it hasn’t already been formalized as part of the guidelines on properties vs. methods, it should be.

  16. I’d go with methods. I agree that that leads people down the right path of making async calls if it’s necessary. Making them properties implies (in my mind) that the data is local, and I would be confused by the fact that remoting was happening.

  17. Properties, please, assuming they are free of side-effects. Types should expose interfaces consistent with their most likely (local) usage. We’ll worry about the extraordinary cases, such as remoting (or you could provide a remoting facade). Using method signatures as remoting performance hints is really kind of gross.

    Thanks for shining light on this and giving us all a chance to speak up.

  18. Kevin Dente says:

    +1 for avoiding location transparency. I’m with Brian on this one.

  19. Mike Iles says:

    If there’s ANY CHANCE that the call could be cross-machine, then methods for sure. I agree with all the others that say that location-transparency can be a bad thing.

    Properties should ONLY be used for trivial data access.

    VS.NET will call properties many times per second during a debugging session and our developers at one point were having constant problems with VS.NET freezing during debugging because of non-trivial property evaluations (this is marginally better in VS.NET 2003 over VS.NET 2002, but still happens).

    Another consideration that I don’t think anyone has mentioned is that you can’t point a delegate at a property accessor, and so can’t invoke it asynchronously. I agree that this is a sensible language restriction — it would be absurd to invoke a trivial property asynchronously — but if the property can result in a remote method call then asynchronous invocation would be desirable and this becomes a very real issue.

  20. Keith Patrick says:

    I don’t think that just because something is cross-machine that it should be a method. Conceivably, just about any object could be used cross-machine, but that doesn’t mean properties should be taken out of the language. If it’s an issue of expense, then there is a very clear set of guidelines in the .Net Framework Reference ("Property Usage Guidelines|Properties vs. Methods"), although even I break this, as I don’t regard expense so much is whether or not something is logically a property or just a calculation:
    Use a method when "the operation is expensive enough that you want to communicate to the user that they should consider caching the result."

  21. Keith Patrick says:

    I don’t think that just because something is cross-machine that it should be a method. Conceivably, just about any object could be used cross-machine, but that doesn’t mean properties should be taken out of the language. If it’s an issue of expense, then there is a very clear set of guidelines in the .Net Framework Reference ("Property Usage Guidelines|Properties vs. Methods"), although even I break this, as I don’t regard expense so much is whether or not something is logically a property or just a calculation:
    Use a method when "the operation is expensive enough that you want to communicate to the user that they should consider caching the result."

  22. Keith J. Farmer says:

    foo = GetUser().PropertyName; // default = current?
    foo = GetUser(id).PropertyName;

    Cavnar-Johnson’s suggestion agrees with me. To minimize network cost, get as much related information as possible. You know the user’s going to ask for it — may as well provide it. It also preserves the integrity of the information as a group: you’re more likely to mix up someone’s LogonTime with someone else’s if you’re having to do the join manually.

  23. It definately depends on the API. If the user has to explicity make the object remote, then they should be aware that a property could be expensive.

    If it’s a simple static method on some class and can easily be mistaken for being cheap, the a method would be better.

  24. Phil McMillan says:

    I’ll throw in my $.02 and agree with Keith Framer and John Cavnar-Johnson. The method call returning a structure with the properties provides for caching, minimize’s the amortized cost of retrieving the data over the network. Also, since it looks like the API methods might be accessing the current user state or the state of a disconnected user – state that’s been persisted disk – it’s more appropriate to make a method call and get a user structure with the data as properties as opposed to individual calls to property accessors or methods.

  25. Ajay says:

    I would prefer methods. If its a property, I would assume that it would be returning value from a stored variable or something and not doing heavy computation/processing (not to mention doing something over the n/w). So having them as methods forces us to acknowledge that there is some kind of computation/processing involved and we better take that into account. My two cents 🙂

  26. Before I answer, I want to ask a question. If this wasn’t going to be an expensive operation would you be asking this question?

    Why should the speed of an operation determine whether you use a property or method? Some methods can be quick; some properties can be slow (eg lazy initialization).

    Personally, I don’t think whether it is a method or a property is going to stop developers from writing poor code. Developers have to take some control, and understand that performance is just another thing that they are going to take care of.

  27. Marco Nova says:

    I would use properties when the operation is pretty fast (like retrieving information from a cache) and functions when the operation is something more complicated that can involve lengthy operations.

    – mn

  28. Funny how I repeatedly see code like this:

    With properties:

    int someValue = myObject.Age;
    // Important Code
    int needThisAgain = myObject.Age;
    // Important Code
    int andAnotherTime = myObject.Age;

    With methods:

    int retrievedValue = myObject.ReadAge();
    int someValue = retrievedValue;
    // Important Code
    int needThisAgain = retrievedValue;
    // Important Code
    int andAnotherTime = retrievedValue;

    My point is that some developers are used to referring to properties throughout their code instead of caching the result in a local variable (often best practice). If there are methods it is more explicit that the there is work being done, and they instinctively cache the result in a variable if they need it multiple times.

    “Developers should read the docs on all the types they use”
    The problem is that a lot of them don’t read the docs when it is fairly obvious what the method/ property “could” do. Would you read the docs for UserInformation.Name, or would you just try and see if it provides the desired result?
    Overall there are way too many assumptions being made by programmers; either one can ignore that and call them irresponsible or one can try to meet them halfway 😉

    I’m just being practical!

  29. Frank Hileman says:

    I’ve come to expect potentially slow operations to be functions, and properties to be faster, usually a constant response time. Also I have coded libraries according to this guideline. So I’d hate to see it disappear. If an operation is potentially unbounded in time a property is not logical. It does not fit the mental model. Keep up the pit of success philosophy!

  30. Per Hammar says:

    Definitely use properties it’s a great invention and makes interfaces clearer and more user-friendly.
    Documentation should be used to make the user aware of the problem. So can FxCop
    Or other tool help user be made aware of the remoting penalty.
    I think we all be at a great loss if we lose properties.

  31. Joel Martinez says:

    I think I’ll have to agree with the pit of success camp. although I love the concept of properties, I’d be confused if a property accessor where taking a long time, or throwing some exception (my own personal pet peeve).

  32. Keith Patrick says:

    That’s a good rule of thumb that I also like to follow (properties should not throw exceptions), as properties are used as "smart fields" basically, and accessing fields does not generally throw exceptions.

  33. Frank Hileman says:

    I forgot the most important reason! No one has mentioned this. Properties must have a constant time response or they wreak havoc with the debugger! For this reason alone the guideline must be left as is.

    In fact, I think the guideline should be made stronger: it should specify that the time required to execute the property must be limited to a constant. Once this constant is reached, the time should not increase no mater how complex the object’s internal state.

    This would dissuade people from creating properties which must traverse large internal data structures to compute results. These types of properties cause debugging hell.

  34. Keith Patrick says:

    I agree with that with the exception of a light initialization. When I say a light one, I mean like instantiating a collection, though, not configuring child components or anything, since that could have a wildly variable time to completion.

  35. Frank Hileman says:

    Keith: I think you were responding to my post. Yes, any type of lazy initialization would be allowed — this does not invlove the traversal of a potentially large data structure. The point is that there is a constant, unspecified, maximum possible amount of time that a property can take to execute. It would be better to actually specify what that amount of time is, but I doubt everyone will ever agree to that. Sort of like the limits on thread switching overhead in a realtime system.

    Without this limit, debuggers and other types of property browsers are unusable. The same type of problem can occur when looking at a Component in the PropertyGrid in visual studio.

  36. Martin Liversage says:

    If this is a vote I’ll vote for methods. ;^)

    It is with good reason that Object.GetType() is a method and not a property.

  37. DrPizza says:

    Properties.

    (a) that’s what they’re there for
    (b) if a method does something apparently simple (which getters and setters do) I would wager that most people will expect them to be quick /anyway/.

    Further, are any of these calls going to be cross-machine /by accident/? I wouldn’t think so — they’ll surely only be remote calls because you’ve explicitly asked a remote machine for its information. It’s this that’ll lead one to believe that calls may be slow; not the existance of an extra verb and a pair of round brackets.

  38. Diego Vega says:

    Brad, I remember when Omri Gazitt got me converted to ADO.NET design philosophy. In http://discuss.develop.com/archives/wa.exe?A2=ind0009B&L=DOTNET&P=R53999&I=-3 he explained that the ADO Recordset design was bad because in some scenarios it isolated the programmer from the knowledge that he was doing expensive cross machine operations.

    The fact is that the changes introduced in ADO.NET had nothing to do with changing property syntax to function syntax. On the contrary they created a new object model in which the programmer had to explicitly program for the cross machine scenario. They also gave the programmer the dataset which allowed for saving networks round trips.

    In your example I sincerely see no point in the function syntax helping code review. I have done code review and I know those parenthesis are lost in 10 thousand lines. You really have to know what you are doing and go line by line, or use case by use case to find the not so great coding.

    In the end the get_ at the beginning and the parenthesis are just adding to code clutter, and they are no replacement for a good profiling tool that would put a red alert close to the expensive line.

    Please, let’s stick to properties and consistence in this case.

  39. Keith Patrick says:

    Is it necessarily a good thing to indicate that something could be expensive or could be cross-machine? We are moving towards a future where cross-machine method calls will be quite common and potentially transparent. Part of that will eventually be a negligible speed hit, so if the speed situation improves, why not design for an idealistic world (and I’m not talking about intentionally slowing down the platform with design changes, just making the interface to it uniform and performance-agnostic in appearance)? Cleanliness and consistency are more important to me in an API than structuring it to indicate when something may be expensive. If something is logically a property, then it should be a property. If something can take unpredictable amounts of time to execute on multiple calls, then it’s not logically a property, but if something is sitting on a machine 3000 miles away and it *does* represent something that is logically a prop, then I would expect it to be, regardless of geography. If it can be cross-machine (and seriously, just about anything can be made to be cross-machine), then put something in the remarks, but it really doesn’t require the API to be structured in a way to indicate it; if the API doesn’t expose something as major as an exception outside of the documentation, why should it then be changed merely to indicate potential speed hits?

  40. Brad Abrams says:

    Way up at the top David L asks about exceptions… We are actively looking into updating the guidelines… All of your questions are being considered. Not saying we will get good answers for them, but they are on the table.

  41. Vishal Kalra says:

    I would say that if the type exposing this information as a property allows you to explicitly set the remoting information then I as the type user will be aware that the call will be going across the network.

  42. Marco Russo says:

    Please remember another guidelines you have writing code for .NET Framework: use properties when you obtain the same result without touching the object (it’s ok if a member method call alters the object state); use methods in other cases (for example a GetID *MUST* be a method and not a property) and when it could have sense to cache the results (a properties should not be cached to significantly improve performance… if you are in this case… write a method).

  43. John Cavnar-Johnson says:

    [There is an error being thrown by the server on the comments page on your newer post. This comment really is in reply to that post.]

    The need for live data is exactly my point, not an argument against it. I wouldn’t consider my suggestion an argument for caching the properties locally. I’m trying to get you to consider the granularity at which the information makes sense. If I want to write code that makes use of the relationship between the values the object returns, then the values have to have a single common reference point. In the specific example you gave, most of the properties were time-related. Depending on the particular time scales involved, the time it takes to make the network calls could have a significant impact on the semantic meaning of the values returned. I want to be able to ask an object for its consistent state at a specific instant in time, particularly when the object may be remote. If you’ve ever dealt with satellite-based networks, you quickly realize the impact of latency on network communications.

    I would like to see API’s designed that encourage code correctness first, code security second, code performance third, and code elegance last.

  44. Keith Hill says:

    I’m with the "location transparency" is bad group and Cavnar-Johnson on minimizing network traffic by grabbing a logically related set of data via a single call that implies potential expense. For example:

    public UserInfo GetUserInfo(string hostname)

    Then use properties (UserInfo.IdleTime, etc) because at this point the data is local.

  45. Simon Harris says:

    Being bored, and dabbling in .Net, I started to read this thread because personally I’ve never understood the property accessors at all and I’m trying to get a feeling for when to use one over the other. I get the feeling that noone seems to know. In fact most people seem to suggest "only when there are no side effects". So what you’re really saying is I might as well have had the thing exposed as a public variable? If all the accessor does is simply return the variable, whats the difference between that and a get method? Maybe the property stuff should really have generated a GetX and SetX method instead of allowing it to be used as just plain X? Then the whole issue goes away and becomes syntactic sugar? Or am I really missing something here. Please enlighten me as I’m desperate for some rules of thumb. — Cheers Simon.

  46. Shripal Meghani says:

    I see a lot of advantages in using Properties:

    1) They cannot be overridden in derived classes, so assist in a clean design

    2) It allows clean seperation between the read from and write to a member

  47. Data-Binding to Web Service Proxies