Introduction to Adapters
• We may have an application that needs to use libraries/a different application/you-name-it, but the thing we want to call has a different interface than our caller.  Alternative 1: Re-write the caller o Ugly, messy, error-prone (Equivalent to changing the power cable in our electrical plug when we go abroad)

 Alternative 2: Re-write the called libraries/classes o May not have the source code o As ugly and error-prone as Alternative 1

 Alternative 3: Write an adapter  The adapter converts all requests to a language the adaptee understands See http://mypages.valdosta.edu/dgibson/courses/cs4322/Lessons/Adap ter/AdapterNotes.pdf

Another example
Client class programmed against a Vendor class. Thus, the Client is strongly coupled with the Vendor class.

Later, it is decided to change vendors. Vendor2 is selected which has different method names.

Example (cont’d)
The Client must be modified in order to adapt to the new vendor.  What was the problem? The Client class encapsulates some portion of application logic, which is intertwined with the Vendor class.  This causes the strong coupling/ dependence. Thus, modifying the Client code to adapt to the new vendor could result in errors being injected into the application logic.  How do we mitigate this situation where we have a Client coded against a Vendor, where the Vendor will change?

Two helpful design principles
• Identify the aspects of your application that vary and separate them from what stays the same. • Program to an interface, not an implementation. • The first principle suggests that we separate the application logic from the code tied to the vendor. • The second design principle indicates how we may achieve that. • We program against an abstraction of all Vendor classes and then use an Adapter to encapsulate vendor specific code required to implement