On Thu, 2002-03-21 at 12:02, James Strachan wrote: > > 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.
I also remember being taught that a good class/variable name is worth a thousand words of documentation :) > 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" ); While it gets around the problem of having multiple classes with the name 'XPath', it's still not very attractive, and you loose information about exactly what the class is doing. To me, if the class's name is 'Dom4jXPath', it is quite clear that this is an implementation of XPath using Dom4j. XPathImpl tells me nothing. Keep in mind that the line of code that instantiates the XPathImpl could be several hundred or thousand lines removed from the import statment. It's a pain in the butt having to scroll back to the top of the document to figure out what particular XPathImpl has been imported - especially if it's someone else's code. > 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. Very ugly, plus we've now got an unnecessary class with concrete ties to each of the currently supported object models. Yuck. > 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 ;-) One example of where it would be valuable to encourage people to use the abstract base class/interface is XPath 2. Although XPath 2 is huge, it is largely backwards-compatible with XPath 1. Lets say you've built an application that makes heavy use of Jaxen to parse through XML documents. A customer requests a feature that would be incredibly easy using XPath 2, but quite difficult with XPath 1. Since the Jaxen team has recently finished their implementation of XPath 2, that would seem to be the easiest path. But there is XPath 1 code all through the application, with references to org.jaxen.dom.XPath everywhere. But the new DOM implementation available at org.jaxen.v2.dom.XPath can't extend the original one because they of course all have to extend the org.jaxen.v2.BaseXPath abstract base class. On the other hand, if there is a top-level class/interface that is the standard type used for variables/references - ie org.jaxen.XPath - throughout the application, then org.jaxen.v2.XPath2 can extend it, meaning that all/any implementations of XPath 2.0 can be passed to objects supporting org.jaxen.XPath. Then the extra features can be integrated very easily - there's probably not even any casting required for most simple cases. Cool, huh. Anyway,there's another two cents to add to your collection. Chow for now, David _______________________________________________ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
