When to use enumerations
There are two ways to define an input field that allows users to select a value from a set of options.
- Define it as an enumeration field
- Define it as a class field that references a model defined elsewhere The characteristics of each method are as follows.
Enumeration fields
The options in an enumeration are defined in the metamodel.
As a result, the profile developer defines the options, and individual developers cannot change the options during design.
For example, design information such as the visibility of a function (public, protected, private,...) is determined at the metamodel definition stage, and is not information that is added during design, so it is appropriate to use an enumeration field.
When a model is added, the enumeration field is initially set to one of the enumeration values (if there is no initial value, the first enumeration value). By defining a value that represents "undesigned" as one of the enumeration values and setting it as the initial value, you can distinguish whether the value was entered intentionally or not.
Class type field
If the options are not determined when the metamodel is defined and you want to flexibly change the options while designing, you can achieve this with a class type reference field.
When using a class type field, the options themselves become the design results.
In addition, class type fields are also suitable for items that are determined to a certain extent but have characteristics that can be customized depending on the product, etc. Common options are defined in advance as models, and designers can define new option models during design.
For example, it is a good idea to define design information such as data types in class type fields so that you can design while modeling. Data types are items that are defined as function return values and data types, but the value range of the data type itself is also design information at the same time.