J2EE Design Patterns

whirlycott writes "In case you're not up to date on what design patterns are, let's do a quick crash course before we jump into a book review on the subject. Design patterns were thrust into the software development mainstream by the book Design Patterns in 1995 (aka the GoF book). A pattern involves three components: first, a description of a generalized recurring problem; second, an abstract solution that is generally accepted; and third, a name for the sake of convenience. Patterns save time and effort by supplying developers with a shared language when discussing common problems. O'Reilly's new J2EE Design Patterns book is a timely, easy-to-read catalog of architectural patterns specific to the J2EE platform." Read on for the rest of whirlycott's review. J2EE Design Patterns author William Crawford and Jonathan Kaplan pages 368 publisher O'Reilly rating 8/10 reviewer Philip Jacob ISBN 0596004273 summary Detailed collection of patterns suitable for beginners or architects alike

If you are working on frameworks, integration projects or system components, it is my belief that you'll almost certainly pick up some ideas from this book. J2EE Design Patterns is organized according to the different layers that you might find in a multi-tier architecture: presentation, business, database, messaging, and others. Consequently, if you're a JSP developer on a project team, youll be able to get some ideas for how to organize your work as well as how to interface it with, for example, controllers, if you're following an MVC framework. Or, if you're integrating various distributed non-Java systems, you'll want to read the chapters on Business Tier Interfaces and Enterprise Concurrency.

Judging by my friends' bookshelves, another popular Java patterns book is Core J2EE Patterns. If you already own this book, you will find that this new offering from O'Reilly doesn't contain as many patterns per se, but seems to go into a greater level of detail describing each pattern and supplementing it with more code samples. A nice feature of the O'Reilly book is that each pattern gets ample coverage in enough detail for you to understand the actual problem, the causes and -- equally importantly -- how to put a solution into place. Each pattern is described using some UML notation and code samples (Chapter 2 contains a UML primer).

One of the problems that I've encountered reading books on the subject is that some steer so deeply into abstraction that they become hard to understand. Others are so stylistically repetitive that trying to read them becomes mind numbing. Fortunately, neither problem surfaced during the time that I spent reading this book. The authors avoided the visual repetition of the traditional Problem / UML / Goal / Actors format that other books follow by moving this type of description into an appendix. That lets the body of the book flow more easily and also supplies the reader with a handy quick reference in the back pages.

Do I have any complaints? Well, this book certainly doesn't suffer from any fatal flaws. But it seems that an acknowledgement of the popularity of certain components could have been included. For example, while specific MVC frameworks, like the ubiquitous Struts, were mentioned, Object-Relational mappers were not; I read some of the chapters and winced at the code samples that manipulated SQL strings and felt grateful that I'm using the wonderful Hibernate O/R mapping engine. Of course, for various reasons, some readers won't be able to use tools like these, and a book about patterns has to maintain a certain level of abstraction in order to maintain any lasting credibility. But the section on Object-Relational Mapping doesnt even mention that a class of tools exists without the use of EJB CMP (Container Managed Persistence). Thats a real shame, because manually moving data from the object world to the relational world and vice versa is time-consuming and error-prone (and frequently unnecessary) work.

It's a good book, with 285 pages of text and 53 pages of appendices. I've owned it for four days, and I've already managed to steal some of these ideas for the projects I'm working on.

Philip Jacob works for Eyeglasses.com. You can purchase J2EE Design Patterns from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

hello room

[Anonymous Coward]

hello room

Re:hello room

[Anonymous Coward]

whats going on in this reply

Re:hello room

[Anonymous Coward]

hello room mate

Re:hello room

[Anonymous Coward]

tie me kangaroo down, mate!


yes im gay

Re:hello room

[Anonymous Coward]

hello room mate with me

Re:hello room

[Anonymous Coward]

will you mate with me? sporty, clean and handsome in a rugged way. geek, of course.

Re:hello room

[Anonymous Coward]

hello room mate with me suddenly

Re:hello room

[Anonymous Coward]

hello, room ? mate with me suddenly !!

Re:hello room

[Anonymous Coward]

HELO room. "Sorry, I lost you at HELO."

holy crap

[Evil Adrian]

everything is italicized! yay editors!

Re:holy crap

[Anonymous Coward]

Cram it you nit!

fp!

[Anonymous Coward]

first post!

Here's a design pattern:

[deadlinegrunt]

I call it the tag delimeter pattern.

Re:Here's a design pattern:

[tomknight]

Yeah, but the front page looks so pretty now...

Tom.

Still Not Real Clear on Design Patterns...

[ViolentGreen]

So is a Design Pattern just a clearly defined common problem and a general, language-independent, algorithm for solving the problem?

I have never heard that term before...

Re:Still Not Real Clear on Design Patterns...

[Evil Adrian]

I believe it's specific to OOP... basically, "design patterns" are about taking common problems, finding a pattern, and coming up with a (generalized) solution dealing with composing and managing objects, and ways of coordinating the objects.

Did that make sense? I haven't had enough caffeine today.

Re:Still Not Real Clear on Design Patterns...

[humandoing]

That seems to be the general take on the matter.

For example, the Gang of Four book (Design Patterns: Elements of Reusable Object-Oriented Software) has a ton of patterns that it discusses, and the language that it happense to use to illustrate the solutions to these "problems" is in SmallTalk... Not a lot of people were using Java in 1995, and I was still in grade 10 programming Pascal ;). It has 3 broad categories of patterns that it defines as Creational, Structure, and Behavioral...

For example, one of the Behavioral patterns defined in the Book is "Iterator". This is defined as "...a way to access the elements of an aggregate object sequentially without exposing its underlying representation". This is an extremely simple example, but it is clear that this is a common problem, with common solutions, implemented in dozens of programming languages (eg: java.util.Iterator).

Hope thats informative!

Re:Still Not Real Clear on Design Patterns...

[j3110]

Basically there are common themes in problems, and patterns help with the theme of the problem, not the problem itself. For example, I could want to centralize and pool objects for some reason. The design pattern to solve this kind of problem is basically to make constructors private and use "Factories" (static member functions) that return the objects using static data to keep track of them.

Pattern can be a misleading word because it has too many meanings. You could interpret design pattern as commonalities in design or as a design template (like sewing involves working off of a pattern). It's closer to the first definition than the second.

Just don't follow a pattern that you don't understand exactly how works. You'll end up with more problem than solution. That's why I usually don't like pattern books. Unless you read them like you would a chess book and try to figure out how/why it's a mate-in-2, then you aren't going to get any real benefit from them. Chances are if you can understand how/why, then you didn't need the book to begin with. There's a slim chance that you'll run into a problem and have not used a more optimal solution because you didn't read one of these books, but I don't think it's all that great. Design patterns should be taught in school as exercises for the common problems they'll run into, not really a place to start when trying to solve a problem.

