|
2. Properties
Properties will be a familiar concept to Delphi and Visual Basic users. The motivation is for the language to formalize the concept of getter/setter methods, which is an extensively used pattern, particularly in RAD (Rapid Application Development) tools.
This is typical code you might write in Java or C++:
foo.setSize (getSize () + 1);
label.getFont().setBold (true);
The same code you would write like this in C#:
foo.size++;
label.font.bold = true;
The C# code is immediately more readable by those who are using foo and label. There is similar simplicity when implementing properties:
Java/C++:
public int getSize() {
return size;
}
public void setSize (int value) {
size = value;
}
C#:
public int Size {
get {return size;
}
set {size = value;
}
}
Particularly for read/write properties, C# provides a cleaner way of handling this concept. The relationship between a get and set method is inherent in C#, while has to be maintained in Java or C++. There are many benefits of this approach. It encourages programmers to think in terms of properties, and whether that property is most natural as read/write vs read only, or whether it really shouldn't be a property at all. If you wish to change the name of your property, you only have one place to look (I've seen getters and setter several hundred lines away from each other). Comments only have to be made once, and won't get out of sync with each other. It is feasible that an IDE could help out here (and in fact I suggest they do), but one should remember an essential principle in programming is to try to make abstractions which model our problem space well. A language which supports properties will reap the benefits of that better abstraction.
Previous
Next
| 
One possible argument against this being a benefit is that you don't know if you're manipulating a field or a property with this syntax. However, almost all classes with any real complexity designed in Java (and certainly in C#) do not have public fields anyway. Fields typically have a reduced access level (private/protected/default) and are only exposed through getter/setters, which means one may as well have the nicer syntax. It is also totally feasible an IDE could parse the code, highlighting properties with a different color, or provide code completion information indicating if it is a property or not. It should also be noted that if a class is designed well, then a user of that class should only worry about the specification of that class, and not its implementation. Another possible argument is that it is less efficient. As a matter a fact, good compilers can in-line the default getter which merely returns a field, making it just as fast as field. Finally, even if using a field is more efficient that a getter/setter, it is a good thing to be able to change the field to a property later without breaking the source code which relies on the property.