Just back to the topic of better design, one of the concrete , may oversimplistic
advantages of having an object-oriented approach, is that the you can move
a lot of the type testing code out into the class heirarchy / class interaction design.
Take for example the previous comment about DV_POSSIBLY_RANGED_POSSIBLY_ACCURATE ;
that is just better naming to warn programmers that they have to do type testing .
Let's say you want to do something like this:
you want to get a DV_ABSTRACT object, give it to a GUI_FACTORY object, and get
back a *viewer/editor* object for the DV_ABSTRACT object , so that the DV_ABSTRACT object
can be manipulated by users.
The DV_ABSTRACT object uses the Composite design pattern , and there is
something like DV_ENCOUNTER_DATA that aggregates the data items that occurred
in an encounter, contains DV_ABSTRACT objects, and is itself a DV_ABSTRACT object,
so now the GUI_FACTORY object can use recursive container walking to create a complex gui object.
Now when DV_COUNT ( actually integer objects), and DV_QUANTIFIED ( actually double/float objects)
are encountered, the GUI_FACTORY would have to do type testing on DV_COUNT and DV_QUANTIFIED
to see if needs to especially add say a little box showing that the DV_COUNT object had accuracy information,
or had range information.
You could use the Visitor pattern and the Decorator pattern here ( from the gang of four , around 1995, one of which is involved with the Eclipse project , around 2004 -2006).
Instead of DV_COUNT and DV_QUANTIFIED inheriting from DV_POSSIBLY_RANGED_POSSIBLY_ACCURACY_GIVEN,
which is just the same as the original design as inheriting from abstract DV_ORDERED, whose child is DV_QUANTIFIABLE,
but only explicit about the minOccurs=0 for all the extra data fields, you can have a DV_ABSTRACT child which
is DV_RANGED ( a renamed DV_ORDERED), which takes a value field as DV_ABSTRACT , and *decorates* the
original object with range data , and similiarly DV_ACCURACY_GIVEN . Then within the
gui factory object, it uses the visitor pattern to construct different gui elements e.g.
createGuiElementFor ( DV_ENCOUNTER_DATA)
createGuiElementFor ( DV_COUNT),
createGuiElementFor( DV_QUANTIFIED)
createGuiElementFor( DV_ACCURACY_GIVEN)
createGuiElementFor(DV_RANGED) ( which calls createGuiElementFor on the value object of the DV_RANGED object, before attaching range display )
then it just uses method overloading , and the type of the DV object passed in to the method createGuiElementFor(..) will determine what
kind of gui element is constructed.
I'm guessing that is one reason why the openehr people are doing it object-oriented, but they haven't focussed on the
"I need to design this to avoid type-testing " objective to get a clearer design.
On Thu Nov 23 0:38 , 'Andrew Patterson'
> Maybe it's a good thing openehr hasn't been proliferated yet,
> otherwise we'd be stuck with some basic flaws.
I think it's broad statements like this that tend to put peoples
noses out of joint - this morning you were decrying their lack of
professionalism because they hadn't done the basics of running
their schemas through a validator - only for it to be your translation
that was wrong. Now, because you disagree with a one
design decision (and you have presented an alternative that
is for all intensive purposes identical, only with fields moved
around), you are claiming that the whole effort has some
basic flaws. My impression of the openehr group is that they
are more than willing that accept good constructive
criticism - if you feel you have some insights into the base
data types you should feed it back to them.
Andrew
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
_______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
