Adapter mode in Java Design Mode

Generally, the client class accesses the services it provides through the class interface. Sometimes, an existing class (existing class) can provide the functional requirements of the customer class, but its interfaces are not necessarily expected by the customer class. This is because the existing interface is too detailed or lacks details or the interface name is different from the one found by the customer class.

In this case, the existing interface needs to be converted to the desired interface of the customer class, which ensures reuse of the existing class. Without such conversion, the customer class cannot use the functions provided by the existing class. Adapter pattern can be used to complete the conversion. In the adapter mode, we recommend that you define a packaging class that encapsulates objects with incompatible interfaces. This package class refers to the adapter, and its packaging object is the adaptee ). The adapter provides the interface required by the customer class. The implementation of the adapter interface is to convert the request of the customer class to the call of the corresponding interface of the adapter. In other words, when the customer class calls the method of the adapter, it calls the method of the adapter class within the adapter class. This process is transparent to the customer class, the customer class does not directly access the adapter class. Therefore, the adapter can work together (Work Together) classes that are incompatible with interfaces and cannot interact with each other ).

The interface discussed above:

(1) It does not refer to the interface concept in the Java programming language, although the class interface can be defined through Java extension.

(2) It is not a user interface of a GUI application composed of forms and GUI controls.

(3) it refers to the programming interface exposed by the class and called by other classes,

Class adapter vs Object Adapter)

There are two types of adapters: Class adapter and Object Adapter)

Class adapter:

The class adapter is implemented by inheriting the adaptee class, and the class adapter implements the interface required by the customer class. When a customer object calls an adapter class method, the adapter internally calls the method of the adapter it inherits.

Object Adapter:
The Object Adapter contains a reference of an adapter, which is the same as the class Adapter. The Object Adapter also implements the interface required by the customer class. When the client object calls the method of the Object Adapter, the Object Adapter calls the appropriate method of the adapter instance it contains.

The following table lists the differences between the class adapter and the Object Adapter:

 

Supplement:

Class adapter Object Adapter)

Combine Objects Based on inheritance concepts

The application can only be an interface when the adapter is an interface and cannot use its subclass interface. When the class adapter is created, it is statically associated with the adapter and can be applied when the adapter is an interface and all its subclasses, because the adapter is a subclass of the adapter, therefore, the adapter may reload some behavior of the adapter.

Note: in Java, the subclass cannot reload the methods declared as final in the parent class. The method of the adapter cannot be reloaded.

Note: literally, it cannot be re-planted because there is no inheritance. However, the adapter provides a packaging method to change behavior as needed.

The customer class is visible to the public interface in the adapter. The customer class and the adaptation are completely unrelated. Only the adapter can perceive the adapter interface.

In Java applications:

The expected interface is in the form of a Java interface, rather than an abstract or concrete class. This is because the Java programming language only allows single inheritance. Therefore, the class adapter is designed as a subclass of the adapter. In Java applications:
This method is applicable when the interface expected by the customer object is in the form of an abstract class and the expected interface is in the form of a Java interface.

Example:

Let's create an application to verify the given customer address. This application is part of a big customer data management application.

Let's define a customer class:

Customer

Figure 20.1: Customer class
Listing 20.1: Customer class

Class Customer {
Public static final string us = "us ";
Public static final string Canada = "Canada ";
Private string address;
Private string name;
Private string zip, state, type;
Public Boolean isvalidaddress (){
...
...
}
Public customer (string inp_name, string inp_address,
String inp_zip, string inp_state,
String inp_type ){
Name = inp_name;
Address = inp_address;
Zip = inp_zip;
State = inp_state;
Type = inp_type;
}
} // End of class
Different customer objects create customer objects and call the (invoke) isvalidaddress method to verify the validity of customer addresses. To verify the validity of the customer address, the customer class is expected to use an address validator class, which provides the interface declared in the interface addressvalidator.

Listing 20.2: addressvalidator as an interface

Public interface addressvalidator {
Public Boolean isvalidaddress (string inp_address,
String inp_zip, string inp_state );
} // End of class

Let's define a usaddress verification class to verify the given u. s address.

Listing20.3: usaddress class

Class usaddress implements addressvalidator {
Public Boolean isvalidaddress (string inp_address,
String inp_zip, string inp_state ){
If (inp_address.trim (). Length () <10)
Return false;
If (inp_zip.trim (). Length () <5)
Return false;
If (inp_zip.trim (). Length ()> 10)
Return false;
If (inp_state.trim (). Length ()! = 2)
Return false;
Return true;
}
} // End of class

The usaddress class implements the addressvalidator interface. Therefore, there is no problem for the customer object to use the usaddress instance as part of the customer address verification process.

Listing 20.4: Customer class using the usaddress class

Class Customer {
...
...
Public Boolean isvalidaddress (){
// Get an appropriate address validator
Addressvalidator validator = getvalidator (type );
// Polymorphic call to validate the address
Return validator. isvalidaddress (address, zip, State );
}
Private addressvalidator getvalidator (string custtype ){
Addressvalidator validator = NULL;
If (custtype. Equals (customer. US )){
Validator = new usaddress ();
}
Return validator;
}
} // End of class
 

 

Figure 20.2: customer/usaddress validator? Class Association

However, when verifying customers from Canada, the application needs to be improved. This requires a verification class to verify the addresses of Canadian customers. Let us assume that there is a caaddress tool used to verify the Canadian customer address.

