Adapter (GoF) - UML

The NextGen problem explored on to motivate the Polymorphismand its solution is more specifically an example of the GoF Adapter pattern.

  • Name : Adapter
  • Problem : How to resolve incompatible interfaces, or provide a stable interface to similar components with different interfaces?
  • Solution : Convert the original interface of a component into another interface, through an intermediate adapter object.

A solution is to add a level. of indirection with objects that adapt the varying external interfaces a consistent interface used within the application. The solution is illustrated in Figure

Figure 26.1 The Adapter pattern

As illustrated in Figure a particular adapter instance will be instantiated for the chosen external service1, such as SAP for accounting, and will adapt the postSale request to the external interface, such as a SOAP XML interface over HTTPS for an intranet Web service offered by SAP.

Figure 26.2 Using an Adapter

Guideline: Include Pattern in Type Name

Notice that the type names include the pattern name "Adapter." This is a relatively common style and has the advantage of easily communicating to others reading the code or diagrams what design patterns are being used.

Related Patterns

A resource adapter that hides an external system may also be considered a Facade object (another GoF pattern discussed in this chapter), as it wraps access to the subsystem or system with a single object (which is the essence of Facade'. However, the motivation to call it a resource adapter especially exists when the wrapping object provides adaptation to varying external interfaces.

Some GRASP Principles as a Generalization of Other Patterns

The previous use of the Adapter pattern can be viewed as a specialization of some GRASP building blocks:

Adapter supports Protected Variations with respect to changing external interfaces or third - party packages through the use of an Indirection object that applies interfaces and Polymorphism.

What's the Problem? Pattern Overload!

The Pattern Almanac 2000 [RisingOO] lists around 500 design patterns. And many hundreds more have been published since then. The curious developer has no time to actually program given this reading list!

A Solution: See the Underlying Principles

Yes, it's important for an experienced designer to know in detail and by memory 50+ of the most important design patterns, but few of us can learn or remember 1,000 patterns, or even start to organize that pattern plethora into a useful taxonomy.

But there's good news: Most design patterns can be seen as specializations of a few basic GRASP principles. Although it is indeed helpful to study detailed design patterns to accelerate learning, it is even more helpful to see their underlying basic themes (Protected Variations, Polymorphism, Indirection, ...) to help us to cut through the myriad details and see the essential "alphabet" of design techniques being applied.

Example: Adapter and GRASP

Figure illustrates my point that detailed design patterns can be analyzed in terms of the basic underlying "alphabet" of GRASP principles. UML generalization relationships are used to suggest the conceptual connections. At this point perhaps this idea seems academic or overly analytical. But it is truly the case that as you spend some years applying and reflecting on myriad design patterns, you will increasingly come to feel that it's the underlying themes that are important, and the fine details of Adapter or Strategy or whatever will become secondary.

Figure 26.3 Relating Adapter to some core GRASP principles


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

UML Topics