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.
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? :)
====
Crudely Drawn Games
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.
Karma Clown
The basic concept behind a design pattern is to reduce common tasks to a set of repeatable and clearly-defined models. These models are:
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.
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."
evil adrian
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.
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.
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.
TallGreen CMS hosting
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.
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.