Craig is right about all the advantages. OOD is wonderful for all these
reasons.
The one disadvantage is that it takes experience to break your objects up
correctly. Often times projects which use OOD go over budget and over
schedule. This is not due to OOD, but rather to the fact often times the
people implementing an OOD design are inexperienced and make all the classic
mistakes. Then after they fail they don't use OOD again since the experience
leaves a bad taste.
I always use OOD on my projects, but OOD must be tempered with schedule and
the experience of the people in the project. It takes expereince and
understanding both of THE PROCESS you are building and OOD without both OOD
can be difficult to implement successfully.
To best use OOD often times it is best to start with a well designed core
and expand from there. I would recommend looking at struts as an example of
this
Overall: For more on this topic see:
http://www.jspinsider.com/jspbuzz/dec2000/buzz_12_19_2000.html#topic
Casey Kochmer
[EMAIL PROTECTED]
>From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>Reply-To: A mailing list about Java Server Pages specification and
> reference <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: JSP and OOD
>Date: Fri, 12 Jan 2001 14:44:36 -0800
>
>Tim Hengst wrote:
>
> > Peter Bishop wrote:
> >
> > Of course, I would also encourage you not to put Java code in your JSP
>pages
> > in the
> > first place (beans and servlets are a better approach, IMHO) ... but
>that's
> > a
> > different issue.
> >
> > Can this become a discussion topic? What are the
>advantages/disadvantages
> > of keeping the Java code encapsulated in beans and servlets?
> >
>
>The biggest disadvantage is increased complexity -- although this is not as
>significant on a large application -- especially as you are first setting
>the app
>up. Everything else is an advantage.
>
>In my experience, the most important issue for long-term maintainability of
>a web
>based application is to separate the presentation logic ("how does this
>application
>look and feel to a user?") from the business logic ("what does this
>application
>actually do?"). What tends to happen over time is that things change:
>
>* You do a web site remodel to refresh the look and feel
>
>* You add a new database back end to increase capacity
>
>* You switch from JavaBeans for business stuff to EJBs
>
>* You suddenly face the need to integrate a bunch of XML-formatted
> data into your environment
>
>* You have to adapt to a distributed application server because
> your app has become popular and business-critical
>
>and what you are after is minimizing the impacts of those changes. When
>you have
>things appropriately separated, you can do things like a web site remodel
>with
>little or no impact on the underlying business logic. Likewise, you can
>fundamentally change how the back end functions operate -- but as long as
>they are
>hidden behind JavaBeans the provide access to the required information, the
>web
>pages themselves need to change very little. These kinds of changes are
>*much*
>more difficult to make if everything is all mixed together.
>
>Other advantages to separation are also of interest:
>
>* You are not stuck doing everything on one server -- if need be,
> you can put the presentation stuff on one box and the business stuff
> on another -- with the database on a third, if appropriate -- and scale
> each tier individually to meet changing demands.
>
>* Mixing presentation and business logic means you need someone
> reasonably good at both HTML and Java to create your app. Have
> you had much luck finding people that are good at both those things?
>
>* Separating presentation logic and business logic means you can
> leverage the skills of page designers and Java developers separately --
> people who may not be good at, or actively dislike, the other
>discipline.
> It also allows each group to utilize tools focused on their particular
> technologies, without having to worry much about the other side.
>
>* Application architectures and designs based on a strict separation
> of concerns tend to be technically better, with clearly articulated
> interfaces between the layers.
>
>The same basic issues were evident when people started building complex
>client-server GUI based applications. The solutions then were pretty much
>the same
>-- and popular web application frameworks (like Struts) have even adopted
>the
>Model-View-Controller (MVC) paradigm that was first popularized in such
>application
>designs.
>
>None of this matters very much if you are writing a simple "guest book"
>type of
>application. These things matter a *lot* if you're designing an Amazon.com
>type
>application system. Even if you think your app is currently closer to the
>"guest
>book" level of complexity, where is it likely to be in a year or two? That
>is what
>you should architect for now. Because, once the basic architecture is in
>place, it
>is *very* difficult to change later.
>
> >
> > Tim Hengst
> > Tampa
> >
>
>Craig McClanahan
>
>===========================================================================
>To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
>JSP-INTEREST".
>For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
>DIGEST".
>Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