From the implementation of the following caadress class, we can find that caadress provides the verification service required by the customer Class Customer class. However, the interface provided by it is not used as expected by the customer class. From the implementation of the following caadress class, we can find that caadress provides the verification service required by the customer Class Customer class. However, the interface provided by it is not used as expected by the customer class.

Listing 20.5: caadress class with incompatible Interface

Class caaddress {
Public Boolean isvalidcanadianaddr (string inp_address,
String inp_pcode, string inp_prvnc ){
If (inp_address.trim (). Length () <15)
Return false;
If (inp_pcode.trim (). Length ()! = 6)
Return false;
If (inp_prvnc.trim (). Length () <6)
Return false;
Return true;
}
} // End of class

The caadress class provides an isvalidcanadianaddr method, but the customer expects an isvalidaddress method declared in the addressvalidator interface.

Interface incompatibility makes it difficult for the customer object to use the existing caadress class. One idea is to change the caadress class interface, but other applications may be using this form of caadress class. Changing the caadress class interface will affect customers who currently use the caadress class.

The application adapter mode. The class adapter caadressadapter can inherit the caadress class to implement the addressvalidator interface.

 

Figure 20.3: Class adapter for the caaddress class
Listing20.6: caaddressadapter as a class Adapter

Public class caaddressadapter extends caaddress
Implements addressvalidator {
Public Boolean isvalidaddress (string inp_address,
String inp_zip, string inp_state ){
Return isvalidcanadianaddr (inp_address, inp_zip,
Inp_state );
}
} // End of class

Because the adapter caadressadapter implements the addressvalidator interface, there is no problem with accessing the client object caadressadapter object. When the client object calls the isvalidaddress method of the adapter instance, the adapter internally passes the call to its inherited isvalidcanadianaddr method.

Within the customer class, the getvalidator private method needs to be extended so that it can return a caadressadapter instance when verifying Canadian customers. The returned objects are polymorphism. Both usaddress and caaddressadapter implement the addressvalidator interface, so you do not need to change it.

Listing 20.7: Customer class using the caaddressadapter class

Class Customer {
...
...
Public Boolean isvalidaddress (){
// Get an appropriate address validator
Addressvalidator validator = getvalidator (type );
// Polymorphic call to validate the address
Return validator. isvalidaddress (address, zip, State );
}
Private addressvalidator getvalidator (string custtype ){
Addressvalidator validator = NULL;
If (custtype. Equals (customer. US )){
Validator = new usaddress ();
}
If (type. Equals (customer. Canada )){
Validator = new caaddressadapter ();
}
Return validator;
}
} // End of class
Caaddressadapter design and multi-state calls to addressvalidator (declaring the expected Interface) objects allow the customer to use the interface to be incompatible with the services provided by the caaddress class.

 

Figure 20.4: Address validation application? Using class Adapter

 

Figure 20.5: Address validation message flow? Using class Adapter

Address adapter used as the Object Adapter

When we discuss how to use class adapters to implement address adapters, we say that the addressvalidator interface expected by the customer class is in the form of a Java interface. Now, let's assume that the client class expects the addressvalidator interface to be an abstract class rather than a Java interface. Because the adapter caadapter must provide the interface declared in the abstract class addressvalidatro, the adapter must be a subclass of the addressvalidator abstract class and implement the abstract method.

Listing 20.8: addressvalidator as an abstract class
Public abstract class addressvalidator {
Public Abstract Boolean isvalidaddress (string inp_address,
String inp_zip, string inp_state );
} // End of class
Listing20.9: caaddressadapter class
Class caaddressadapter extends addressvalidator {
...
...
Public caaddressadapter (caaddress address ){
Objcaaddress = address;
}
Public Boolean isvalidaddress (string inp_address,
String inp_zip, string inp_state ){
...
...
}
} // End of class

Because multi-inheritance is not supported in Java, the adapter caaddressadapter cannot inherit the existing caaddress class. It has used the only chance to inherit other classes.

Application Object Adapter mode. caaddressadapter can contain an instance of the adapter caaddress. When the adapter is created for the first time, the adapter's instance is passed to the adapter through the client. Generally, the adapter instance can be provided to the adapter that wraps it in the following two ways.

(1) the client of the Object Adapter can pass an adapter's instance to the adapter. This method has great flexibility in the form of selection class, but the client perceives the adapter or adaptation process. This method is suitable when the adapter not only needs to adapt to the object behavior but also needs a specific State.

(2) The adapter can create its own adapter instance. This method lacks flexibility. This method is applicable when the adapter only needs to adapt to the behavior of the object but not the specific state of the object.

 

Figure 20.6: Object Adapter for the caaddress class

Listing 20.10: caaddressadapter as an Object Adapter

Class caaddressadapter extends addressvalidator {
Private caaddress objcaaddress;
Public caaddressadapter (caaddress address ){
Objcaaddress = address;
}
Public Boolean isvalidaddress (string inp_address,
String inp_zip, string inp_state ){
Return objcaaddress. isvalidcanadianaddr (inp_address,
Inp_zip, inp_state );
}
} // End of class

When the client object calls the isvalidaddress Method on caaddressadapter (adapter), the adapter internally calls the isvalidcanadianaddr Method on caaddress (adaptee.

 

Figure 20.7: Address validation application? Using Object Adapter

From this example, we can see that the adapter can enable the customer (client) class to access the services provided by the incompatible caaddress (adaptee!

Http://blog.csdn.net/scs2000/archive/2007/04/06/1554463.aspx