OO design in servlet design question

[dave]

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 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?
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.720 / Virus Database: 476 - Release Date: 7/14/04

[Ryan Stewart]

"dave" <go******************@nowhere.com> wrote in message
news:0L*****************@nwrdny03.gnilink.net...

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 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?

There are many possible answers to this. Probably the most basic one is that
it's rarely desirable to give up maintainability in favor of efficiency.
Besides, OOD doesn't claim to be efficient.

[Sampsa Sohlman]

dave wrote:

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 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?

I'm trying to reach good OO design with my NetForm web application
framework (http://netform.sohlman.com). It has inhertance, reuse,
delegation etc. It is not used very big scale, but let's see.

- Sampsa

--
-------------------------------------------
// Sampsa Sohlman //
// My email can be found on my homepage //
// http://sampsa.sohlman.com //
-------------------------------------------

[iamfractal]

"dave" <go******************@nowhere.com> wrote in message news:<0L*****************@nwrdny03.gnilink.net>...

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

www.EdmundKirwan.com - Home of The Fractal Class Composition

[Raymond DeCampo]

dave wrote:

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 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?

Dave,

Forget about your servlets for a minute. Now, design and write all of
your business logic code as a service library. Use as much OO as is
appropriate. (These will be your models and controllers.) Now write
your servlets as simple wrappers that invoke the business logic in the
servlet context. Use a templating engine like JSP, velocity, XSLT to
create the HTML responses. (These will be your view.)

Using a framework like Struts can help you with this task as well.

HTH,
Ray

--
XML is the programmer's duct tape.