Re: OO design in servlet design question
Date: 07/17/04

Date: 17 Jul 2004 04:35:26 -0700

"dave" <> wrote in message news:<0LPJc.9028$>...
> One thing i'm finding very quickly as my servlets become more logically
> condensed, is that an "object" in the sense of "object oriented design"
> becomes restricted to a "webpage/servlet".

How so? I've misunderstood something here.

At its most simple, a servlet is a class that inherits from
HttpServlet. Yes, there are restrictions on your user I/O and your
threading model, but it remains just a class. To process a particular
doPost(), your HttpServlet subclass will start talking to other
classes in other packages in your system: "oject in the sense of
"object oriented design" applies equallys to all instances of those
classes. It's not restricted to the HttpServlet subclass object.

> How do you enterprise programmers
> manage to effectively incorporate OO design (in the architecturally broad
> sense) within an application that, perhaps more efficiently benefits in
> performance from one servlet rather than 12 servlets performing the logical
> functions of what 1 servlet spaghetti coded can do?

OO design, in the architecturally broad and any other sense we care to
mention, is flexibility through variance encapsulation. To make your
sevlet more OO, just make it flexible. I've always found that the best
way to encapsulate variation is to have an alternate implementation
always in mind when performing the design. The obvious choice (without
knowing what your servlets actually do) here is to design your servlet
so that it's also runnable from a command line. Or from a local GUI.
Even if you don't actually implement the alternative, it concentrates
the mind wonderfully on the interfaces your system exposes rather than
the user-access implementation. These interfaces then encapsulation
the user-access variations, and Robert is your father's bruvva.

.ed - Home of The Fractal Class Composition