The adapter pattern introduced in the PHP design pattern

Interface changes are a common problem that requires programmers to accept and deal with (albeit reluctantly). The program provider modifies their code, the system library is modified, and the various programming languages and associated libraries evolve and evolve. One of my children's countless toys is a brief description of the dilemma: you can't reasonably arrange a slicker person.

Problem

How do you avoid the inconvenience caused by external library API changes? If you write a library, can you provide a way to allow the existing users of your software to upgrade perfectly even if you have changed your API? How do you change the interface of an object in order to better fit your needs?

Solution

The adapter (Adapter) mode provides an entirely different interface for the object. You can use adapters (Adapter) to implement a common interface for a different class, while avoiding disputes arising from the escalation and dismantling of client code.

Consider when (not assuming!) What happens to an API change for a third-party library. In the past you had to grit your teeth and modify all your client code, and the situation is often not that simple. You may be working on a new project that uses the features of a new version of the library, but you already have many old applications, and they interact well with previous versions of the library. You will not be able to demonstrate the value of these new features if this upgrade means that the client code for other applications will be involved.

Note: Control body mode

The adapter (Adapter) pattern is the latest example of a control-body pattern. The structure of an adapter (Adapter) is similar to that of proxy servers (proxies) and modifiers (decorator), and they differ in that the purpose of the adapter (Adapter) is to change the interface of the encapsulated class, the proxy server (proxy), and the Decorator (decorator ) is to keep the interface unchanged.

Sample code

Let's take a look at how you can protect your application from being affected when the API changes.

Suppose you tried to find the right library and finally found Hwlib, a set of code that was designed to send information.

The following is the source code for the Hwlib class:

PHP4

/**
* the HwLib helps programmers everywhere write their first program
* @package HelloWorld
* @version 1
*/
class HwLib {
/**
* Say “Hello”
* @deprec this function is going away in the future
* @return string
*/
function hello() {
return ‘Hello ‘;
}
/**
* target audience
* @return string
*/
function world() {
return ‘World!’;
}
}

The following is an example of how the Library works:

$HW =& New Hwlib;

echo $HW->hello (), $HW->world ();

Hwlib has a complete documentation. The author has made it clear in the document that the Hello () method will not be supported (or even eliminated) in future releases.

Next, now assume that the second version of Hwlib has been released. A new greet () method replaces Hello ().

The following is a new version of the library (note has been extracted):

// version 2
class HwLib {
function greet() {
return ‘Greetings and Salutations ‘;
}
function world() {
return ‘World!’;
}
}

To accommodate the different versions of Hwlib, first perform some tests based on the first version of the Hwlib interface:

class AdapterTestCase extends UnitTestCase {
function TestOriginalApp() {
$lib =& new HwLib;
$this- >assertEqual(
‘Hello World!’
,$lib->hello().$lib->world ());
}
}

You can also show that a simple upgrade to this library will cause the application to fail.

class AdapterTestCase extends UnitTestCase {
The Adapter Pattern 221
function TestOriginalAppWouldFail() {
$lib =& new HwLib; // now using HwLib version 2
$this->assertFalse(method_exists($lib, ‘hello’));
}
}