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 call it the tag delimeter pattern.
BSD is designed. Linux is grown. C++ libs
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.
Your friend and well-wisher
m0smithslash
http://www.ferociousflirting.com
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!
...is the spaghetti warehouse with a competence facade. Use it all the time.
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
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.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
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
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!
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.
VeryGeekyBooks has more reviews of this book.
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
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.
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.
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
The gift of death metal does not smile on the good looking.
Any one notice that our 'new' Singleton overlord is the exact same one as the old one?
TallGreen CMS hosting