You’ll have no trouble understanding what an OO adapter is because the real world is full of them. How’s this for an example: Have you ever needed to use a US-made laptop in Great Britain? Then you’ve probably needed an AC power adapter...

You know what the adapter does: it sits in between the plug of your laptop and the British AC outlet; its job is to adapt the British outlet so that you can plug your laptop into it and receive power. Or look at it this way: the adapter changes the interface of the outlet into one that your laptop expects.

Some AC adapters are simple—they only change the shape of the outlet so that it matches your plug, and they pass the AC current straight through—but other adapters are more complex internally and may need to step the power up or down to match your devices’ needs.

Okay, that’s the real world; what about object-oriented adapters? Well, our OO adapters play the same role as their real-world counterparts: they take an interface and adapt it to one that a client is expecting.

Say you’ve got an existing software system that you need to work a new vendor class library into, but the new vendor designed their interfaces differently than the last vendor:

Okay, you don’t want to solve the problem by changing your existing code (and you can’t change the vendor’s code). So what do you do? Well, you can write a class that adapts the new vendor interface into the one you’re expecting.

The adapter acts as the middleman by receiving requests from the client and converting them into requests that make sense on the vendor classes.

It’s time to see an adapter in action. Remember our ducks from Chapter 1? Let’s review a slightly simplified version of the Duck interfaces and classes:

Here’s a subclass of Duck, the MallardDuck.

Now it’s time to meet the newest fowl on the block:

Now, let’s say you’re short on Duck objects and you’d like to use some Turkey objects in their place. Obviously we can’t use the turkeys outright because they have a different interface.

So, let’s write an Adapter:

Code Up Close

Now we just need some code to test drive our adapter:

Now that we have an idea of what an Adapter is, let’s step back and look at all the pieces again.

Enough ducks, turkeys, and AC power adapters; let’s get real and look at the official definition of the Adapter Pattern:

Now, we know this pattern allows us to use a client with an incompatible interface by creating an Adapter that does the conversion. This acts to decouple the client from the implemented interface, and if we expect the interface to change over time, the adapter encapsulates that change so that the client doesn’t have to be modified each time it needs to operate against a different interface.

We’ve taken a look at the runtime behavior of the pattern; let’s take a look at its class diagram as well:

The Adapter Pattern is full of good OO design principles: check out the use of object composition to wrap the adaptee with an altered interface. This approach has the added advantage that we can use an adapter with any subclass of the adaptee.

Also check out how the pattern binds the client to an interface, not an implementation; we could use several adapters, each converting a different backend set of classes. Or, we could add new implementations after the fact, as long as they adhere to the Target interface.

Now despite having defined the pattern, we haven’t told you the whole story yet. There are actually two kinds of adapters: object adapters and class adapters. This chapter has covered object adapters and the class diagram on the previous page is a diagram of an object adapter.

So what’s a class adapter and why haven’t we told you about it? Because you need multiple inheritance to implement it, which isn’t possible in Java. But, that doesn’t mean you might not encounter a need for class adapters down the road when using your favorite multiple inheritance language! Let’s look at the class diagram for multiple inheritance.

Look familiar? That’s right—the only difference is that with class adapter we subclass the Target and the Adaptee, while with object adapter we use composition to pass requests to an Adaptee.

Duck Magnets

Your job is to take the duck and turkey magnets and drag them over the part of the diagram that describes the role played by that bird, in our earlier example. (Try not to flip back through the pages.) Then add your own annotations to describe how it works.

Class Adapter

Object Adapter

Drag these onto the class diagram, to show which part of the diagram represents the Duck and which represents the Turkey.

Duck Magnets Answer

Note

Note: the class adapter uses multiple inheritance, so you can’t do it in Java...

Class Adapter

Object Adapter

Let’s take a look at the use of a simple Adapter in the real world (something more serious than Ducks at least)...

Old-world Enumerators

If you’ve been around Java for a while you probably remember that the early collection types (Vector, Stack, Hashtable, and a few others) implement a method, elements(), which returns an Enumeration. The Enumeration interface allows you to step through the elements of a collection without knowing the specifics of how they are managed in the collection.

New-world Iterators

The newer Collection classes use an Iterator interface that, like Enumeration, allows you to iterate through a set of items in a collection, but also adds the ability to remove items.

First we’ll look at the two interfaces to figure out how the methods map from one to the other. In other words, we’ll figure out what to call on the adaptee when the client invokes a method on the target.

Designing the Adapter

Here’s what the classes should look like: we need an adapter that implements the Target interface and that is composed with an adaptee. The hasNext() and next() methods are going to be straightforward to map from target to adaptee: we just pass them right through. But what do you do about remove()? Think about it for a moment (and we’ll deal with it on the next page). For now, here’s the class diagram:

