axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: QName's
Date Mon, 01 Oct 2001 19:25:21 GMT
Sam Ruby wrote:
> 
> Berin Loritsch wrote:
> >
> > Do we really have that much overlap?
> 
> The question is whether names such as the following contain unnecessary
> redundancy, or whether such redundancy is in the name of ensuring global
> uniqueness is good:
> 
>    org.apache.axis.transport.http.AxisHttpSession
>    org.apache.axis.transport.http.HttpTransport

My approach to naming is this:

org.apache.axis.transport.Transport; // interface for transports
org.apache.axis.transport.AbstractTransport; // abstract class name
org.apache.axis.transport.http.HttpTransport; // specific implementation of transport

Now, regarding things like protocol handlers, where naming rules are
imposed in order to automatically detect the classes, then I am open
to the naming convention that is proposed.  That is generally the
exception to the rule though.

Most times there are name conflicts it is one of these following cases:
* There is a duplication of effort (i.e. QName)
* The conflicting class is usually a specialization, therefore its classname
  should reflect that (open to the afforementioned exception)
* The conflicting classes have completely different purposes and are not
  in any way associated.  This is less common, but the separate namespace
  is used for a reason.  This rarely occurs within the same jar in a well
  planned project.  In fact, if this case occurs in the same jar I usually
  suggest refactoring.

The reason I dislike duplicate names of classes is that when you examine
the code, it is difficult to keep track of which version of the class you
are using.  This increases the learning curve of the project and also leads
to potential careless mistakes.

Again, classes that are in the pattern of the URLHandler (the package name
is the protocol name, and all implementing classes are named Handler) is
acceptable because they are rarely directly manipulated or used directly
in user code.  They are the sole responsibility of the Factory code.

Mime
View raw message