cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Stimmel <jon-li...@stimmel.net>
Subject Interfaces vs. Abstract classes (was Re: DirectoryGenerator.java)
Date Thu, 25 May 2000 19:15:10 GMT
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 =).

Mime
View raw message