Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Standard Edition >

Amaze your developer friends with design patterns

<strong>Java Design Patterns</strong> column kicks off with a look at three important design patterns

By David Geary, JavaWorld.com, 10/12/01

  • Print
  • Feedback
.
Welcome to the first installment of JavaWorld's Java Design Patterns. This column will explore, strictly from a Java perspective, many of the design patterns discussed in Design Patterns by Gamma, Helm, Johnson, and Vlissides -- the so-called Gang of Four (GOF). Many regard that book, published by Addison-Wesley in 1994, as the seminal work regarding design patterns pertaining to object-oriented software development. Although it offers an excellent introduction to design patterns, all of the book's code examples are written in C++ or Smalltalk, both of which Java developers can find difficult to translate. In this column I will present those patterns with examples written exclusively in Java, eliminating the need to translate from C++ and Smalltalk, and perhaps more importantly, to illustrate how you can take full advantage of Java programming language features when you use and implement design patterns. Additionally, I will discuss how design patterns are used and implemented in the Java 2 Software Development Kit (SDK).

In this introductory installment of Java Design Patterns, I discuss the nature of design patterns and what benefits they provide. I conclude with a brief tour of three patterns implemented in the Java 2 SDK: Strategy, Composite, and Decorator. That discussion should whet your appetite, giving you some idea of the benefits of design patterns.

Besides using Java to implement design patterns, this column will also use the Unified Modeling Language (UML) to portray static relationships between classes and dynamic interactions between objects at runtime. For those new to UML, please consult the citations listed in Resources at the end of this article.

Subsequent articles will explore a single design pattern. Each article will contain a sample design pattern implementation useable as a starting point for your own implementations. And, where applicable, each article will also discuss an implementation of those patterns in the Java 2 SDK to further illustrate how those patterns are used and what benefits they provide.

Finally, I would like this column to be as interactive as possible. Please feel free to send me your comments and questions. If I get enough feedback, I will begin each subsequent article in this column by discussing a few of your questions.

Audience

I'm targeting this column for experienced Java developers who are, for the most part, unfamiliar with design patterns. As a reader of this column, you should have a good grasp of Java programming language constructs. For example, you should understand inner classes, and when it might be appropriate to use them. On the other hand, you do not need to be a language lawyer to benefit from this column; for example, you don't need to know, off the top of your head, the difference between nested and inner classes.

As a reader, you should also possess a minimal understanding of object-oriented design and development. For example, you should understand that classes encapsulate data and methods, and why encapsulation is important. You should also know what distinguishes object-oriented programming from programming with abstract data types (polymorphism), and why that distinction is important (because different kinds of objects with the same interface can be substituted for each other at runtime). If you don't have that basic understanding, you can readily obtain it by consulting some of the references cited at the end of this article. As we go along, I will explain other object-oriented concepts such as why you should favor object composition over class inheritance (because inheritance breaks encapsulation).

  • Print
  • Feedback

Resources