Eric,
I got it. This is a valid point and I already said in an earlier post
that I would rename the ~Support classes to Base~. The only place
where I want to keep the ~Support naming is the unit tests. If I call
a class ~Test, Maven will think this is truly a test that needs to run.
I might as well call these classes "~TestDontRunThis". Of course, you
can tell Maven to skip some classes, but I would rather keep it simple.
I hope that class names in the test subtree are not as important - so
perhaps it's ok to keep the naming I have there.
I also agree that having both Reflection and Introspector in the name
may be an overkill - the sole reason for the Reflection prefix is that
all classes in that package (org.apache.commons.clazz.reflect) start
with "Reflected". I don't think I have problem with renaming some of
them.
- Dmitri
--- [EMAIL PROTECTED] wrote:
>
> 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]
>
>
>
>
>
=== message truncated ===
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