Writing the EnumerationIterator adapter

Here’s simple but effective code for all those legacy classes still producing Enumerations:

Exercise

While Java has gone in the direction of the Iterator, there is nevertheless a lot of legacy client code that depends on the Enumeration interface, so an Adapter that converts an Iterator to an Enumeration is also quite useful.

Write an Adapter that adapts an Iterator to an Enumeration. You can test your code by adapting an ArrayList. The ArrayList class supports the Iterator interface but doesn’t support Enumerations (well, not yet anyway).

Brain Power

Some AC adapters do more than just change the interface—they add other features like surge protection, indicator lights, and other bells and whistles.

If you were going to implement these kinds of features, what pattern would you use?

Fireside Chats

Tonight’s talk: The Decorator Pattern and the Adapter Pattern discuss their differences.

Decorator:	Adapter:
I’m important. My job is all about responsibility—you know that when a Decorator is involved there’s going to be some new responsibilities or behaviors added to your design.
	You guys want all the glory while us adapters are down in the trenches doing the dirty work: converting interfaces. Our jobs may not be glamorous, but our clients sure do appreciate us making their lives simpler.
That may be true, but don’t think we don’t work hard. When we have to decorate a big interface, whoa, that can take a lot of code.
	Try being an adapter when you’ve got to bring several classes together to provide the interface your client is expecting. Now that’s tough. But we have a saying: “an uncoupled client is a happy client.”
Cute. Don’t think we get all the glory; sometimes I’m just one decorator that is being wrapped by who knows how many other decorators. When a method call gets delegated to you, you have no idea how many other decorators have already dealt with it and you don’t know that you’ll ever get noticed for your efforts servicing the request.
	Hey, if adapters are doing their job, our clients never even know we’re there. It can be a thankless job.
	But, the great thing about us adapters is that we allow clients to make use of new libraries and subsets without changing any code; they just rely on us to do the conversion for them. Hey, it’s a niche, but we’re good at it.
Well, us decorators do that as well, only we allow new behavior to be added to classes without altering existing code. I still say that adapters are just fancy decorators—I mean, just like us, you wrap an object.
	No, no, no, not at all. We always convert the interface of what we wrap; you never do. I’d say a decorator is like an adapter; it is just that you don’t change the interface!
Uh, no. Our job in life is to extend the behaviors or responsibilities of the objects we wrap; we aren’t a simple pass through.
	Hey, who are you calling a simple pass through? Come on down and we’ll see how long you last converting a few interfaces!
Maybe we should agree to disagree. We seem to look somewhat similar on paper, but clearly we are miles apart in our intent.
	Oh yeah, I’m with you there.

There’s another pattern in this chapter.

You’ve seen how the Adapter Pattern converts the interface of a class into one that a client is expecting. You also know we achieve this in Java by wrapping the object that has an incompatible interface with an object that implements the correct one.

We’re going to look at a pattern now that alters an interface, but for a different reason: to simplify the interface. It’s aptly named the Facade Pattern because this pattern hides all the complexity of one or more classes behind a clean, well-lit facade.

Before we dive into the details of the Facade Pattern, let’s take a look at a growing national obsession: building your own home theater.

You’ve done your research and you’ve assembled a killer system complete with a DVD player, a projection video system, an automated screen, surround sound, and even a popcorn popper.

Check out all the components you’ve put together:

You’ve spent weeks running wire, mounting the projector, making all the connections, and fine tuning. Now it’s time to put it all in motion and enjoy a movie...

Pick out a DVD, relax, and get ready for movie magic. Oh, there’s just one thing—to watch the movie, you need to perform a few tasks:

Let’s check out those same tasks in terms of the classes and the method calls needed to perform them:

But there’s more...

So what to do? The complexity of using your home theater is becoming apparent!

Let’s see how the Facade Pattern can get us out of this mess so we can enjoy the movie...

A Facade is just what you need: with the Facade Pattern you can take a complex subsystem and make it easier to use by implementing a Facade class that provides one, more reasonable interface. Don’t worry; if you need the power of the complex subsystem, it’s still there for you to use, but if all you need is a straightforward interface, the Facade is there for you.

Let’s take a look at how the Facade operates:

Let’s step through the construction of the HomeTheaterFacade. The first step is to use composition so that the facade has access to all the components of the subsystem:

Now it’s time to bring the components of the subsystem together into a unified interface. Let’s implement the watchMovie() and endMovie() methods:

It’s SHOWTIME!

