Peter Donald wrote:
On Fri, 14 Dec 2001 07:06, Berin Loritsch wrote:
So if the "Profilable" interface was changed to add the setName(), we could
implement something like this:
interface Profilable {
void setName( String name );
// ..... skip other already declared methods .....
}
...snip...
What are your feelings on the subject?
I really dislike any notion of a public setName() method. Perhaps it would be
better to allow points to create their own children. If that is not viable
for whatever reason then you could make constructors look like
class MyPoint
{
MyPoint( Point parent, String myName )
{
super( parent, myName );
}
}
The problem arrizes with how do we determine what the parent ProfilePoint is?
It does not make sense to have a Pool's max active ProfilePoint be the parent
of an ObjectFactory's number of created instances ProfilePoint. They represent
something completely unique.
If this is going to scale, we *have* to make it happen at the Profilable level.
Remember, this is IoC, so a child Profilable is not going to have access to the
Parent's ProfilePoints at all.
We have to come up with a solution where the name is given by the parent to the
child, like everything else.
and the name would be set via
parent.getName() + myName
however the method getName() would be protected, package or private access
(depending on what we could get away with) and done in the case class.
I don't like this, as it is Subversion of Control. A child should not have
a direct reference to it's parent. The name has to come from being assigned,
or we trust the Component to use proper "divination" to generate a meaningful
name.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
