> > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
