Composition vs Inheritance (RE: ContainerManager (was: RE: [Proposal] ECM / ECS / AbstractContainer))

[Leo Simons <ma...@leosimons.com>]

> > I would like to split this one and break out the get and has methods.
> >
> > AbstractContainer: Provides methods for obtaining handlers to
> components.
> > AbstractManager  : Provides methods for accessing component handlers.
> >
> > Basically, AbstractContainer.m_mapper would be AbstractManager.m_mapper,
> > and the rest of the class follows as needed to compile.

not commenting on the rest, here's a question: is this really a
place where inheritance/abstract classes is smart? (me, I always
use composition by default and switch to inheritance when it is
neccessary. A maintainability issue...)

Actually, I've been wondering whether this should be at least
mentioned in the framework documentation.

I generally prefer:


interface SomeInterface
interface SomeInterfaceHelper

class DefaultSomeInterfaceHelper implements SomeInterfaceHelper
class DefaultSomeInterface implements SomeInterface
class Alternate1SomeInterface implements SomeInterface
class Alternate2SomeInterface implements SomeInterface

DefaultSomeInterface --uses--> DefaultSomeInterfaceHelper
Alternate1SomeInterface --uses--> DefaultSomeInterfaceHelper
Alternate2SomeInterface --uses--> DefaultSomeInterfaceHelper


to:


interface SomeInterface

abstract class AbstractSomeInterface implements SomeInterface

class DefaultSomeInterface extends AbstractsomeInterface
class Alternate1SomeInterface extends AbstractsomeInterface
class Alternate2SomeInterface extends AbstractsomeInterface


while the first one generally means more code, it improves
code readability. For the most part, Framework and Excalibur
follow this approach. Pete's been known to do it differently
in places =)

thoughts?

- Leo


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Composition vs Inheritance (RE: ContainerManager (was: RE: [Proposal] ECM / ECS / AbstractContainer))

[Berin Loritsch <bl...@apache.org>]

Leo Simons wrote:
>>>I would like to split this one and break out the get and has methods.
>>>
>>>AbstractContainer: Provides methods for obtaining handlers to
>>>
>>components.
>>
>>>AbstractManager  : Provides methods for accessing component handlers.
>>>
>>>Basically, AbstractContainer.m_mapper would be AbstractManager.m_mapper,
>>>and the rest of the class follows as needed to compile.
>>>
> 
> not commenting on the rest, here's a question: is this really a
> place where inheritance/abstract classes is smart? (me, I always
> use composition by default and switch to inheritance when it is
> neccessary. A maintainability issue...)
> 
> Actually, I've been wondering whether this should be at least
> mentioned in the framework documentation.
> 
> I generally prefer:
> 
> 
> interface SomeInterface
> interface SomeInterfaceHelper
> 
> class DefaultSomeInterfaceHelper implements SomeInterfaceHelper
> class DefaultSomeInterface implements SomeInterface
> class Alternate1SomeInterface implements SomeInterface
> class Alternate2SomeInterface implements SomeInterface
> 
> DefaultSomeInterface --uses--> DefaultSomeInterfaceHelper
> Alternate1SomeInterface --uses--> DefaultSomeInterfaceHelper
> Alternate2SomeInterface --uses--> DefaultSomeInterfaceHelper
> 
> 
> to:
> 
> 
> interface SomeInterface
> 
> abstract class AbstractSomeInterface implements SomeInterface
> 
> class DefaultSomeInterface extends AbstractsomeInterface
> class Alternate1SomeInterface extends AbstractsomeInterface
> class Alternate2SomeInterface extends AbstractsomeInterface
> 
> 
> while the first one generally means more code, it improves
> code readability. For the most part, Framework and Excalibur
> follow this approach. Pete's been known to do it differently
> in places =)
> 
> thoughts?


The ContainerManager and Container handle two different concerns.
The ContainerManager's responsibility is to manage the Container
instance, and all the other helper managers in the system.  It is
also meant to reuse existing Managers if they are already created.
The Container is designed to manage the Component instances.  The
AbstractContainer does make use of other managers and components
to do its job.  But it's purpose is to map components between the
different component instances.  I.e. it can be so fine grained as
to allow some components to be available to one component but not
another.

The concrete example would be the following scenario:

Components:

DataSourceComponent
Store
Monitor

Store may be able to obtain a reference to the DataSourceComponent
and the Monitor, but the DataSourceComponent wouldn't be able to
obtain a reference to anything else.  Furthermore, the Monitor might
be able to reference the DataSourceComponent but not the Store.

In the ECM, everything is accessible to everything else.

The AbstractContainer provides all the basic logic and hooks to allow
you to enforce whatever policy you want and still maintain the same
configuration format.  The AbstractContainer defaults to the same
behavior as the ECM, but allows you to have more fine control.



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>