Questions and Answers on any aspect of .NET. Now closed.
This may be a dumb questions but why would expose something as a method instead of a property or vice versa?
If I have an Person class, I could have a Person GetMother() public method or a Mother property.
I'm probably over thinking this, but a lot of things I would make a method could be represented as a property? Pros/Cons?
You are right - anytime you are thinking of a method called GetXxx you should think "Property".
You should have a private Mother property, with Get and Set methods.
Thursday, January 25, 2007
The general rule is that it should be a property if access is relatively fast and the returned value/object represents some logical data contained by the class.
Mother would likely be better as a property because it's something you're probably not doing a large amount of calculation to return -- just returning a data item. It also makes sense as a property because it makes sense as logical data of a Person -- a Person has a Mother.
As an opposite example, HttpWebRequest returns the response using the method GetResponse rather than a property Response. This makes sense because GetResponse requires hitting a web server which would be orders of magnitude slower than returning a simple data member. It also makes sense because a Response isn't logically something that you'd consider as a Request's data but rather the result of a request.
> I'm probably over thinking this, but a lot of things I would make a method could be represented as a property? Pros/Cons?
Mother can be a property (or getMother can be a method).
A method and a property are the same thing under the hood, aren't they? Or very nearly the same thing (a property is easier to see in the debugger, is accessed via a different Reflection API, is slightly less typing to define and use, ...).
Any method like "X getFoo()" or "void setFoo(X x)" can be an "X Foo" property instead ...
... provided that it doesn't require any extra parameters: if it needs extra parameters then it can't be a property and must be a method, e.g. a BankAccount's "void setBalance(decimal amount)" method could be a "decimal Balance" property instead, but "decimal calculateReturn(decimal principal, float interestRate, int years)" can't be a property and must be a method because it has so many parameters (except that an "indexer" in C# is a kind of property which can take one extra parameter).
Pretty much anything that can be a function can also be a property. Using a function instead of a property signifies that there's more involved than just retrieving a value from memory.
If you're hitting the database, you should use a function. That's why you would use a GetWhatever function instead of a Whatever property. Contrived example: Say we have an employee class which can retrieve the employee's role from the database. If we have a property do this, we might see code like this:
Dim e As New Employee(2834)
If e.Role = SomeRole OrElse e.Role = SomeOtherRole Then
Now we're potentially hitting the database _twice_ in that line. Instead, we create a GetRole function. This implicitly communicates that the return value should be cached:
Dim e As New Employee(2834)
Dim role As Int32 = e.GetRole
If role = SomeRole OrElse role = SomeOtherRole Then
> you can serialize a property on the wire -- you cant take a method with you on that same trip :)
Good point, jonathan.
This is not true in all sutuations: compare binary vs. XML serialization, but this can be taken as a guiding rule as to if to use properties or methods.
Friday, January 26, 2007
Yeah actually there is an excellent and closed (ie: full circle) discussion of this topic in the CLR via C# book (by Richter) -- this is by far the most complete and fascinating read on .NET i've seen so far. He discusses props in there and explains why he doesnt like em :)
Personally I use em a lot but hardly ever than as accessor/mutators. ie: if there's anything besides get/set in there i method it out.
It's actually just a convenience apparently it make zilch difference to the CLR if i remember correctly. Either way a method is generated in the IL.
Saturday, January 27, 2007
It's true that a method is generated either way (internally Properties generate get_X/set_X methods and you must use those methods to attach Delegates to them).
However, saying they are just syntactic sugar is as inaccurate as saying that JavaBeans are just syntactic sugar. Just like Java containers understand the JavaBean specification and can utilize it, the .NET framework understands Properties as a spec and can leverage them under the covers (e.g. serialization, control attributes)
The value in Properties is their standardization within the framework, not the convenience
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz