适配器模式

之前找实习去面试的时候,被问及了设计模式的东西,没能答上来,在这里只是是偷偷的补一翻.

在大话设计模式中,对产适配器模式,他用了姚明在NBA需要一名翻译的例子.

关于适配器模式的简单定义,就是把一个类的接口能过适配器转换成客户代码希望的另外一种接口,使得原来不能兼容的两个类现在可以一起工作.

当系统中的数据和行为都是正确的,但就是接口不符合,我们就可以考虑用适配器,目的是使控制范围之外的一个原有对象与某个接口匹配.适配器主要应用于希望利用一些现存的类,但是接口又与利用环境要求不一致的情况.

关于何时使用适配器的讨论

我们已经知道对于使用一个已经存在的类,但如果它的接口,也就是它的方法和你的要求不同时,就应该考虑用适配器模式.两个类所做的事情相同或相似,但是具有不同的接口的时候,我们可以使用它,客户代码统一调用同一接口就行了.

但另一方面,做用适配器也是无奈之举,有点"亡羊补牢"的感觉.我们通常是在开发后期或者是维护阶段会用到适配器,因为如果我们是在开发设计阶段的时候,我们应该力求让类似的功能类的接口设计得相同.在设计过程中,如果出现了接口不相同时,我们首先的不应该是考虑使用适配器,而是考虑通过重构统一接口,也就是要在双方都不太容易修改的时候使用.

还有另外一种情况,就是当我们在使用第三方组件的时候,如果它提供的接口跟我们自己系统的接口不一致,而我们也完全没有必须修改自己的接口,而是可以考虑用适配器模式来解决接口不同的问题.

关于适配器模式的应用举例.

在.Net中有一个类库已经实现的适配器中,DataAdapter.

DataAdapter用途DataSet和数据源宰的适配器,以便检索和保存数据.DataAdapter通过映射Fill和Udpate来提供这一适配器.

总的来说,如果我们能事先预防接口不同的问题,不匹配的问题就不会发生,在有小的接口不统一问题发生时,及时重构,问题不到于扩大,只有碰到无法改变的原有设计和代码的情况时,才考虑适配器.事后控制不如事中控制,事中控制不如事前控制.

下面,我把大话设计模式中关于适配器模式的结构图照画了一遍:

客户端的代码是这样的

static void Main(string[] args)

{

Target target = new Adapter();

target.Request();

}

Adapter的代码是这样的

Class Adapter:Target

{

private Adaptee ads = new Adaptee();

public override void Request()

{

    ads.SpecificRequest();

}

}