cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Checkstyle
Date Tue, 03 Apr 2007 23:49:51 GMT
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 <phumenn@iona.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message