Design Patterns - Discussion of Structural Patterns
The document discusses the similarities and differences between various structural design patterns, specifically Adapter, Bridge, Composite, Decorator, and Proxy. It highlights how Adapter resolves incompatibilities between interfaces while Bridge allows for multiple implementations of an abstraction. Additionally, it explains that Composite and Decorator both use recursive composition but serve different purposes, with Composite focusing on uniform treatment of related objects and Decorator allowing for dynamic addition of responsibilities.
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
0 ratings0% found this document useful (0 votes)
4 views2 pages
Design Patterns - Discussion of Structural Patterns
The document discusses the similarities and differences between various structural design patterns, specifically Adapter, Bridge, Composite, Decorator, and Proxy. It highlights how Adapter resolves incompatibilities between interfaces while Bridge allows for multiple implementations of an abstraction. Additionally, it explains that Composite and Decorator both use recursive composition but serve different purposes, with Composite focusing on uniform treatment of related objects and Decorator allowing for dynamic addition of responsibilities.
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
You are on page 1/ 2
DISCUSSION OF STRUCTURAL PATTERNS 219
Discussion of Structural Patterns
You may have noticed similarities between the structural patterns, especially in their
participants and collaborations. This is so probably because structural patterns rely on
the same small set of language mechanisms for structuring code and objects: single
and multiple inheritance for class-based patterns, and object composition for object
patterns. But the similarities belie the different intents among these patterns. In this
section we compare and contrast groups of structural patterns to give you a feel for
their relative merits.
Adapter versus Bridge
‘The Adapter (139) and Bridge (151) patterns have some common attributes. Both pro-
mote flexibility by providing a level of indirection to another object. Both involve
forwarding requests to this object from an interface other than its own.
The key difference between these patterns lies in their intents. Adapter focuses on
tesolving incompatibilities between two existing interfaces. It doesn’t focus on how
those interfaces are implemented, nor does it consider how they might evolve inde-
pendently. It’s a way of making two independently designed classes work together
without reimplementing one or the other. Bridge, on the other hand, bridges an ab-
straction and its (potentially numerous) implementations. It provides a stable interface
to clients even as it lets you vary the classes that implement it. It also accommodates
new implementations as the system evolves.
‘As a result of these differences, Adapter and Bridge are often used at different points
in the software lifecycle. An adapter often becomes necessary when you discover that
two incompatible classes should work together, generally to avoid replicating code. The
coupling is unforeseen. In contrast, the user of a bridge understands up-front that an
abstraction must have several implementations, and both may evolve independently.
The Adapter pattern makes things work afier they’re designed; Bridge makes them
work before they are. That doesn’t mean Adapter is somehow inferior to Bridge; each
pattem merely addresses a different problem.
You might think of a facade (see Facade (185)) as an adapter to a set of other objects. But
that interpretation overlooks the fact that a facade defines a new interface, whereas an
adapter reuses an old interface. Remember that an adapter makes two existing interfaces
work together as opposed to defining an entirely new one.
Composite versus Decorator versus Proxy
Composite (163) and Decorator (175) have similar structure diagrams, reflecting the fact
that both rely on recursive composition to organize an open-ended number of objects.
This commonality might tempt you to think of a decorator object as a degenerate220 STRUCTURAL PATTERNS CHAPTER 4
composite, but that misses the point of the Decorator pattern. The similarity ends at
recursive composition, again because of differing intents.
Decorator is designed to let you add responsibilities to objects without subclassing. It
avoids the explosion of subclasses that can arise from trying to cover every combination
of responsibilities statically. Composite has a different intent. It focuses on structuring
classes so that many related objects can be treated uniformly, and multiple objects can
be treated as one. Its focus is not on embellishment but on representation.
These intents are distinct but complementary. Consequently, the Composite and Deco-
rator patterns are often used in concert. Both lead to the kind of design in which you can
build applications just by plugging objects together without defining any new classes
There will be an abstract class with some subclasses that are composites, some that are
decorators, and some that implement the fundamental building blocks of the system.
In this case, both composites and decorators will have a common interface. From the
point of view of the Decorator pattern, a composite is a ConcreteComponent. From the
point of view of the Composite pattern, a decorator is a Leaf. Of course, they don’t have
to be used together and, as we have seen, their intents are quite different.
Another pattern with a structure similar to Decorator’s is Proxy (207). Both patterns
describe how to provide a level of indirection to an object, and the implementations of
both the proxy and decorator object keep a reference to another object to which they
forward requests. Once again, however, they are intended for different purposes.
Like Decorator, the Proxy pattern composes an object and provides an identical in-
terface to clients, Unlike Decorator, the Proxy pattern is not concerned with attaching
or detaching properties dynamically, and it’s not designed for recursive composition.
Its intent is to provide a stand-in for a subject when it’s inconvenient or undesirable
to access the subject directly because, for example, it lives on a remote machine, has
restricted access, or is persistent.
Inthe Proxy pattern, the subject defines the key functionality, and the proxy provides (or
refuses) access to it. In Decorator, the component provides only part of the functionality,
and one or more decorators furnish the rest. Decorator addresses the situation where an
objects total functionality can’t be determined at compile time, at least not conveniently.
‘That open-endedness makes recursive composition an essential part of Decorator. That
isn’t the case in Proxy, because Proxy focuses on one relationship—between the proxy
and its subject—and that relationship can be expressed statically.
These differences are significant because they capture solutions to specific recurring
problems in object-oriented design. But that doesn’t mean these patterns can’t be com-
bined. You might envision a proxy-decorator that adds functionality to a proxy, or
a decorator-proxy that embellishes a remote object. Although such hybrids might be
useful (we don’t have real examples handy), they are divisible into patterns that are
useful.
Pattern What Is Pattern How To Create It. Types Ofpatterns. Pattern Matching Explain Examples Method of Thepatterns. Laudagues of Pattern. Examples Related Types Ofpatterns