Re:Still Not Real Clear on Design Patterns...

[Space cowboy]

Pretty much. For example, the 'Singleton' pattern is where you may have a single resource you want to share between multiple objects, without making a copy of the interface to that resource. Typical behaviour is to have a static getInstance() method which checks to see if a static object already exists and returns that instead of a new object. The contructor is usually kept private/protected to enforce the pattern.

The first time you read a "patterns" book, you'll sit thinking "but that's obviously how you do it". The advantage is that the pattern books generally spell out *why* it's the best solution, and you can then apply that knowledge in other situations.

Personally, I found 'Design patterns' hard reading. The concepts weren't hard, but the prose was painful. 'Patterns in Java' (not to recommend it too much - I mentioned it in another post as well :-) is far more readable, but there's a lot of crossover.

Simon.

Re:Still Not Real Clear on Design Patterns...

[butane_bob2003]

Not a algorithms exactly, design patterns are described by class diagrams. Design patterns generally describe behavioral, structural and creational aspects of objects. Algorithms are concrete implementations of solutions to problems.

Re:Still Not Real Clear on Design Patterns...

[Mikkeles]

Software design patterns are an offshoot of Christopher Alexander's architectural patterns as described in his book: A Pattern Language. (E.g., reviewed here and here.)

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. -- ChristopherAlexander

Re:Still Not Real Clear on Design Patterns...

[soundofthemoon]

The term pattern may not be the best choice of a word to describe the concept, but it comes close. Just like you can have a pattern for a garment and then use that pattern to make a shirt from any type of fabric, design patterns supply standard solutions that can be used to solve common problems, but in an easily customizable way.

When the Gang-Of-Four book Design Patterns first appeared, there was a lot of talk about it at OOPSLA that year. I'd been a lucky witness to the birth of the concept a year or two previously. There was a lot of talk among Smalltalkers at Apple and everyone was reading Christopher Alexander's book A Pattern Language. By the time the Gang published the book, the meme had mutated and most people didn't get the underlying concept.

The OOP software community was struggling for a metaphor for understanding patterns. Many people latched onto the idea of the chip catalog. Like you can grab a catalog for SSI and LSI chips and find the OR gates or shifters you need, wire them together and voila you have a circuit board. Programmers want that kind of reuse, and are tired of having to reinvent the wheel every time they want to go for a ride.

But patterns can't be reused in the same way that chips can. I think API calls are a more equivalent concept to chips in a catalog. Patterns are more like things like "power suppy" or "transmitter" or "step motor". They exist in the design space above the chip or API call. They show how to use the more granular pieces to assemble higher-level solutions.

Working in Smalltalk, some of us noticed there were ways we would use classes, objects, inheritance, and references that we would repeat over and over. We began to make up names for them so they were easier to talk about. I remember encapsulator was one of the early names that was used a lot (it's an object that intercepts all references and messages to another object).

Design patterns provide a vocabulary for talking about, and more importantly thinking about, the ways that we've learned to solve common problems. This shouldn't be surprising, since the origin of the term was something called a pattern language, and languages have vocabulary. If you don't have a word for something, it's hard to reason about it. Try thinking about an arrangement of buildings if you have no concept of "community" or "town". Patterns supply the concepts for reasoning about design problems.

Re:Still Not Real Clear on Design Patterns...

[mark_lybarger]

i'd beg to differ that these are oop specific. there's design patterns all over the place. there's a problem, a common solution, and general name.

take freeway exists. there's different freeway exiting implementation depending on the problem at hand. very high traffic, you'll see the four circles around the exit. lower traffic, and possibly just straight exit and entrance ramps w/out the loops.

Re:Still Not Real Clear on Design Patterns...

[KillerCow]

So is a Design Pattern just a clearly defined common problem and a general, language-independent, algorithm for solving the problem?

Remove "clearly defined." Sometimes moving from the problem to the pattern is not clear, but going from the pattern to the problem should be clear.

Change "algorithm" to "model."

Definitions from Google

Re:Still Not Real Clear on Design Patterns...

[Evil Adrian]

I would argue that "freeway exit" represents an abstract object, of which are derived different concrete types... ;-)

Re:Still Not Real Clear on Design Patterns...

[EastCoastSurfer]

I believe it's specific to OOP

OOP Design patterns are the only patterns specific to OOP :)

Deisgn patterns were first developed by an architect named Christopher Alexander. In his book A Pattern Language he used them to help present common design problems and solutions to other architects. Patterns are as much as a best practices book as they are a communication tool.

Re:Still Not Real Clear on Design Patterns...

[EastCoastSurfer]

Chances are if you can understand how/why, then you didn't need the book to begin with.

I beg to differ. Design patterns are not just about showing problems and solutions. They are also to help for a common vocabulary among the people who use them. Instead of me having to explain that I used a pool of small objects with intrinsic and extrinsic state to solve this problem I can just say Flyweight.

Design patterns should be taught in school as exercises for the common problems they'll run into, not really a place to start when trying to solve a problem.

Design patterns are the perfect place to start solving a problem. As you break a problem down into smaller parts you can start solving pieces just by applying a pattern. If everyone on the team is knowledgable of patterns the "simple" parts of the architecture can be dealt with quickly. This leaves more time to work on the complex architecture issues.

Re:Still Not Real Clear on Design Patterns...

[RetroGeek]

I remember encapsulator was one of the early names

Hmm, I have used this, but I always called it a wrapper.

That is it wraps around another more complex class (or classes) to provide an easier (and usually with pre-defined behaviour) interface.

Re:Still Not Real Clear on Design Patterns...

[soundofthemoon]

The 80s use of the term encapsulator was an object that not only wrapped another, but mimiced it's interface. So externally you couldn't tell you were using an encapsulated object. It was a way of adding functionality by composition rather than inheritance. The trivial example is an encapsulator that logs all messages, which is perhaps useful for debugging. What you are talking about is more like a Facade pattern.

Re:Still Not Real Clear on Design Patterns...

[RetroGeek]

So externally you couldn't tell you were using an encapsulated object.

Isn't that like "extending" the class?

Of course you must then instantiate the extended class to use it.

Facade pattern

Sigh....

I wish we as an industry could just STOP coming up with new names for the same old things.

Re:Still Not Real Clear on Design Patterns...

[NickFitz]

Isn't that like "extending" the class?

He already said not:

adding functionality by composition rather than inheritance

Re:Still Not Real Clear on Design Patterns...

[GreggBert]

Anyone who thinks design patterns are only applicable to OOP should really read the book "A pattern language - Towns, Buildings, Construction" by Alexander, Ishikawa, Silverstein, Jacobson, King and Angel (c) 1977 (ISBN 0-19-501919-9). It is the second in a trilogy of books on Patterns, what they are, how to recognize them and how they are applicable to municipal planning and building systems.

