通常,客户类(clients of class)通过类的接口访问它提供的服务。有时,现有的类(existing class)可以提供客户类的功能需要,但是它所提供的接口不一定是客户类所期望的。这是由于现有的接口太详细或者缺乏详细或接口的名称与客户类所查找的不同等诸多不同原因导致的。
在这种情况下,现有的接口需要转化(convert)为客户类期望的接口,这样保证了对现有类的重用。如果不进行这样的转化,客户类就不能利用现有类所提供的功能。适配器模式(Adapter Pattern)可以完成这样的转化。适配器模式建议定义一个包装类,包装有不兼容接口的对象。这个包装类指的就是适配器(Adapter),它包装的对象就是适配者(Adaptee)。适配器提供客户类需要的接口,适配器接口的实现是把客户类的请求转化为对适配者的相应接口的调用。换句话说:当客户类调用适配器的方法时,在适配器类的内部调用适配者类的方法,这个过程对客户类是透明的,客户类并不直接访问适配者类。因此,适配器可以使由于接口不兼容而不能交互的类可以一起工作(work together)。
在上面讨论的接口:
(1) 不是指在JAVA编程语言中接口的概念,虽然类的接口可以通过JAVA借扩来定义。
(2) 不是指由窗体和GUI控件所组成的GUI应用程序的用户接口。
(3) 而是指类所暴露的,被其他类调用的编程接口,
类适配器(Class Adapter)VS对象适配器(Object Adapter)
适配器总体上可以分为两类:类适配器(Class Adapter)VS对象适配器(Object Adapter)
类适配器:
类适配器是通过继承类适配者类(Adaptee Class)实现的,另外类适配器实现客户类所需要的接口。当客户对象调用适配器类方法的时候,适配器内部调用它所继承的适配者的方法。
对象适配器:
对象适配器包含一个适配器者的引用(reference),与类适配器相同,对象适配器也实现了客户类需要的接口。当客户对象调用对象适配器的方法的时候,对象适配器调它所包含的适配器者实例的适当方法。
下表是类适配器(Class Adapter)和对象适配器(Object Adapter)的详细不同:
补充:
类适配器(Class Adapter) 对象适配器(Object Adapter)
基于继承概念 利用对象合成
只能应用在适配者是接口,不能利用它子类的接口,当类适配器建立时,它就静态地与适配者关联 可以应用在适配者是接口和它的所有子类,因为适配器是作为适配者的子类,所以适配器可能会重载适配者的一些行为。
注意:在JAVA中,子类不能重载父类中声明为final的方法。 不能重载适配者的方法。
注意:字面上,不能重栽只是因为没有继承。但是适配器提供包装方法可以按需要改变行为。
客户类对适配者中声明为public的接口是可见的, 客户类和适配者是完全不关联的,只有适配器才能感知适配者接口。
在JAVA应用程序中:
适用于期待的接口是JAVA接口的形式,而不是抽象地或具体地类的形式。这是因为JAVA编程语言只允许单继承。因此,类适配器设计成适配者的子类。 在JAVA应用程序中:
适用于当客户对象期望的接口是抽象类的形式,同时也可以应用于期望接口是Java接口的形式。
例子:
让我们建立一个验证给定客户地址的应用。这个应用是作为大的客户数据管理应用的一部分。
让我们定义一个Customer类:
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
不同的客户对象创建Customer对象并调用(invoke)isValidAddress方法验证客户地址的有效性。为了验证客户地址的有效性,Customer类期望利用一个地址验证类(address validator class),这个验证类提供了在接口AddressValidator中声明的接口。
public interface AddressValidator {
public boolean isValidAddress(String inp_address,
String inp_zip, String inp_state);
}//end of class
让我们定义一个USAddress的验证类,来验证给定的U.S地址。
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
USAddress类实现AddressValidator接口,因此Customer对象使用USAddress实例作为验证客户地址过程的一部分是没有任何问题的。
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
但是当验证来自加拿大的客户时,就要对应用进行改进。这需要一个验证加拿大客户地址的验证类。让我们假设已经存在一个用来验证加拿大客户地址的使用工具类CAAddress。
从下面的CAAdress类的实现,可以发现CAAdress提供了客户类Customer类所需要的验证服务。但是它所提供的接口不用于客户类Customer所期望的。从下面的CAAdress类的实现,可以发现CAAdress提供了客户类Customer类所需要的验证服务。但是它所提供的接口不用于客户类Customer所期望的。
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
CAAdress类提供了一个isValidCanadianAddr方法,但是Customer期望一个声明在AddressValidator接口中的isValidAddress方法。
接口的不兼容使得Customer对象利用现有的CAAdress类是困难的。一种意见是改变CAAdress类的接口,但是可能会有其他的应用正在使用CAAdress类的这种形式。改变CAAdress类接口会影响现在使用CAAdress类的客户。
应用适配器模式,类适配器CAAdressAdapter可以继承CAAdress类实现AddressValidator接口。
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
因为适配器CAAdressAdapter实现了AddressValidator接口,客户端对象访问适配器CAAdressAdapter对象是没有任何问题的。当客户对象调用适配器实例的isValidAddress方法的时候,适配器在内部把调用传递给它继承的isValidCanadianAddr方法。
在Customer类内部,getValidator私有方法需要扩展,以至于它可以在验证加拿大客户的时候返回一个CAAdressAdapter实例。返回的对象是多态的,USAddress和CAAddressAdapter都实现了AddressValidator接口,所以不用改变。
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设计和对AddressValidator(声明期望的接口)对象的多态调用使Customer可以利用接口不兼容CAAddress类提供的服务。
作为对象适配器的地址适配器
当讨论以类适配器来实现地址适配器时,我们说客户类期望的AddressValidator接口是Java接口形式。现在,让我们假设客户类期望AddressValidator接口是抽象类而不是java接口。因为适配器CAAdapter必须提供抽象类AddressValidatro中声明的接口,适配器必须是AddressValidator抽象类的子类、实现抽象方法。
public abstract class AddressValidator {
public abstract boolean isValidAddress(String inp_address,
String inp_zip, String inp_state);
}//end of class
Listing 20.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
因为多继承在JAVA中不支持,现在适配器CAAddressAdapter不能继承现有的CAAddress类,它已经使用了唯一一次继承其他类的机会。
应用对象适配器模式,CAAddressAdapter可以包含一个适配者CAAddress的一个实例。当适配器第一次创建的时候,这个适配者的实例通过客户端传递给适配器。通常,适配者实例可以通过下面两种方式提供给包装它的适配器。
(1) 对象适配器的客户端可以传递一个适配者的实例给适配器。这种方式在选择类的形式上有很大的灵活性,但是客户端感知了适配者或者适配过程。这种方法在适配器不但需要适配者对象行为而且需要特定状态时很适合。
(2) 适配器可以自己创建适配者实例。这种方法相对来说缺乏灵活性。适用于适配器只需要适配者对象的行为而不需要适配者对象的特定状态的情况。
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
当客户对象调用CAAddressAdapter(adapter)上的isValidAddress方法时, 适配器在内部调用CAAddress(adaptee)上的isValidCanadianAddr方法。
从这个例子可以看出,适配器可以使Customer(client)类访问借口不兼容的CAAddress(adaptee)所提供的服务!
分享到:
相关推荐
总的来说,Java/IO库巧妙地运用了Decorator和Adapter模式,实现了流处理器的动态扩展和接口的兼容性,使得Java程序在处理输入输出时拥有极高的灵活性。这种设计思想不仅提升了代码的可维护性,也使得开发者能够更...
结构型模式如适配器(Adapter)、装饰器(Decorator)和代理(Proxy)等,关注如何组合对象和类,以实现新的功能或改善原有结构。行为型模式如观察者(Observer)、模板方法(Template Method)和策略(Strategy)等...
结构模式是指在对象之间的关系和结构上使用的模式,包括 Flyweight(共享模式)、Bridge(桥模式)、Decorator(装饰模式)、Composite(组合模式)、Adapter(适配器模式)、Proxy(代理模式)、Facade(外观模式)...
2. **结构型模式**:如适配器(Adapter)、装饰器(Decorator)、代理(Proxy)、桥接(Bridge)、组合(Composite)、外观(Facade)和享元(Flyweight)。这些模式处理对象的组合和关系,提供更好的结构和接口,...
在这个特定的场景中,我们讨论的是"Java_Adapter_for_Mobile_2.2.zip",这是一个针对移动设备的Java适配器的新版本2.03。这个压缩包文件包含了"Java_Adapter_for_Mobile_2.2.exe",这很可能是该适配器的安装程序。 ...
在Java中,适配器模式扮演着重要的角色,尤其在处理遗留代码或者第三方库集成时,能够有效地解决接口不匹配的问题。本文将深入探讨适配器模式的概念、类型、优点和如何在Java中实现。 一、适配器模式概念 适配器...
自己总结了一个在性能和结构上都很容易理解的Adapter模式。 Adapter模式也叫适配器模式,是由GoF提出的23种设计模式的一种。Adapter模式是构造型模式之一,通过Adapter模式,可以改变已有类(或外部类)的接口...
f) 适配器模式(Adapter) 适配器模式允许将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以一起工作。JDK中的实例包括: - java.util.Arrays#asList(),将数组转换为列表。 - java.io....
适合Java设计模式期末考试选择题复习,形式如下: 10.(单选题)Facade(外观)模式的意图是 正确答案: A A.希望简化现有系统的使用方法,你需要定义自己的接口 B.将一个无法控制的现有对象与一个特定借口相匹配。 C....
Adapter模式是一种结构型设计模式,它允许不兼容的类或接口之间进行通信。在软件开发中,我们常常遇到这样的情况:需要使用一个已经存在的类,但是它的接口与我们的需求不匹配,这时候Adapter模式就能派上用场。它...
结构型设计模式包括适配器(Adapter)、桥接(Bridge)、装饰(Decorator)、外观(Facade)、享元(Flyweight)、组合(Composite)和代理(Proxy)。这些模式帮助我们更好地组织类和对象之间的关系,实现松耦合,...
在Java中,适配器模式被广泛应用于解决系统间的兼容性问题,尤其是当我们需要将一个已有的类库或者对象与我们的系统接口相匹配时。汽车适配器的概念是一个具体的实例,可能指的是在汽车电子系统中,如何通过适配器来...
2. 结构型模式:关注对象组合和类的继承,例如适配器模式(Adapter)、装饰器模式(Decorator)、桥接模式(Bridge)、组合模式(Composite)、外观模式(Facade)、享元模式(Flyweight)和代理模式(Proxy)。...
Java设计模式是软件工程中的一种最佳实践,它提供了一种在特定情况下解决常见问题的模板。这些模式在软件开发中被广泛使用,因为它们能够使代码更可读、可维护和可扩展。在这个名为"java设计模式程序源代码"的压缩包...
3. 适配器模式(Adapter Pattern)与桥接模式(Bridge Pattern): 适配器模式是一种结构型设计模式,它允许不兼容的接口之间可以协同工作。适配器通过将一个类的接口转换成客户期望的另一个接口,从而使原本接口不...
包括适配器模式(Adapter)、桥接模式(Bridge)、装饰模式(Decorator)、外观模式(Facade)、享元模式(Flyweight)、组合模式(Composite)和代理模式(Proxy)。如装饰模式可以在不修改原有对象的基础上添加新...
结构型模式关注如何将类和对象组合成更大的结构,如适配器模式(Adapter)、装饰器模式(Decorator)和代理模式(Proxy)。这些模式允许不同类之间的交互,即使它们的设计原则和接口不完全匹配。 行为型模式着重于...
包括适配器模式(Adapter)、桥接模式(Bridge)、装饰器模式(Decorator)、外观模式(Facade)、组合模式(Composite)、享元模式(Flyweight)和代理模式(Proxy)。这些模式可以帮助我们更好地组织代码,实现...
八、适配器模式(Adapter) 适配器模式作为两个不兼容接口之间的桥梁,使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。它可以将旧的接口转换为新的接口,以适应现有的系统。 九、模板方法模式...
结构型模式如适配器(Adapter)、桥接(Bridge)、组合(Composite)、装饰(Decorator)、外观(Facade)、享元(Flyweight)和代理(Proxy),主要关注如何组合不同的类和对象以实现新的功能。行为型模式如策略...