Weisfeld. The object-oriented thought process
Подождите немного. Документ загружается.
294
Chapter 15 Design Patterns
Figure 15.4 Using the Counter singleton.
Counter counter1 = Counter.getInstance();
System.out.println(“Counter : “ + counter1.getCounter() );
Counter counter2 = Counter.getInstance();
System.out.println(“Counter : “ + counter2.getCounter() );
}
}
Two References to a Single Counter
Be aware that in this example, there are two separate references pointing to the counter.
This code actually uses the Counter singleton.Take a look at how the objects are cre-
ated:
Counter counter1 = Counter.getInstance();
The constructor is not used here.The instantiation of the object is controlled by the
getInstance() method. Figure 15.4 shows what happens when this code is executed.
Note that the message New instance created is only output a single time.When
counter2 is created, it receives a copy of the original object—the same as counter1.
Let’s prove that the references for counter1 and counter2 are the same.We can update
the application code as follows:
package Counter;
public class Singleton
{
public static void main(String[] args)
{
295
Types of Design Patterns
Counter counter1 = Counter.getInstance();
counter1.incrementCounter();
counter1.incrementCounter();
System.out.println(“Counter : “ + counter1.getCounter() );
Counter counter2 = Counter.getInstance();
counter2.incrementCounter();
System.out.println(“Counter : “ + counter2.getCounter() );
}
}
Figure 15.5 shows the output from the singleton application. Note that in this case, we
are incrementing counter1 twice, so the counter will be 2.When we create the counter2
reference, it references the same object as counter1, so when we increment the counter,
it’s now 3 (2+1).
Structural Patterns
Structural patterns are used to create larger structures from groups of objects.The follow-
ing seven design patterns are members of the structural category.
n
Adapter
n
Bridge
n
Composite
n
Decorator
n
Façade
n
Flyweight
n
Proxy
Figure 15.5 Using the updated Counter singleton.
296
Chapter 15 Design Patterns
As an example from the structural category, let’s take a look at the adapter pattern.The
adapter pattern is also one of the most important design patterns.This pattern is a good
example of how the implementation and interface are separated.
The Adapter Design Pattern
The adapter pattern is a way for you to create a different interface for a class that already
exists.The adapter pattern basically provides a class wrapper. In other words, you create a
new class that incorporates (wraps) the functionality of an existing class with a new and—
ideally—better interface.A simple example of a wrapper is the Java class Integer.The
Integer class actually wraps a single Integer value inside it.You might wonder why you
would bother to do this. Remember that in an object-oriented system, everything is an
object. In Java, primitives, such as ints, floats, and so on are not actually objects.When you
need to perform functions on these primitives, such as conversions, you need to treat
them as objects.Thus, you create a wrapper object and “wrap” the primitive inside it.
Thus, you can take a primitive like the following:
int myInt = 10;
and then wrap it in an Integer object:
Integer myIntWrapper = new Integer (myInt);
Now you can do a conversion, so we can treat it as a string:
String myString = myIntWrapper.toString();
This wrapper allows us to treat the original integer as an object, thus providing all the
advantages of an object.
As for the adapter pattern itself, consider the example of a mail tool interface. Let’s as-
sume you have purchased some code that provides all the functionality you need to im-
plement a mail client.This tool provides everything you want in a mail client, except you
would like to change the interface slightly. In fact, all you want to do is change the API to
retrieve your mail.
The following class provides a very simple example of a mail client for this example.
package MailTool;
public class MailTool {
public MailTool () {
}
public int retrieveMail() {
System.out.println (“You’ve Got Mail”);
return 0;
}
}
297
Types of Design Patterns
When you invoke the retrieveMail() method, your mail is presented with the very
original greeting “You’ve Got Mail.” Now let’s suppose you want to change the interface
in all your company’s clients from retrieveMail() to getMail().You can create an in-
terface to enforce this:
package MailTool;
interface MailInterface {
int getMail();
}
You can now create your own mail tool that wraps the original tool and provide your
own interface:
package MailTool;
class MyMailTool implements MailInterface {
private MailTool yourMailTool;
public MyMailTool () {
yourMailTool= new MailTool();
setYourMailTool(yourMailTool);
}
public int getMail() {
return getYourMailTool().retrieveMail();
}
public MailTool getYourMailTool() {
return yourMailTool ;
}
public void setYourMailTool(MailTool newYourMailTool) {
yourMailTool = newYourMailTool;
}
}
Inside this class, you create an instance of the original mail tool that you want to retro-
fit.This class implements MailInterface, which will force you to implement a
getMail() method. Inside this method, you literally invoke the retrieveMail() method
of the original mail tool.
To use your new class, you simply instantiate your new mail tool and invoke the
getMail() method.
package MailTool;
public class Adapter
{
public static void main(String[] args)
{
MyMailTool myMailTool = new MyMailTool();
myMailTool.getMail();
}
}
298
Chapter 15 Design Patterns
When you do invoke the getMail() method, you are using this new interface to actu-
ally invoke the retrieveMail() method from the original tool.This, of course, is a very
simple example; however, by creating this wrapper, you can actually enhance the interface
and add your own functionality to the original class.
The concept of an adapter is quite simple, but you can create new and powerful inter-
faces using this pattern.
Behavioral Patterns
The behavioral patterns consist of the following categories:
n
Chain of response
n
Command
n
Interpreter
n
Iterator
n
Mediator
n
Memento
n
Observer
n
State
n
Strategy
n
Template method
n
Visitor
As an example from the behavioral category, let’s take a look at the iterator pattern.
This is one of the most commonly used patterns and is implemented by several program-
ming languages.
The Iterator Design Pattern
Iterators provide a standard mechanism for traversing a collection, such as a vector. Func-
tionality must be provided so that each item of the collection can be accessed one at a
time.The iterator pattern provides information hiding, keeping the internal structure of
the collection secure.The iterator pattern also stipulates that more than one iterator can
be created without interfering with each other. Java actually provides its own implemen-
tation of an iterator.The following code creates a vector and then inserts a number of
strings into it.
package Iterator;
import java.util.*;
299
Antipatterns
public class Iterator {
public static void main(String args[]) {
// Instantiate an ArrayList.
ArrayList<String> names = new ArrayList();
// Add values to the ArrayList
names.add(new String(“Joe”));
names.add(new String(“Mary”));
names.add(new String(“Bob”));
names.add(new String(“Sue”));
//Now Iterate through the names
System.out.println(“Names:”);
iterate(names );
}
private static void iterate(ArrayList<String> arl) {
for(String listItem : arl) {
System.out.println(listItem.toString());
}
}
}
Then we create an enumeration so that we can iterate through it.The method
iterate() is provided to perform the actual iteration functionality. In this method, we
use the Java enumeration method hasMoreElements(), which traverses the vector and
lists all of the names.
Antipatterns
Although a design pattern evolves from experiences in a positive manner, antipatterns can be
thought of as collections of experiences that have gone awry. It is well documented that
most software projects are ultimately deemed unsuccessful. In fact, as indicated in the article
“Creating Chaos” by Johnny Johnson, fully one-third of all projects are cancelled outright.
It would seem obvious that many of these failures are caused by poor design decisions.
The term antipattern derives from the fact that design patterns are created to proac-
tively solve a specific type of problem.An antipattern, on the other hand, is a reaction to a
problem and is gleaned from bad experiences. In short, whereas design patterns are based
on solid design practices, antipatterns can be thought of as practices to avoid.
In the November 1995 C++ Report,Andrew Koenig described two facets of antipatterns:
n
Those that describe a bad solution to a problem, which result in a bad situation
n
Those that describe how to get out of a bad situation and how to proceed from
there to a good solution
300
Chapter 15 Design Patterns
Many people believe that antipatterns are actually more useful than design patterns.This
is because antipatterns are designed to solve problems that have already occurred.This
boils down to the concept of root-cause analysis.A study can be conducted with actual
data that might indicate why the original design, perhaps an actual design pattern, did not
succeed. It might be said that antipatterns emerge from the failure of previous solutions.
Thus, antipatterns have the benefit of hindsight.
For example, in his article “Reuse Patterns and Antipatterns,” Scott Ambler identifies a
pattern called a robust artifact, and defines it as follows:
An item that is well-documented, built to meet general needs instead of project-specific needs,
thoroughly tested, and has several examples to show how to work with it. Items with these qual-
ities are much more likely to be reused than items without them. A Robust Artifact is an item
that is easy to understand and work with.
However, there are certainly many situations when a solution is declared reusable and
then no one ever reuses it.Thus, to illustrate an antipattern, he writes:
Someone other than the original developer must review a Reuseless Artifact to determine
whether or not anyone might be interested in it. If so, the artifact must be reworked to become
a Robust Artifact.
Thus, antipatterns lead to the revision of existing designs, and the continuous refactoring
of those designs until a workable solution is found.
Conclusion
In this chapter, we explored the concept of design patterns. Patterns are part of everyday
life, and this is just the way you should be thinking about object-oriented designs.As with
many things pertaining to information technology, the roots for solutions are founded in
real-life situations.
Although this chapter covered design patterns only briefly, you should explore this topic
in greater detail by picking up one of the books referenced at the end of this chapter.
References
Alexander, Christopher, et al. A Pattern Language:Towns, Buildings, Construction. Oxford
University Press, 1977. Cambridge, United Kingdom.
Gamma, Erich, et al. Design Patterns: Elements of Reusable Object-Oriented Software.Addison-
Wesley, 1995. Boston, MA.
Larman, Craig. Applying UML and Patterns:An Introduction to Object-Oriented Analysis and
Design and Iterative Development, 3rd ed.Wiley, 2004. Hoboken, NJ.
Grand, Mark. Patterns in Java:A Catalog of Reusable Design Patterns Illustrated with UML,
2nd ed.,Volume 1.Wiley, 2002.
Ambler, Scott.“Reuse Patterns and Antipatterns.” 2000 Software Development Magazine.
Jaworski, Jamie. Java 2 Platform Unleashed. Sams Publishing, 1999. Indianapolis, IN.
Johnson, Johnny.“Creating Chaos.” American Programmer, July 1995.
301
Example Code Used in This Chapter
Example Code Used in This Chapter
The following code is presented in C# .NET and VB .NET.These examples correspond
to the Java code that is listed inside the chapter itself.
C# .NET
Counter.cs
using System;
using System.Collections.Generic;
using System.Text;
namespace Counter
{
class Counter
{
private int counter;
private static Counter instance = null;
protected Counter()
{
}
public static Counter getInstance()
{
if (instance == null)
{
instance = new Counter();
Console.WriteLine(“New Instance of Counter...”);
}
return instance;
}
public void incrementCounter()
{
counter++;
}
public int getCounter()
{
return counter;
}
}
}
302
Chapter 15 Design Patterns
Singleton.cs
using System;
using System.Collections.Generic;
using System.Text;
namespace Counter
{
class Singleton
{
public Singleton()
{
Counter counter1 = Counter.getInstance();
counter1.incrementCounter();
counter1.incrementCounter();
Console.WriteLine(“Counter = “ + counter1.getCounter());
Counter counter2 = Counter.getInstance();
counter2.incrementCounter();
Console.WriteLine(“Counter = “ + counter2.getCounter());
Console.WriteLine(“Press any key to continue...”);
Console.ReadKey();
}
}
}
MailTool.cs
using System;
namespace MailAdapter
{
class MailTool
{
public MailTool()
{
}
public int retrieveMail()
{
Console.WriteLine(“You’ve got mail!”);
return 0;
}
}
}
303
Example Code Used in This Chapter
Mailinterface.cs
using System;
using System.Collections.Generic;
using System.Text;
namespace MailAdapter
{
interface MailInterface
{
int getMail();
}
}
MyMail.cs
namespace MailAdapter
{
class MyMailTool : MailInterface
{
private MailTool yourMailTool;
public MyMailTool()
{
yourMailTool = new MailTool();
setYourMailTool(yourMailTool);
}
public int getMail()
{
return getYourMailTool().retrieveMail();
}
public MailTool getYourMailTool()
{
return yourMailTool;
}
public void setYourMailTool(MailTool newYourMailTool)
{
yourMailTool = newYourMailTool;
}
}
}
Adapter.cs
using System;
using System.Collections.Generic;