With one of mine coworkers often argue about "the right way" of writing 'Get' methods. My opinion is object GetSomeObject(). My colleague thinks it is better to be void GetSomeObject(object obj). I know the result is one and the same in both cases. I want to hear and other opinions. Ohhh i forgot to tell for what platform we are talking about - .NET Framework the language is C#.
- 9I'd love to hear your colleague's arguments as to why his way is better.Michael– Michael2010-09-30 07:17:19 +00:00Commented Sep 30, 2010 at 7:17
- Well i will try to make him to make account here and post (but i am not sure that he will).ikirachen– ikirachen2010-09-30 07:49:06 +00:00Commented Sep 30, 2010 at 7:49
Add a comment |
7 Answers
If it is a simple get then it should be a property
public object SomeObject { get { return _someObj; } } if it is computational then
object GetSomeObject() { ... } Is far more commonly expected. Besides the other would have to have either a ref or out passed in as the argument which is discouraged if the former can be achieved
4 Comments
Xander
"have to have either ref or out" not necessarily, objects are passed by reference by default. That statement really only applies if its a value object (int, char etc) rather than a reference object (if that makes sense)... But for readability sake its usually better to make it clearer what you are attempting to do by use of ref/out
Xander
However I agree with the use of properties unless there is some business logic then use the method you described.
aqwert
@Xander, Actually the pointer to the object is passed by value just like a value type. It is just the pointer that is copied and not the actual structure. If you want to change the callers instance to be a new one then you need ref or out (just like a value type). Because the instance is not copied then all you can do is change its state and with a method having a'Get' signature it is not expected for a method to do that, in otherwords having sideeffects.
Xander
.. that was what I was trying to say... but not as well articulated as your answer... Cheers
void GetSomeObject(object obj) won't actually 'get' anything. If you turned it into an out parameter you could assign a value to it, and it would technically work, buy why when you can use return types exactly as they were intended:
public void GetSomeObject(out returnObject) { returnObject = ... } or
public object GetSomeObject() { return ... } 
1 Comment
Xander
if the returnObject is an actual object and you make changes to it as it is passed by reference by default you will see the reflected changes... However i still think using properties is the best way unless you are performing some business logic, in which case "object GetSomeObject() { ... }"
Of course object GetSomeObject() is better. The other one is more a setter than a getter...
Comments
It reads easier and is good coding practice to return a value, over modifying a reference parameter (which to me at least, is an old-school way of getting values back)
If you're looking for a deeper meaning:
Function parameters in C# are created as Value parameters by default (as apposed to reference parameters).
To change the parameter value and persist that change to the calling code, the parameter needs to be declared reference. You probably know all this.
Here's the difference: Both value and ref parameters are stored on the stack (which is highly efficient), but the reference parameter's data is stored on the heap. So there is a fraction overhead using reference values.
In most cases this is not a problem at all, but some issues might pop up, like:
- recursive functions that use up too much stack (and you get a stack overflow)
- functions that require the speed, like calculating primes or fractals
There's probably more, and better examples, than what I gave, you get the idea though.
1 Comment
ikirachen
Yeah i got the idea, thank you for complete answer.I will use it next time ]:>
object getSomeObject(); is better.
2 Comments
pete the pagan-gerbil
Agreed - it's the most common way in the .NET framework itself, so makes most sense to follow the same pattern.
Winston Smith
That should be
GetSomeObject, according to the Framework Design Guidelines.Generally speaking the first way is more typical and better because object GetSomeObject() allows you to do the following: GetSomeObject().Foo(). And it's somewhat more intuitive.
However, bool GetSomeObject( out object obj ) can be useful as in the case of TryGetValue() in the Dictionary class.
Comments
I can pretty much only see a single reason for using void GetSomeObject(out object obj) instead of object GetSomeObject() and that is if you get rid of the void and instead do something like ErrorResult GetSomeObject(out object obj) (and the GetSomeObject-operation is hairy and error-prone) since you can then report status via the return value.
However, that would still be better handled via plain old Exceptions IMHO. Though I know that some coding standards say that exceptions shouldn't be used at all and in those cases you might want to do something like this.
Still, I'd say just go with a property or the object GetSomeObject() unless you have a really good reason not to.
