>> One idea is to split it into different objects, having one object just
>> containing the tree.
>> class O {GRO g; XMLO x; PHYO p; List<O> others;}
>
> Where's the "contain each other recursively" part? Is GRO, XMLO and
> PHYO
The contain each other recursively is the List<O> others.
> a subclass of O? If so why?
Yes, we decided to have:
interface Business {}
interface Drawable {}
class Model {Drawable getDraw(); ...}
class ConcreteModel extends Model {Drawable getDraw() {return d;}
private ConcreteGRO d;...}
class ConcreteGRO extends ConcreteModel implements Drawable {}
> Or more specifically, what is O that it can be
> a superclass of GRO, XMLO and PHYO all at the same time?
Yes, the Model is superclass of all Concrete Models and ConcreteGRO (graphic
objects). So in (business or graphical) code, you have a model, use a get()
function to get the real object and work with it.
> Otherwise all you have is a n-ary tree like structure (or perhaps an
> arbitrary directed graph), which in itself doesn't strike me as being "too
> big". Your problems might be elsewhere; like does O really need to know
> about GRO? Perhaps GRO needs to know about O, but not the other way
> around. I'm assuming O is some sort of model, and GRO and XMLO are views
> on this model.
Yes, you are completely right. Thank you very much for the input. The idea
to see it as Model is working out very good.
thank you
Markus Raab

Signature
http://www.markus-raab.org |
-o) |
Kernel 2.6.16.9 /\ |
on a i686 _\_v |
Oliver Wong - 13 May 2006 22:00 GMT
>>> One idea is to split it into different objects, having one object just
>>> containing the tree.
[quoted text clipped - 14 lines]
> private ConcreteGRO d;...}
> class ConcreteGRO extends ConcreteModel implements Drawable {}
Shouldn't Model and/or ConcreteModel implement Business?
I don't think Model should have a getDraw() method. Rather, you should
have a view implement Drawable, and you provide it with a model. The view
then queries to the model to figure out how to draw itself.
- Oliver