It's pretty interesting to see where some of these modern day architects got their ideas and that patterns occur in things all around us in our everyday lives.

It's also required reading for anyone REALLY serious about playing Sim City.

Re:Still Not Real Clear on Design Patterns...

[RetroGeek]

Note the quotes around extending.

If you are using the same method names to do the same functions, albet with added functionality, then in effect you ARE extending the class. Just not formally.

Moreover it could be argued that this adds to the memory footprint and to processing time, as the new class must be instantiated, then it in turn must instantiate the class it is a mimic for.

Re:Still Not Real Clear on Design Patterns...

[NickFitz]

then in effect you ARE extending the class

From a pragmatic point of view, yes. I would prefer to say that the class has the same method signature. Note that, for example, an encapsulating class of this kind could not be used in the same place as an instance of a superclass of the wrapped class. So taking a simple example:

class Ape() {
...
}

class Bonobo extends Ape {
...
}

class BonoboWrapper {
private Bonobo wrappedBonobo;

public void BonoboWrapper(Bonobo myApe) {
this.wrappedBonobo = myApe;
}
}

then a method expecting an Ape would work with a Bonobo instance, but not with a BonoboWrapper instance. As to which is more appropriate, it depends on the circumstances. Better minds than mine have debated this extensively here and here, so I'm not going to commit myself and look even more stupid :-)

(Sorry about losing the indentation on the code; today's too short to work out how to get round /.'s formatting vagaries.)

Re:Still Not Real Clear on Design Patterns...

[RetroGeek]

Better minds than mine have debated this extensively

Mine too :-))

There are subtleties to this OO business....

Another useful patterns book

[Space cowboy]

though not J2EE (only "standard" Java) is 'Patterns in Java', coming in a few volumes, though I rate the first one highest, the other two get increasingly abstract/uncommon. When does a pattern become an occurrence ...

Simon

hear hear

[m0smithslash]

Conincidently a co-worker/cow-irker of mine just borrowed my copy. The nice thing about it is it gives some names to ideas a lot of us already use, making it easier to talk about them.

Most popular Java pattern

[Anonymous Coward]

is the buzzword pattern.

Maybe I'm getting old, but at one time we just wrote systems that worked without regard to what was in fashion at the time.

Scottie: Cap'n - I confluckulated and strutified the entity beans, and I'm given 'er all she's got!

Re:Most popular Java pattern

[Anonymous Coward]

I've used some of these systems that "just worked." You're a fucking delusional liar if you think your glory days of software were better.

Re:Most popular Java pattern

[FortKnox]

Patterns aren't a "fashion". In fact, I bet you wouldn't have commented on this if it concerned C++ patterns.

That's right, I'm accusing you of being a COMPUTER LANGUAGE BIGOT!

Can't we all just get along?!?!

Seriously, though. Patterns are nice to have for architects, and since they are 'reused' its easier for developers to "create" the ideas the architect develops.
And patterns have been around too long to be considered a 'fad' (things like Extreme Programming is what I'd argue is/was a 'fad').

If you are an XP lover, I don't mean to start an arguement, its just how I see the field...

Re:Most popular Java pattern

[Anonymous Coward]

Your systems were also almost certainly written by a team of 4 and had no requirements of 100% failover, etc. Or maybe not, but either what this post would make one assume as such.

Pretty typical post of the typical Hippy style, Dogmatic Unix Nerd ... and as much as I can respect those types, it is easy to disregard them when talking about $100 million systems, such as the J2EE /struts/pattern driven project I am currently on. Yeha ... 200+ developers, 4 time zones ... try that in perl.

Re:Most popular Java pattern

[Enonu]

There are proper ways to handle common problems when writting server-side Java applications. If everybody would simply code using these "design patterns" then understandability and maintainability would sky rocket, not to mention the fact that your solution will just plain work.

In other words, don't roll your own when the hard work of others is out there and precisely documented for you to use. IMHO, this is part of the difference between a software-engineer and your run-of-the-mill coder.

Re:Most popular Java pattern

[wthynot]

That's right, I'm accusing you of being a COMPUTER LANGUAGE BIGOT!

Can't we all just get along?!?!

As always, a great way to kick off a long and meaningful friendship.

Re:Most popular Java pattern

[Safiire Arrowny]

Yeah, he was saying that Java is like a buzzword, not design patterns.

Re:Most popular Java pattern

[Anonymous Coward]

But you're old and stupid so you wouldn't understand all of these formal, educated approachs to software development.

Re:Most popular Java pattern

[sfjoe]

Maybe I'm getting old, but at one time we just wrote systems that worked without regard to what was in fashion at the time.

Yes, but a horse cart is far less complicated than a Porsche.

Re:Most popular Java pattern

[EastCoastSurfer]

C++ patterns.

Maybe the original poster wasn't talking about patterns, but *Java* patterns. Patterns are generally supposed to be implementation independent. Personally, I would be much quicker to read a book called Distributed Architecture Patterns than J2EE patterns. In my mind all the patterns in the J2EE book should be subsets of the larger concepts presented in a Distributed Architecture book.

Re:Most popular Java pattern

[yintercept]

Patterns are nice to have for architects

We just skipped the important debate about whether or not "architecture" is the right metaphor for most IT. Most IT involves systems that evolve, as such they are generally better served with a flat structure where multiple people have input on the design and direct responsibilities in regard to implementation.

The architect metaphor is from the construction industry. In construction, the architect is pretty much elevated one step above God. The metaphor demotes everyone else to the status of code monkey. While such social patterns might be needed in a packaged software environment, I think it is better for most companies to have a flatter political hierarchy where multiple people have input on design and have their own areas of responsibility.

Regardless, design patterns have a great deal to offer in flatter structures, as they give people greater ability to talk about design issues.

Re:Most popular Java pattern

[Anonymous Coward]

Yes, it speaks volumes when you say your J2EE/struts/pattern driven project costs $100 million and has 200+ developers. Of course it does! Too bad you don't realize that it's a very bad thing that this technology is completely blowing your budget. That's the point! To spend that much on a system could mean nothing other than total disaster.

And what does 100% failover have to do with cost anyway? I've delivered a dozen systems with 100% failover in the securities industry for well under $1 million each (most under $100K). Big fucking deal. It's called proper DESIGN. It sure beats rebooting the fucking java appserver twice per day to reduce memory or whenever it crashes for no good reason.

Re:Most popular Java pattern

[Tablizer]

Maybe I'm getting old, but at one time we just wrote systems that worked without regard to what was in fashion at the time.

Shhhhhhh! Fad-grabbing is the best jobs program we have right now. Companies pay us to rewrite programs/systems of paradigm X into paradigm X+1 because they fear that their competitors will jump past them using the latest buzzware that looks so shiney in the brochure. Rationality and jobs are not necessarily related.

Design Patterns...

[Valar]

I've never really understood the point, because 'commonly ocuring problems/projects' are, by definition, commonly occuring. People who have spent any amount of time as a junior developer or a computer science student have been handheld through these types of scenarios about 1,000 times before they actually get to design anything important on their own. Beyond that, you're never going to be able to account for the wide varieties of situations that occur in the real world with one book full of templates. Maybe someone can sell this point to me? :)

