Tom-随笔
更详细的 Bridge Adapter Facade模式之间的比较
更详细的 Bridge Adapter Facade模式之间的比较
在这篇文章中
,我写了Bridge和adapter模式的区别.但是 maninred说
Bridge和adapter是没有关系的,而和Facade比较象,但在我的经验中更多的时候
是会混淆Bridge和adapter而不是Facade,这里详细的列出三个模式的比较 .
一,定义:
1.Facade模式是为一个复杂系统提供一个简单的接口。
比如你要去博物馆参观,很多东西,你一个个到处去问每个东西的管理员很麻烦,所以你找一个导游,让他给你一个个介绍,你只要找到导游就好了。导游就是门面。
2,适配器模式,引用一下GOF95中的话:
适配器模式是把一个类的接口变换成客户端所期待的另一种接口,从而使原本因接口不匹配而无法工作的两个类能够工作到一起。
举个例子,例如变压器
3,Bridge模式:
GOF95中的桥梁模式的描述:桥梁模式的用意是"将抽象化与实现化脱耦,使的二者可以独立变化。
例如AWT的实现
二,目的:
1,Facade模式使用在给一个复杂的系统提供统一的门面(接口),目的是简化客户端的操作,但并没有改变接口.
2,Adapter模式使用在两个部分有不同的接口的情况,目的是改变接口,使两个部分协同工作
3,桥梁模式是为了分离抽象和实现
二,使用场合
1,Facade模式出现较多的情况是这样的情况,你有一个复杂的系统,对应了各种情况,
客户看了说功能不错,但是使用太麻烦.你说没问题,我给你提供一个统一的门面.
所以Facade使用的场合多是对系统的"优化".
2,Adapter模式出现的情况是这样,你有一个类提供接口A,但是你的客户需要一个实现接口B的类,
这个时候你可以写一个Adapter让把A接口变成B接口,所以Adapter使用的场合是
指鹿为马.就是你受夹板气的时候,一边告诉你我只能提供给你A(鹿),一边告诉你说
我只要B(马),他长了四条腿,你没办法了,把鹿牵过去说,这是马,你看他有四条腿.
(当然实现指鹿为马也有两种方法,一个方法是你只露出鹿的四条腿,说你看这是马,这种方式就是
封装方式的Adapter实现,另一种方式是你把鹿牵过去,但是首先介绍给他说这是马,因为他长了四条腿
这种是继承的方式.)
3,Bridge模式在一般的开发中出现的情况并不多,AWT是一个,SWT也算部分是,
如果你的客户要求你开发一个系统,这个系统在Windows下运行界面的样子是Windows的样子.
在Linux下运行是Linux下的样子.在Macintosh下运行要是Mac Os的样子.
怎么办? 定义一系列的控件Button,Text,radio,checkBox等等.供上层开发者
使用,他们使用这些控件的方法,利用这些控件构造一个系统的GUI,然后你为这些控件
写好Linux的实现,让它在Linux上调用Linux本地的对应控件,
在Windows上调用Windows本地的对应控件,在Macintosh上调用Macintosh本地的对应控件
ok,你的任务完成了.
三,需求程度
1,Facade的需求程度是"中等",因为你不提供Facade程序照样能工作,只是不够好.
2,Adapter的需求程度是"必须",因为你不这么做就不能工作,除非你自己从头实现一个.
3,Bridge的需求程度是"一般",适合精益求精的人,因为你可以写三个程序给客户.
四,出现时期
1,Facade出现在项目中期,再优化
2,Adapter出现在项目后期,大部分都有了,差的仅仅是接口不同
3,Bridge出现在项目前期,你想让你的系统更灵活,更cool
五,在写文章的时候想到的
1,Facade很多时候是1:m的关系
2,Adapter很多是候是1:1的关系
3,Bridge很多时候是m:n的关系
呵呵.
六,最后
另外:回应一下maninred
1,我并没有把模式看的很独立,其实很多模式是配合使用的,而且在一定情况下可以
用一个替换另一个.同一个需求,有可能当你思考的角度不同时,使用的模式就不同了.
2,设计模式并不是"用OO的封装来封装所有的东西",模式其实可以应用于所有的设计上
和OO没有直接的关系,只是因为计算机的设计模式大部分是GOF收集总结的,
他们讲解设计模式是用的C++,而在Java中得到了大量应用,所以我们谈到设计模式
的时候多提到OO.其实模式更早应用于建筑学,Alexander的《建筑的永恒之道》讲的
就是设计模式。所以说设计模式应该是设计过程中积累下来的一些成型的东西。
更深入一点,《Java与模式》的作者认为模式起源于中国的道教思想,讲的是哲学。呵呵。
3,对于模式的使用,个人感觉,模式很大程度上是为了对应这类需求的所有情况,也就
是最复杂情况,最灵活情况,当我们实际的开发中并没有遇到这么多这样的情况。
所以在需要的时候使用,根据需求简化使用,而不是照搬。
4,虽然模式是相关的,但是只有知道了每个模式的区别点,才能更好的根据需求选择使用哪个模式。
posted on 2007-01-23 10:34
Tom
阅读(371)
评论(0)
编辑
收藏
所属分类:
Java
新用户注册
刷新评论列表
只有注册用户
登录
后才能发表评论。
网站导航:
博客园
IT新闻
知识库
C++博客
博问
管理
相关文章:
Java反射学习
栈与堆 de 区别
一个关于StringBuilder与StringBuffer性能的小试验
利用静态内部类为您的代码添加辅助功能
PO BO VO DTO POJO DAO概念及其作用(附转换图)
适配器模式
更详细的 Bridge Adapter Facade模式之间的比较
Java抽象类和接口的区别
JDOM使用详解及实例
Aaron Johnson对Class.forName()的解释
Powered by:
BlogJava
Copyright © Tom
<
2007年1月
>
日
一
二
三
四
五
六
31
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
1
2
3
4
5
6
7
8
9
10
导航
BlogJava
首页
新随笔
联系
聚合
管理
统计
随笔 - 43
文章 - 0
评论 - 17
引用 - 0
常用链接
我的随笔
我的评论
我的参与
最新评论
留言簿
(1)
给我留言
查看公开留言
查看私人留言
随笔分类
(42)
Appfuse(3)
(rss)
Asp(1)
(rss)
CVS(2)
(rss)
DB(5)
(rss)
Develop IDE(1)
(rss)
EJB(1)
(rss)
Java(10)
(rss)
JavaScript(5)
(rss)
Spring(2)
(rss)
个人随笔(8)
(rss)
报表工具(4)
(rss)
随笔档案
(43)
2007年12月 (1)
2007年11月 (3)
2007年9月 (1)
2007年8月 (1)
2007年7月 (2)
2007年2月 (4)
2007年1月 (11)
2006年12月 (8)
2006年11月 (12)
文章分类
Java
(rss)
相册
Photo in ShangHai
搜索
最新评论
1. re: 一个关于StringBuilder与StringBuffer性能的小试验 [未登录]
@dreamstone
多线程还比什么,一个是线程安全的,一个是非线程安全的,没有可比性
--icanfly
2. re: 一个关于StringBuilder与StringBuffer性能的小试验 [未登录]
而且并不是多线程下一定要用stringBuffer
多线程下并不一定要同步的。比如只读的情况,或不是公共资源的情况。
--abc
3. re: 一个关于StringBuilder与StringBuffer性能的小试验
都是牛人啊
--路人甲
4. re: 热烈庆祝CVSNT架设成功!呵呵[未登录]
评论内容较长,点击标题查看
--aaaa
5. re: appfuse 乱码问题[未登录]
解决这类问题,这些方法都太麻烦。
最方便的办法是用propertiesEditor编辑properties配置文件。
一个eclipse的插件。
--YeSoon
阅读排行榜
1. appfuse 乱码问题(3494)
2. Tomcat JSP调用JBoss布署的EJB远程方法(2302)
3. 一个关于StringBuilder与StringBuffer性能的小试验 (2281)
4. 热烈庆祝CVSNT架设成功!呵呵(2117)
5. ORACLE查询树型关系(2069)
评论排行榜
1. 一个关于StringBuilder与StringBuffer性能的小试验 (5)
2. 扼腕叹息者,华为之倏然兴衰也(3)
3. 中国之怪现状-----"党纪、行政处分"(2)
4. appfuse 乱码问题(2)
5. 热烈庆祝CVSNT架设成功!呵呵(2)