CODEWITHSUNDEEP
c#propertiesmethodsclass-design
Grace Note
Grace Note

Reputation: 3215

When is it better to use a method versus a property for a class definition?

Partially related to an earlier question of mine, I have a system in which I have to store complex data as a string. Instead of parsing these strings as all kinds of separate objects, I just created one class that contains all of those objects, and it has some parser logic that will encode all properties into strings, or decode a string to get those objects. That's all fine and good. This question is not about the parser itself, but about where I should house the logic for the parser. Is it a better choice to put it as a property, or as a method?

In the case of a property, say public string DataAsString, the get accessor would house the logic to encode all of the data into a string, while the set accessor would decode the input value and set all of the data in the class instance. It seems convenient because the input/output is indeed a string.

In the case of a method, one method would be Encode(), which returns the encoded string. Then, either the constructor itself would house the logic for the decoding a string and require the string argument, or I write a Decode(string str) method which is called separately. In either case, it would be using a method instead of a property.

So, is there a functional difference between these paths, in terms of the actual running of the code? Or are they basically equivalent and it then boils down to a choice of personal preference or which one looks better? And in that kind of question... which would look cleaner anyway?

Upvotes: 3

Views: 296

Answers (6)

supercat
supercat

Reputation: 81123

Another point not mentioned is that if one or more read-write properties on an object are written, and then all are read back without any intervening method calls, the values read should match the values written. If writing property Foo would cause the value of read-write property Bar to change, that in my mind would be a good sign that one or the other should be a pair of explicit getter-setter methods rather than a property. There are numerous classes in .net which violate this principle, but I regard such behavior as sloppy. Perhaps the worst offender is the Visible property of Control. Writing the property updates a field whose state cannot be read, while reading the property returns the result of some computations. A better design would have been to have a read-write Hidden property and a read-only Visible field. BTW, on a slightly-similar note, I would have made the "Length" property of a StringBuilder read-only, but had methods to truncate or pad it; the only read-write property I would have had would have been Value.

Upvotes: 1

kemiller2002
kemiller2002

Reputation: 115440

Technically, they can do the same thing. Generally, if there is complex processing involved, I put it in a method instead of a property. The main reason behind this (although I am not saying that people should assume this), is that there is a common perception that properties are supposed to allow quick access to data, where a method call has the expectation that it could take several cycles to complete. Should people assume this? Definitely not, but they do.

I like using methods to note to people interfacing with my code, "Hey this is a method, there is some processing going on, so don't assume that you are going to get an immediate result." You can't have asynchronous property access either. You can fire a method and be notified when the result returns.

Upvotes: 3

Adam Robinson
Adam Robinson

Reputation: 185613

There is no functional difference; properties are simply pairs of get and set methods from a behavior perspective.

However, properties are, in general, intended to be lightweight. If your property's getter or setter are performing substantial calculations, then moving them to a method is generally encouraged.

There are obvious exceptions to this (namely lazy loading in the ORM realm, where a get could trigger a database call).

Upvotes: 12

Ray
Ray

Reputation: 21905

If your class will be used in a data-binding situation, then you will need properties. Otherwise, I refer you to the other answers.

Upvotes: 2

Jennifer Zouak
Jennifer Zouak

Reputation: 1348

"Nouns": The convention is that properties do not do actual business logic nor do they have side-effects, i.e. change object state (other than Set a value).

"Verbs: Methods are expected to do work and have side effects.

Things like "convert" or "parse" or "encode" sound like verbs to me. I would use methods.

Upvotes: 8

Pieter Germishuys
Pieter Germishuys

Reputation: 4886

Personally, my properties are extremely dumb, only doing certain checks in extreme cases. i.e. check if the parameter is not null it's returning and if it is, new it up or throw an exception

Let's take for example a Person class Person.Name makes sense as a property in this case. Person.Speak() does not make sense as a property.

It all depends on what function it's performing.

Upvotes: 1

Related Questions