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

Question

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?

Answer 1

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).

Answer 2

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.

Answer 3

"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.

Answer 4

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

Answer 5

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.