アウトライン
ソフトウェアシステムでは、アプリケーションによる環境の変化に、多くの場合、我々は、新しい環境のアプリケーション上で、「既存のオブジェクトの一部」、新しい環境要件である必要はなく、これらのインタフェースは、既存のオブジェクトに満足していません。だから、どのように我々はこの「移行の変更」に対処するのですか？新しいインターフェイスが必要なアプリケーション環境を満たすためにしながら、既存のオブジェクトの良い使用の両方を達成するためにどのように？これは、アダプタのパターンを言うために紙です。
意図
クライアントは別のインターフェイスを期待していたクラスのインタフェースを変換します。Adapterパターンは、そうでないため、互換性のないインタフェースのこれらのクラスが一緒に働くことができない一緒に動作するようになります。
Structureチャート
図のクラスアダプタパターン構成図。1
物体2のアダプタパターン構成図
ライフ例
モードは、アダプタが別のインターフェース顧客の期待にクラスのインターフェースを変換でき、そうので、互換性のないインターフェースの元のクラスは、仕事と一緒に動作することができません。これは、レンチアダプタの例を提供します。ラチェットスリーブの開口部は、各辺の大きさは同じラチェットあります。1/2「」1/4「」の典型的な米国の辺の長さです。アダプタを使用しない場合、明らかに、その後1/2「」穴「適当ラチェット1/4ありません」。アダプタ1/4雄スナップつつに溝に、「歯「メス溝1/2を置く」1/2」を有する「1/4」1/2 '1 / 4 '' レンチ。
図の図3レンチアダプタアダプタオブジェクトの例。
図の典型的なケースデザイン：
User.csを作成します。
public class User
{
public int ID
{
get;
set;
}
public string Name
{
get;
set;
}
public string Age
{
get;
set;
}
} 然后再新建IDBHelper.cs public interface IDBHelper
{
/// <summary>
/// 连接字符串
/// </summary>
/// <returns></returns>
string DBConnectString();
/// <summary>
/// 返回结果集
/// </summary>
/// <param name="strsql"></param>
/// <returns></returns>
DataSet GetUserGroup(string strsql);
/// <summary>
/// 返回插入的行数
/// </summary>
/// <param name="user"></param>
/// <returns></returns>
int InsertUser(User user);
} 然后再新建SQLHelper.cs: public class SQLHelper:IDBHelper
{
#region IDBHelper 成员
public string DBConnectString()
{
return "SQL Connect String";
}
public DataSet GetUserGroup(string strsql)
{
DataSet ds = new DataSet();
return ds;
}
public int InsertUser(User user)
{
return 1;
}
#endregion
}然后再新建OracleHelper.cs: public class OracleHelper:IDBHelper
{
#region IDBHelper 成员
public string DBConnectString()
{
return "Oracle Connect String.";
}
public DataSet GetUserGroup(string strsql)
{
DataSet ds = new DataSet();
return ds;
}
public int InsertUser(User user)
{
return 1;
}
#endregion
}
そしてDataContent.csを構築します：
public class DataContent:IDBHelper
{
private IDBHelper DbHelper = GetDBHelper();
public static IDBHelper GetDBHelper()
{
string strClass = ConfigurationSettings.AppSettings["DBHeper"].ToString();
Assembly assembly = Assembly.Load("Adapter");
IDBHelper dbHelper = assembly.CreateInstance(strClass) as IDBHelper;
return dbHelper;
}
#region IDBHelper 成员
public string DBConnectString()
{
return DbHelper.DBConnectString();
}
public System.Data.DataSet GetUserGroup(string strsql)
{
return DbHelper.GetUserGroup(strsql);
}
public int InsertUser(User user)
{
return DbHelper.InsertUser(user);
}
#endregion
}
以下リガApp.configファイルのコードでは：
<appSettings>
<add key="DBHeper" value="Adapter.SQLHelper"/>
<!--<add key="DBHeper" value="Adapter.OracleHelper"/>-->
</appSettings>
私たちの呼び出しプログラムを参照してください。
public partial class Run : Form
{
public Run()
{
InitializeComponent();
}
private void btnRun_Click(object sender, EventArgs e)
{
DataContent dataContent = new DataContent();
rtbResult.AppendText(dataContent.DBConnectString());
}
}
結果が示されています。
達成のポイント
1。アダプタモードは、主に使用されている「既存のクラスの一部を再利用したいのですが、インターフェースおよび多重化環境要件の場合矛盾に」再利用レガシーコードの移行ライブラリは非常に便利です。
2。アダプタオブジェクトアダプタとクラスモデルは、実装構造アダプタの2つの形式がありますが、インプリメンテーションの「多重継承」のようなアダプタは、貧しい高い結合を持っていた、それが一般的に推奨されていません。疎結合の精神に沿って、より多くの「オブジェクトの組み合わせ」を介してオブジェクトアダプタ、。
3．Adapter模式的实现可以非常的灵活，不必拘泥于GOF23中定义的两种结构。例如，完全可以将Adapter模式中的“现存对象”作为新的接口方法参数，来达到适配的目的。
4．Adapter模式本身要求我们尽可能地使用“面向接口的编程”风格，这样才能在后期很方便的适配。[以上几点引用自MSDN WebCast]
5. 适配器模式是否能成功运用的关键在于代码本身是否是基于接口编程的，如果不是的话，那么适配器无能为力。
6. 适配器模式的实现很简单，基本的思想就是适配器一定是遵循目标接口的。
7. 适配器模式的变化比较多，可以通过继承和组合方式进行适配，适配器可以是一组适配器产品，适配器也可以是抽象类型。
8. 适配器模式和Facade的区别是，前者是遵循接口的，后者可以是不遵循接口的，比较灵活。
9. 适配器模式和Proxy的区别是，前者是为对象提供不同的接口，或者为对象提供相同接口，并且前者有一点后补的味道，后者是在设计时就会运用的。
效果
对于类适配器：
1．用一个具体的Adapter类对Adaptee和Taget进行匹配。结果是当我们想要匹配一个类以及所有它的子类时，类Adapter将不能胜任工作。
2．使得Adapter可以重定义Adaptee的部分行为，因为Adapter是Adaptee的一个子类。
3．仅仅引入了一个对象，并不需要额外的指针一间接得到Adaptee.
对于对象适配器：
1．允许一个Adapter与多个Adaptee，即Adaptee本身以及它的所有子类（如果有子类的话）同时工作。Adapter也可以一次给所有的Adaptee添加功能。
2．使得重定义Adaptee的行为比较困难。这就需要生成Adaptee的子类并且使得Adapter引用这个子类而不是引用Adaptee本身。
适用性
在以下各种情况下使用适配器模式：
1．系统需要使用现有的类，而此类的接口不符合系统的需要。
2。いくつかのクラスのための再利用可能なクラスを作成するいくつかのクラスを含め、互いの間に大きな相関が、一緒に将来の仕事に導入することができるではありません。これらのソースのカテゴリは、必ずしも非常に複雑なインターフェースではありません。
3。デザインの（オブジェクトアダプタの面で）、複数のインターフェースを使用すると、Adapterパターンのクラスを使用している場合、非常に実用的ではないそれぞれのサブカテゴリー、用のアダプタを作成する必要があり、既存のサブクラスを変更する必要があります。
コードの観点から4.あなたがインターフェイスに続くクラスは、顧客が期待するシステムかどうかの要件を満たしていない呼び出す必要がある場合は、アダプターを使用することを検討してください。
アプリケーションの観点から、5、ケースの両方につながる変化製品の移行、連携モジュールは、一貫性のあるインタフェースの不整合を生成する、または両者の関係を確立したい場合ので、アダプタのタイプに関連付けられていないが考えることができますモード。
概要
要するに、アダプタモードを使用して、あなたは完全に移行クラスライブラリを楽しむことができ、ライブラリの再利用の喜びをもたらします。
Paizhuanを歓迎。
ます。https：//www.cnblogs.com/springyangwc/archive/2011/04/08/2008874.htmlで再現