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
