>>>The age old questions. Should I use a property or a method? Is one faster than the other?
>>
>>Einar,
>>I just looked this up in book Framework Design Guidelines (ISBN-10:0-321-24675-6). This is focused more on resuable frameworks instead of general code, but I think a lot of the ideas still apply:
>>
>>Use a property, rather than a method, if the value of the property is stored in the process memory and the property would just provide access to the value. (I think we can all agree on this)
>>
>>Use a method, rather than a property, in the following situations:
>>-The operation is orders of magnitude slower than a field access would be.
>>-The operation is a conversion, such as Object.ToString method. (Note that DateTime.Now property does not adhere to this guideline, and should)
>>-The operation returns a different result each time it is called, even if the parameters don't change (like Guid.NewGuid).
>>-The operation has a significant and observable side effect.
>>-The operation returns a copy of an internal state.
>>-The operation returns an array.
>
>That is very close to what I found on the link I provided. I guess I better get that book :o)

Furthermore, let's say you have an Employee class. You want to create a property returning how many days they have been sick, but you need to return that dynamically from the database. Before this discussion I would have had a property that looked up the value in the database and returns the value. It appears that is the incorrect way of doing it, and I should make that a method instead. That would make it more apparent to the user of my class that it isn't a simple retrieval of an item in memory.

Interesting. I dig conceptual stuff like this.