[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