Intro to Java Patterns

This entry is part 10 of 13 in the series Intro to Java

Patterns are a very important part of Java. They allow us to speak a common language. The names can be misused, and thrown around by people trying to sound important, but they really do help us to be able to communicate ideas between us.

It does take some Java knowledge to be able to read, use and apply patterns, but I think we have seen enough Java and OO principles to start looking at patterns. It is good to start hearing about and seeing different patterns at any level of Java programming.

So what is a pattern? In the physical world, it would be a series of steps taken over and over again that could be written down and repeated. In the software world, it is not really a set of steps, but a software solution that people apply over and over again in their coding. Experienced developers have put these solutions together, and given their pattern a name. By looking at and studying patterns, we can take advantage of the experience of others, and learn from their solutions. One interesting thing about patterns, is that they don’t need to be language specific. If you learn about the Adapter or the Command pattern, you can apply that pattern to PHP, Ruby, or Java.


One of the original books on the topic is by the Gang of Four: Design Patterns: Elements of Reusable Object-Oriented Software (Amazon)

Sun on J2EE design patterns:

A list of common Java design patterns:

Head First Design Patterns

If you would like a paper copy of something, I would recommend the Head First Design Patterns book. It’s by Freeman & Freeman, published by O’Reilly. (Amazon) This is a good book that doesn’t assume a high level of java knowledge (at least at the beginning) but does a great job of explaining patterns. It uses Java for the examples, and the different patterns often build on each other. Well worth a read for all levels of programmers.

Q & A Session

Q: What am I supposed to ask questions about?
A: Patterns. Anything that you want to ask about patterns is fair game.

Q: Well, don’t people just learn the pattern names so they can throw them around to sound important?
A: I hope not, but I am sure some people do. When we all learn patterns, it makes it easier to talk about designing code. When someone is helping you, and you both understand some patterns, it is easier to communicate.

Q: But can’t people just explain what they mean. Don’t we have enough acronyms and buzzwords already?
A: I sense that patterns make you nervous, but don’t be. Think of it this way. When someone says they FedEx something, we know what the steps they went through. They wrapped the package, dropped it off, FedEx picked it up, flew it across the country, put it in a truck, and delivered it. When someone says “I Googled it”, we know what they did. They used a computer, with a web browser, at Google’s site, to search the internet for something.

Q: Yea, Ok, but everyone knows what FedEx and Google are, not everyone knows patterns.
A: Bingo. Now your making my point. You now see the value when people understand a common language. All I am suggesting is that we all try to improve our language skills to make it easier to communicate.

Q: Alright, maybe it is a good idea to learn a few of them. Where did they come from anyway?
A: People have always looked to more experienced coders for help. It is likely that experienced people have already run across similar problems and found a good way to fix them. Kind of like keeping a tool box of solutions in your back pocket.

Q: So, then Patterns are just random code examples that people have collected?
A: No, they are more basic than that. One of the best early attempts to collect patterns into a published work was by the Gang of Four mentioned earlier. They recognized that there were clearly defined solutions to problems that could be applied to almost any computer language.

Q: Almost any computer language?
A: Patterns usually focus on object orientated design principles, like those that we have talked about in earlier sessions. Some of the patterns are much harder to apply to languages that don’t use objects.

Q: Learning about Patterns is just building on what we have been learning?
A: Exactly. We have talked about objects, classes, interfaces, abstract classes, containment, and inheritance. We will use all of these ideas and principles as we look at patterns.

Q: Ok, so if Patterns are so great, why haven’t you brought it up yet?
A: I have. Remember the last unit, on Reflection? We talked about a Factory. Guess what? That is a pattern. We just hadn’t named it as one.

Q: Cool. These aren’t so bad.
A: Alright, are you ready to look at some more then?

Q: Wait a minute. I was just skimming the Head First Design Patterns book. Don’t they use the Q&A thing in there a lot? Did you steal that idea?
A: I didn’t steal it. I just applied the Pattern.

Q: Ok, fine. What’s first?
A: The next pattern we will look at is the Adapter Pattern.

Series NavigationIntro to Java AnnotationsIntro to Java Adapter Pattern