wood burning stoves 2.0*
The moose likes OO, Patterns, UML and Refactoring and the fly likes About design patterns & open source frameworks Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "About design patterns & open source frameworks" Watch "About design patterns & open source frameworks" New topic
Author

About design patterns & open source frameworks

Mihai Lihatchi
Ranch Hand

Joined: Oct 28, 2005
Posts: 138

Hello everybody.
I took a good look at most J2EE patterns (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.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
*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
Mihai Lihatchi
Ranch Hand

Joined: Oct 28, 2005
Posts: 138

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).
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Another good book is Robert C. Martin's "Agile Software Development - Principles, Patterns and Practices", by the way.
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

You absolutely need to know the Gof (Gang of Four) Design Patterns:

GOF Design Patterns

Then, if your working with J2EE, you should check out J2EE Design Patterns. These compliment the basic Design Patterns, they don't necessarily compete or replace with them:

J2EE Design Patterns

I think these books really cover the idea of J2EE design patterns and practices quite thoroughly.

Cheers!

-Cameron McKenzie

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:

J2EE Without EJBs by Rod Johnson

As was said before, a good book on Agile Development should be on your bookshelf:

Agile Development, Principles Patterns and Practice

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:

Refactoring Code - A Great Read
Mihai Lihatchi
Ranch Hand

Joined: Oct 28, 2005
Posts: 138

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 .
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
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.

p. 9 Object Oriented Design Heuristics; Arthur J. Riel
  • 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 ]
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: About design patterns & open source frameworks