Shortcut for denoting or implying getters and sett

2020-02-25 06:18发布

问题:

In a UML class diagram, if a class has 5 private attributes that need to be mutable and readable, the UML gets pretty ugly with 10 get/set methods even without any of the class' interesting functionality:

Ugliness aside, I feel like the UML should focus on the class' more interesting functionality. Am I correct?

Is there some standard shortcut for denoting or implying getters and setters for private attributes?

回答1:

You are correct: there is no need to include the (noise of) "boilerplate" signatures of standard setters and getters in a class model. Unfortunately, UML does not define a standard notation for implying getters and setters for private attributes. So, you'd have to use your own convention. For instance, you could include a general explanation (that all private properties have getters and setters, while private read-only properties have only getters) as a UML Comment, shown as a rectangle with the upper right corner bent (also called a “note symbol”) attached to the diagram.

If you prefer to make the getter/setter convention more explicit for the properties concerned, then create your own stereotypes (e.g., «get/set» and «get») to be used for categorizing these private properties, as shown in the following diagram:

I'm also using this for describing/documenting the implicit getters and setters of ECMAScript 6 classes.



回答2:

UML does not define getter setter operations. Get and Set method are used in programming languages to realize attribute definition. For example, readonly attribute will have getter method only in implementation code. if attribute is defined as calculated, getter method is usually used in code to implement calculation, and setter can be leaved out, because calculated attributes are usually readonly. Visibility of attribute is usually moved to visibility to getter and setter methods in code as well. It does not make sense to define geter and setter methods in code for attributes defined read write and not calculated.