[jdom-interest] making SAXOutputter extensible

[William Krick]

You can always use encapsulation instead of inheritance.  Create you own
class that includes an instance of the SAXOutputter as a member.  Then you
write a bunch of trivial wethods for your class that call the same named
methods of the instance, passing the parameters and returning the results.
It's essentially a fancy wrapper.  You can then add any new functionality
you want.  It's not always the most efficient implementation but it usually
works.  The main problem is when you have methods that take a SAXOutputter
as a parameter.  As your new class isn't extended from SAXOutputter, it
won't be compatible with the method signature.  This sort of problem makes a
really good case for more widespread use of Interfaces.

If encapsulation isn't an option, you can always take the source for
SAXOutputter and modify it to create your own class (using a different name,
of course) and submit it.  If it turns out to be useful to other people,
maybe it will be added to the JDOM package.

...
Krick

> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]On Behalf Of Jason Hunter
> Sent: Tuesday, January 06, 2004 3:49 AM
> To: PJ Fanning
> Cc: 'jdom-interest at jdom.org'
> Subject: Re: [jdom-interest] making SAXOutputter extensible
>
>
> Any time you make internal fields of a class like SAXOutputter protected
> or public, that's a promise not to change their names or behavior in the
> future lest we break people's code.  That eliminates the benefits of
> encapsulation and is a larger promise than I think we should sign up
> for.  The real solution then is for you to just take advantage of the
> source that's distributed and make the changes yourself.  That way at
> least you understand that your code depending on SAXOutputter internals
> may break in future releases.
>
> -jh-
>
> PJ Fanning wrote:
>
> > Hi,
> > I've got a small enhancement request.
> > I'd like to produce a subclass of SAXOutputter that destroys
> the document as
> > it outputs it, in order to conserve memory. The current
> codebase does not
> > allow you to extend this class. Specifically, most of the members and
> > methods are private. If they were marked as protected and the
> NamespaceStack
> > class marked as public, I would be able to achieve what I'm
> looking to do.
> > If there are no objections, I could forward modified versions
> of these two
> > classes to the list.
> > _______________________________________________
> > To control your jdom-interest membership:
> >
> http://lists.denveronline.net/mailman/options/jdom-interest/yourad
dr at yourhost.com
>

_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com