commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ericpa...@discoverfinancial.com
Subject Re: [Clazz] names of classes
Date Wed, 18 Jun 2003 14:35:02 GMT

To add my two cents...  I think that it is clearer and more standard for a
class to be named for what it is and does instead of how it is recommended
to be used (delegatory vs. sub-class).  I think that any recommendations of
that sort could go in the JavaDoc, but are out of place in the name.  I
also think that it should be named for the simplest possible use of it so
that simple code looks simple.

Having ~Support in the name is something that I wondered about when I first
saw it.  I had to investigate to find out that I could just ignore it.  It
seems to me that if a class extends another or implements an interface and
the interface ends with "PropertyInspector", then the class should be named
as some kind of "PropertyInspector".  Having ~Support at the end of the
name negates that because it says to me that it is not in fact a
PropertyInspector, but instead some useful class that has something to do
with implementing (or maybe using) PropertyInspectors.

FWIW, I think that having both "Reflected" and "Inspector" in a name is
overkill.  I don't know if it is completely redundant, but I think that it
implies an implementation when it's feasible that an implementation might
not use Reflection at all.  It could just as well use a configuration file
to lookup the properties.


Eric Pabst



|---------+--------------------------->
|         |           Michael Heuer   |
|         |           <heuermh@acm.org|
|         |           >               |
|         |           Sent by: Michael|
|         |           Heuer           |
|         |           <heuermh@shell3.|
|         |           shore.net>      |
|         |                           |
|         |                           |
|         |           06/17/03 05:56  |
|         |           PM              |
|         |           Please respond  |
|         |           to "Jakarta     |
|         |           Commons         |
|         |           Developers List"|
|         |                           |
|---------+--------------------------->
  >---------------------------------------------------------------------------------------------------------------|
  |                                                                                      
                        |
  |        To:      Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
                             |
  |        cc:                                                                           
                        |
  |        Subject: Re: [Clazz] names of classes                                         
                        |
  >---------------------------------------------------------------------------------------------------------------|





For what it's worth, I've always used ~Support to indicate a class that is
used via delegation to fulfill the contract of an interface.

e.g.

interface XxxInterface
{
  public void a();
}

abstract class AbstractXxx
  implements XxxInterface
{
  public void a() { ...; }
}

class XxxSupport
// may extend AbstractXxx
{
  public void a() { ...; }
}

then you can do

class MyClass
  extends AbstractXxx
{
  ...
}

or

class MyClass
  implements XxxInterface
{
  private XxxSupport support = new XxxSupport();

  public void a() { support.a(); }
}


This is in the spirit of java.beans.PropertyChangeSupport.

   michael


On Tue, 17 Jun 2003, David Graham wrote:

> > > >I do not like the names of ~Support classes. ~Support or ~Helper
> >indicate
> > > >(for me)
> > > >that these are Helper classes with (often static) utility functions.
In
> > > the
> > > >Java API I think
> > > >I have found the usage of Abstract~ or Base~ much more often for
> >classes
> > >
> > > You've missed an important difference between Helper classes and
> > > Base/Abstract classes.  Helper classes allow composition/reuse
outside
> >of
> > > a
> > > class hierarchy.  Abstract class' methods can only be used by
> >subclasses.
> > >
> >
> >Thanks for expressing that much better than I could. So the ~Suppport
> >classes
> >_are_ Base/Abstract classes, since they are abstract and only used by
> >subclassing in Clazz, aren't they?
>
> I don't work on, nor use the Clazz package so I don't know the details.
I
> was making a statement about OOP design in general.  If the Clazz classes
> you're referring to are, in fact, abstract classes used in a class
> hierarchy, they should be named Abstract* or Base* to follow widely used
> Java naming conventions.
>
> David
>
> >
> >Victor
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
> _________________________________________________________________
> STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org







---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message