Structural Design Patterns-Adapters

Apple D-shape headphone jack patent application. Image credit Apple Insider

This Week I’m reviewing Structural Design Patterns. Each structural pattern is ideal for specific circumstances, but their overall goal is to model relationships between entities. For example the Bridge Structural Pattern focuses on entities relationships and is a great patten for new applications. On the other hand the Adapter Pattern is designed to resolve relationship issues after the fact of implementation.

We can see the Adapter Pattern constantly in everyday life. Take for example the latest Apple rumor. If Apple chose to change the input jack of their next iPhone, it will leave all existing headphones incompatible with the new device. This would be a prime example of the need for the Adapter Pattern. Rather than building new headphones with the required jack specs, savvy consumers who may have invested heavily in there current headPhone sets will likely purchase an adapter to maintain their relationship with the entity in this case the next iPhone release.

As an technologist we may hate to wrap poor code design within a wrapper to fix a problem, but often the cost to rewrite may be expensive and not worth the investment. The Adaptor Patterns role is to take code that offers great value and make it compatible with future entities entering the application environment.

Take a look at the Java example below.

In this example we create an adapter that implements the iPhoneJack interface. Any client using our adapter will not know its details and will simply treat it as an iPhoneJack, yet its core behavior is compatible with the standard headphone plug we see here represented as MiniJackPlug. Thats the beauty of wrappers is creates flexibility in legacy code.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.