小例子背后的大道理——Adapter模式详解
小例子背后的大道理&mdash;&mdash;Adapter模式详解<div class="postText"><div id="cnblogs_post_body">上回问题回顾
前文说到一位用户拿着业界标准开关（一个标准的StandardSwitcher，它依赖IStandardSwitchable接口才能工作，然而目前我们的灯并不支持这个接口）出现在我面前，叫嚣着他的“标准开关”应该能打开我们的灯。好吧，这个需求是合理的，的确应该支持。但是该死的是，为什么没有早一点儿知道这个标准的存在呢？这样就不需要花费时间和人力定义这个接口，现在也不会这么纠结。和上次一样，先讲故事、演进方案，再分析背后的思想。
这回主要讲解Adapter模式，GoF讲解了这个模式是什么，怎么用，用在什么地方。我想来解释一下Adapter模式的要点是什么，对Adapter模式的延展，以及对Adapter模式的误用。顺便得瑟一下我对面向对象设计的理解。
两个方案
现在有两个选择。
[*] 让我们的灯直接支持标准开关。也就是让灯实现IStandardSwitchable接口。
[*] 好处：成本低，实现方式优雅。
[*] 坏处：相当于放弃了已经买了我们的灯，又想用标准开关的用户。
[*] 不改变现在的灯，让标准开关能打开我们的灯。标准接口我们改不了，灯也不能改。好在计算机界有句话，叫“加一层可以解决一切问题”。这让我想到了买外国电器附赠的那个电源接口转换器。现在，我们的灯需要个类似的玩意儿。
[*] 好处：支持所有的灯。
[*] 坏处：这东西都是要附赠的，会降低我们的利润。
第一个方案很简单，就是让Light多实现个接口就OK了。图就不给了。
现在分析第二个方案，标准接口依赖IStandardSwitchable接口，那我们必须有一个类来实现它，并完成所需要的功能——操作灯。咱也是学过设计模式的人，这个问题很明显可以用Adapter模式来解释。
相关类图很容易就可以画出来。
http://images.cnblogs.com/cnblogs_com/nankezhishi/201205/201205312251345660.png
图1 让灯支持IStandardSwitchable接口的方案
其对应的代码会是这个样子：
<div class="csharpcode"> 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]