• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

About design patterns & open source frameworks

 
Ranch Hand
Posts: 138
Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
*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.
 
Mihai Lihatchi
Ranch Hand
Posts: 138
Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another good book is Robert C. Martin's "Agile Software Development - Principles, Patterns and Practices", by the way.
 
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 138
Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 .
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
     
    reply
      Bookmark Topic Watch Topic
    • New Topic