It's not a secret anymore!
The moose likes Java in General and the fly likes Design patterns confusion ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Design patterns confusion ?" Watch "Design patterns confusion ?" New topic

Design patterns confusion ?

Abhilash Chander
Ranch Hand

Joined: Oct 18, 2009
Posts: 39
Hi All,

I have been developing J2EE web applications from last 3 years. I use Struts 2 for the same. Recently I came across these articles about 'Programming to Interface not Implementation' and 'Design Patterns'. And I am completely amazed by the amount of flexibility, security and scalability you get by using these set of rules. I am also looking forward to designing applications and developing Java based APIs. So for that very reason I am reading 'Head First Design Patterns' these days. Though I am now quite familiar with the purpose of using 'design patterns' and 'programming to Interface not Implementation' but when it comes to implementing the same in my application I am completely confused. Even When I implement these rules they seem unnecessary and just for the sake of 'Design Patterns' implementation. My question is for expert developers -

How can I develop 'Programming to Interface not Implementation' coding style ?
What path should I take to learn 'Design Patterns' ?
Are there any other good books that may help learning 'Design Patterns' or 'Interface based programming' besides Head First Design Patterns' ?

I have been trying from last few weeks but of no use. Please help.

Thanks to All
Abhilash ''
David Newton

Joined: Sep 29, 2008
Posts: 12617

Abhilash Chander wrote:How can I develop 'Programming to Interface not Implementation' coding style ?

Program to interfaces, not implementations.

You probably already do this to some extent--like when you use an ArrayList you define the variable as a List, or even Collection, not an ArrayList.

If you practice TDD, or something slightly less militant, you'll find yourself doing this a lot, out of necessity: if I'm testing a method that relies on another class I don't necessarily want to use an actual instance of the other class. Instead I'd want to use a mock object to simulate various ways the method under test could behave. If the method uses a specific implementation I'm forced to test both the method, and the class the method uses--and I might not be able to simulate all the behaviors I need to.
Francesc Martinez

Joined: Feb 13, 2009
Posts: 24
I read Head First Design Patterns a few months ago I I think it is an excellent book. It explains not only patterns but also why they are good, based on some recommended basic rules (don't repeat code, hide the implementation ie. program to interfaces, etc). I highly recommend you to re-read that book and pay special attention to the reasons for the patterns.
Bobby Smallman
Ranch Hand

Joined: Sep 09, 2010
Posts: 107
I heartily agree with Francesc's book recommendation. While I am a relatively new convert to Java I found this book to be a well balanced introduction to design patterns.

Everyday in every way, we get a little better.
Nandini Bhaduri

Joined: Oct 23, 2006
Posts: 11

You could get a copy of Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (Gang of Four). That's the originator of Design Patterns.
David Newton

Joined: Sep 29, 2008
Posts: 12617

Nandini Bhaduri wrote:That's the originator of Design Patterns.

I'd feel more comfortable saying it's the canonical reference work--patterns existed in various forms before they were written down.

On a side note, I have a copy of _Pattern Hatching_ signed by John Vlissides.
wood burning stoves
subject: Design patterns confusion ?
jQuery in Action, 3rd edition