Hi Tom
How about using the template pattern,defining in the base constructor
what things must happen in what order. Someone extending the a Fig
should then never have to do anything in the constructor apart from
call the appropriate super constructor.
It enforces the order in which things happen rather than rely on some
future developer getting the order correct by following some
standards.
Bob.
class AbstractBaseParent {
AbstractBaseParent(Object owner) {
constructComposites();
setOwner(Object owner);
}
abstract protected void constructComposites();
}
class Parent {
Fig fig1;
Parent(Object owner) {
super(owner);
}
protected void constructCompositess() {
fig1 = new Fig();
}
void setOwner(Object owner) {
super.setOwner(owner);
fig1.setOwner(Object)
}
}
class Child extends Parent{
Fig anotherFig;
Child(Object owner) {
super(owner);
}
protected void constructCompositess() {
super.constructComposites();
anotherFig = new Fig();
}
void setOwner(Object owner) {
super.setOwner(owner);
anotherFig.setOwner(owner);
}
}
2008/11/18 Tom Morris <[EMAIL PROTECTED]>:
> Thanks for the review and feedback everyone. I need to review Bob's
> comments in more detail, but since basically everyone asked about
> adding Layer to the list of arguments, let me address that. I
> considered adding it since the FigEdge factory
> (*Renderer.getFigEdgeFor()) seemed to require it (but then don't pass
> it to the constructor usually), although the FigNode factory did not.
> The main issue as I remember it was getting the PGMLStackParser did
> the setLayer as a separate step and I really, REALLY only wanted a
> single constructor for use both by the parser and interactive use.
> Also, the I'll take another look and see if there's a solution.
>
> The other thing that is causing me a little difficulty is the
> invocation of overloaded methods from constructors. The problem with
> this is that the subclasses data structures haven't necessarily been
> initialized yet because their constructor hasn't finished running.
> Anyone have a good pattern for addressing this? Might current feeling
> is that constructors shouldn't call methods that can be overloaded.
>
> Here's an example,
>
> class Parent {
> Fig fig1;
>
> Parent(Object owner) {
> fig1 = new Fig();
> setOwner(Object owner);
> }
> void setOwner(Object owner) {
> super.setOwner(owner);
> fig1.setOwner(Object)
> }
>
> class Child extends Parent{
> Fig anotherFig;
>
> Child(Object owner) {
> super(owner);
> anotherFig = new Fig();
> setOwner(owner);
>
> void setOwner(Object owner) {
> super.setOwner(owner);
> anotherFig.setOwner(owner);
> }
> }
>
> at the time that the Parent constructor attempts to invoke
> this.setOwner() (which will resolve to Child.setOwner()), the field
> anotherFig is still null, so this will throw a NullPointerException.
>
> My current idea is to move all one-time only initialization to private
> methods and make it a rule that the constructors can't invoke any
> methods which can be overridden. In this case, have a
> setOwnerInternal() that the constructor can use (and that setOwner()
> can call during the transition period, if necessary).
>
> Anyone got better ideas?
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
