Contanier hierachy & good style

V

VisionSet

I have a nice simple self contained MouseListener class that manages an
innerclass popup menu and uses MouseEvent.getComponent() meaning I only need
one of these Listener objects.

I have a 3 tier hierachy of containers, the Listener needs adding to all of
the innermost containers (3rd tier).

It seems to make sense to have the Listener as an attribute of the 1st tier,
as it is 1:1 with this.

I've a feeling it isn't good style to retrieve this reference by backward
delegation, or pass the reference forward at creation. Since the containers
are then not self contained.

What is the best way to add this Listener to my inner tier of components?
 
J

John C. Bollinger

VisionSet said:
I have a nice simple self contained MouseListener class that manages an
innerclass popup menu and uses MouseEvent.getComponent() meaning I only need
one of these Listener objects.

I have a 3 tier hierachy of containers, the Listener needs adding to all of
the innermost containers (3rd tier).

It seems to make sense to have the Listener as an attribute of the 1st tier,
as it is 1:1 with this.

I've a feeling it isn't good style to retrieve this reference by backward
delegation, or pass the reference forward at creation. Since the containers
are then not self contained.

What is the best way to add this Listener to my inner tier of components?

Whatever constructs the third tier containers should add the listener.
That object [or objects] must therefore have access to the listener
during the construction. I typically prefer to use generic GUI
components where possible, and otherwise components as minimally
customized possible, where an external object composes them into a full
UI. In that scenario, the builder object would construct the listener
and set it on the appropriate third-tier objects, and the higher tiers
don't need any knowledge of it.

If you have the higher tiers constructing the lower tiers, or if you
need to be able to globally remove (or add another) listener after
initial construction, then the top tier should be able to so instruct
the second tier, and the second tier should forward such instructions to
the third tier (presumably in this case by invoking removeMouseListener
[etc.] on the third-tier containers).


John Bollinger
(e-mail address removed)
 
V

VisionSet

John C. Bollinger said:
Whatever constructs the third tier containers should add the listener.
That object [or objects] must therefore have access to the listener
during the construction. I typically prefer to use generic GUI
components where possible, and otherwise components as minimally
customized possible, where an external object composes them into a full
UI. In that scenario, the builder object would construct the listener
and set it on the appropriate third-tier objects, and the higher tiers
don't need any knowledge of it.

If you have the higher tiers constructing the lower tiers,

Yes, so the higher tier does need knowledge of it? and this is natural since
it is 1:1 with the higher tier. Though I'd rather it didn't have knowledge
of it, but then we get into Singletons or factories which seems wrong since
I may potentially have a number of these higher tier containers. The higher
tier would only be storing the reference to enforce the 1:1 and for passing
the reference along, I guess this is a good enough reason.
or if you
need to be able to globally remove (or add another) listener after
initial construction, then the top tier should be able to so instruct
the second tier, and the second tier should forward such instructions to
the third tier (presumably in this case by invoking removeMouseListener
[etc.] on the third-tier containers).

So I should forward the Listener reference in the constructors to have
listener registered at construction which seems a bit messy.
OR cascade the construction and *then* delegate a separate chain that
registers the listeners?

This really isn't a GUI question, there are lots of cases where delegation
1->n->n*m means tier1 needs ref to tier2 needs ref to tier3, but the reverse
feels wrong, but if tier3 needs an attribute of tier1 then surely it should
have it, but it just feels wrong.
I mean maximum flexibility would have everything being able reference
everything.
 
J

John C. Bollinger

VisionSet said:
Whatever constructs the third tier containers should add the listener.
That object [or objects] must therefore have access to the listener
during the construction. I typically prefer to use generic GUI
components where possible, and otherwise components as minimally
customized possible, where an external object composes them into a full
UI. In that scenario, the builder object would construct the listener
and set it on the appropriate third-tier objects, and the higher tiers
don't need any knowledge of it.

If you have the higher tiers constructing the lower tiers,


Yes, so the higher tier does need knowledge of it? and this is natural since
it is 1:1 with the higher tier. Though I'd rather it didn't have knowledge
of it, but then we get into Singletons or factories which seems wrong since
I may potentially have a number of these higher tier containers. The higher
tier would only be storing the reference to enforce the 1:1 and for passing
the reference along, I guess this is a good enough reason.

If the higher tier is constructing the lower tier, then it needs to have
a reference to the listener during construction. If everything is
constructed at once and then just let run, then the higher tier does not
need to _retain_ a reference. If new lower-tier objects are going to be
added on the fly and will need the listener installed then the highest
tier is a logical place to store that reference, and also a logical
place to put the construction code.
or if you
need to be able to globally remove (or add another) listener after
initial construction, then the top tier should be able to so instruct
the second tier, and the second tier should forward such instructions to
the third tier (presumably in this case by invoking removeMouseListener
[etc.] on the third-tier containers).


So I should forward the Listener reference in the constructors to have
listener registered at construction which seems a bit messy.
OR cascade the construction and *then* delegate a separate chain that
registers the listeners?

If you do as you have said and have each tier construct the next lower
tier, then either style you mention for registering the listeners is
reasonable. The latter (a seperate method invocation over the
hierarchy) is more flexible. It might be overkill, but you could
consider setting up your tree to support the Visitor pattern. You could
then use a Visitor to set the listeners on the third tier, and have the
flexibility to use the same mechanism for other tree-walking type
procedures that you might want to perform.
This really isn't a GUI question, there are lots of cases where delegation
1->n->n*m means tier1 needs ref to tier2 needs ref to tier3, but the reverse
feels wrong, but if tier3 needs an attribute of tier1 then surely it should
have it, but it just feels wrong.
I mean maximum flexibility would have everything being able reference
everything.

GUI widgets are nevertheless a good example. At least for AWT / Swing,
components (including containers) know their parent container, and
containers know all their child components. I guess Sun opted for
maximum flexibility there.

I think you're making too much of the question, or perhaps asking the
wrong one. Consider the class inheritence hierarchy, for instance. For
the most part, _all_ the "references" go in the direction that feels
wrong to you.

If you set up an object hierarchy then actions should flow along the
hierarchical lines, but it seems okay to me for them to go in either
direction, as necessary. Depending on your needs you could set up
ancillary objects for storing whole-hierarchy data and/or per-level data.

There are better designs and poorer ones, but there are few, if any,
designs that are completely "right", and none that get the job done but
are completely "wrong".


John Bollinger
(e-mail address removed)
 
V

VisionSet

....
If you set up an object hierarchy then actions should flow along the
hierarchical lines, but it seems okay to me for them to go in either
direction, as necessary. Depending on your needs you could set up
ancillary objects for storing whole-hierarchy data and/or per-level data.

There are better designs and poorer ones, but there are few, if any,
designs that are completely "right", and none that get the job done but
are completely "wrong".

Thank you!!
It shall feel wrong no longer.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top