----- Original Message -----
From: "David Peterson" <[EMAIL PROTECTED]>
> On Thu, 2002-03-21 at 09:25, James Strachan wrote:
> > ----- Original Message -----
> > So we could have
> >
> > org.jaxen.BaseXPath
> > org.jaxen.dom.XPath
> > org.jaxen.dom4j.XPath
> > org.jaxen.jdom.XPath
> > etc.
> >
> > Then when folks are working with one model in their code they can use
the
> > import to denote which XPath object they use.
> >
> > Then if folks wanna be generic the can use (say)
> >
> > org.jaxen.generic.XPath
> >
> >
> > BTW I find DOMXPath, Dom4jXPath, JDOMXPath idea all very ugly class
names -
> > I far prefer to use package names to namespace these things. The use of
the
> > name XPath for all different model-centric object is similar to most XML
> > models naving an Element and Document type - they don't call them
> > JDOMElement or DOMDocument etc.
I guess this one is pretty subjective...
> My personal preference would be:
>
> org.jaxen.XPath (abstract superclass)
> org.jaxen.dom.DOMXPath
> org.jaxen.dom4j.Dom4jXPath
> etc...
>
> or perhaps even
>
> org.jaxen.XPath (interface)
> org.jaxen.BaseXPath (abstract superclass)
> org.jaxen.dom.DOMXPath
> etc...
>
> Then Jaxen could be used as follows:
>
> import org.jaxen.*;
> import org.jaxen.jdom.*;
> //...
> XPath xpath = new JDOMXPath("//foo/bar");
> List nodes = xpath.selectNodes();
>
> This follows the pattern established by the Collections API, where the
> variable type is the interface (List, Map, Set), but the implementation
> is concrete (ArrayList, LinkedList, etc). You could do the same thing
> using BaseXPath, of course, but it just feels wrong...
>
> I'll agree that the names don't render to be terribly attractive, but my
> personal philosophy of design is that the top of the hierarchy should be
> named for what it is - an XPath - and implementation-specific subclasses
> should be descriptive. You wouldn't design an object hierarchy for
> animals like the following:
>
> org.nature.BaseAnimal;
> org.nature.dog.Animal;
> org.nature.cat.Animal;
> org.nature.hippo.Animal;
>
> That's just bizarre.
>
> Each of the OM-specific implementations share most of their code - a
> single method is overridden - so it makes sense that the superclass that
> has all the methods that get used declared should be the primary
> interface used on a daily basis. I wouldn't feel comfortable doing that
> if its name was BaseXPath.
>
> But maybe that's just me.
You've got a point and I hear where you are coming from. Though I remember
reading in some good book that I've forgotten the name of right now (and am
travelling so can't rifle through my bookcase) a good Java-OO pattern of
simplifying classnames wherever possible and if possible hide some
implementaiton detail from its name. e.g. all the major DOM-ish APIs have an
Element and a Document rather than a JDOMDocument etc.
Maybe another way of skinning the cat is to name each concrete XPath
implementation XPathImpl?
org.jaxen.XPath
org.jaxen.foo.XPathImpl
XPath xpath = new XPathImpl( "//xyz" );
We could maybe have a helper method in XPath or a new helper XPathFactory
class that could create new instances for each model - though I can't think
of a clean naming convention. e.g.
XPath xpath = XPathFactory.domXPath( "//foo" );
XPath xpath = XPathFactory.dom4jXPath( "//foo" );
XPath xpath = XPathFactory.exmlXPath( "//foo" );
XPath xpath = XPathFactory.jdomXPath( "//foo" );
XPath xpath = XPathFactory.genericXPath( "//foo" );
Though its still a little ugly IMHO.
I guess it comes down to, do people need to use the abstract base class /
interface of BaseXPath / XPath in their code or are users happy using one of
the various concrete implementations, not caring too deeply over what the
implementation means other than the package in which it resides (if that all
makes sense ;-)
James
_______________________________________________
Jaxen-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jaxen-interest
