HELP: creating first instances of aggregates

[Anonymous]

I have the folowing classes:
    class Doc {};
    class DocObject {};
    class A : public DocObject {};
    class B : public A {};

and relationships:
    Doc <>-->> DocObject
    B <>-->> A

and constructors generated by CB:
    ModelDocObj(ModelDoc* pModelDoc);
    A(B* pB)
    B(B* pB)

The question is how do I create the
*first* instance of class B; keeping
in mind that the class hierarchy in a
real application can be much deeper and
the constructors for those classes bit
more complicated than the simple example
suggests.

The constructor generated by CB 'requires'
a parent class B.

[Valery Goldring]

What is ModelDoc?
Why would B inherit A and own its instances simultaneously?
Anyway, you need to provide B* pB for A(B* pB), which is base A of B, i.e. "this" of an instance of B.
What does it have to do with Docs?

[Anonymous]

Sorry for the typo. The first line in the list
of constructors should read:
DocObj(Doc* pDoc);

[Craig Gunhouse]

This looks a lot like the tree pattern from the pattern book. In my opinion the example from the pattern book is flawed, the relationship is the wrong way around. They want an aggregation except for the top of the tree. However code generation is very consequent and doesn't make exceptions. Of cource there are ways to trick around, bit it is better to model the problem correctly, e.g.
DocObject<|---- Parent
Parent <|---- Child
Parent <|---- Root

Doc <>-->> DocObject
Parent <>--->> Child

Where parent is a abstract class, something is either a root or a child, or a derivation from it.

Jimmy Venema

Posted to Forum by gunner

[Anonymous]

Craig,

I understand and agree with your solutions for some
cases like lists, directory structures etc.

However, look at this example:

*************************************************
class stateDoc {};
class stateDocObject {};

class stateChartItem  : public stateDocObject {};
class stateTransition : public stateChartItem {};
class stateSimple     : public stateChartItem {};
class stateComplex    : public stateSimple    {};

stateDoc     <>-->> stateDocObj
stateSimple  <>-->> stateTransition // in
stateSimple  <>-->> stateTransition // out
stateComplex <>-->> stateSimple
*************************************************

Although a tree structure is present, it would not
make sense to turn it upside-down.

Regards,
Aiden

[Craig Gunhouse]

Actually it was my solution, since the initial question came from the forum
on the SourceForge site, I have been forwarding them to the Classbuilder
CoolList Listserver and then pasting the response back into the forum.  The
solution was Jimmy's, I just posted his solution to the forum.

Aiden, I posted your response to the CoolList Listserver for  Classbuilder.  This listserve pre-dates the move to Sourceforge.

Craig

[Craig Gunhouse]

What you want is in ClassBuilders terms an aggregations that is an association in one particular case. What you can do is use an association and build the aggregation behaviour at the correct places manually. This involves adding objects to teh relation in certain contructors and deleting object sin destructors. Or use an aggregation and hack around. Oner way to hack around is to provide the 'this' pointer so in the one non aggregate case, the object will point to itself. I would normally try to model around it, often the model improves and get more general.

Jimmy Venema

Posted by Gunner from Classbuilder CoolList

[Anonymous]

Hacking relations in CB can be more trouble
than it is worth as its possible to stuff up
Serialization of objects and one may have to
go through a large number of constructors to
check and regenerate etc; can be long and boring
job.

I have ended up turning aggregations to
associations in some parts  of the model. Though
'conceptually' the model is not quite right now
it worked out OK in practice. It was not a major
sacrifies.

I decided to do this to keep serialization consistent and 'automatic', as generated by CB.

I'm quite happy now with what I've got.

Thanks for yur comments and time,
Aiden

[Jimmy Venema]

What you want is something that is sometimes an aggregation and sometimes an association. It is the sometimes that is difficult with code generation. Code generation is always very strict, so I agree if that a better model can not be found it is best to go to association, since it covers the base and to manualy make it an aggregation in those cases needed. It often only involves a few additional lines of code. In some constructors you have to add something like X->AddYLast(this);
While in the destructor you will have to add
DeleteAllY(); So it isn't that hard to do. It is difficult to say that it is conceptual wrong, you can only use one symbol in a static picture, it is either association or aggregation. While in reality the dynamic behaviour is both, which ever symbol you use it is always wrong in some situation. The fact how it is used in the majority of cases is not that important, it is important that it is dynamic. In these circumstances I always attach a note to the relation in the Class Diagram, just to mention this fact and the reader is aware that there is something specific to this relation woth knowing.

Jimmy Venema