OO design in servlet design question

Discussion in 'Java' started by dave, Jul 16, 2004.

  1. dave

    dave Guest

    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, Jul 16, 2004
    1. Advertisements

  2. dave

    Ryan Stewart Guest

    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.
    Ryan Stewart, Jul 16, 2004
    1. Advertisements

  3. 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, Jul 16, 2004
  4. dave

    iamfractal Guest

    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.

    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.


    www.EdmundKirwan.com - Home of The Fractal Class Composition
    iamfractal, Jul 17, 2004
  5. 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.

    Raymond DeCampo, Jul 17, 2004
  6. Well, for one thing, we don't cram all the functionality into
    the servlet class! There is no efficiency gained by keeping your
    code in a servlet class, and you lose enormously in terms of ease
    of testing and maintainability.

    You can put most of your functionality into classes that can be tested
    outside the servlet environment and greatly speed up your development
    cycle. It will then be easier to observe good OO practice too.

    William Brogden, Jul 17, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.