Properties Redux
Well, thank you all for your input on Properties. There seems to be a lot of "Guff" written on Properties. As far as I can make out the following statements are valid:
In the following the term Property means an construct similar to a C# Property or a Visual Basic Property. It is not a requirement that the Property be part of a Class (as some languages have Properties, but not Classes).
--------------------
I define a Property as a construct that looks like an Attribute (or Field, or Variable, or structural feature) to the client, but whose value is actually accessible through at least one and up to two specific accessors defined by the supplier. The accessors are known as the setter and getter (Operations, methods, behavioural features).
Where a Property is read only, a setter is not required. It is possible to create a write only attribute; in which case, a getter is not required.
In order for the Property to behave like an attribute for both setting and obtaining a value, the name of the Operation must be the same for both the setter and getter. Their signatures will, however, be different:
In order for the Property to behave like an attribute for obtaining a value, the getter (Operation) cannot have a parameter. In order for the Property to behave like an attribute for setting a value, the setter (method) must have exactly one parameter (the value).
Properties are defined in terms of a Name and Type (just like an Attribute).
There is no requirement for a Property to be bound in any way to an other Attribute or Property.
Not every programming language has the Property Construct. In particular, Java attempts to simulate the property construct by means of Operations with specifically formatted naming. These Java constructs are not true Properties and are contentious (see
[size=13]Why getter and setter methods are evil[/size])
Although Properties are often used to
"provide a Public Interface to a Private Attribute", this is just one usage. The Property may have arbitrary visibility (just like any other Attribute). The visibility of the Property applies equally to the accessors.
UML derived Attributes can only properly be instantiated using a read-only Property.
--------------------
Here is what Microsoft has to say in the documentation for the PropertyInfo class:
"Properties are logically the same as fields. A property is a named aspect of an object's state whose value is typically accessible through get and set accessors. Properties may be read-only, in which case a set routine is not supported."
Paraphrasing
Programming C# by Jesse Liberty
"... Properties ... act like methods to the creator of the property but look like fields to clients of the property.
Properties allow clients to access the property as if they were accessing fields directly, while actually implementing that access through two methods.
Properties provide a simple interface to the client, appearing to be a field. They are implemented as methods, however, providing the data hiding required by good object-oriented design."
What does this mean for UML modelling of such Property constructs?It seems to me that in order to correctly round-trip such constructs the Property must ostensibly appear to be an Attribute. Fortunately, EA seems to agree thus far. You can designate an Attribute as a Property.
Secondly, the Property must specify where it has read or write accessors. EA also concurs.
The visibility of the Property defines that of the accessors. EA (incorrectly in my view) allows this to variable. However proper modelling discipline will solve that.
The name of the accessors must be the same as the Property (pseudo Attribute) (if exposed - such as with some forms of Basic). EA allows separate naming, discipline will help.
The Property must allow the definition of the appropriate accessor bodies. Unfortunately EA does not support this. For the present, I'd advise creating the two accessor Operations with the same name as the Property Attribute - the getter with no Parameter, but returning a value of the same type as the Property Attribute; and the setter with exactly the one Parameter of the same type as the Property Attribute.
Where a Property actually interacts with one or more other Attributes or Properties, it would be nice to be able to record this dependency. In particular, where a Property is simply used to set and get another Attribute, one could have a checkbox so indicating that and a link to the bound Attribute or Property. The accessor bodies could then be generated without further input.
Thoughts anyone?
How about it Sparxians?
Paolo
[size=0]©2005 Paolo Cantoni, -Semantica-[/size]
