Why is it "methods against properties"? A method does something. A property is, well, a member of an object. They're totally different things, although two kinds of methods commonly written - getters and setters - correspond to properties. Since comparing properties with methods in general is not meaningful, I'll assume you meant to talk about getters/setters.
Getter and setter method pairs are a code smell.
Not necessarily, I'd argue, but either way this isn't a matter of getters/setters vs. properties but a matter of whether either should be used. Also note that you can e.g. leave out the setX
part just like you can make read-only properties.
What is important to a consumer of an object is what it does, not how it does it. Its behavior is what it does; its state is how it does it. If you find yourself caring about an object's state (except for persistence, though this also breaks OO), you're simply not doing OOP and losing out on its advantages.
A highly questionable attitude. If the GUI wants to output data held by a DataStuffManagerImpl
, it needs to get that number from it somehow (and no, cramming half of the application into the widget class is not an option).
As the property gets more and more complex, the performance indication of using a property seems less and less truthful.
[Methods have] No performance guarantees. The API will remain truthful even if the method gets more complex. The consumer will need to profile their code if they are running in to performance issues, and not rely on word-of-API.
In almost all cases, all the validation logic etc. is still effectively O(1), or otherwise negible in cost. If not, perhaps you've gone too far and it's time for a change. And a getX()
method is usually treated as cheap as well!
Sure, typing myObject.Length is easier than typing myObject.Length(), but couldn't that be fixed with a little syntactic sugar?
Properties are that syntactic sugar.
Less for the consumer to think about. Does this property have a setter? A method sure doesn't.
"Is there a setter for this getter?" Same difference.
The programmer of the API will think more deeply about methods with return values, and avoid modifying the object's state in such methods, if possible. Separation of commands from queries should be enforced wherever possible.
I'm not sure what you're trying to tell us here. For properties, there's an even stronger unwritten law not to cause side effects.
The C# team has considered that this would be a very useful feature, and that's why in C# 6, they implemented it (just a little different from your proposal).
Getter-only auto-properties
This new kind of properties are getter-only, but can be set either inline or in the constructor. This means they are backed internally by a readonly field.
Instead of declaring a property as readonly set
, you simply not declare it.
Inline assignment
public class Customer
{
public string First { get; } = "Jane";
public string Last { get; } = "Doe";
}
Constructor assignment
public class Customer
{
public string Name { get; }
public Customer(string first, string last)
{
Name = first + " " + last;
}
}
You can read about this and other new features of C# 6 in the Roslyn wiki in GitHub.
Best Answer
No. The idea of properties is that the property itself is public and provides access to private fields. Your example however does the opposit by declaring the property private while the field is exposed public.
What it should look like:
DO NOT: expose fields outside of the class
DO: provide appropriate methods/properties to access fields where needed
note that the setter of the property only allows to increase the age by one as suggested in the answer you referenced. A property without logic would again be subject to the answer you referenced because it exposes the field without any control those breaking encapsulation again.