cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@infoplanning.com>
Subject Re: Interfaces vs. Abstract classes (was Re: DirectoryGenerator.java)
Date Thu, 25 May 2000 19:21:24 GMT


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 =).

It is important to note that while you can implement multiple interfaces
per class, you should not always do that.  Any time that a system uses
components, it should specify an interface so that the component behaves
in an expected manner.  Interfaces are an integral part of component
based engineering.  Cocoon definitely qualifies as a component based
architecture--so the interfaces should stay.

I also think your point about maintainability should be well taken.  Even
though I legally can implement multiple interfaces in an object, for
maintainability reasons I should really think about better/alternative
ways of handling that scenario.

Case and point about why interfaces should stay: JDBC.  Without interfaces
for programs to use, database programming in Java would be an unruly
mess.  We know have a well defined API, and we know what should happen
with a well behaved JDBC driver.  The same concept applies in Cocoon.



Mime
View raw message