Jeffrey Schwab said:
Come to think of it, there's probably no good reason at all for one
class to extend another in modern Java except for brevity in simple
cases, e.g. an anonymous inner listener class extending an adapter.
Oh, absolutely disagree. Here's a hierarchy of classes:
java.lang.Object
extended by javax.servlet.GenericServlet
extended by javax.servlet.http.HttpServlet
extended by uk.co.weft.maybeupload.MaybeUploadServlet
extended by uk.co.weft.htform.Servlet
extended by uk.co.weft.htform.WithExceptionHandlerServlet
extended by uk.co.weft.domutil.DocPage
extended by uk.co.weft.domutil.TransformPage
extended by uk.co.weft.domutil.CachedPage
(
http://www.weft.co.uk/library/jacquard/documentation/uk/co/weft/domutil/CachedPage.html)
I won't comment on the first three, since they aren't mine.
uk.co.weft.maybeupload.MaybeUploadServlet deals with file upload; in all
other respects its a straight plug-in replacement for Sun's HttpServlet
and can be used transparently in conventional Servlet code wherever file
upload is necessary. It is, of course, abstract.
uk.co.weft.htform.Servlet is the base layer Jacquard Servlet which does
basic configuration, and handles converting all the namespaces involved in
an HTTP service into a single namespace. It's abstract, too, but it
handles a lot of useful stuff for things higher up the tree.
uk.co.weft.htform.WithExceptionHandlerServlet provides pluggable exception
handlers for things further up the tree. It's abstract too. This
functionality could have been built into uk.co.weft.htform.Servlet, but
when it was first released it was experimental, so it seemed better not
to.
The htform Servlets were all built on the model that you print things to
the output stream as you compute them. This is simple and efficient but it
confuses content with logic and is on the whole not a good thing.
uk.co.weft.domutil.DocPage is a Servlet into which can be plugged a
DocumentGenerator. The DocumentGenerator encapsulates the logic of
whatever is being done and returns a completed org.w3.dom.Document which
DocPage can either print directly or (configurably) transform with an XSL
stylesheet serverside before printing.
uk.co.weft.domutil.TransformPage extends this by allowing which XSL
stylesheet to use for server-side transformation to be selected on the fly
at service time. This includes the possibility of not doing the transform
server-side, but instead offloading it to the client if the client
advertises that it is suitably equipped.
Doing server-side XSL transformation for each service is quite heavyweight.
In order to reduce the load on the server uk.co.weft.domutil.CachedPage
caches generated pages and serves requests from the cache where possible.
So there's a stack of six classes of mine, each of which adds some useful
functionality to its superclass, and in doing so compartmentalises
functionality in the codebase.
Browsing through my code there's a similar stack here:
http://www.weft.co.uk/library/jacquard/documentation/uk/co/weft/xhtmlgen/ImgListItemGenerator.html
and here
http://www.weft.co.uk/library/jacquard/documentation/uk/co/weft/htform/LinkTableWidget.html
while each of the classes in this package
http://fisherman.cvs.sourceforge.net/fisherman/fisherman/src/java/uk/co/weft/fisherman/web/
sits on a ten deep stack of classes, each of which adds some useful
functionality.