I completely agree that we should get rid of this rule.
First of all, Aegis from XFire use Type which is abstract, and I don't want
to change this for migration reasons which is one of the reasons pmd is
disabled for this module.
Second, I agree that the Abstract/base/factory naming is incredibly awkward.
I hear some mumblings of "just use interfaces" - but abstract classes
provide a much more robust way to add features in the future. With an
interface, if you add a method, it will break every class that implemented
that interface. With abstract classes if you add a new method, all you need
to do is provide a default implementation of it and everything will work
swell in the future. So I tend to use abstract classes more and more to
avoid future incompatibilities (AbstractWSFeature,
AbstractServiceFactoryBean, AbstractEndpointFactory). With at least the
first two, I would like to get ride of the Abstract.
- Dan
On 4/3/07, Polar Humenn <[EMAIL PROTECTED]> wrote:
Is there a "good" motivation of why "abstract" classes have to be named
"Abstract" "Base" or "Factory"?
If a class is declared "abstract", I want the *compiler* to tell the
developer that s/he has not filled out a particular functionality when
s/he extends the abstract class. Not that I want it named "Abstract".
For example,
abstract class Muffin {
......
abstract Kind kind();
}
I really don't want my code littered with method definitions like:
void eat(AbstractMuffin muff) {
I want it to be:
void eat(Muffin muff);
because that's what it is. It's not an AbstractMuffin, it's a Muffin!
Can we get rid of that particular checkstyle rule?
I say that, because it forces, either
a) illogical names, like AbstractMuffin, to be used in definitions,
making for
awkwardness. (i.e. eat(AbstractMuffin muff);
b) default implementations, just to avoid the illogical names!
This particular avoidance causes errors to be caught at run time
instead of compile time, where it should be caught! And sometimes
causing
a loss of time to find it.
For example, with the current checkstyle rule I could be forced to write
the class with
a default implementation expecting it to be overridden. (Except there is
no way to tell a compiler that).
class Muffin {
.....
Kind kind() {
return Kind.BLUEBERRY;
}
}
void eat(Muffin muff) {
System.out.println("I'm eating a " + muff.kind() + " muffin!");
}
and a developer goes ahead and writes:
class CornMuffin extends Muffin {
Kind kiend() {
return Kind.CORN;
}
}
and it compiles fine without problems. Subsequently he can't figure out
why his application still says he has a BLUEBERRY muffin, especially
when he has used "eat(new CornMuffin())".
This kind of pattern complete adverted the use of compiler protections.
Cheers,
-Polar
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
