And back to design patterns! Today it’s time to start with structural
patterns, since I have finished
all the creational patterns. What are those structural patterns anyway?
In Software Engineering, Structural Design Patterns are Design Patterns that
ease the design by identifying a simple way to realize relationships
The first among the structural design patterns is Adapter. The name for it
is totally appropriate, because it does exactly what any other real-life thing
called adapter does. It converts some attribute of one device so it is usable
together with another one. Most common adapters are between various types of
electrical sockets. The adapters usually convert the voltage and/or the shape
of the connector so you can plug-in different devices.
The software adapters work exactly like the outlet adapters. Imagine having
(possibly a third-party) class or module you need to use in your application.
It’s poorly coded and it would pollute your nicely designed code. But there’s
no other way, you need it’s functionality and don’t have time to write it from
scratch. The best practice is to write your own adapter and wrap the old code
inside of it. Then you can use your own interface and therefore reduce your
dependence on the old ugly code.
Especially, when the code comes from a third-party module you have no control
on whatsoever. They could change something which would result in breaking your
code on many places. That’s just unacceptable.
Here is an example class diagram of adapter use. You see there is some old
interface which the adapter uses. On the other end, there is new target
interface that the adapter implements. The client (i.e. your app) then
uses the daisy fresh new interface. For more explanation see the source code
The adapter uses the old rusty interface of a class or a module and maps it’s
functionality to a new interface that is used by the clients. It’s kind of
wrapper for the crappy code so it doesn’t get your code dirty.