Re:Design Patterns...

[Evil Adrian]

As an owner of the original Design Patterns bible, I can assure you, they account for an incredible variety of situations that occur in the real world.

As it relates to OOP, it is like understanding how a car works. If you can grasp how a car works, you can generally fix any type of car.

There are many different problems out there, but if you recognize the problem (as it fits to a particular design pattern), you can use a specific OOP design pattern as a model for a solution.

If you spend some time learning the patterns, you save a lot of time creating a solution when a familiar problem presents itself.

Re:Design Patterns...

[joib]

Uh, I don't agree with your point. With the same logic you could say that introductory (and references for that matter) programming books are also unnecessary, since these contain stuff that "every CS undergraduate" should know. Well, you have to start somewhere and build on that. And while your memory might be perfect, mine certainly isn't, so I feel it's very helpful to have those books available.

Re:Design Patterns...

[Anonymous Coward]

One of the great things that come out of using design patterns is that designers/coders get a common nomenclature to use when communicating. It is a great save of time to be able to refer to something as "composite pattern" instead of "you, know that piece of code that we use to manage hierarchical structures of objects and sub-objects, where some of the sub-objects can contain other sub-objects"

Re:Design Patterns...

[GoofyBoy]

>you're never going to be able to account for the wide varieties of situations that occur in the real world with one book full of templates.

Its a pattern, not a final soluton. Use it as a starting point/a headstart.

>Maybe someone can sell this point to me? :)

Number one reason I like patterns is because it gives me a warm feeling that someone already had to suffer through the same dammed problems as me.

Re:Design Patterns...

[haystor]

If these patterns are truly recurring, why can't I just do something like:

Factory f = new Factory();

Any good programming language should be extensible to handle frequently recurring constructs. Java does not.

That's right, this is a LISP post. We have macros and a whole host of other things you don't, nyah nyah nyah.

Oh yea..LISP is dead. More like, "LISP is a dead end where programmers go to never return to their original language."

Re:Design Patterns...

[Evil Adrian]

If you think you are "extending" the LISP language by building functions... ha. Call it what you want but you're doing the same thing Java programmers do, you're writing a program. The only difference is the methodology (functional vs. procedural).

LISP isn't dead -- it's just another language. Arguing what is the "best language" is retarded, because there is only a "best language" relative to a specific problem. LISP may be great for writing AI routines, but no one sane would use it to write a cross-platform application with a GUI.

Re:Design Patterns...

[haystor]

The difference between extending the language in java and LISP is that the LISP extensions are indistinguishable from the language itself.

There are many things that just can't be done in java that require workarounds. Try using the + to add an integer to an Integer.

Try implementing

begin {
} commit {
} rollback {
}

to handle arbitrary code in each of the blocks. I can implement the equivalent in LISP in just a few lines. Java requires quite a bit more.

The most successful thing about java has been its hype.

At least with something like Perl I feel that the language attempts to meet me part way rather than declaring how everything must be done.

Re:Design Patterns...

[yintercept]

Design patterns give people a greater ability to talk about programs. Unforunately, it also comes with the hype that you will be able to just create UML model with your named patterns and a working bug free programs will drop out of the sky. For the most part, the ability to talk about programs abstractly is worth the effort to learn about patterns, although pattern-speak can add nasty dimensions to corporate politics...with one click pattern-speaking and another click not.

Re:Design Patterns...

[btlzu2]

The most successful thing about java has been its hype.

That's pretty much BS. Considering I have been going through a Comp Sci Master's program only knew FORTRAN and C in passing when I started, I know that Java is much much more than hype and to say otherwise is fairly ignorant. I have subsequently learned C, C++, Perl, and PHP and Java is, by far, the best bang for your buck hands down. Cross-platform is only the tip of the iceburg. Handling sockets, connecting to databases of all kinds, web development, server-side processing, etc. are elegantly solved in Java. No longer are there propriety libraries that everyone had to write in C or C++. There's a more formal ground-up OO structure in Java compared to C++. Java is absolutely not hype. Your fairly weak examples do not do much to discount from the overall benefits of Java IMHO.

I have no knowledge of LISP, but that does NOT mean I can't argue against someone saying that Java is best at hype. That's just a dumb thing to say.

Re:Design Patterns...

[haystor]

Cross platform...ooh. Yea, now I can replace that big Sun box on a whim with something else. In 8 years of doing business programming, I have never (NEVER!) had to change platforms such that a rewrite would occur.

There is a small benefit that you can run your own server on your windows box and that code should (not necessarily will) run on your server. This gives me the luxury of being able to use my IDE, Weblogic, and Lotus Notes all on my own machine. I'm going to tab over to my IDE and back real quick to see if the build is done, I'll be back in 30 minutes.

(30 minutes and 2 alt-tabs later)

Back. Best bang for my buck? I'll take Perl. Lets see now...More stuff than Java on more platforms running more stably divided by zero.

Perl wins.

Oh, and I don't give a damn about objects or patterns. They are for the weak minded who need hand holding. Blah blah blah data encapsulation. Bullshit. If I want to trash the data I damn well ought to have the power.

It may suck to shoot yourself in the foot, but I'm not giving up my power to shoot everyone else in the foot just because I'm afraid.

Re:Design Patterns...

[E_elven]

> Handling sockets, connecting to databases of all kinds, web development, server-side processing, etc. are elegantly solved in Java.

No, they aren't. They're (elegance arguable) solved in the Java Standard Edition library.

I hate it when people tout Java because of its libraries. Give me a few weeks (and some cash for snacks) and I'll compile you a list of C++ libraries better and more extensive.

Re:Design Patterns...

[Anonymous Coward]

Case in point: We fear what we don't understand.

Re:Design Patterns...

[btlzu2]

I know it's probably a subjective thing, but C++'s syntax makes me wretch. I hated C++ even though I was all excited about learning it. Java just seemed like home...less forced. This is probably an opinion thing only, but there are quite a lot less syntax kludges involved with Java than C++ IIRC & IMHO.

I'm a big fan of C (especially, obviously, for Unix/Linux system programming) even though I don't nearly use it as much anymore, but C++ was just god-awful IMO. However, you've got to admit that C/C++ are not nearly as safe to program in as it is in Java.

Re:Design Patterns...

[can_dcm]

Clique, dude, clique. I'm not a spelling/grammar Nazi, but represting drunk Canadians everywhere, I was *confused* by your comment:) Visions of battling corporate mice were dancing through my head....

Re:Design Patterns...

