cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <>
Subject Re: Interfaces vs. Abstract classes (was Re:
Date Thu, 25 May 2000 19:25:36 GMT
On Thu, 25 May 2000, Jonathan Stimmel wrote:

> On Wed, May 24, 2000 at 08:59:43PM +0200, Giacomo Pati wrote:
> > The interface definition is made according to the design pattern in use.
> > The abstract class fills some commonly used method with code and/or
> > implements other interfaces as well (you know multiple inheritance from
> > abstract classes is not possible in java).
> Sure, interfaces let you implement mutliple inheritance (actually, that's
> probably a misnomer, since you're not inheriting actual method calls),
> but is that necessarily a Good Thing(tm)? Interfaces should be used
> for secondary relationships, not primary roles. Looking through
> O'Reilly's "Java in a Nutshell", I rarely see this kind of relationship
> (interface->abstract->xxx), and its mostly for truly abstract concepts
> or utilities (the collections classes, specifically).
> I realise that I'm the dissenting opinion here, and it's not really a
> battle worth fighting (feels like the start of coding-style holy war).
> IMO, though, encouraging this methodology as the rule (rather than the
> exception) only serves to increase cocoon's complexity by encouraging
> objects to have many relationships to each other. Maintenance is an
> important consideration for any project, but especially for a project
> that is still in an evolutionary phase. A future version (e.g. 2.5) can
> always add the interfaces back if it's discovered that they truly are
> needed (and, of course, they could always be removed later if I can
> prove that they're unecessary =).

cocoon objects hardly ever have direct relationships to each other. the
cocoon framework provides a central service called director (maybe
something else in cocoon2, can't remember) from which a cocoon object can
request a reference to the object which plays a certain role (parser,
transformer, whatever). i find that to be a very clean way to manage
interobject relationships.

interfaces in cocoon also provide important clues to the director when
it's creating and initializing its actors. the director knows that if an
actor implements a certain interface, certain things should occur (e.g.
configuration information should be read from the properties file, a
logging channel should be created, etc.)

- donald

View raw message