I was just thinking about it and since .Net has introduced properties is there ever a situation where you would want to leave your code as a method that returns a value as opposed to a readonly property.
+2
A:
If it's a parameterless method, then it's worth considering migrating to a property, yes. If it's just returning a private member variable, then it should definitely be a property.
But in general, no, not every method that returns a value should be a property. Some methods instantiate objects and return them, and those should never be properties. Some methods return this allowing for a "Fluent" API. None of these should be properties.
Randolpho
2010-05-19 14:34:25
@Randolpho. Yes sorry, you are right, I meant parameterless.
uriDium
2010-05-19 14:36:30
@uriDium: Then maybe you should edit your question.
Gorpik
2010-05-19 14:41:33
@Gorpik. But that changes the question and makes Randolpho look like an idiot how can't read the question.
uriDium
2010-05-19 14:45:59
@uriDium: No, it does not, since you clarify the situation in your comment. Suddenly changing a question is bad; adding some information you forgot is good. It will help other people trying to give you an answer. And Randolpho can edit his answer to match your rephrasing, of course, though I think it would still apply (the parameterless part is important, so he may just stress it in his answer).
Gorpik
2010-05-19 14:55:50
A:
No. Methods that return something, and perform expensive operations should not be modified into a property for instance.
Methods that take parameters cannot be turned into a property.
Methods that return arrays should not be transformed into a property for instance. That is because in such cases , you should return a copy of the array in order to prohibit that someone modifies the array outside the class. When you use a property that returns a copy of an array, then programmers are more likely to write something like this:
foreach( var x in myClass.PropertyThatReturnsArray )
{
}
For every iteration, an new copy of the array will be created. Instead, if you have written this as a method, programmers will more likely write this:
var foo = myClass.GetTheArray();
foreach( var x in foo )
{
}
(This is a rule that has been enforced by fxcop : http://msdn.microsoft.com/en-us/library/0fss9skc(VS.80).aspx ).
It's a psychological thing. :)
Frederik Gheysels
2010-05-19 14:43:41
@Frederik. I would almost still suggest that it is a property. I have done that a couple of times but in the documentation I state that it is a copy of the collection. I am thinking of the collection class that .Net has, for example Dictionary, both keys and values are exposed as properties. Thanks for your comments.
uriDium
2010-05-19 14:45:22
@Frederik. You are wrong about this creating a new instance of your array for each pass of the `foreach` statement. The system creates a state machine and only retrieves the property value once.
Matthew Whited
2010-05-19 14:55:38
See my answer at http://stackoverflow.com/questions/2447559/c-does-function-get-called-for-each-iteration-of-a-foreach-loop/2447646#2447646 to see how the `foreach` works internally.
Matthew Whited
2010-05-19 14:58:51
Matthew: I never said that the foreach creates a copy of the array on each pass. I'm saying that a property that returns an array should return a copy of that array; in other words: the programmer should make sure that he returns a copy of the array, instead of the (internal) array itself. By doing so, you make sure that the array (the one that is held by the class internally) cannot be modified outside the class by someone else.See also FxCop rule CA1819.
Frederik Gheysels
2010-05-19 15:16:11
@uriDium: I'm not saying 'collections'. I'm specifically talking about arrays. That's not the same situation ...
Frederik Gheysels
2010-05-19 15:17:11
..."For every iteration, `an new copy of the array will be created`. Instead, if you have written this as a method, programmers will more likely write this:"...
Matthew Whited
2010-05-19 15:35:19
... selective quoting is an art ... read the paragraph above the sentence that you've quoted as well:'you should return a copy of the array in order to prohibit that someone modifies the array outside the class".The sentence that you've quoted implies that you've followed the 'rule' in the other paragraph.
Frederik Gheysels
2010-05-19 19:32:23
+10
A:
No. I'd recommend taking a look at Microsoft's Property Usage Guidlines:
Class library designers often must decide between implementing a class member as a property or a method. In general, methods represent actions and properties represent data. Use the following guidelines to help you choose between these options.
- Use a property when the member is a logical data member. In the following member declarations, Name is a property because it is a logical member of the class.
- Use a method when:
- The operation is a conversion, such as Object.ToString.
- The operation is expensive enough that you want to communicate to the user that they should consider caching the result.
- Obtaining a property value using the get accessor would have an observable side effect.
- Calling the member twice in succession produces different results.
- The order of execution is important. Note that a type's properties should be able to be set and retrieved in any order.
- The member is static but returns a value that can be changed.
- The member returns an array. Properties that return arrays can be very misleading. Usually it is necessary to return a copy of the internal array so that the user cannot change internal state. This, coupled with the fact that a user can easily assume it is an indexed property, leads to inefficient code. In the following code example, each call to the Methods property creates a copy of the array. As a result, 2n+1 copies of the array will be created in the following loop.
Nathan Ernst
2010-05-19 14:48:18
Nathan Ernst
2010-05-19 15:05:06