[E_elven]

I happen to like C++ more :)

You say Java is safer. I ask what if I add one of the many garbage collection libraries? One -or many- of the many smart pointer libraries? How about then? :)

Oh, what a nice pattern

[Karamchand]

Thanks for the review, but it is rather pointless to write a whole story/article in italic. Italice (oblique) is kind of mark up.
Regards..

Re:Oh, what a nice pattern

[Karamchand]

I don't mind being modded down, but I mind if all you techies think the form, the presentation doesn't matter - it does. A text should be readable as easy as possible. Therefor it is not advisable to set it all italic. Fewer people might read it, fewer people might get the message. And usually that's not what you as a writer want.
Regards

Re:Oh, what a nice pattern

[October_30th]

That actually reminds me of a good point my MD friend made a while ago.

He's was involved in an MRI R&D project and was frustrated by the techies/engineers/scientists who insisted on using obscure slang without bothering to translate it. You know, the classical RTFM attitude of an elitist geek.

Over here they teach the MDs to deal with young and old people, people with low/high IQ, people with good/bad literacy and so on. In short, they teach social skills. In my mind, this should be made compulsory in the engineering/science degrees as well.

As I say to my students: if you can't communicate an idea in quantum mechanics to your grandma, you have not really understood the physics.

YOU FAIL IT

[Anonymous Coward]

# Important Stuff: Please try to keep posts on topic.
# Try to reply to other people's comments instead of starting new threads.
# Read other people's messages before posting your own to avoid simply duplicating what has already been said.
# Use a clear subject that describes what your message is about.
# Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)

Problems regarding accounts or comment posting should be sent to CowboyNeal.

CLOSE YOUR FUCKING TAG POLESMOKER

[Anonymous Coward]

dumbass

Buzzword alert!!!

[Anonymous Coward]

Someone has been eating too many acronyms laterly:

J2EE Design Patterns, GoF book, JSP developer, MVC framework, UML notation, SQL strings, O/R mapping engine, EJB Container Managed Persistence.

Re:Buzzword alert!!!

[WormholeFiend]

that's TMI, so STFU.

"But sir, if the VP is such a VIP, shouldn't we keep his PC on the QT, 'cause if it leaks to the VC he could end up an MIA and then we'd all be put on the KP ASAP." /Good Morning Vietnam

My personal favorite design pattern...

[Anonymous Coward]

...is the spaghetti warehouse with a competence facade. Use it all the time.

Re:My personal favorite design pattern...

[Anonymous Coward]

I like to compliment that pattern with the high-rate-do-nothing contractor pattern.

More like antipattern

[Timesprout]

I am a fan of design patterns but many of the patterns I see described in these books are workarounds for weaknesses or performance issues in the J2EE specs. In many cases a "best practice " tag is more appropriate than a design pattern.

Re:More like antipattern

[Anonymous Coward]

Please elaborate on the difference between "best practice" and "design pattern".

Re:More like antipattern

[mark_lybarger]

design patterns are concerned with the design, and anti patterns are more concerned with the implementation. ok, so the two meld a little. if your design had you using J2EE CMP entity beans, you're kinda sorta stuck w/ an anitpatern.

i see more the design patterns describing general stuff, and the anti patterns books describing lessons learned, and good (or bad) implementation practices.

J2EE?

[Anonymous Coward]

J2EE, huh? Sounds suspiciously like J2E2, the cousin of R2D2 that ratted to the Empire about his where abouts...

Design Patterns are a Shared Language

[jetkust]

Patterns save time and effort by supplying developers with a shared language when discussing common problems.

Finally someone with an accurate description of what a design pattern actually is. In fact, that is ALL it is. I disagree that being able to identify patterns in your code saves time and effort though. And how does forcing patterns into your code help when, by definition, a design pattern is commonly occoring. Yes, you may have added new words to your vocabulary of programmer technobabble, but how helpful is it?

Re:Design Patterns are a Shared Language

[Evil Adrian]

It's helpful in conversation, in the sense that patterns are tools. For example: it's much easier to say "singleton" than to say "make sure this class has only one instance and make sure there's a way everyone can get to it" -- just as it's easier to say "hammer" than "that thing you bang nails into things with."

Re:Design Patterns are a Shared Language

[vingilot]

I disagree that being able to identify patterns in your code saves time and effort though. And how does forcing patterns into your code help when, by definition, a design pattern is commonly occoring

You have it backwards: Identify the pattern and your code will fit around it (no forcing). Design patterns are not about code or patterns in code-- but about architecture. And they are regonized from the problem-- the solution is the design pattern. There is not a design pattern for every problem but for the most common problems patterns represent a powerful tool.

I have found that design patterns do relate to saved time and effort. Number one, they give clear direction as to the solution (if applied correctly). And number two, other devleopers who are familiar with patterns will understand your code quicker.

Re:Design Patterns are a Shared Language

[FortKnox]

Its funny to explain patterns to old programmers. I usually say "You've probably used them and just not realized it". Its about 'high level' modelling, not simply algorithms.

Re:Design Patterns are a Shared Language

[butane_bob2003]

Patterns that are forced into code are being applied inappropriately. Patterns tend to fall into place where necessary, not needing to be sought out or hammered into shape. If you have a very good grasp on the applicability and shortcomings of known patterns and combinations of patterns, you will benefit from their use. Patterns stretch most developers into a realm that is more abstract than they are used too, which is why many developers misuse them. Novices introduced to patterns will try to apply them to everything, and end up wasting a lot of time thinking about how to apply them. If you are a good 00 programmer, the patterns will find you without much extra effort on your part.

Re:Design Patterns are a Shared Language

[bluGill]

Well yes and no. A design pattern is commonly occuring in general industry. That doesn't mean that your particular branch will use it. So not only do you gain a simple language to talk about what you are doing, but you also get insight into things you could/should be doing, but instead are doing a much harder way not realizing it.

Recognizing patterns also helps in deisgn. You know you need to do something. By having a list of patterns you turn to the list to make sure you pick the right one, instead of one similear that isn't quite the same, and doesn't fit quite right but you can force it to work.

Of course once you see patterns you've never seen nor though of, you might be tempted to use them where they don't make sense. Normally not a problem.

Bush Re-Selection Advertising: +1, Patriotic

[Anonymous Coward]

"Democrats criticized the President for attacking the terrorists."

Be patriotic, impeach the Liars.

Thank you and a Happy Thanksgiving,
Kilgore Trout

Re:Bush Re-Selection Advertising: +1, Patriotic

[Anonymous Coward]

I agree.

Anyone who criticizes the President, who has led the way so bravely so far, is only serving the terrorists. At a time like this even the elections-process must be subject to certain limitations. Too much freedom will only help the enemy who brought down the WTC. Would you like the terrorists voting in our next leader? No? Would you like people who sympathize with the terrorists to vote in our next leader? NO!

