This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
Hello everybody. I took a good look at most J2EEpatterns (such as Bussiness Delegate, Service Locator, Data Transfer Object) and it looks to me that these do not apply when you are working on a non-EJB solution , with dependency injection (such as Spring + Hibernate ). On the other hand most of the web patterns are already implemented by the framework (Spring MVC or Struts both implement Front Controller and MVC ). In this case where does your design pattern knowledge make a difference? I found my self looking more through Spring docs when trying to get a solution then applying one of the J2EE design patterns. Guess somebody already thought about the problems before me. However most of my more experienced work colleaques praise the Gang of Four patterns book - they say that it is a design pattern book for all OO programming objects. I am just looking to learn patterns in order to do my work better and get home sooner Any thoughts ? [ October 28, 2006: Message edited by: Mihai Lihatchi ]
Better, faster, lighter Java ... you mean Ruby right ?
SCEA5,SCBCD1.3,SCWCD5,SCJP1.4 - memories from my youth.
*Definitely* learn the GoF patterns! They are much more universal than those J2EE patterns - you will find places for them no matter what kind of system you are developing.
The GoF book, though, might not be the best to start learning them - it's kind of dry, in my opinion.
Take a look at "Head First Design Patterns" - if you like the style, it's a good start into the world of patterns.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Thank you for your answer Ilja.Probably GoF is the reference after all .. . I have not heard too much at my workplace about Head First Design Patterns probably because it is a newer book but because it's a Head First book .. it's probably worth looking at.(I have also read the review on Javaranch).
Joined: Jul 11, 2001
Another good book is Robert C. Martin's "Agile Software Development - Principles, Patterns and Practices", by the way.
I think these books really cover the idea of J2EE design patterns and practices quite thoroughly.
Finally, I think alot of J2EE Design Patterns have to do with NOT using EJBs, and getting away from heavyweight components when lightweight ones will do. On the note of minimizing EJB use, Rod Johnsons book on J2EE without EJBs is a great read. It also lays much of the groundwork for Spring and Hibernate:
Of course, there's nothing worse than working with someone who sees a Design Pattern in EVERYTHING. Hey, "that's a singleton" or "Hey, that's a factory pattern." It does get annoying. For people like that, you need to give them a copy of Refactoring:
Thanks Cameron. Rod Johnson's book was a recommended read .. when I started to learn Spring. What I remember from that book is : EJB's are not good .. then EJB's are not good because ... then for each argument I get the reason why EJB's are not good. Sometimes it looks like Spring framework (although it is pretty nice and useful) was built just as a counter-EJB alternative. Now don't get me wrong I work with Spring every day .. and I like it but to develop a framework should be a solution to a problem not an alternative to a pre-existing solution.
Anyway. Thank you for your information . I will save the book titles somewhere .
Originally posted by Mihai Lihatchi: Sometimes it looks like Spring framework � was built just as a counter-EJB alternative. Now don't get me wrong I work with Spring every day .. and I like it but to develop a framework should be a solution to a problem not an alternative to a pre-existing solution.
Actually the problem was that EJB was trying to solve problems that didn't exist for 85-95% of the applications that were implemented in J2EE. J2EE being a distributed component architecture tried to make all the components distributable - in fact you actually want to avoid that scenario for as long a possible. Ron Johnson acknowledged the fact that this problem existed in his book Expert One-on-One J2EE Design and Development (check out the excellent sample Chapter 1: J2EE Architectures) where he heavily supported "colocating" the web-tier and the EJB tier and ultimately presented the com.interface21 package which was the precursor to Spring. J2EE burdens 85-95% of developed applications with the overhead and complexities that could only be justified and utilized by the remaining 5-15% of applications.
EJBs introduced way too much accidental complexity (see No Silver Bullet: Essence and Accidents of Software Engineering) for most software solutions which incurred unjustifiable additional cost and effort. Spring tried to re-balance the situation by focusing on the essential problems that majority of the software solutions needed to address without trying to solve everybody�s problems.
So to say that Spring is just an alternative to a pre-existing solution oversimplifies the situation. That of course doesn't mean that Spring is perfect, nor that it may forget why it was initially so successful - by eliminating accidental complexity.
Accidental Complexity - The complexity in an application resulting from the use of mismatched tools or paradigms of software development.
Essential Complexity - The complexity in an application due to the intrinsic qualities of the software itself.
In light of how easy it is to introduce accidental complexity into systems built with J2EE, knowledge of J2EE AntiPatterns can be just as valuable as knowledge of J2EE patterns (in addition to knowledge of general design principles and patterns). [ October 29, 2006: Message edited by: Peer Reynders ]