Design Patterns Defined

Whether you are a software manager, designer, engineer, or student, design patterns are the best foundation on which to design and build software projects. One of the first examples of applying design patterns to software was in the classic book Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995), written by the Gang of Four (GoF) ”Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. This chapter helps you bridge the gap between the highly abstract GoF presentation and the real-world challenges of writing code. If design patterns are used as Sun suggests, and this chapter echoes, they become a core asset of any software shop. Patterns show developers how to systematically solve problems created by market and technology forces.

So where do design patterns fit in the design hierarchy? You often hear about two-tier, three-tier, and multitier applications. The number of tiers refers to the number of major responsibilities. For example, a three- tier application has presentation, logic, and database tiers. Another way of thinking about an application is in layers of abstractions, from most granular to most general, as described in the following list:

• Token ( int seatNumber )

• Statement ( seatNumber = 25; )

• Block ( while(true){} )

• Algorithm (seat search)

• Object ( SuperBowlSeat )

• Design Pattern (Value Object)

• Framework (Collections framework)

• Architecture (GUI ”RMI ”database)

• Solution (certification submission)

You need to traverse all these layers to produce a successful solution. Although the Token and Statement layers are simple, the remaining layers require increasingly sophisticated ideas. In fact, I propose that starting at the Algorithm layer, the evaluator should begin deducting points if the algorithm isn't designed right. The seat search (your instructions might call it something like "criteria search") is actually listed in the scoring section of the instructions. The instructions also name specific design patterns. You will definitely use the Model-View-Controller (MVC) pattern in the GUI (Swing technology is built with it), and most candidates use Value Object for transporting database query results back to the requesting GUI (the approach my solution used through RMI). Your evaluator hopes to find good use of preexisting J2SE classes throughout your code. For example, my lock manager used the Collection framework in the form of a HashMap . Evaluators would rather see smart reuse than invention. Last, your architecture has to be effective. A GUI ”socket ”RMI ”database architecture, for example, would be weak because the socket portion, which is already implemented in RMI, is unnecessary. This chapter defines and describes the patterns you will most likely use in your solution and throughout your career as you address enterprise design needs.

The term "pattern" comes from the architect Christopher Alexander, who wrote several books on the topic of patterns. Alexander, a building architect, was the first to "codify" patterns for architecture. Although he was interested in urban planning and building architecture, his notions were clearly useful in many areas and isolated the concept of patterns better than anyone before him. Alexander is one of those rare people who take a step back and question why people do things the way they do. He gave the result of his inquiry the name "pattern language" and defined it at length in his seminal book, A Pattern Language: Towns, Buildings , Construction (by Christopher Alexander, Sara Ishikawa, and Murray Silverstein; Oxford University Press, 1977).

While Alexander was thinking buildings and foundations, it became clear to many that his design patterns were abstract enough to be useful elsewhere. That is when the GoF applied patterns to software in Design Patterns: Elements of Reusable Object-Oriented Software . It took a while, but the GoF started a groundswell. There are now dozens of books, and many more on the way, about design patterns.

Design patterns are often defined as "a solution to a problem in a context." This falls short of the abstract definition that experts prefer, however. Suppose you have an object that makes copies of files. What is the design pattern? You don't know yet, so throw in an object that copies the content of one text box to another. Something about the copying process is the same between the two objects. Neither the files nor the text boxes differ , but the copying is the same. Therefore, the sameness is copying. By itself, this isn't a pattern, but you're on the way to finding one.

What are design patterns? Sun defines them in the following way: "A design pattern describes a proven solution to a recurring design problem, placing particular emphasis on the context and forces surrounding the problem, and the consequences and impact of the solution."

Design Pattern Elements

There are many ways to define a pattern, but the classic way is to describe its elements or aspects. There are several lists of elements in the current literature. I've used a dolled-up version of the GoF's approach, which centers on three basic elements ” context, problem , and solution :

• Context is the recurring situation in which you find a problem to be solved .

• Problems are the so-called forces, such as marketing and technology, that occur in this context.

• Solution is the defined design that reorganizes or manipulates (some say "resolves") the forces on a situation into a desired outcome. This solution applies to a specific context and might not apply to others.

The design pattern is not only these three elements, but the relationship between them and the formal language that describes the whole business. That is a lot of heady language and is certainly not on the exam directly, but understanding these relationships will help you select and correctly apply design patterns to your solution.

Remember that context, problem, and solution are at the core of design patterns. The following list of pattern elements is my way of expanding on the three basic elements to give you a way to understand the essence of a given pattern:

• Is ” This element is a direct explanation of what the pattern is, without jargon.

• Is Not ” This element is an attempt at providing a contrasting concept because often looking at what something isn't helps clarify the pattern as much as looking at what it is .

• Analogy ” This element provides a comparison based on general aspects of the pattern. Analogies give you a way to relate a concept you're already familiar with to the pattern.

• Problem ” This element is a statement of the problem that describes the pattern's purpose and intent.

• Responsibility ” This element describes what the pattern is accountable for ”the primary things it accomplishes.

• Intent (or goals and constraints) ” This element contains the goals and objectives the pattern should accomplish within the given context.

• Primary Activity ” A pattern is helpful, but this element describes the main responsibility or work the pattern must perform.

• Context ” This element describes the conditions and environment in which the problem and its solution recur. In other words, when should you consider and apply this pattern?

• Motivation or Forces ” This element describes the forces that affect the context and explains why you would use this pattern and the advantages it offers.

• Applicability ” This elements describes which kinds of situations are good candidates for this pattern.

• Solution ” This element consists of two parts :

  • Strategy ” This part explains how you should go about applying the pattern.

  • Pseudo Code ” This part helps you see how you might actually implement the pattern, to extend the concept to actual practice.

• Consequences ” This element describes the result of using the pattern, the final state of the system. There are good and bad consequences of applying the pattern. It could solve one problem, for example, but give rise to a new one.

• Known Uses ” This element offers one or more examples of how the pattern is being used.

• Related Patterns ” This element names other patterns related by context, solution, or consequences. The related pattern might solve the same problem in another way or share the same context, but involve different forces.

• Reference ” This element points you to a resource that provides more material on the pattern.