Slashdot Mirror
J2EE Design Patterns
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.
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
Physicists get Hadrons!
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.
evil adrian
That seems to be the general take on the matter.
;). It has 3 broad categories of patterns that it defines as Creational, Structure, and Behavioral...
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
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!
java guy, tech blog...
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.
evil adrian
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.
:-) is far more readable, but there's a lot of crossover.
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
Simon.
Physicists get Hadrons!
VeryGeekyBooks has more reviews of this book.
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.
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.
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.
TallGreen CMS hosting
Great minds think alike; fools seldom differ.
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.
GET YOUR WEAPONS READY! --DR.LIGHT
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.