To use the Facade Pattern, we create a class that simplifies and unifies a set of more complex classes that belong to some subsystem. Unlike a lot of patterns, Facade is fairly straightforward; there are no mind-bending abstractions to get your head around. But that doesn’t make it any less powerful: the Facade Pattern allows us to avoid tight coupling between clients and subsystems, and, as you will see shortly, also helps us adhere to a new object-oriented principle.

Before we introduce that new principle, let’s take a look at the official definition of the pattern:

There isn’t a lot here that you don’t already know, but one of the most important things to remember about a pattern is its intent. This definition tells us loud and clear that the purpose of the facade is to make a subsystem easier to use through a simplified interface. You can see this in the pattern’s class diagram:

That’s it; you’ve got another pattern under your belt! Now, it’s time for that new OO principle. Watch out, this one can challenge some assumptions!

The Principle of Least Knowledge guides us to reduce the interactions between objects to just a few close “friends.” The principle is usually stated as:

But what does this mean in real terms? It means when you are designing a system, for any object, be careful of the number of classes it interacts with and also how it comes to interact with those classes.

This principle prevents us from creating designs that have a large number of classes coupled together so that changes in one part of the system cascade to other parts. When you build a lot of dependencies between many classes, you are building a fragile system that will be costly to maintain and complex for others to understand.

public float getTemp() {
    return station.getThermometer().getTemperature();
}

Okay, but how do you keep from doing this? The principle provides some guidelines: take any object; now from any method in that object, the principle tells us that we should only invoke methods that belong to:

This sounds kind of stringent doesn’t it? What’s the harm in calling the method of an object we get back from another call? Well, if we were to do that, then we’d be making a request of another object’s subpart (and increasing the number of objects we directly know). In such cases, the principle forces us to ask the object to make the request for us; that way we don’t have to know about its component objects (and we keep our circle of friends small). For example:

Keeping your method calls in bounds...

Here’s a Car class that demonstrates all the ways you can call methods and still adhere to the Principle of Least Knowledge:

There Are No Dumb Questions

Q:	Q: There is another principle called the Law of Demeter; how are they related?
A:	A: The two are one and the same and you’ll encounter these terms being used interchangeably. We prefer to use the Principle of Least Knowledge for a couple of reasons: (1) the name is more intuitive and (2) the use of the word “Law” implies we always have to apply this principle. In fact, no principle is a law, all principles should be used when and where they are helpful. All design involves tradeoffs (abstractions versus speed, space versus time, and so on) and while principles provide guidance, all factors should be taken into account before applying them.
Q:	Q: Are there any disadvantages to applying the Principle of Least Knowledge?
A:	A: Yes; while the principle reduces the dependencies between objects and studies have shown this reduces software maintenance, it is also the case that applying this principle results in more “wrapper” classes being written to handle method calls to other components. This can result in increased complexity and development time as well as decreased runtime performance.

Sharpen your pencil

Do either of these classes violate the Principle of Least Knowledge? Why or why not?

Brain Power

Q:	Can you think of a common use of Java that violates the Principle of Least Knowledge? Should you care?
A:	Answer: How about System.out.println()?

Your toolbox is starting to get heavy! In this chapter we’ve added a couple of patterns that allow us to alter interfaces and reduce coupling between clients and the systems they use.

Design Patterns Crossword

Yes, it’s another crossword. All of the solution words are from this chapter.

Across

Down

1. True or false? Adapters can wrap only one object. 5. An Adapter __________ an interface. 6. Movie we watched (five words). 10. If in Britain, you might need one of these (two words). 11. Adapter with two roles (two words). 14. Facade still ________ low-level access. 15. Ducks do it better than Turkeys. 16. Disadvantage of the Principle of Least Knowledge: too many __________. 17. A __________ simplifies an interface. 19. New American dream (two words).

2. Decorator called Adapter this (three words). 3. One advantage of Facade. 4. Principle that wasn’t as easy as it sounded (two words). 7. A __________ adds new behavior. 8. Masquerading as a Duck. 9. Example that violates the Principle of Least Knowledge: System.out.__________. 12. No movie is complete without this. 13. Adapter client uses the __________ interface. 18. An Adapter and a Decorator can be said to ________ an object.

Sharpen your pencil Solution

Let’s say we also need an Adapter that converts a Duck to a Turkey. Let’s call it DuckAdapter. Here’s our solution:

Sharpen your pencil Solution

Do either of these classes violate the Principle of Least Knowledge? Why or why not?

Exercise Solution

You’ve seen how to implement an adapter that adapts an Enumeration to an Iterator; now write an adapter that adapts an Iterator to an Enumeration.

Who Does What? Solution

Match each pattern with its intent:

Design Patterns Crossword Solution