<< §1.3.1.(b) Direct role acquisition | ↑ Table of Contents ↑ | §1.3.1.(d) Lack of subtyping >> |
§1.3.1.(c) Overriding and implicit inheritance
If a team contains a role class definition by the same name as a role defined in its super-team, the new role class overrides the corresponding role from the super-team and implicitly inherits all of its features. Such relation is established only by name correspondence.
A role that overrides an inherited role should be marked with an @Override
annotation.
A compiler should optionally flag a missing @Override
annotation with a warning.
Conversely, it is an error if a role is marked with an @Override
annotation but does not actually
override an inherited role.
It is an error to override a role class with an interface or vice versa. A final role cannot be overridden.
Unlike regular inheritance, constructors are also inherited
along implicit inheritance, and can be overridden just like normal methods.
<< §1.3.1.(b) Direct role acquisition | ↑ Table of Contents ↑ | §1.3.1.(d) Lack of subtyping >> |
R1
inT
implicitly inherits all features ofR1
inS
. This is, because its enclosing teamT
extends the teamS
(line 10) and the role definition uses the same nameR1
(line 11). Hence the attributeok
is available in the methodm()
inT.R1
(line 13).T.R1
also overridesS.R1
which is marked by the@Override
annotation in line 11.