这一章主要讲2个模式,一个是,适配器模式(负责将一个类的接口适配成用户所期待的),另外一个是外观模式(为子系统提供一个共同的对外接口),看完的第一反应是,为什么要把它们两放在同一章,难道它们有什么不可告人的秘密?
难道是因为他们俩都很简单吗?不会不会,毕竟是大名鼎鼎的headfirst,怎么可能这么草率,这我是万万不相信的!
细想了一下,我和工作的点点滴滴,我发现,一般到项目的后期,好像都比较容易用上这两个东西...
当然,项目的后期并不是说一个项目自己从头发开到尾的项目,而是在它生命周期的后半段,比如适配器,用来适配老的接口,比如外观模式,用来隐藏各个子系统,各个模块的协作细节。
不过外观模式却不一定都是在后期才发力的:
1,前期如果系统比较复杂,在系统规划的时候,就会有意识的对系统分层,为上层模块提供一些高级的api。
2,在系统的中期呢,开发过程中,发现子系统越来越复杂,也可以提供类似的操作。
3,在系统后期,模块越来越多,功能越来越复杂,还有历史原因,外观模式就更加有用了,毕竟,有一个简单易用的API,比手动调用各个系统的逻辑那简直是不要太舒服!
为什么后期不重构?而是要做这些修修补补的工作呢?
举个例子,房子上有棵树,你觉得这棵树很碍事,就把树给干掉了,因为你以为,是房子上面长的,结果呢?特么是树把房子吊着的!类似的坑实在是太多了,所以,重构需谨慎,且构且珍惜。
当然不是说重构不好,而是要综合考量各方面的因素,而且,重构也用得上这些啊,毕竟,重构不是重写...(诶,重写好像也要用)
先说说它是干嘛的,用通俗一点的话来讲就是,VGA转DVI,2线插头转3线插头...废话不多说,上个图就知道了
什么?大家很想看个例子?那么我就来一个例子吧,就举一个小火鸡变成小鸭子的故事吧
先看看鸭子接口(对应Target)
/** * 鸭子接口 */public interface Duck { /** * 鸭叫 */ void quack(); /** * 飞行 */ void fly();}
然后看一下火鸡的接口和实现类(对应Adaptee)
/** * 火鸡接口 */public interface Turkey { /** * 火鸡叫 */ void gobble(); /** * 飞行 */ void fly();}/** * 野火鸡 */public class WildTurkey implements Turkey { public void gobble() { System.out.println("咯咯"); } public void fly() { System.out.println("我在飞,虽然我飞的很近"); }}
首先可以看出,它们的之间有一些共同之处,都有叫声,都可以飞行,这个也是适配的前提,有共同点!
如果没有共同点,是不是去隔壁的其他设计模式看看?
OK,接下来开始适配操作
火鸡适配器(Adapter)
/** * 火鸡适配器 */public class TurkeyAdapter implements Duck { Turkey turkey;//持有一个火鸡对象 public TurkeyAdapter(Turkey turkey) { this.turkey = turkey; } /** * 鸭叫 */ public void quack() { turkey.gobble(); } /** * 飞行 */ public void fly() { //适配的时候,这里模拟飞行5次 for(int i= 0; i < 5; i++) { turkey.fly(); } }}
适配器的逻辑也很简单
首先,实现Duck接口,要让Client能够调用,那么首先得长得和别人一样啊
其次,持有一个真正的处理对象,然后再根据Duck接口来进行适配,比如这里,quack接口,就直接调用Turkey#gobble(),而fly()可能是因为某种神秘力量,需要火鸡飞行的距离和鸭子一样远,所以需要手动去适配,在这里添加了适配的代码
最后,适配器的作用就是把一个类转换成另外一个类,转换的时候可能需要一些逻辑上的处理,让它能符合用户的期待
测试下是不是成功的伪装了呢
public class DuckClient { public static void main(String[] args) { //初始化一只火鸡 WildTurkey turkey = new WildTurkey(); //伪装成一只鸭子 Duck duck = new TurkeyAdapter(turkey); System.out.println("鸣叫:"); duck.quack(); System.out.println("------------------"); System.out.println("飞行:"); duck.fly(); }}
结果:
适配器模式模式确实很简单,但是确实也很实用,优点很明显,可以将目标类和适配者解耦,不需要改动原来的结构(新增了Adapter来封装了适配的逻辑),但是建议不要在系统设计阶段就盲目的使用它,增加系统的复杂度
这个就更简单了,例子我可以举一堆,比如说,酒店前台的小姐姐,餐厅前台的小姐姐,医院的小姐姐...
核心思想:为子系统们提供一套通用的对外接口(高级API)
为什么会有这样的需求呢?
各个子系统在设计过程中,或者在实际使用的过程中会发现,有一些通用的步骤,对于更加高的调用层来说,它们其实不需要知道底层是通过哪些步骤来实现的,更多的是,以一个统一的接口来调用。
比如,在想在家里搞一个家庭影院,需要以下步骤:
1,灯光不能太亮,亮度需要调低到10
2,需要打开投影机,并且要调整到宽屏模式
3,音响需要调整成环绕立体音,音量设置成5
4,打开DVD开始播放
代码如下:
灯光:
/** * 影院灯光 */public class TheaterLights { String description; public TheaterLights(String description) { this.description = description; } public void on() { System.out.println(description + " 打开"); } public void off() { System.out.println(description + " 关闭"); } public void dim(int level) { System.out.println(description + " 亮度调节到:" + level + "%"); } public String toString() { return description; }}
投影仪:
/** * 投影仪屏幕 */public class Screen { String description; public Screen(String description) { this.description = description; } public void up() { System.out.println(description + " 上升"); } public void down() { System.out.println(description + " 下降"); } public String toString() { return description; }}/** * 投影仪 */public class Projector { String description; DvdPlayer dvdPlayer; public Projector(String description, DvdPlayer dvdPlayer) { this.description = description; this.dvdPlayer = dvdPlayer; } public void on() { System.out.println(description + " 打开"); } public void off() { System.out.println(description + " 关闭"); } public void wideScreenMode() { System.out.println(description + " 调整到宽屏模式"); } public void tvMode() { System.out.println(description + " 调整到tv模式"); } public String toString() { return description; }}
音响:
/** * 音响 */public class Amplifier { String description; public Amplifier(String description) { this.description = description; } public void on() { System.out.println(description + " 打开"); } public void off() { System.out.println(description + " 关闭"); } //立体声 public void setStereoSound() { System.out.println(description + " 立体声模式"); } //环绕声 public void setSurroundSound() { System.out.println(description + " 环绕声模式"); } public void setVolume(int level) { System.out.println(description + " 调整音量到: " + level); } public String toString() { return description; }}
DVD播放器:
/** * DVD播放器 */public class DvdPlayer { String description; int currentTrack; Amplifier amplifier; String movie; public DvdPlayer(String description, Amplifier amplifier) { this.description = description; this.amplifier = amplifier; } public void on() { System.out.println(description + " 播放"); } public void off() { System.out.println(description + " 关闭"); } public void play(String movie) { this.movie = movie; currentTrack = 0; System.out.println(description + " 播放 \"" + movie + "\""); } public String toString() { return description; }}
不重要的代码就折叠了,免得难得看,不使用外观模式,需要调用一堆代码:
/** * 不使用外观模式 */public class Client { public static void main(String[] args) { Amplifier amp = new Amplifier("Top-O-Line 扬声器"); DvdPlayer dvd = new DvdPlayer("Top-O-Line DVD播放器", amp); Projector projector = new Projector("Top-O-Line 投影仪", dvd); TheaterLights lights = new TheaterLights("客厅灯"); Screen screen = new Screen("投影仪银幕"); System.out.println("准备看电影..."); lights.dim(10); screen.down(); projector.on(); projector.wideScreenMode(); amp.on(); amp.setSurroundSound(); amp.setVolume(5); dvd.on(); dvd.play("夺宝奇兵"); }}
使用外观模式,一行解决:
/** * 使用外观模式后的测试类 */public class FacadeClient { private static HomeTheaterFacade HOME_THEATER; static{ Amplifier amp = new Amplifier("Top-O-Line 扬声器"); DvdPlayer dvd = new DvdPlayer("Top-O-Line DVD播放器", amp); Projector projector = new Projector("Top-O-Line 投影仪", dvd); TheaterLights lights = new TheaterLights("客厅灯"); Screen screen = new Screen("投影仪银幕"); HOME_THEATER = new HomeTheaterFacade(amp, dvd, projector, screen, lights); } public static void main(String[] args) { //看电影 HOME_THEATER.watchMovie("夺宝奇兵"); }}
我擦?咋还是这么多行?
static块里面的代码是初始化代码,一般使用spring,都是依赖注入的东西,其实调用就一行:
HOME_THEATER.watchMovie("夺宝奇兵");
一键解决就是爽啊,如果说对比的话,相当于,去网上买了个床,小哥送来的是一堆零件让你组装,和小哥送来就是一张组装好了的床啊!
但是能够一键解决的,更多的是一些通用的操作,比如说,例子中,灯光不能太亮,你想把它调到5,不想用默认的10,,那么可能就只能自己写一遍外观模式封装的逻辑了。
那么这里就有个问题了,能不能重载方法,让它支持可以自定义灯光亮度这个参数呢?对于这个我只能说,要看业务需求了,如果100个人里面只有1个人用,那么对于系统产生的复杂度可能比 产生的价值高,反过来,可能就需要去实现。
但是,如果这种需求越来越多,系统变得越来越复杂,那外观模式还是一个简单可爱的小姐姐吗?如果不实现,就无法达到隐藏子系统复杂度的痛点,如果实现,就会产生新的API调用的复杂度,我终于知道为啥我特么还在学习设计模式了...
说了这么多,说说它的优缺点吧
优点:
1,对客户屏蔽了子系统组件使用起来门槛更低。
2,实现了子系统与客户之间的松耦合关系。
3,虽然提供了访问子系统的统一入口,但是并不影响用户直接使用子系统类。
缺点:
1,通过外观类访问子系统时,减少了可变性和灵活性。
2,在新的子系统加入,或者子系统接口变更时,可能需要修改外观类或客户端的源代码,违背了“开闭原则”。
联系客服