Jim & Jim:
Sounds like you might want to look at Anti-Patterns. This is a great
resource.
Patterns are great, and we all use them if we know it or not. Jim P.s
solution is a pattern of sorts too.
Thor HW
----- Original Message -----
From: "Jim Bailey" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 04, 2000 12:05 PM
Subject: Design patterns (Was: static initialiser block in JSP page)
> 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
>
===========================================================================
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
