适配器模式

意图：把一个类的接口变换成客户端所期待的另一种接口，从而使原本接口不匹配而无法在一起工作的两个类能够在一起工作.

类图：

 

说明：

     Adaptee类没有Request 方法，而客户期待这个方法。为了使客户能够使用
     Adtapee类，提供一个中间环节，即类 Adapter类，Adapter类实现了 Target 接口，并继承
     自 Adaptee，Adapter类的 Request 方法重新封装了 Adaptee的 SpecificRequest 方法，
     实现了适配的目的。
     因为 Adapter与 Adaptee是继承的关系，所以这决定了这个适配器模式是类的

 代码：

　　using System;

　　interface ITarget
　　{
　　　　void Request();
　　}

　　class Adaptee
　　{
　　　　public void SpecificRequest()
　　　　{
　　　　　　Console.WriteLine("Called SpecificRequest()" );
　　　　}
　　}
　　class Adapter : Adaptee, ITarget
　　{
　　　　public void Request()
　　　　{
　　　　　　this.SpecificRequest();
　　　　}
　　}
　　public class Client
　　{
　　　　public static void Main(string[] args)
　　　　{
　　　　　　ITarget t = new Adapter();
　　　　　　t.Request(); 
　　　　}
　　}

类图二：

　　

 

说明：

　　客户端需要调用 Request 方法，而Adaptee没有该方法，为了使客户端能
够使用 Adaptee类，需要提供一个包装（Wrapper）类 Adapter。这个包装类包装了一个
Adaptee的实例，从而将客户端与 Adaptee衔接起来。由于 Adapter与 Adaptee是委派关
系，这决定了这个适配器模式是对象的。

代码： 

      class Target
     {
　　　　virtual public void Request()
　　　　{
　　　　}
　　}
　　class Adapter : Target
　　{
　　　　private Adaptee adaptee = new Adaptee();
　　　　override public void Request()
　　　　{
　　　　　　adaptee.SpecificRequest();
　　　　}
　　}
　　class Adaptee {
　　　　public void SpecificRequest()
　　　　{
　　　　　　Console.WriteLine("Called SpecificRequest()" );
　　　　}
　　}
　　public class Client
　　{
　　　　public static void Main(string[] args)
　　　　{
　　　　　　Target t = new Adapter();
　　　　　　t.Request();
　　　　}
　　}

何时采用:

    从代码角度来说， 如果你希望分离复杂类型构建规则和类型内部组成，或者希望把相同的构建过程用于构建不同类型的时候可以考虑使用建造者模式。

    从应用角度来说， 如果你希望解耦产品的创建过程和产品的具体配件，或者你希望为所有产品的创建复用一套稳定并且复杂的逻辑的时候可以考虑使用建造者模式。

实现要点:

    适配器模式是否能成功运用的关键在于代码本身是否是基于接口编程的，如果不是的话，那么适配器无能为力。

    适配器模式的实现很简单，基本的思想就是适配器一定是遵循目标接口的。

    适配器模式的变化比较多，可以通过继承和组合方式进行适配，适配器可以是一组适配器产品，适配器也可以是抽象类型。

    适配器模式和Facade的区别是，前者是遵循接口的，后者可以是不遵循接口的，比较灵活。

    适配器模式和Proxy的区别是，前者是为对象提供不同的接口，或者为对象提供相同接口，并且前者有一点后补的味道，后者是在设计时就会运用的。

注意事项:

    在对两个无关类进行适配的时候考虑一下适配的代价，一个非常庞大的适配器可能会对系统性能有影响。