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]>
