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 |
| | <[EMAIL PROTECTED]|
| | > |
| | Sent by: Michael|
| | Heuer |
| | <[EMAIL PROTECTED]|
| | shore.net> |
| | |
| | |
| | 06/17/03 05:56 |
| | PM |
| | Please respond |
| | to "Jakarta |
| | Commons |
| | Developers List"|
| | |
|---------+--------------------------->
>---------------------------------------------------------------------------------------------------------------|
|
|
| To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
|
| 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: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> _________________________________________________________________
> STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
