解读设计模式----适配器模式(Adapter Pattern)

解读设计模式----适配器模式(Adapter Pattern),麻雀飞上枝头真能成凤凰？

金庸武侠里出现的有3大神功：北冥神功、化工大法和吸醒大法，这三大神功都是吸取别人内力之功效，却各有异同。北冥神功 北冥神功的确可以吸人内力化为我用,但并不是所有的北冥神功都可以吸人内力----损人利己。比方说虚竹体内的北冥神功就不可以,这是童姥说的。

化功大法 化功大法是用毒把别人的内力化掉，损失了别人内力却不能为己所用----损人不利己。

吸星大法 吸星大法就是吸掉别人的内力，然后自己用，但不像北冥那样真的和自身内力容为一体，弄不好不属于自己的内力会反扑，伤害到自己----损人又损己。
在金庸笔下，这三大神功都是难得之宝，多少人为得到他而......,仔细的分析下这三大神功，还是北冥较好，呵呵。我们从软件设计的角度来看，这不知算不算得上是一种复用（功力复用）的思想，只不过有点残忍罢。而在软件设计领域里，"复用"在某些时候也会出现很多问题，比如平台不兼容，开发语言不同或是接口不同等多种原因，弄得不好会不会出现既浪费了别人的现有资源，而自己的系统又无法完成呢？这有点像吸星大法----损人又损己。

企图将设计做好，就能够一劳永逸地坐享其成，这样的愿望就好上面所提到的吸星大法神功一般，这是无效无望的。因为需求的变化最是无常，我们不可能在设计之初将所以的需求变化都考虑彻底，因为我们不是先知，也不是智者，只是略懂设计技术的工匠而已。那我们应该如何应对变化呢？

有没有一套神奇的法决，能在吸取了别人的内力的同时既不损失别人的内力又能将吸取的功力为己所用呢？呵呵，或许正在看本文的你去发明了这套法决后，也会成为与张三丰齐名的一代宗师（看我说到那切了........）。其实在软件设计中也有如同此故事一般的情形出现，比如有一个已设计好的类A（内部有一方法public void Aa(){}）,我们需要在现在的系统里去调用他，而系统里却提供的是接口IB（接口下定义有一方法void Bb();），此时，我们要怎么才能让这两个不匹配的接口能够在一起工作呢？

1public class A
2public interface IB
9
13//?????????
14//我们应该怎么才能让A类的Aa方法和IB接口的Bb()方法匹配呢？
到这里，如果熟悉设计模式的朋友应该已经想到了面向对象里的一个设计模式--适配器(Adapter)模式，他正是用来解决上面所提出的这样的问题。适配器模式把一个类的接口变换成客户端所期待的另一种接口，从而使原本接口不匹配而无法在一起工作的两个类能够在一起工作。也有人把这种模式叫做包装（Wrapper）模式。

我们来看看一个很不精确的例子（这是在一位前辈的Blog留言中检到的，具体不记不清楚了），"如虎添翼"是怎么实现的呢？示意性代码如下：

namespace DesignPattern.Adapter.FlyingTigers
2namespace DesignPattern.Adapter.FlyingTigers
2namespace DesignPattern.Adapter.SparrowPhoenix
2
13
14运行结果：我是美丽的凤凰,也有人叫我火鸟,是吉祥和谐的象征。

麻雀变凤凰（对象Adapter模式）的UML草图：



呵呵，原本丑陋的麻雀，通过了Adapter的包装，将其改装为了凤凰的血统，神奇了，他还真变成了"凤凰"勒。现在我们可回头去仔细分析下，给老虎加入了翅膀，他真的变飞虎了吗？给麻雀换上凤凰的血液，麻雀真的变凤凰了吗？

本文示例代码下载：[b]DesignPattern.Adapter.rar[/b]

转载请注明出处：http://beniao.cnblogs.com/ 或 http://www.cnblogs.com/