小例子背后的大道理小例子背后的大道理——Adapter模式详解模式详解
上回问题回顾
前文说到一位用户拿着业界标准开关（一个标准的StandardSwitcher，它依赖IStandardSwitchable接口才能工作，然而目前
我们的灯并不支持这个接口）出现在我面前，叫嚣着他的“标准开关”应该能打开我们的灯。好吧，这个需求是合理的，的确应
该支持。但是该死的是，为什么没有早一点儿知道这个标准的存在呢？这样就不需要花费时间和人力定义这个接口，现在也不
会这么纠结。和上次一样，先讲故事、演进方案，再分析背后的思想。
这回主要讲解Adapter模式，GoF讲解了这个模式是什么，怎么用，用在什么地方。我想来解释一下Adapter模式的要点是什
么，对Adapter模式的延展，以及对Adapter模式的误用。顺便得瑟一下我对面向对象设计的理解。
两个方案
现在有两个选择。
1.让我们的灯直接支持标准开关。也就是让灯实现IStandardSwitchable接口。
好处：成本低，实现方式优雅。
坏处：相当于放弃了已经买了我们的灯，又想用标准开关的用户。
2.不改变现在的灯，让标准开关能打开我们的灯。标准接口我们改不了，灯也不能改。好在计算机界有句话，叫“加一层可以
解决一切问题”。这让我想到了买外国电器附赠的那个电源接口转换器。现在，我们的灯需要个类似的玩意儿。
好处：支持所有的灯。
坏处：这东西都是要附赠的，会降低我们的利润。
第一个方案很简单，就是让Light多实现个接口就OK了。图就不给了。
现在分析第二个方案，标准接口依赖IStandardSwitchable接口，那我们必须有一个类来实现它，并完成所需要的功能——操
作灯。咱也是学过设计模式的人，这个问题很明显可以用Adapter模式来解释。
相关类图很容易就可以画出来。
图1 让灯支持IStandardSwitchable接口的方案
其对应的代码会是这个样子：
public interface IStandardSwitchable {
void TurnOn();
void TurnOff();
}
public class SwitcherAdapter : IStandardSwitchable {
public Light Switchee { get; set; }
public void TurnOn() { Switchee.TurnOn(); }
public void TurnOff() { Switchee.TurnOff(); }
}
代码1
Job Done。Light通过SwitcherAdapter支持了新的接口，这简直就是应用适配器模式的典范啊。（嗯，这句的确是反话，不过
你猜出来为什么这个Adapter不属于适配器模式吗？）
“上回真是白跟你说了那么多，平时没觉得你这么不开窍啊。你自己好好想想吧！”背后看着我画UML图的设计Guru好像有点儿
生气。
上回？我冷静下来回想上回的内容和现在的问题。上回讲的DIP，讲不要依赖实现，要依赖抽象。再想想目前的需求，我们有
灯，有收音机，如果用户说要用标准开关开收音机，难道还要实现一个RadioAdapter不成？这显然违反了OCP。
资源评论
weixin_38558660
- 粉丝: 2
- 资源: 937
最新资源
- asm-西电微机原理实验
- Arduino-arduino
- C语言-leetcode题解之70-climbing-stairs.c
- C语言-leetcode题解之68-text-justification.c
- C语言-leetcode题解之66-plus-one.c
- C语言-leetcode题解之64-minimum-path-sum.c
- C语言-leetcode题解之63-unique-paths-ii.c
- C语言-leetcode题解之62-unique-paths.c
- C语言-leetcode题解之61-rotate-list.c
- C语言-leetcode题解之59-spiral-matrix-ii.c
资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！
点击此处反馈
