[EMAIL PROTECTED] wrote:
<snip/> > I see where you're coming from, but I don't think you have to worry. > The dependencies would be isolated to a single method > (getNavigatorForObject I think is what I proposed calling it). If I > used the java.lang reflection classes, then this dependency would be > invisible even to the compiler. Well, using reflection makes it less of a concern to me. I'd hate to have to keep the other object models around just to keep the compiler happy. > You could then subclass BaseXPath (renamed) exactly like you already > are, and you could even include the source code in your project. > > The thing is, the "dependencies" right now is exactly one dependency > -- which Navigator to instantiate? -- and it's IMHO more confusing to > have four extra nearly-empty subclasses than to have a slightly > smarter superclass. > > I suppose it would be possible to split the dependent method off into > its own subclass, but I don't see a compelling use case for that. > Using your own object model would be no problem. Can you spin another > use case, or is it just a general sense of unease? It doesn't feel like a very clean OO design to me. I prefer to have abstract classes as a base class if I expect it to be subclassed. But if you and others feel differently, I won't object. Since you are using reflection and the dependencies are isolated to a method I can override, my key concerns are addressed. Thanks. _______________________________________________ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