Participating in a focus group on design patterns,

[Anonymous Coward]

I may be able to offer some perspectives.

The basic concept behind a design pattern is to reduce common tasks to a set of repeatable and clearly-defined models. These models are:

• Simple to implement
• Either complete in themselves or modular
• Easily repeatable

Most businesses find themselves using one of three different design patterns. Larger businesses tend to choose one that is more suitable for dealing with a larger amount of business, whereas smaller businesses may find a more cost- and time-effective solution in a cheaper pattern.

I haven't read this book, but it's likely it'll touch on these and other design patterns. As always, it comes down to choosing the pattern you're most comfortable with.

This country is going to hell in a handbasket

[Anonymous Coward]

This country will go to hell in a handbasket if GWB/Diebold/Christian Fanatics-conglomerate "wins" the next elections.

Mark my words. Blood will flow.

more reviews of this book

[Anonymous Coward]

VeryGeekyBooks has more reviews of this book.

Re:more reviews of this book

[Anonymous Coward]

All linked to affiliate sites, with referral IDs attached. Good job, spammer.

Re:more reviews of this book

[Anonymous Coward]

no, only the ads are linked to referrals, like the ads on any other web site. All the external book reviews are regular links.

Definitions.

[ninejaguar]

A pattern involves three components: first, a description of a generalized recurring problem; second, an abstract solution that is generally accepted; and third, a name for the sake of convenience.

What's the difference between a Design Pattern and a template?

= 9J =

Re:Definitions.

[FerretFrottage]

Actually there is a design pattern called the "template pattern"

Re:Definitions.

[2nd Post!]

In common parlance, a template is a pattern and a pattern is a template.

When you want to make a dress, you don't buy a template, you buy a pattern.
When you want spray paint letters onto a sign, you use a stencil, not a template.
When you're carving letters into stone, you use a template, not a pattern.

It's all about relevant language. If someone else had written a salient article, perhaps we'd be talking about design templates, and pattern template, instead of design patterns and the template pattern.

Regardless, the point is still the same: Design patterns provides a vocabulary in which people can talk about problems and solutions.

Re:Definitions.

[lysander]

What's the difference between a Design Pattern and a template?

A template you fill in. This assumes that someone has already solved your exact problem, and you just need to add the details specific to this particular incarnation of the problem.

Design patterns are programming concepts that you can assemble to solve your problem. They are reusable in the sense that the problems that patterns solve come up often enough that knowing when and how to use them becomes important.

Design patterns also encapsulate nicely the best ways to look at some problems. Using patterns does not imply that there is only one way of solving a problem. Several patterns provide similiar functionality and yield different trade-offs, such as future customizability, efficiency, straightforwardness to implement, and opportunity for code reuse. Knowledge of patterns can help when designing solutions and analyzing alternatives, and they can also provide a good road map during implementation.

Four more years? No way in hell!

[Anonymous Coward]

Are you going to give him four more years to establish not the United but a theocratic neo-con States of America, instead?

After all, it's been "one nation under God" since 1950s when the reference to God was sneaked in to the pledge our kids are made to recite. Why not follow the course to the end and just call it "mission accomplished"?

Vote out GWB in 2004. I don't care if you're Republican, Democrat or something else. That is your PATRIOTIC duty.

Re:Four more years? No way in hell!

[Anonymous Coward]

"After all, it's been "one nation under God" since 1950s when the reference to God was sneaked in to the pledge our kids are made to recite."

Yep. That's why the Bible was taught in school from our nation's birth up until a few decades ago when we began our downward spiral.

That's why the Declaration of Independence recognizes the God-given rights of all mankind.

That's why the majority of the founding fathers were Deists, if not Christians.

That's why one of the requirements of admission to the Union was that the Bible be taught in school.

That's why every session of the U.S. Supreme Court opens with the phrase, "God save the United States and this Honorable Court."

That's why the words "In God We Trust" are inscribed in the House and Senate chambers.

That's why on the walls of the Capitol dome are the words: "The New Testament according to the Lord and Savior Jesus Christ."

That's why in the Rotunda of the Capitol is a figure of the crucified Christ.

That's why a picture of the baptism of Pocahontas at Jamestown hangs in the Capitol Rotunda.

That's why a painting of the pilgrims hanging in the Capitol Rotunda shows Elder William Brewster holding a Bible and the words "God With Us" are inscribed on the ship's sails.

That's why a relief of Moses hangs in the House Chamber.

That's why the Latin phrase Annuit Coeptis -- "God has smiled on our undertaking" -- is inscribed on the Great Seal of the United States.

That's why under the seal is the phrase from Lincoln's Gettysburg address: "This nation under God."

That's why the Liberty Bell has Leviticus 25:10 prominently displayed in a band around its top: "Proclaim liberty throughout all the land, unto the inhabitants thereof."

That's why Micah 6:8: "He hath shown thee, O man, what is good; and what doth God require of thee, but to do justly, and to love mercy, and to walk humbly with thy God" are engraved upon the walls of the Library of Congress.

That's why the lawmaker's library quotes the Psalmist's acknowledgement of the beauty and order of God's creation: "The Heaven's declare the glory of God, and the firmament showeth his handiwork."

That's why engraved on the metal cap on the top of the Washington Monument are the words: "Praise Be to God."

Check your facts. This has been one nation under God from the beginning. It's only very recently that God-haters like you hijacked the judiciary and started systematically eliminating all acknowledgements of God from the public domain and our nation's consciousness. Can you honestly sit there and say that all of our problems, both domestic and international, are not a result of us failing to apply Christian principles to our domestic and foreign policy? Even if you are not a Christian, you must recognize the utility of God's second greatest commandment: to love one another as much as we love ourselves. Please stop destroying the foundation of my country.

Re:Four more years? No way in hell!

[Anonymous Coward]

I don't believe in God.

Federal government is supposed to represent me.

If they speak as if they speak for God, they're not speaking for me and thus fail representing me which is their fundamental function.

That's my beef with religion in the government.

As far as the "benefits of religion" go, yeah sure. A puritan religious society was adept at sweeping the problems under the rug by social coercion. Now they're in the open which is a good thing. That way we can actually address the problems.

Re:Four more years? No way in hell!

[Anonymous Coward]

" I don't believe in God. Federal government is supposed to represent me."

No, the government is supposed to represent EVERBODY. Your view is pretty damn selfish, and typical of leftist elites. Fact is, YOU are in the minority, ma'am. Most people believe in God of some form, whether they call him God, Allah, or a host of other names. I believe the real issue is not that you don't believe in God, but that you hate what he represents because He represents the last idealogical barrier between you and the indulgement of your every wicked and selfish desire.

More J2EE patterns

[^Case^]

Core J2EE Patterns is another book on the subject. You can even find many (all?) of the patterns from the book online.

