New to Java? We'll help you get started with our revised beginner's tutorial, or our free online textbook.

Get the latest Java books
h t t p : / /w w w . j a v a c o f f e e b r e a k . c o m /

Java Coffee Break


Learning Java

Author Profiles
Talk Java!

Using Java

Discuss Java

Looking for Java resources? Check out the Java Coffee Break directory!

Java Profiles

Mark Grand

Mark Grand Mark Grand is the author of a series of books titled Patterns in Java, which teach the basics of design patterns and provide examples of their implementation in the Java programming language.  He is also currently one of the architects of an open-source application framework for e-commerce called Hatchware. In this exclusive interview, we talk with Mark about design patterns.

Q: You've written extensively on the topic of design patterns in Java. For the benefit of people unsure exactly what one is, how would you define a design pattern?

A: A very simple definition for a pattern is a reusable solution to a recurring problem. A design pattern is a pattern that solves a software design problem.

Some other pattern writers take exception to such a simple definition of
pattern, because it does not address important form and style issues. For people who may be interested in reading patterns, I think this definition is good enough.

Q: Design patterns are very popular with developers using
languages like C++. There's a range of books aimed at a C++ audience, but a relatively small amount of titles for Java. How does Java stack up to C++ in general, and specifically with regard to design patterns.

A: There has been much material written that compares Java and C++. Most design patterns are language neutral, although the specific solution that they propose may be slanted towards a particular language. The differences that you see are typical of the language's different object models. Where you may see multiple inheritance or abstract classes in an example oriented towards C++, you will usually see interfaces in a Java oriented solution.

Another difference that you find is in applying some patterns. C++ gives
you more than one way of doing many things, where Java give you just one. For example, C++ allows an object to contain a value or a pointer to the value. This means having to make more decisions in how to apply a pattern.

Q: Do you find the lack of certain C++ features like multiple inheritance and generic types in Java a hindrance when designing software, or do they make object designs simpler?

A: As you may guess from my previous response, I generally find that my designs are simpler when designing for Java. Multiple inheritence is something that I rarely use. Generic types simplify coding, but do not have much impact on design. I understand that JavaSoft has looked at some proposal for generic types, but has not acted on the proposals yet.

Q: You've written two volumes on Java design patterns, and I understand a third volume is underway. What can readers expect to gain from these books? Does an understanding of design patterns make life easier on programmers, make software more robust and reliable, or are there productivity bonuses?

A: Experience gives programmers a variety of wisdom. As programmers gain experience, they recognize the similarity of new problems to problems they have solved before. With even more experience, they recognize that the solutions for similar problems follow recurring patterns. With the knowledge of these patterns, experienced programmers recognize the situations where patterns apply and immediately use the solution without having to stop, analyze the problem, and then pose possible strategies.

When a programmer discovers a pattern, it's just an insight. In most cases, to go from an unverbalized insight to a well thought-out idea that the programmer can clearly articulate is surprisingly difficult. It's also an extremely valuable step. When we understand a pattern well enough to put it into words, we are able to intelligently combine it with other patterns. More importantly, once put into words, a pattern can be used in discussions among programmers who know the pattern. That allows programmers to more effectively collaborate and combine their wisdom. It can also help to avoid the situation where programmers argue over different solutions to a problem, only to find out later that they were really thinking of the same solution but expressing it in different ways.

Putting a pattern into words has an additional benefit for less experienced programmers who have not yet discovered the pattern. Once a pattern has been put into words, more experienced programmers can teach it to programmers who aren't familiar with the pattern.

The Patterns in Java books I have written provide experienced programmers with a common vocabulary to discuss patterns. It also allows programmers who have not yet discovered a pattern to learn about the pattern.

Each of the volumes of Patterns in Java have a different focus.

The first volume is about micro-architecture design patterns. The patterns in there tend to focus on issues such as how to create objects, organize behavior, manage complexity and multi-threading.

The pattern topics that the second volume covers include patters for GUI design, coding and testing. I wrote that with the idea that people can use information about patterns outside of the design realm.

The third volume of Patterns in Java will focus on design patterns for
enterprise and distributed applications. There seems to be a lot of
interest in it. I am behind schedule, but I am still hoping that it will be
out before the end of the year. The current working outline is at 

I still need people to review some of my chapters, if any of your readers
would be interested.

Q: Design patterns are often expressed using Unified Modeling Language notation. What's your opinion of UML diagrams? While many universities now teach UML diagrams, do you think that they're accessible to the average programmer?

A: There are really two issues in your questions. UML is just a notation for expressing software designs. I like it because its basic feature set is
focused on the essentials. There are some specialized design details, such as thread synchronization semantics, that UML does not provide a good way to express.

Because UML is just a notation for expressing software designs rather than a full blown design methodology, it is possible to learn UML without knowing much about software design.

The reason that I have chosen to use UML in my books is that it is currently the most popular notation for software designs.

Q: Thanks for your perspective on design patterns, Mark - they certainly appear to be an important topic for developers. Readers interested in learning more about design patterns will find the Patterns in Java series available in your local bookstore, or online from 

Back to main

Copyright 1998, 1999, 2000 David Reilly

Privacy | Legal | Linking | Advertise!

Last updated: Monday, June 05, 2006