15

It strikes me that Properties in C# should be use when trying to manipulate a field in the class. But when there's complex calculations or database involved, we should use a getter/setter.

Is this correct?

When do you use s/getter over properties?

Haoest
  • 13,610
  • 29
  • 89
  • 105
  • 1
    There's more on this here: http://stackoverflow.com/questions/2908415/what-getters-and-setters-should-and-shouldnt-do – Steven Sudit May 25 '10 at 21:28

9 Answers9

20

The .NET design guidelines provide some answers to this question in the Properties vs. Methods section.

Basically, properties have the same semantics as a field. You shouldn't let a property throw exceptions, properties shouldn't have side effects, order shouldn't matter, and properties should return relatively quickly. If any of those things could happen, it's better to use a method. The guidelines also recommend using methods for returning arrays.

When deciding whether to use a property or method, it helps if I think of it like a field. I think about the behavior of the property and ask myself, "If this were a field on the class, would I be surprised if it behaved the way it does?" Consider, for example, the TcpClient.GetStream method. It can throw several exceptions based on if the connection is made, and it's important that the TcpClient is configured before you try to get the stream. Because of this, it is a Get method rather than a property.

If you take a good look at the design guidelines, you'll see that it's usually not a matter of preference; there's good reasons to use methods instead of properties in certain cases.

OwenP
  • 24,950
  • 13
  • 65
  • 102
  • Bingo! You said it better than I could (and with references too!). I still think it's important to also consider our fellow developers since we all, at some point, might have to use someone else's bad code. Courtesy to future maintenance guys is such a rare quality, it seems! – Sean Hanley Sep 15 '08 at 23:19
2

If your language supports properties, just use properties.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
2

Use the properties. One interesting note from MS's framework design guidelines book is that if you have a property and need to add extra methods for more complex set/get, then you should eliminate the property and go with only get/set methods.

Torlack
  • 4,395
  • 1
  • 23
  • 24
1

This is all personal preference. When it gets compiled it turns out to be getter/setter functions either way.

I personally use properties when setting and retrieving member values without any side affects. If there are side affects to retrieving/saving the value, then I use a function.

Sam
  • 2,166
  • 2
  • 20
  • 28
1

I'd say always ask yourself which makes more sense. Methods tend to be understood as actions to perform and are usually worded as such — open(), flush(), parse(). Properties tend to be understood as fancier fields/variables — DisplayName, AutoSize, DataSource.

This tends to come up a lot with custom control development I've noticed. Since it has the potential of being used by many other people down the road who didn't write it and you might not be around to ask, best go with a design that makes logical sense and doesn't surprise your fellow developers.

Sean Hanley
  • 5,677
  • 7
  • 42
  • 53
1

I tend to use setters when a value is write-only or there are multiple values to be set at once (obviously). Also my instinct, like yours, is to use getters and setters as a signal that a process may be long-running, spawn threads, or do some other non-trivial work. Also, if a setter has non-obvious prerequisites in the class, I might use a getter or setter instead, since people rarely read documentation on properties, and properties are expected to be accessable at all times. But even in these circumstances I might use a property if it will potentially make the calling code read better.

Jeffrey L Whitledge
  • 58,241
  • 9
  • 71
  • 99
0

Microsoft's answer is good, but I'd add a few more rules for read-write properties (which Microsoft violates sometimes, btw, causing much confusion): (1) A property setter should generally not affect the observable properties of objects which are not considered to be part of the object whose property is being set; (2) Setting a property to one value and then another should leave any affected objects in the same (observable) state as simply setting it to the second value; (3) Setting a property to the value returned by its getter should have no observable effect; (4) Generally, setting a property should not cause any other read-write properties to change, though it may change other read-only properties (note that most violations of this rule would violate #2 and/or #3, but even when those rules would not be violated such designs still seem dubious). Making an object usable in the designer may require giving it some properties which don't follow these rules, but run-time changes which will not follow such semantics should be done by setter methods.

In many cases, it may be appropriate to have a read-only property and a separate "Set" method (that would be my preference, for example, for a control's "Parent" property). In other cases, it may be useful to have several related ReadOnly properties that are affected by one read/write property (e.g. it may be useful to have a read-only property that indicates whether a control and all its parents are visible, but such functionality should not be included in a read-write Visible property).

supercat
  • 77,689
  • 9
  • 166
  • 211
0

Forget the Getter and Setter methods. Just use Properties.

An interesting thing to mention is that Properties are ending up as Setter and/or Getter method(s) in the assembly. Setter and/or Getter become a Property just by a little bit of metadata. So in fact, properties = setter/getter methods.

JRoppert
  • 5,854
  • 5
  • 32
  • 37
0

Properties should be fast, as they have a certain promise of just being there. They are also mandatory for databinding.

And they should have no side-effects.

Thomas Eyde
  • 3,820
  • 2
  • 25
  • 32