I've found a lot of these patterns to be useful in other domains (PHP webapps) as well.

Holla if you are a troll too!

[iluvtrolls]

Who let the trolls out (woof, woof, woof, woof)
Who let the trolls out (woof, woof, woof, woof)

When slashdot was nice, the moderation was jumpin
(Hey, Siggie, Yi, Yo)
And everybody havin a ball
(Hah, ho, Sig leven Yi Yo)
I tell the trolls start the First Postin
(Siggie Yi Yo)
And the moderators report to the call
The poor dogs mod down

Who let the trolls out (woof, woof, woof, woof)
Who let the trolls out (woof, woof, woof, woof)

Rap 1
I see ya little Taco head up our site
He really want to keep us down
But his readers are too stupid to see us comin
And everybody mods up us clowns

Verse
Im gonna tell
(Hey, Siggie, Yi, Yo)
To any Dan Hayes and Anne Marie
(Siggie, Yi, Yo)
Tell the dummy Hey Baby, Kiss MY Blade!
(Siggie Yi, Yo)
You fetch a moderator in front and her trolls behind
(Siggie, Yi, Yo)
Her points run out now

Chorus
Who let the trolls out (woof, woof, woof, woof)
Who let the trolls out (woof, woof, woof, woof)

Chant
Say, A troll is nuttin if he dont have suckers
All mods give up ya points, all mods give em up
A troll is nuttin if he dont have suckers
All mods give up ya points, all mods give em up

Rap 2

Wait for yall my trolls, the party is on
I gotta get my girl I got my goatsex on
Do you see the mods comin from my eye
What could you be first post
that Katz man thats breakin them down?
Me and My petrified short shorts
And I cant post a lot, any troll will do
Im figurin thats why they call me Lita Juarez
Cause Im a stupid man of the land
When they see me they go doo-doo (howl)

Chorus 5 Xs
Who let the trolls out (woof, woof, woof, woof)
Who let the trolls out (woof, woof, woof, woof)

Is the Design Patterns book insane ?

[andy666]

Is it just me or do others find this book to be unreadable and crazy ?

Re:Is the Design Patterns book insane ?

[NickFitz]

Just you.

Too cold a definition

[Anonymous Coward]

Design Patterns were inspired by the terrific book 'A Pattern Language' by Christopher Alexander.

But, in this book, a pattern is not -just- a commonly accepted solution. It's a solution that's really good, really works incredibly well, and feels like a fundamental thing. It's a solution whose insight leaves a lasting impression on you.

This is where the software design patterns people rather missed the point, and the razzing they get from older engineers is well-deserved.

Re:Too cold a definition

[Anonymous Coward]

maybe they should read the other two books in the series
"The Oregon Experiment" and
"A Timeless Way of Building" both by Christopher Alexander.
They might even stop calling themselves architects once they truely understand.

"IForone" pattern

[Begemot]

I, for one, welcome our new Singleton(); overlord (sorry couldn't resist).

Re:"IForone" pattern

[Mindwarp]

I, for one, welcome our new Singleton(); overlord (sorry couldn't resist).

That should read "I, for one, welcome our Singleton.getInstance() overlord"

Sorry, couldn't resist ;-)

Re:"IForone" pattern

[butane_bob2003]

Any one notice that our 'new' Singleton overlord is the exact same one as the old one?

Re:"IForone" pattern

[DarthTaco]

Any one notice that our 'new' Singleton overlord is the exact same one as the old one?

Now that was funny.

Re:"IForone" pattern

[Kingpin]

ISingleton.getInstance().welcome("overlord"); :)

Didn't we just have such a review?

[mcbevin]

I remember commenting on some other topic regarding J2EE design patterns recently.

Like I sort of said that time, the design patterns are mostly just workarounds for a bad system. My advice is 'use JDO' and avoid all these problems (this is coming from someone working on both a JDO and a J2EE system right now).

I do in fact have one such EJB design patterns book, and its crazy the lengths they go to to make a broken system work ....

- Its too costly to make calls to an EJB's individual get methods - make a value object for each EJB!

- Don't like making all these extra objects, and coping with the extra maintenance required, and writing all the methods to transfer values between the EJBs and these objects? Transfer the information using a hashmap!

- Don't like the loss of all the advantages of using OO programming languages and entity beans instead of SQL which comes from passing everything with hashmaps? etc etc

Enough to make any experienced _object oriented_ programmer pull their hair out. Of course, if you prefer using the buzzwords of 'EJB design patterns' to the practicality of JDO then go ahead, code an EJB application - enjoy developing in an environment where the deployment required to test any changes is 5 minutes plus for any decent sized EJB project, where your $10,000s EJB server can't work out how to handle basic relations in the right order, and where you have to code half of your queries in SQL anyway (i.e. see the 'Data Access Command beans' pattern which the book no doubt has) as the system is so slow and not powerful enough.

Re:Didn't we just have such a review?

[balbeir]

Amen to that. J2EE itself suffers from the "Golden Hammer" antipattern. There is a certain class of problems that J2EE is good for: e.g. as a backend for a web application. For a lot of problems in the real world there is an impedance mismatch that makes any competent developer pull out their hair. No threads, no direct access to files etc... Something that is simple without J2EE suddenly becomes a balancing act on a tightrope with both hands tied to your back when you're forced to do it in the constrained environment that J2EE provides you. Unfortunately the whole thing is so hyped that a lot of "architects" won't even consider solving a problem without J2EE.

Re:Didn't we just have such a review?

[FerretFrottage]

I think you are right on here. EJBs are really a component model, not an object one. As such components don't map real well to persistence. That is where implemtations such as JDO come in--they fill that need (weakness) in the current EJB model. There is talk of CMP beans implementations that support JDO (ouch metadata overload) or even JDO replacing entity EJBs someday. Oh, life as an object will be interesting (well if it wants to save itself)

Design Patterns For Beginners

[jd]

Here is a quick guide for "design patterns" for any novice to the subject who is familiar with basic programming concepts.

1. Throw away any book on the subject. Jargon is only useful if it is short-hand for knowledge that would be tiresome to re-explain otherwise
   
2. Learn the basic concepts of functions, procedures and macros - when to use them, why to use them, and how to build complex components from simpler ones using them
   
3. Develop a set of basic toolkits, where each toolkit is a collection of functions that work together on a given piece of data to do something useful
   
4. Describe a common problem, and build a more complex toolkit out of the simpler toolkits, such that:
   
   • The complex toolkit solves that problem
     
   • The solution operates on some single chunk of data
     
   • You don't need to know the internals of that data, outside of that toolkit
     
   
   

You now have a fully working "design pattern". People from older methodologies will also refer to this as a Jackson Structured Design, a heirarchical design, a bottom-up implementation, an abstract data type, an encapsulated design, reusable code or a library.

Personally, I think we've enough techno-gibberish and that Software Engineers who introduce yet more to describe exactly the same scenario as some other jargon should be forced to read from /dev/zero.

I don't mind jargon. I use plenty of it myself, but it's no use if nobody understands it. If there are more terms for the same thing than there are qualified programmers, you've achieved exactly nothing.

Instead of creating a comprehensible short-hand, which can be used to increase efficiency and re-use concepts as well as code, we're close to out-doing the story of the Tower of Babel - and we haven't even needed a pissed-off deity to produce the confusion of languages.

Re:Design Patterns For Beginners

[butane_bob2003]

Sure, things can be refactored into a common library that can be used for things that won't need to change. But this is usually best done *after* it is determined a component is re-usable. This determination is best made after a component is reused a few times, not before it has ever been used at all.

Every one has written an XML toolkit, File toolkit, JSP toolkit, Swing toolkit, etc.. The Java SDK is a 'tookit' itself. This does not eliminate the need for design patterns. In reality, software is designed from the top down, where the top layer is the user/client interface(s). (where the client can be human,monkey,machine,other software,etc..). As the layers get lower and lower, they (should) become less volatile. Good bottom up designs are made better (more flexible,expandable) by design patterns.

Removing dependancies on the 'toolkits' can be extremely difficult without the simplest design patterns. Dependencies between layers of applications are to be avoided for obvious reasons.

Design patterns can't be avoided in good object oriented design. They are not a product of some company or focus group deciding developers need a new tool, they are natural occurences that have been observed and recorded during the development cycle that people have found useful and often necessary.

Feh

[iluvtrolls]

Feh...

Eh?

Imagine a Beowulf cluster of LOGO processors...

[Anonymous Coward]

Haven't we taken a wrong turn in pursuing Java, J2EE et al?

Really, isn't a functional language like LOGO
(hmmm, something strange about that turtle head there) better?

And what about LOGO's big brother, Common Lisp?

C'mon guys! The Turtle is calling for you. Will you answer?

Here comes the flame bait, but ...

[jemele]

Design patterns can be useful. The demonstrate good design in generally language neutral terms. They are useful teaching devices and solidly formalise a lot of things a lot of people having been saying in a lot of communities for a long time.

But they are not the end-all-be-all-panacea that some developers (and managers) imagine them to be. I have witnessed the following more than once, and it scares the hell out of me:

Oh, the proxy manager pool pattern in my framework does not have a helper. Perhaps a composite visitor pattern will suffice ...

I try to run the fsck away when I hear such atrocities (that is a euphemism, kids ;).

What is more, one day bored, I wrote a small script to go through the tree, examine all class declarations.

The design pattern fanatics had a mean class name length of 73 ... not 7.3, or 13 ... 73 ...

They were also using delphi, so no typedef for them ;)

