Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of polar.humenn@iona.com
 designates 65.223.216.181 as permitted sender)
Message-ID: <4612C2C3.7020102@iona.com>
Date: Tue, 03 Apr 2007 17:10:27 -0400
From: Polar Humenn <phumenn@iona.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: cxf-dev@incubator.apache.org
Subject: Checkstyle
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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