[Uml-devel] oo design question

Andrew Sutton ansutton at kent.edu
Fri Jan 17 08:05:02 UTC 2003


list,

still stumbling around with the Reflective/MOF implementation for 2.0 and had 
a question as to preference of design.

if you've ever looked at the documentation for MOF, you'll know that its a 
pretty deep inheritance tree. each class defines various attributes, 
references, etc. the reflective interfaces provide generic mechanisms for 
retrieving those attributes and references (among other things).

i see two ways to implement (in regards to luis' and my discussion a couple 
days back).

1. interface/implementation
all the classes in the MOF (and UML eventually) will be built with all pure 
virtual methods. that means we have implementations derived from non-abstract 
classes that implement ALL the attribute/reference accessors and mutators for 
derived classes.

this is actually a pretty good solution. it helps deal with "odd" inheritance 
where a non-abstract class is derived from a non-abstract class (e.g. 
UML::Model : public UML::Package). its odd because it doesn't happen very 
often.

anyways, the net result with this solution is a large number of interfaces and 
a small number of implementations, but they're enormous and we duplicate alot 
of code.

2. partial implementation
each class implements its own accessors and mutators. however, only 
non-abstract classes implement the reflective interfaces. in otherwords, the 
leaves of the inheritance tree ARE the implementations of the reflective 
interfaces. its not a bad idea.

3. partially implemented interfaces/distinct implementation
this is a combination of 1 & 2. each class in the MOF (and UML) standards 
implements mutators, accessors and methods (maybe). a private implementation 
class implements the reflective interfaces.

to be honest, i think this is the best of both worlds. it eliminates the 
massive duplication of code and isolates implementation of reflective 
implementations to a single class where further derivation won't cause 
ambiguity problems.

any preferences? i like 3.

andy




More information about the umbrello-devel mailing list