13

I tend to assume that getters are little more than an access control wrapper around an otherwise fairly lightweight set of instructions to return a value (or set of values).

As a result, when I find myself writing longer and more CPU-hungry setters, I feel Perhaps this is not the smartest move. In calling a getter in my own code (in particular let's refer to C# where there is a syntactical difference between method vs. getter calls), then I make an implicit assumption that these are lightweight -- when in fact that may well not be the case.

What's the general consensus on this? Use of other people's libraries aside, do you write heavy getters? Or do you tend to treat heavier getters as "full methods"?

PS. Due to language differences, I expect there'll be quite a number of different thoughts on this...

Engineer
  • 8,529
  • 7
  • 65
  • 105
  • Caching is the biggest issue here, to my mind. If a getter is not intended to change object state, then is caching a viable option? This is where, to me, it becomes obvious that a getter is intended for atomic read operations. Also, syntactic sugar: I love eg. C#'s getters. But if the language cannot enforce the kind of usage quoted in Thomas's reply, then should it even try (take Java for instance)? Performance should then be simply noted in a method's documentation. The point is, it's all very subjective. P.S. Just to prevent a war, I'm a fan of both languages (and many others beside). – Engineer Nov 01 '10 at 12:03

7 Answers7

9

Property getters are intended to retrieve a value. So when developers call them, there is an expectation that the call will return (almost) immediately with a value. If that expectation cannot be met, it is better to use a method instead of a property.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
9

From MSDN:

Property Usage Guidelines

Use a method when:
[...]

  • The operation is expensive enough that you want to communicate to the user that they should consider caching the result.the result.

And also:

Choosing Between Properties and Methods

Do use a method, rather than a property, in the following situations.

  • The operation is orders of magnitude slower than a field set would be. If you are even considering providing an asynchronous version of an operation to avoid blocking the thread, it is very likely that the operation is too expensive to be a property. In particular, operations that access the network or the file system (other than once for initialization) should most likely be methods, not properties.
Community
  • 1
  • 1
Thomas Levesque
  • 286,951
  • 70
  • 623
  • 758
  • This covers it for C#, at least. I definitely agree about asynch calls not being getters in *any* language. Also the issue of caching is really what got me asking the question. – Engineer Nov 01 '10 at 11:45
6

True. Getters should either access a simple member, or should compute and cache a derived value and then return the cached value (subsequent gets without interleaved sets should merely return that value). If I have a function that is going to do a lot of computation, then I name it computeX, not getX.

Michael Aaron Safyan
  • 93,612
  • 16
  • 138
  • 200
  • Thanks, this to me was the most informative of the answers given. Your mention of caching, I think, is the winning point. – Engineer Oct 17 '11 at 17:40
2

All in all, very few of my methods are so expensive in terms of time that it would matter based on the guidelines as posted by Thomas. But the thing is that generally calls to a getter should not affect that state of the class. I have no problem writing a getter that actually runs a calculation when called though.

Kirk
  • 4,431
  • 1
  • 15
  • 8
  • +1, this is a view I was wondering if anybody would take. As I write real-time stuff like games and simulations, often for web where efficiency is a concern, my view is concerned with per-cycle efficiency. – Engineer Nov 01 '10 at 12:08
  • There are certainly times when one needs to be concerned with efficiency. (Though most people's programs really don't need to.) In those cases I would balance the the cost of calculating in advance or on demand. For most of my programs it is a wash since most of these are used in binding in either Silverlight or WPF. Then they get read once per time it changes. But for that matter, I use a getter versus a method because of binding issues. – Kirk Nov 03 '10 at 00:49
1

In general, I write short, efficient ones. But you might have complex ones -- you need to consider how the getter will be used. And if it is an external API, you don't have any control how it is used - so shoot for efficiency.

zekeyeehaw
  • 141
  • 1
  • 1
  • 4
1

I would agree with this. It is useful to have calculated properties for example for things like Age based on DateOfBirth. But I would avoid complex logic like having to go to a database just to calculate the value of an object's property. Use method in that case.

lahsrah
  • 9,013
  • 5
  • 37
  • 67
  • I would agree that a call to the database would not seem like a good thing for a getter to do. – Kirk Nov 03 '10 at 00:45
0

My opinion is that getter should be lightweight, but again as you say there is a broad definition of "lightweight", adding a logger is fine for tracing purpose, and probably some cache logic too and database/web service retrieval .. ouch. your getter is already considered heavy. Getter are syntaxic sugar like setters, I consider that method are more flexible because of the simplicity of using them asynchronously.

But there is no expectation set for your getter performance (maybe try to mention it in the cough documentation ), as it could be trying to retrieve fresh values from slow source. Others are certainly considering getter for simple objects, but as your object could be a proxy for your backend object, I really see not point too set performance expectations as it helps you makes the code more readable and more maintainable.

So my answer would be, "it depends", mainly on the level of abstraction of your object ( short logic for low level object as the value should probably be calculated on the setter level, long ones for hight level ).

dvhh
  • 4,724
  • 27
  • 33
  • 1
    Adding logging to a getter would cause me to wonder about code smell. Not to say that it would never happen, but I would have to think about it. – Kirk Nov 03 '10 at 00:53
  • If I was writing a proxy that might need to go get something, I would then probably return a reference object while an async call went to get the real data. Then again, I have a very strong preference towards async data calls anyway. I had to learn it for Silverlight and now just prefer it. – Kirk Nov 03 '10 at 00:59