適配器模式介紹
適配器模式的作用就是把原本不兼容的接口，通過適配修改到統一的過程，使得用戶方便使用。
在實際工作中， 有時候我們需要把各個業務線的各種類型服務做統一的包裝，再對外提供接口進行使用。
適配器模式要解決的主要問題就是多種差異化類型的接口做統一輸出。
適配器可擔任兩個對象間的封裝器，它會接收對於一個對象的調用，並將其轉換為另一個對象可識別的格式和接口。
適配器模式通過封裝對象將復雜的轉換過程隱藏於幕后。被封裝的對象甚至察覺不到適配器的存在。
適配器模式結構
- 對象適配器
構成原則：適配器實現其中一個對象的接口，並對另一個對象進行封裝。
1、客戶端：包含當前程序業務邏輯的類。
2、客戶端接口：描述了其他類與客戶端代碼合作時必須遵循的協議。
3、服務：其中的有些功能類或方法，客戶端無法直接調用其功能，無法進行使用。
4、適配器：可以同時與客戶端和服務交互的類，它在實現客戶端接口的同時封裝了服務對象。適配器接受客戶端通過適配器接口發起的調用，並將其轉換為適用於被封裝服務對象的調用。
客戶端代碼只需通過接口與適配器交互即可，無需與具體的適配器耦合。這在服務類接口被更改或替換時很有用，你無需修改客戶端代碼就可以創建新的適配器類。
- 類適配器
通過繼承機制，適配器同時繼承兩個對象的接口。此種方式只在支持多重繼承的編程語言中實現，例如C++
類適配器不需要封裝任何對象，因為它同時繼承了客戶端和服務的行為。適配功能在重寫的方法中完成，最好生成的適配器可替代已有的客戶端類進行使用。
適配器模式優缺點
優點：
-
使得代碼干凈整潔，易於維護，減少大量重復的判斷和使用，讓代碼更加易於維護和擴展。
-
單一職責原則，可以將接口或數據轉換代碼從程序主要業務邏輯中分離。
-
開閉原則，客戶端代碼通過客戶端接口與適配器進行交互，你就能在不修改現有客戶端代碼的情況下在程序中添加新類型的適配器。
缺點：
- 代碼復雜度增加，需要增加很多接口和類
Demo
/// <summary>
/// 接口類，客戶端類
/// </summary>
public interface ITarget
{
string GetRequest();
}
/// <summary>
/// 被適配者 例如遺留老代碼，開源模塊等
/// </summary>
public class Adaptee
{
public string GetSpecificRequest()
{
return "特殊的請求 遺留的老代碼";
}
}
/// <summary>
/// 適配器
/// </summary>
public class Adapter:ITarget
{
private readonly Adaptee _adaptee;
public Adapter(Adaptee adaptee)
{
this._adaptee = adaptee;
}
/// <summary>
/// 顯示實現的接口類
/// 在這里可以調用遺留老代碼的方法。
/// </summary>
/// <returns></returns>
public string GetRequest()
{
return "我正在調用：" + _adaptee.GetSpecificRequest();
}
}
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Start Test Adapter Mode");
//實例化老代碼模塊
Adaptee tempAdaptee = new Adaptee();
ITarget adapter = new Adapter(tempAdaptee);
//通過實現的接口去調用老代碼模塊中的方法。
var showResult=adapter.GetRequest();
Console.WriteLine(showResult);
Console.ReadKey();
}
}
可以看到在上述代碼中，我們通過適配器去直接調用的老代碼中的方法。在我們平時的開發過程中，適配器使用的場景還是很多的，比如系統對開源組件的支持，多設備的支持等。對於設計模式而言，要學會注意它的使用場景，也只有在合適的場景下使用它，才能發揮它最大的效果。
適配器可以通過以不同抽象或接口實例為參數的構造函數來識別。當適配器的任何方法被調用時，它會將參數轉換為合適的格式，然后將調用定向到其封裝對象中的一個或多個方法。
小寄語
人生短暫，我不想去追求自己看不見的，我只想抓住我能看的見的。
原創不易，給個關注唄。
我是阿輝，感謝您的閱讀，如果對你有幫助，麻煩點贊、轉發 謝謝。