Long story short, good teaching tool, awesome way to watch the stupid and uninformed create a tangled web of complexity to hang themselves in ...

Naturally, Your Mileage May Vary :) (tm)
joshua

Thank you for endorsing censorship:

[Anonymous Coward]

You obviously suffer from the same malady as the
fearful "leader" as evidenced by this logic:

"See, free nations are peaceful nations. Free nations don't attack each other. Free nations don't develop weapons of mass destruction.

--- George W. Bush--- Milwaukee, Wis., Oct. 3, 2003

Unfortunately, many alleged "patriots", such as you, are both illiterate and innumerate, as evidenced by your uncritical consumption of propaganda from the U.S. media and BushCo.

As always,
Kilgore Trout

Re:Thank you for endorsing censorship:

[Anonymous Coward]

Okay! Thank you very much, Anonymous Coward with the fictitious name!

Design Patterns Explained

[dilute]

If you want to know about design patterns (and you SHOULD), the Gang of Four book is the classic. However, I have found another book (Design Patterns Explained, by Shalloway) that really lays it out, explaining how to evaluate which pattern is right (or best) for a particular task or project. Read that book first.

And don't forget...

[Anonymous Coward]

... to use the new cover page on the TPS reports...

Designpattern today, antipattern tomorrow

[PingoSvin]

A book which doesn't mention alternatives to entitybeans and raw sql sounds quite outdated.
The story of cmp/ejb is really the tale of the emperor's new clothes. Three years ago any critique voiced against this new wonder tech. was labeled as uneducated drivel. But the truth was that anyone(ok not you) forced to work in this setting, was demonstrating terrible productivity.
As anyone reading theserverside.com will acknowledge, the emperor has now officially been declared naked.
Now it's time for the trial. Let's have a book examining how and why so many clever and bright people could be fooled so badly.

Design Patterns...Who's on "First"?

[Anonymous Coward]

Soo's FORTH. I don't see anyone crowing about that

Besides LISP had it's chance...and it's share of hype as well. BTW I use Smalltalk, so their, pffft!.

How about web Services...

[timjdot]

...tell me how you really feel! If you think the ideas of an object system (entity beans) over a constant barrage into an RDBMS are bad, then you must really be pissing your pants now that Web Services is the new rage. Talk about one more re-hash for distributed computing. "Let's think of the slowest possible distributed computing infrastructure and promote that".
Maybe one can define all the patterns on a few basic patterns -- caller, callee, data store. In addition to GoF, "The Pattern Almanac" was the best book I found because it lists all the names of these patterns as used in various industries. As skilled programmers who know how computers work we all have done most of these before or could do them in a few weeks if needed. Personally, I think using pattern names is useful as it gives one more level of composition abstraction - something between talking about a module and a class perhaps.

Joke Pattern with Humor Facade

[deadlinegrunt]

you'll see the four circles around the exit. lower traffic, and possibly just straight exit and entrance ramps w/out the loops.

On older freeway systems you got performance increases too from loop unrolling although todays freeway systems that is less and less of a concern because of new aggressive optimizing architects and civil engineer caching.

My comment has nothing to do with design patterns by the way - it's an implementation artifact of humor.

In other words

[LPetrazickis]

"But, sir, if the Vice President is such a Very Important Person, shouldn't we keep his Personal Computer on the Quick Time, 'cause if it leaks to the Venture Capitalists he could end up Missing in Action and we'd all be sent to maintain www.goatse.kp (North Korea)."

You make a strong point.

Simple Definition - Simple Thoughts

[bossvader]

Patterns are a common strategy/idiom for solving a common class of problems. Poorly applied patterns, indiscriminently applied or poorly-understood patterns will make things worse. Anti-Patterns are as important as normal patterns. (See above) A nice tool with pattern support/generation (Together ControlCenter) can help with implementation and understanding.

no mention of Alexander?

[goon]

when the enevitable book,discussion, etc on patterns and their use in software I remind myself of Christopher Alexander , Austrian born, Cambridge educated maths and architecture graduate.

One aspect of Alexanders work often overlooked, is that we should be making up your own patterns. Instead we look to references as cook books rather than as building blocks.