Whether a property is implemented as a field or as calculated value, it represents something an object can always provide. You shouldn�t use a property to model a transient relationship, such as an object that is passed as a parameter during a method call and used only within the confiness of that interaction.
I can�t really understand what he wants to say in the second sentence: what is the problem with transient relationships?
I don't think he's saying there's anything bad about transient relationships. What he means is you don't try to model them (transient relationships) with a property. (He gives the example of an object parameter to a method.) It might look something like this:
A class diagram is a static view on the interfaces, classes and the relationships among them (association, implementation and inheritance). If you put transient relationships in the model, reader of model is overwhelmed with information. Also transient stuff is inherently dynamic. An instance member is allways "there" as long as the class does exist, though it might be null. A transient variable has a much shorter life-cycle.
Transient stuff gets focus in types of uml models which show dynamic behaviour like interaction diagrams.
posted 15 years ago
Thank you, Ed and Axel, the combination of your replies makes it all clear
Gian Franco Casula
"Eppur si muove!"
We don't have time to be charming! Quick, read this tiny ad: