This is a little off topic but a very interesting discussion to me.
I don't agree that design patterns limit your problem solving ability.
Patterns are only a tool for describing common programming practices. They
give everyone who uses them a common jumping off point in terms of basic
architecture and more importantly, in terminology. Even with extensive use
of patterns there is always a huge amount of coding that doesn't fit any
known pattern.
As a developer, I would much rather see a state machine developed along the
lines of the State pattern described in the GOF book than the many, mostly
horrible, implementations that I've come across in my 17 years doing
software development. If someone tries to shoehorn a problem into a state
machine that isn't one, that is a different problem. I don't normally see
that though, what I see are state machines that are giant blocks of nested,
hidden gotos. They tend to be completely unmaintainable and end up being
either "don't touch" or "throw away" code. What a relief to see a comment at
the top of some previously unseen code that says "modeled after the GOF
State pattern".
I would love to see more discussion about design patterns and their impact
on JSP & servlet development. J2EE and EJBs are one big design pattern
(unlike javabeans which Sun calls a pattern but is really more of an API
naming convention.) So is the servlet forwarding technique commonly refered
to here as "Model 2" jsp. I imagine that developers are out there creating
many more patterns too.
A final point, one major advantage that Java has over other languages is
that many of the design patterns are either unnecessary since they merely
provide methods of managing complex memory objects that are already handled
quite well by the JVM memory management or they are already implemented in
the collection classes provided by Java 2.
-----Original Message-----
From: Jim Preston [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 04, 2000 2:21 PM
To: [EMAIL PROTECTED]
Subject: Re: static initialiser block in JSP page
(Getting back to the JSP topic.) The other reason that I don't like design
patterns is that, rather than looking at a problem and trying to find the
best solution, people look at a problem and simply find the closest matching
design pattern; if all you ever code with are the specified design patterns,
you've got a very limited toolbox. The original problem, as I understand it,
does not need "the singleton pattern" to solve it. Once you've decided to
move your Hashtable into a bean, you put the originally-desired static
initializer of the Hashtable in the bean, and then use the bean however you
want. This allows more flexibility in how the bean is used and scoped. And
it looked to me like the Hashtable in question is meant to be read-only, so
there shouldn't be any threading issues (in which case, consider using a
HashMap instead, which doesn't synchronize so you'll save some overhead).
--Jim Preston
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
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
