Java设计模式结构型模式代理模式适配器模式等.docx
- 文档编号:26158553
- 上传时间:2023-06-17
- 格式:DOCX
- 页数:24
- 大小:319.03KB
Java设计模式结构型模式代理模式适配器模式等.docx
《Java设计模式结构型模式代理模式适配器模式等.docx》由会员分享,可在线阅读,更多相关《Java设计模式结构型模式代理模式适配器模式等.docx(24页珍藏版)》请在冰豆网上搜索。
Java设计模式结构型模式代理模式适配器模式等
结构型模式
前面创建型模式介绍了创建对象的一些设计模式,这节介绍的结构型模式旨在通过改变代码结构来达到解耦的目的,使得我们的代码容易维护和扩展。
代理模式
第一个要介绍的代理模式是最常使用的模式之一了,用一个代理来隐藏具体实现类的实现细节,通常还用于在真实的实现的前后添加一部分逻辑。
既然说是代理,那就要对客户端隐藏真实实现,由代理来负责客户端的所有请求。
当然,代理只是个代理,它不会完成实际的业务逻辑,而是一层皮而已,但是对于客户端来说,它必须表现得就是客户端需要的真实实现。
理解代理这个词,这个模式其实就简单了。
publicinterfaceFoodService{
FoodmakeChicken();
FoodmakeNoodle();
}
publicclassFoodServiceImplimplementsFoodService{
publicFoodmakeChicken(){
Foodf=newChicken()
f.setChicken("1kg");
f.setSpicy("1g");
f.setSalt("3g");
returnf;
}
publicFoodmakeNoodle(){
Foodf=newNoodle();
f.setNoodle("500g");
f.setSalt("5g");
returnf;
}
}
//代理要表现得“就像是”真实实现类,所以需要实现FoodService
publicclassFoodServiceProxyimplementsFoodService{
//内部一定要有一个真实的实现类,当然也可以通过构造方法注入
privateFoodServicefoodService=newFoodServiceImpl();
publicFoodmakeChicken(){
System.out.println("我们马上要开始制作鸡肉了");
//如果我们定义这句为核心代码的话,那么,核心代码是真实实现类做的,
//代理只是在核心代码前后做些“无足轻重”的事情
Foodfood=foodService.makeChicken();
System.out.println("鸡肉制作完成啦,加点胡椒粉");//增强
food.addCondiment("pepper");
returnfood;
}
publicFoodmakeNoodle(){
System.out.println("准备制作拉面~");
Foodfood=foodService.makeNoodle();
System.out.println("制作完成啦")
returnfood;
}
}
客户端调用,注意,我们要用代理来实例化接口:
//这里用代理类来实例化
FoodServicefoodService=newFoodServiceProxy();
foodService.makeChicken();
我们发现没有,代理模式说白了就是做 “方法包装” 或做 “方法增强”。
在面向切面编程中,算了还是不要吹捧这个名词了,在AOP中,其实就是动态代理的过程。
比如Spring中,我们自己不定义代理类,但是Spring会帮我们动态来定义代理,然后把我们定义在@Before、@After、@Around中的代码逻辑动态添加到代理中。
说到动态代理,又可以展开说……Spring中实现动态代理有两种,一种是如果我们的类定义了接口,如UserService接口和UserServiceImpl实现,那么采用JDK的动态代理,感兴趣的读者可以去看看java.lang.reflect.Proxy类的源码;另一种是我们自己没有定义接口的,Spring会采用CGLIB进行动态代理,它是一个jar包,性能还不错。
适配器模式
说完代理模式,说适配器模式,是因为它们很相似,这里可以做个比较。
适配器模式做的就是,有一个接口需要实现,但是我们现成的对象都不满足,需要加一层适配器来进行适配。
适配器模式总体来说分三种:
默认适配器模式、对象适配器模式、类适配器模式。
先不急着分清楚这几个,先看看例子再说。
默认适配器模式
首先,我们先看看最简单的适配器模式默认适配器模式(DefaultAdapter)是怎么样的。
我们用Appachecommons-io包中的FileAlterationListener做例子,此接口定义了很多的方法,用于对文件或文件夹进行监控,一旦发生了对应的操作,就会触发相应的方法。
publicinterfaceFileAlterationListener{
voidonStart(finalFileAlterationObserverobserver);
voidonDirectoryCreate(finalFiledirectory);
voidonDirectoryChange(finalFiledirectory);
voidonDirectoryDelete(finalFiledirectory);
voidonFileCreate(finalFilefile);
voidonFileChange(finalFilefile);
voidonFileDelete(finalFilefile);
voidonStop(finalFileAlterationObserverobserver);
}
此接口的一大问题是抽象方法太多了,如果我们要用这个接口,意味着我们要实现每一个抽象方法,如果我们只是想要监控文件夹中的文件创建和文件删除事件,可是我们还是不得不实现所有的方法,很明显,这不是我们想要的。
所以,我们需要下面的一个适配器,它用于实现上面的接口,但是所有的方法都是空方法,这样,我们就可以转而定义自己的类来继承下面这个类即可。
publicclassFileAlterationListenerAdaptorimplementsFileAlterationListener{
publicvoidonStart(finalFileAlterationObserverobserver){
}
publicvoidonDirectoryCreate(finalFiledirectory){
}
publicvoidonDirectoryChange(finalFiledirectory){
}
publicvoidonDirectoryDelete(finalFiledirectory){
}
publicvoidonFileCreate(finalFilefile){
}
publicvoidonFileChange(finalFilefile){
}
publicvoidonFileDelete(finalFilefile){
}
publicvoidonStop(finalFileAlterationObserverobserver){
}
}
比如我们可以定义以下类,我们仅仅需要实现我们想实现的方法就可以了:
publicclassFileMonitorextendsFileAlterationListenerAdaptor{
publicvoidonFileCreate(finalFilefile){
//文件创建
doSomething();
}
publicvoidonFileDelete(finalFilefile){
//文件删除
doSomething();
}
}
当然,上面说的只是适配器模式的其中一种,也是最简单的一种,无需多言。
下面,再介绍“正统的”适配器模式。
对象适配器模式
来看一个《HeadFirst设计模式》中的一个例子,我稍微修改了一下,看看怎么将鸡适配成鸭,这样鸡也能当鸭来用。
因为,现在鸭这个接口,我们没有合适的实现类可以用,所以需要适配器。
publicinterfaceDuck{
publicvoidquack();//鸭的呱呱叫
publicvoidfly();//飞
}
publicinterfaceCock{
publicvoidgobble();//鸡的咕咕叫
publicvoidfly();//飞
}
publicclassWildCockimplementsCock{
publicvoidgobble(){
System.out.println("咕咕叫");
}
publicvoidfly(){
System.out.println("鸡也会飞哦");
}
}
鸭接口有fly()和quare()两个方法,鸡Cock如果要冒充鸭,fly()方法是现成的,但是鸡不会鸭的呱呱叫,没有quack()方法。
这个时候就需要适配了:
//毫无疑问,首先,这个适配器肯定需要implementsDuck,这样才能当做鸭来用
publicclassCockAdapterimplementsDuck{
Cockcock;
//构造方法中需要一个鸡的实例,此类就是将这只鸡适配成鸭来用
publicCockAdapter(Cockcock){
this.cock=cock;
}
//实现鸭的呱呱叫方法
@Override
publicvoidquack(){
//内部其实是一只鸡的咕咕叫
cock.gobble();
}
@Override
publicvoidfly(){
cock.fly();
}
}
客户端调用很简单了:
publicstaticvoidmain(String[]args){
//有一只野鸡
CockwildCock=newWildCock();
//成功将野鸡适配成鸭
Duckduck=newCockAdapter(wildCock);
...
}
到这里,大家也就知道了适配器模式是怎么回事了。
无非是我们需要一只鸭,但是我们只有一只鸡,这个时候就需要定义一个适配器,由这个适配器来充当鸭,但是适配器里面的方法还是由鸡来实现的。
我们用一个图来简单说明下:
上图应该还是很容易理解的,我就不做更多的解释了。
下面,我们看看类适配模式怎么样的。
类适配器模式
废话少说,直接上图:
看到这个图,大家应该很容易理解的吧,通过继承的方法,适配器自动获得了所需要的大部分方法。
这个时候,客户端使用更加简单,直接 Targett=newSomeAdapter(); 就可以了。
适配器模式总结
1.类适配和对象适配的异同
一个采用继承,一个采用组合;
类适配属于静态实现,对象适配属于组合的动态实现,对象适配需要多实例化一个对象。
总体来说,对象适配用得比较多。
2.适配器模式和代理模式的异同
比较这两种模式,其实是比较对象适配器模式和代理模式,在代码结构上,它们很相似,都需要一个具体的实现类的实例。
但是它们的目的不一样,代理模式做的是增强原方法的活;适配器做的是适配的活,为的是提供“把鸡包装成鸭,然后当做鸭来使用”,而鸡和鸭它们之间原本没有继承关系。
桥梁模式
理解桥梁模式,其实就是理解代码抽象和解耦。
我们首先需要一个桥梁,它是一个接口,定义提供的接口方法。
publicinterfaceDrawAPI{
publicvoiddraw(intradius,intx,inty);
}
然后是一系列实现类:
publicclassRedPenimplementsDrawAPI{
@Override
publicvoiddraw(intradius,intx,inty){
System.out.println("用红色笔画图,radius:
"+radius+",x:
"+x+",y:
"+y);
}
}
publicclassGreenPenimplementsDrawAPI{
@Override
publicvoiddraw(intradius,intx,inty){
System.out.println("用绿色笔画图,radius:
"+radius+",x:
"+x+",y:
"+y);
}
}
publicclassBluePenimplementsDrawAPI{
@Override
publicvoiddraw(intradius,intx,inty){
System.out.println("用蓝色笔画图,radius:
"+radius+",x:
"+x+",y:
"+y);
}
}
定义一个抽象类,此类的实现类都需要使用DrawAPI:
publicabstractclassShape{
protectedDrawAPIdrawAPI;
protectedShape(DrawAPIdrawAPI){
this.drawAPI=drawAPI;
}
publicabstractvoiddraw();
}
定义抽象类的子类:
//圆形
publicclassCircleextendsShape{
privateintradius;
publicCircle(intradius,DrawAPIdrawAPI){
super(drawAPI);
this.radius=radius;
}
publicvoiddraw(){
drawAPI.draw(radius,0,0);
}
}
//长方形
publicclassRectangleextendsShape{
privateintx;
privateinty;
publicRectangle(intx,inty,DrawAPIdrawAPI){
super(drawAPI);
this.x=x;
this.y=y;
}
publicvoiddraw(){
drawAPI.draw(0,x,y);
}
}
最后,我们来看客户端演示:
publicstaticvoidmain(String[]args){
ShapegreenCircle=newCircle(10,newGreenPen());
ShaperedRectangle=newRectangle(4,8,newRedPen());
greenCircle.draw();
redRectangle.draw();
}
可能大家看上面一步步还不是特别清晰,我把所有的东西整合到一张图上:
这回大家应该就知道抽象在哪里,怎么解耦了吧。
桥梁模式的优点也是显而易见的,就是非常容易进行扩展。
本节引用了这里的例子,并对其进行了修改。
装饰模式
要把装饰模式说清楚明白,不是件容易的事情。
也许读者知道JavaIO中的几个类是典型的装饰模式的应用,但是读者不一定清楚其中的关系,也许看完就忘了,希望看完这节后,读者可以对其有更深的感悟。
首先,我们先看一个简单的图,看这个图的时候,了解下层次结构就可以了:
我们来说说装饰模式的出发点,从图中可以看到,接口 Component 其实已经有了 ConcreteComponentA 和 ConcreteComponentB 两个实现类了,但是,如果我们要增强这两个实现类的话,我们就可以采用装饰模式,用具体的装饰器来装饰实现类,以达到增强的目的。
从名字来简单解释下装饰器。
既然说是装饰,那么往往就是添加小功能这种,而且,我们要满足可以添加多个小功能。
最简单的,代理模式就可以实现功能的增强,但是代理不容易实现多个功能的增强,当然你可以说用代理包装代理的方式,但是那样的话代码就复杂了。
首先明白一些简单的概念,从图中我们看到,所有的具体装饰者们ConcreteDecorator_ 都可以作为Component来使用,因为它们都实现了Component中的所有接口。
它们和Component实现类ConcreteComponent_ 的区别是,它们只是装饰者,起装饰作用,也就是即使它们看上去牛逼轰轰,但是它们都只是在具体的实现中加了层皮来装饰而已。
注意这段话中混杂在各个名词中的Component和Decorator,别搞混了。
下面来看看一个例子,先把装饰模式弄清楚,然后再介绍下javaio中的装饰模式的应用。
最近大街上流行起来了“快乐柠檬”,我们把快乐柠檬的饮料分为三类:
红茶、绿茶、咖啡,在这三大类的基础上,又增加了许多的口味,什么金桔柠檬红茶、金桔柠檬珍珠绿茶、芒果红茶、芒果绿茶、芒果珍珠红茶、烤珍珠红茶、烤珍珠芒果绿茶、椰香胚芽咖啡、焦糖可可咖啡等等,每家店都有很长的菜单,但是仔细看下,其实原料也没几样,但是可以搭配出很多组合,如果顾客需要,很多没出现在菜单中的饮料他们也是可以做的。
在这个例子中,红茶、绿茶、咖啡是最基础的饮料,其他的像金桔柠檬、芒果、珍珠、椰果、焦糖等都属于装饰用的。
当然,在开发中,我们确实可以像门店一样,开发这些类:
LemonBlackTea、LemonGreenTea、MangoBlackTea、MangoLemonGreenTea……但是,很快我们就发现,这样子干肯定是不行的,这会导致我们需要组合出所有的可能,而且如果客人需要在红茶中加双份柠檬怎么办?
三份柠檬怎么办?
万一有个变态要四份柠檬,所以这种做法是给自己找加班的。
不说废话了,上代码。
首先,定义饮料抽象基类:
publicabstractclassBeverage{
//返回描述
publicabstractStringgetDescription();
//返回价格
publicabstractdoublecost();
}
然后是三个基础饮料实现类,红茶、绿茶和咖啡:
publicclassBlackTeaextendsBeverage{
publicStringgetDescription(){
return"红茶";
}
publicdoublecost(){
return10;
}
}
publicclassGreenTeaextendsBeverage{
publicStringgetDescription(){
return"绿茶";
}
publicdoublecost(){
return11;
}
}
...//咖啡省略
定义调料,也就是装饰者的基类,此类必须继承自Beverage:
//调料
publicabstractclassCondimentextendsBeverage{
}
然后我们来定义柠檬、芒果等具体的调料,它们属于装饰者,毫无疑问,这些调料肯定都需要继承Condiment类:
publicclassLemonextendsCondiment{
privateBeveragebevarage;
//这里很关键,需要传入具体的饮料,如需要传入没有被装饰的红茶或绿茶,
//当然也可以传入已经装饰好的芒果绿茶,这样可以做芒果柠檬绿茶
publicLemon(Beveragebevarage){
this.bevarage=bevarage;
}
publicStringgetDescription(){
//装饰
returnbevarage.getDescription()+",加柠檬";
}
publicdoublecost(){
//装饰
returnbeverage.cost()+2;//加柠檬需要2元
}
}
publicclassMangoextendsCondiment{
privateBeveragebevarage;
publicMango(Beveragebevarage){
this.bevarage=bevarage;
}
publicStringgetDescription(){
returnbevarage.getDescription()+",加芒果";
}
publicdoublecost(){
returnbeverage.cost()+3;//加芒果需要3元
}
}
...//给每一种调料都加一个类
看客户端调用:
publicstaticvoidmain(String[]args){
//首先,我们需要一个基础饮料,红茶、绿茶或咖啡
Beveragebeverage=newGreenTea();
//开始装饰
beverage=newLemon(beverage);//先加一份柠檬
beverage=newMongo(beverage);//再加一份芒果
System.out.println(beverage.getDescription()+"价格:
¥"+beverage.cost());
//"绿茶,加柠檬,加芒果价格:
¥16"
}
如果我们需要芒果珍珠双份柠檬红茶:
Beveragebeverage=newMongo(newPearl(newLemon(newLemon(newBlackTea()))));
是不是很变态?
看看下图可能会清晰一些:
到这里,大家应该已经清楚装饰模式了吧。
下面,我们再来说说javaIO中的装饰模式。
看下图InputStream派生出来的部分类:
我们知道InputStream代表了输入流,具体的输入来源可以是文件(FileInputStream)、管道(PipedInputStream)、数组(ByteArrayInputStream)等,这些就像前面奶茶的例子中的红茶、绿茶,属于基础输入流。
FilterInputStream承接了装饰模式的关键节点,其实现类是一系列装饰器,比如BufferedInputStream代表用缓冲来装饰,也就使得输入流具有了缓冲的功能,LineNumberInputStream代表
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Java 设计 模式 结构 代理 适配器