设计形式之-适配器模式(adapter)
设计模式之--适配器模式(adapter)
工作一年多了,纸上的笔记写了不少,但一直没有机会整理。现在离职了,就用这段时间整理一下自己的笔记,也顺便丰富一下自己的博客吧,要不也真的对不起在这里潜水两年的时间。
适配器:基于现有类所提供的服务,向客户提供接口,以满足客户的期望
《Java设计模式》
类适配器
客户的开发人员定义了一个接口,期望用这个接口来完成整数的求和操作,接口定义如下:
开发人员在了解这个接口的定义后,发现一个第三方类,里面有一个方法能实现他们期望的功能,其代码如下:
以上第三方类OtherOperation的方法public int otherAdd(int a,int b)所提供的功能,完全能符合客户的期望,所以只需要想办法把OtherOperation的otherAdd(int a,int b)和客户的Operation接口联系起来,让这个第三方类来为客户提供他们期望的服务就行了,这样就避免了开发人员再度去研究类似OtherOperation的otherAdd(int a,int b)方法的实现(利用已有的*,避免重复发明),这方法之一,就是用适配器模式:
以上就是适配器的实现方法之一,类适配器,在以上实现中存在着三中角色分别是:
1:适配目标角色:Operation。
2:适配类(原)角色:OtherOperation。
3:适配器角色:AdapterOperation。
其中适配器角色是适配器模式的核心。
适配器的主要工作就是通过封装现有的功能,使他满足需要的接口。
对象适配器
我们再来看看另一种情况:
假如客户接口期望的功能不止一个,而是多个:
而能提供这些实现的原可能不止一个:
由于java是不能实现多继承的,所以我们不能通过构建一个适配器,让他来继承所有原以完成我们的期望,这时候怎么办呢?只能用适配器的另一种实现--对象适配器:
上面代码很明显,适配器并不是通过继承来获取适配类(原)的功能的,而是通过适配类的对象来获取的,这就解决了java不能多继承所带来的不便了。这也是java提倡的编程思想之一,即尽量使用聚合不要使用继承。
还有一种情况是需要使用对象适配器的。我们来看看,
单我们的客户提供的需求并不是一个明确的接口,而是一个类,并没有定义期望的方法,如下
现在客户要一个新类B,要求能在保留类A功能的情况下增加一个运算减法的功能,并要求B能随时替换掉A但不能对已有系统造成影响。这样我们只能新建一个类B,并让B继承A。
这时候,我们发现类C已经提供了实现减法的函数,
为了避免重复去设计该函数,我们决定引入C类,通过适配C类来达到我们的期望,但问题是A和C都是一个具体类,我们无法让B同时继承这个两个类,而B继承A又是必须的,所以我们只能考虑把C给内聚到B内部,对象适配器又得派上用场了。
这样,在需要A类的地方都能用B类来代替,同时又保证了新的功能的引入。
更灵活的实现--隐藏目标接口的抽象适配器
做java 桌面应用的都知道WindowListener接口,
要实现这个接口,我们就必须实现它所定义的所有方法,但是实际上,我们很少需要同时用到所有的方法,我们要的只是其中的两三个。为了不使我们实现多余的方法,
jdk WindowListener提供了一个WindowListener的默认实现类WindowAdapter类,这是一个抽象类,
WindowAdapter类对WindowListener接口的所有有方法都提供了空实现,
有了WindowAdapter类,我们只需要去继承WindowAdapter,然后选择我们所关心的方法来实现就行了,这样就避免了直接去实现WindowListener接口。
框架级别?请举个例子说说
1.一种补救模式???
2.不过适配器模式不单在代码级别适用,更重要的应该用在框架级别,在系统架构的角度去看???
第一句不懂,第二句迷糊^_^
为什么说是一种补救模式呢???
1.一种补救模式???
2.不过适配器模式不单在代码级别适用,更重要的应该用在框架级别,在系统架构的角度去看???
第一句不懂,第二句迷糊^_^
为什么说是一种补救模式呢???
呵呵,问一个问题 如果两个东西能够很好的结合何必要适配呢???
一般说来适配的出现时机不是系统开发初期,恰恰是系统标准已经形成以后.就好比你要安装驱动程序一样.
系统架构的角度去看是这样的 因为适配不单纯只涉及到一个具体的JAVA类或者一段代码,它有可能是一个系统前期设计时候必须考虑的问题,好比你你要集成新旧两个系统的时候 你怎么让这两个东西很好的结合工作呢, 改旧系统?让新系统去适应就系统?? 还是写一个适配呢?? 在分布式里面适配器就是,......头疼的问题..估计百分之60的时间都是在开发适配器,比如你有一个已经存在的服务A 你要方便别人使用你的服务 这时候你就要写适配器. 总之一句话 适配来适配去 就是为了补救
1.一种补救模式???
2.不过适配器模式不单在代码级别适用,更重要的应该用在框架级别,在系统架构的角度去看???
第一句不懂,第二句迷糊^_^
为什么说是一种补救模式呢???
举个简单的例子吧,比如你设计一个MVC框架,其中View层技术,你有要支持JSP有要支持Velocity(模板技术)。Jsp技术的话,数据是通过request.setAttribute()进行传递的,在action中setAttribute(),在Jsp中
getAttribute();Velocity的话是在action中在Context里边进行put()操作的,然后在Template中直接以对象打点的方式取值的。
从上面的不描述不难看出,Jsp和Velocity技术的数据传输介质是不一样的。加入设计这样的MVC框架的话,那么就应该引入一个中间的对象,比如叫做ViewContext对象。在Action中把view层需要的数据put进这个ViewContext中,然后渲染模板或者渲染JSP文件。但是渲染模板需要的Context对象(velocity的一个接口),而JSP需要HttpServletRequest对象。这个时候适配器就有用了,通过做两个Adapter,一个叫做VelocityContextAdapter,这个类实现Context对象,然后将把ViewContext的方法转嫁到VelocityContextAdapter的各个对应的方法中去。而JSP的话只需要集成HttpRequestWrappter类,覆盖需要的方法,即可。其实从形式上来讲,适配器模式跟代理模式有点像,只是出发点可能不一样。个人认为没有必要花那么多心思去区分。
讲的有点乱哈。。。
工作一年多了,纸上的笔记写了不少,但一直没有机会整理。现在离职了,就用这段时间整理一下自己的笔记,也顺便丰富一下自己的博客吧,要不也真的对不起在这里潜水两年的时间。
适配器:基于现有类所提供的服务,向客户提供接口,以满足客户的期望
《Java设计模式》
类适配器
客户的开发人员定义了一个接口,期望用这个接口来完成整数的求和操作,接口定义如下:
public interface Operation{ public int add(int a,int b); }
开发人员在了解这个接口的定义后,发现一个第三方类,里面有一个方法能实现他们期望的功能,其代码如下:
public class OtherOperation{ public int otherAdd(int a,int b){ return a + b; } }
以上第三方类OtherOperation的方法public int otherAdd(int a,int b)所提供的功能,完全能符合客户的期望,所以只需要想办法把OtherOperation的otherAdd(int a,int b)和客户的Operation接口联系起来,让这个第三方类来为客户提供他们期望的服务就行了,这样就避免了开发人员再度去研究类似OtherOperation的otherAdd(int a,int b)方法的实现(利用已有的*,避免重复发明),这方法之一,就是用适配器模式:
public class AdapterOperation extends OtherOperation implements Operation{ public int add(int a,int b){ return otherAdd(a,b); } }
以上就是适配器的实现方法之一,类适配器,在以上实现中存在着三中角色分别是:
1:适配目标角色:Operation。
2:适配类(原)角色:OtherOperation。
3:适配器角色:AdapterOperation。
其中适配器角色是适配器模式的核心。
适配器的主要工作就是通过封装现有的功能,使他满足需要的接口。
对象适配器
我们再来看看另一种情况:
假如客户接口期望的功能不止一个,而是多个:
public interface Operation{ public int add(int a,int b); public int minus(int a,int b); public int multiplied(int a,int b); }
而能提供这些实现的原可能不止一个:
public class OtherAdd{ public int otherAdd(int a,int b){ return a + b; } } public class OtherMinus{ public int minus(int a,int b){ return a - b; } } public class OtherMultiplied{ public int multiplied(int a,int b){ return a * b; } }
由于java是不能实现多继承的,所以我们不能通过构建一个适配器,让他来继承所有原以完成我们的期望,这时候怎么办呢?只能用适配器的另一种实现--对象适配器:
public class AdapterOperation implements Operation{ private OtherAdd add; private OtherMinus minus; private OtherMultiplied multiplied; public void setAdd(OtherAdd add){ this.add = add; } public void setMinus(OtherMinus minus){ this.minus = minus; } public void setMultiplied(OtherMultiplied multiplied){ this.multiplied = multiplied; } //适配加法运算 public int add(int a,int b){ return add.otherAdd(a,b); } //适配减法运算 public int minus(int a,int b){ return minus.minus(a,b); } //适配乘法运算 public int multiplied(int a,int b){ return multiplied.multiplied(a,b); } }
上面代码很明显,适配器并不是通过继承来获取适配类(原)的功能的,而是通过适配类的对象来获取的,这就解决了java不能多继承所带来的不便了。这也是java提倡的编程思想之一,即尽量使用聚合不要使用继承。
还有一种情况是需要使用对象适配器的。我们来看看,
单我们的客户提供的需求并不是一个明确的接口,而是一个类,并没有定义期望的方法,如下
public class A{ public int add(int a,int b){ return a + b; } }
现在客户要一个新类B,要求能在保留类A功能的情况下增加一个运算减法的功能,并要求B能随时替换掉A但不能对已有系统造成影响。这样我们只能新建一个类B,并让B继承A。
public class B extends A{ b(){ super(); } public int minus(int a,int b){ //待实现的减法运算函数.. } }
这时候,我们发现类C已经提供了实现减法的函数,
public class C{ public int minus(int a,int b){ return a - b; } }
为了避免重复去设计该函数,我们决定引入C类,通过适配C类来达到我们的期望,但问题是A和C都是一个具体类,我们无法让B同时继承这个两个类,而B继承A又是必须的,所以我们只能考虑把C给内聚到B内部,对象适配器又得派上用场了。
public class B extends A{ private C c; B(){ super(); } public void setMinus(C c){ this.c= c; } public int minus(int a,int b){ return c.minus(a,b); } }
这样,在需要A类的地方都能用B类来代替,同时又保证了新的功能的引入。
更灵活的实现--隐藏目标接口的抽象适配器
做java 桌面应用的都知道WindowListener接口,
public interface WindowListener extends EventListener{ public void windowActivated(WindowEvent e); public void windowClosed(WindowEvent e); public void windowClosing(WindowEvent e); public void windowDeactivated(WindowEvent e); public void windowDeiconified(WindowEvent e); public void windowIconified(WindowEvent e); public void windowOpened(WindowEvent e); }
要实现这个接口,我们就必须实现它所定义的所有方法,但是实际上,我们很少需要同时用到所有的方法,我们要的只是其中的两三个。为了不使我们实现多余的方法,
jdk WindowListener提供了一个WindowListener的默认实现类WindowAdapter类,这是一个抽象类,
public abstract class WindowAdapter implements WindowListener{ public void windowActivated(WindowEvent e){} public void windowClosed(WindowEvent e){} public void windowClosing(WindowEvent e){} public void windowDeactivated(WindowEvent e){} public void windowDeiconified(WindowEvent e){} public void windowIconified(WindowEvent e){} public void windowOpened(WindowEvent e){} }
WindowAdapter类对WindowListener接口的所有有方法都提供了空实现,
有了WindowAdapter类,我们只需要去继承WindowAdapter,然后选择我们所关心的方法来实现就行了,这样就避免了直接去实现WindowListener接口。
1 楼
zhiblin
2008-11-26
谢谢 作者精彩的描述,学习了
2 楼
司徒正美
2008-11-30
Good!
学习了!
学习了!
3 楼
司徒正美
2008-11-30
BaseAction.java
MoneyAction.java
package cheng.controller; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.apache.struts2.interceptor.ServletRequestAware; import org.apache.struts2.interceptor.ServletResponseAware; import com.opensymphony.xwork2.ActionSupport; import com.opensymphony.xwork2.ModelDriven; import com.opensymphony.xwork2.Preparable; //隐藏目标接口的抽象适配器 @SuppressWarnings("all") public abstract class BaseAction<T> extends ActionSupport implements ModelDriven<T>, Preparable, ServletRequestAware, ServletResponseAware { public abstract T getModel(); public void prepare() throws Exception { } public void setServletRequest(HttpServletRequest request) { } public void setServletResponse(HttpServletResponse response){ } }
MoneyAction.java
package cheng.controller.money; import java.io.IOException; import java.util.Map; import javax.servlet.http.HttpServletResponse; import net.sf.json.JSONObject; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.beans.factory.annotation.Qualifier; import org.springframework.stereotype.Controller; import com.opensymphony.xwork2.ActionContext; import cheng.controller.BaseAction; import cheng.entity.Money; import cheng.service.MoneyManager; @Controller public class MoneyAction extends BaseAction<Money> { private static final long serialVersionUID = -6769263990506962430L; @Autowired @Qualifier("moneyManager") private MoneyManager moneyManager; @Autowired private Money money; @Override public Money getModel() { return money; } private HttpServletResponse response; public void setServletResponse(HttpServletResponse response) { this.response = response; } @SuppressWarnings("unchecked") public String execute() throws IOException { System.out.println("invoked execute method!!response"); Money money = getModel(); String record = money.getType(); if (null != record) { JSONObject jsonObject = JSONObject.fromObject(record); System.out.println(jsonObject.toString()); response.setCharacterEncoding("UTF-8"); response.setHeader("json", jsonObject.toString()); response.flushBuffer(); return "money";//go to money.jsp } return "list";//go to list.jsp }
4 楼
fjlyxx
2008-12-01
适配器是一种补救模式,这种模式用的还是很多的.值得学习,不过适配器模式不单在代码级别适用,更重要的应该用在框架级别,在系统架构的角度去看.
个人意见
个人意见
5 楼
hanjs
2008-12-04
学习了,不错!
6 楼
zgxzowen
2009-02-17
仁者见仁,智者见智,楼主的分析恰到好处,此设计模式是对老系统和升级改造的依据之一。
7 楼
WorldHello
2009-02-18
fjlyxx 写道
适配器是一种补救模式,这种模式用的还是很多的.值得学习,不过适配器模式不单在代码级别适用,更重要的应该用在框架级别,在系统架构的角度去看.
个人意见
个人意见
框架级别?请举个例子说说
8 楼
langhua9527
2009-03-17
Servlet 里面的
HttpServlet
GenericServlet
到最的的Servlet
算不算适配器模式啊。。。。
HttpServlet
GenericServlet
到最的的Servlet
算不算适配器模式啊。。。。
9 楼
tinyyea
2009-03-18
小弟不才,
适配器,外观,装饰器,劳烦您抛砖引玉,说说这其中的哲学!
适配器,外观,装饰器,劳烦您抛砖引玉,说说这其中的哲学!
10 楼
hansen-van
2009-03-20
很好很强大!
11 楼
autolo
2009-03-20
我可以这样了解吗:适配器将原有对象(包括类,接口)内聚成一个新的对象。
12 楼
beanwon
2009-03-20
对适配器有了一定的认识。谢谢楼主。
13 楼
wujie2008
2009-03-21
设计模式到处可见:
1.继承和组合实现代码复用。
2.面向抽象和接口编程。
3.对扩展支持,对修改关闭。
1.继承和组合实现代码复用。
2.面向抽象和接口编程。
3.对扩展支持,对修改关闭。
14 楼
zhuxing
2009-03-24
fjlyxx 写道
适配器是一种补救模式,这种模式用的还是很多的.值得学习,不过适配器模式不单在代码级别适用,更重要的应该用在框架级别,在系统架构的角度去看.
个人意见
个人意见
1.一种补救模式???
2.不过适配器模式不单在代码级别适用,更重要的应该用在框架级别,在系统架构的角度去看???
第一句不懂,第二句迷糊^_^
为什么说是一种补救模式呢???
15 楼
fjlyxx
2009-04-02
zhuxing 写道
fjlyxx 写道
适配器是一种补救模式,这种模式用的还是很多的.值得学习,不过适配器模式不单在代码级别适用,更重要的应该用在框架级别,在系统架构的角度去看.
个人意见
个人意见
1.一种补救模式???
2.不过适配器模式不单在代码级别适用,更重要的应该用在框架级别,在系统架构的角度去看???
第一句不懂,第二句迷糊^_^
为什么说是一种补救模式呢???
呵呵,问一个问题 如果两个东西能够很好的结合何必要适配呢???
一般说来适配的出现时机不是系统开发初期,恰恰是系统标准已经形成以后.就好比你要安装驱动程序一样.
系统架构的角度去看是这样的 因为适配不单纯只涉及到一个具体的JAVA类或者一段代码,它有可能是一个系统前期设计时候必须考虑的问题,好比你你要集成新旧两个系统的时候 你怎么让这两个东西很好的结合工作呢, 改旧系统?让新系统去适应就系统?? 还是写一个适配呢?? 在分布式里面适配器就是,......头疼的问题..估计百分之60的时间都是在开发适配器,比如你有一个已经存在的服务A 你要方便别人使用你的服务 这时候你就要写适配器. 总之一句话 适配来适配去 就是为了补救
16 楼
brandom520
2009-04-08
不错。 学习了。
17 楼
yuanyao
2009-06-04
系统开发初期就考虑适配????????????接下来!!!!!!!!
18 楼
果0o冻
2009-06-13
学习了,讲的很清晰。
19 楼
零下冰度
2009-06-16
不错
学习了
学习了
20 楼
lishuaibt
2009-06-22
zhuxing 写道
fjlyxx 写道
适配器是一种补救模式,这种模式用的还是很多的.值得学习,不过适配器模式不单在代码级别适用,更重要的应该用在框架级别,在系统架构的角度去看.
个人意见
个人意见
1.一种补救模式???
2.不过适配器模式不单在代码级别适用,更重要的应该用在框架级别,在系统架构的角度去看???
第一句不懂,第二句迷糊^_^
为什么说是一种补救模式呢???
举个简单的例子吧,比如你设计一个MVC框架,其中View层技术,你有要支持JSP有要支持Velocity(模板技术)。Jsp技术的话,数据是通过request.setAttribute()进行传递的,在action中setAttribute(),在Jsp中
getAttribute();Velocity的话是在action中在Context里边进行put()操作的,然后在Template中直接以对象打点的方式取值的。
从上面的不描述不难看出,Jsp和Velocity技术的数据传输介质是不一样的。加入设计这样的MVC框架的话,那么就应该引入一个中间的对象,比如叫做ViewContext对象。在Action中把view层需要的数据put进这个ViewContext中,然后渲染模板或者渲染JSP文件。但是渲染模板需要的Context对象(velocity的一个接口),而JSP需要HttpServletRequest对象。这个时候适配器就有用了,通过做两个Adapter,一个叫做VelocityContextAdapter,这个类实现Context对象,然后将把ViewContext的方法转嫁到VelocityContextAdapter的各个对应的方法中去。而JSP的话只需要集成HttpRequestWrappter类,覆盖需要的方法,即可。其实从形式上来讲,适配器模式跟代理模式有点像,只是出发点可能不一样。个人认为没有必要花那么多心思去区分。
讲的有点乱哈。。。