解釋器模式是什麼 解釋器是一種行為型設計模式，指給分析對象定義一個語言，並定義該語言的文法表示，再設計一個解析器來解釋語言中的句子。也就是說，用編譯語言的方式來分析應用中的實例。這種模式實現了文法表達式處理的介面，該介面解釋一個特定的上下文。 為什麼用解釋器模式 在軟體開發中，會遇到有些問題多次重覆 ...
結構型設計模式
創建型設計模式主要是為瞭解決創建對象的問題，而結構型設計模式則是為瞭解決已有對象的使用問題。
適配器模式
適配器模式比較好理解，因為在我們的日常生活中就很常見，如耳機轉換線、充電器適配器、插座等，舉個最常見的例子：
插座就是個適配器，將一個介面擴展為多個介面，將牆上的雙孔介面轉換為三孔介面。而這也就是適配器的作用：將一個介面轉換為用戶期望的另一個介面。
適配器的使用場景：
- 需要使用第三方SDK的核心功能，但其介面或者功能不符合需求，這時可以使用適配器對其進行相容和擴展
- 隨著業務發展，舊介面已經不能滿足需求，但重寫代價又太大，這時可以使用適配器對介面功能進行擴展
註意：適配器是對已有資源進行相容和擴展，屬於一種折中的方式，如果可以的話，儘量重構系統而不是使用適配器
繼承器的實現有兩種方式：繼承和組合,基於合成復用的原則，組合優於繼承，所以應儘量使用組合的方式實現適配器。類圖如下：
實現代碼：
//已有的舊介面,不相容於現在的系統
public interface IAmericanElectrictService
{
int Get110VElectric();
}
//adaptee，需要適配的SDK
public class AmericanElectrictService : IAmericanElectrictService
{
public int Get110VElectric()
{
Console.WriteLine("美國的電壓是110v，只能提供110V的電壓");
return 110;
}
}
//已有介面，現在的系統需要使用這個介面
public interface IChineseElectricService
{
int Get220VElectric();
}
//適配器，採取組合的方式
//這裡是為了適配已有介面，所以實現了這個介面
public class AdapterPattern : IChineseElectricService
{
private readonly IAmericanElectrictService _service;
public AdapterPattern(IAmericanElectrictService service)
{
this._service = service;
}
public int Get220VElectric()
{
var electric = this._service.Get110VElectric();
Console.WriteLine("劈里啪啦劈里啪啦，經過一番操作，現在電壓轉換為220V的了");
return electric + 110;
}
}
//使用適配器，將110V電壓轉換成220V
public class AdapterRunner : IRunner
{
public void Run()
{
//實際情況中，adaptee有可能是已有SDK，有可能是interface，通過IOC容器對應具體實現類
var americanElectric = new AmericanElectrictService();
var electric = americanElectric.Get110VElectric();
Console.WriteLine($"獲得了{electric}V電壓");
Console.WriteLine("使用適配器");
var adapter = new AdapterPattern(americanElectric);
electric = adapter.Get220VElectric();
Console.WriteLine($"使用適配器後獲得了{electric}V電壓");
}
}
//輸出
//------------------------------------
//美國的電壓是110v，只能提供110V的電壓
//獲得了110V電壓
//使用適配器
//美國的電壓是110v，只能提供110V的電壓
//劈里啪啦劈里啪啦，經過一番操作，現在電壓轉換為220V的了
//使用適配器後獲得了220V電壓
總結
優點：
- 可以擴展和相容現有類，靈活性高
- 提高了類的復用，原本不能使用的類適配後能使用
缺點：
- 適配器本質是套一層，如果使用過多，可能導致系統混亂，甚至出現套中套的複雜情況
裝飾器模式
利用繼承和組合，在不改變現有結構的情況下對功能進行擴展的模式稱為裝飾器模式
裝飾器模式和適配器模式很像，但側重點不一樣。適配器的重心在於相容已有系統，而裝飾器的重心在於功能擴展。裝飾器的類圖如下：
上圖中，基礎裝飾器繼承抽象類，每個裝飾器繼承前一個裝飾器，一步一步添加功能，並且所有裝飾器都用到具體實現類，因為需要擴展具體功能。
這裡其實就能看出一些裝飾器和適配器的區別，適配器和裝飾器都使用組合來包裝已有類，不同的是裝飾器用到了繼承。裝飾器的核心原則是里氏替換原則，即父類一定能被子類替換而不影響現有代碼。實現代碼如下：
//抽象基礎類
public abstract class AbstractStudent
{
public abstract void Study();
}
//具體實現類
public class Student : AbstractStudent
{
public override void Study()
{
Console.WriteLine("我正在學習！！！");
}
}
//基礎裝飾器，什麼也不做
//註意，這裡標記為抽象類，此後的裝飾器以此為基礎
public abstract class BaseDecorator : AbstractStudent
{
private readonly AbstractStudent _student;
public BaseDecorator(AbstractStudent student)
{
this._student = student;
}
//這裡使用override還是Virtual取決於AbstractStudent基礎類是抽象類還是介面
public override void Study()
{
this._student.Study();
}
}
//首碼裝飾器，在調用具體功能前做點什麼
public class PreDecorator : BaseDecorator
{
public PreDecorator(AbstractStudent student) : base(student)
{
}
public override void Study()
{
Console.WriteLine("學習前看會兒小說");
base.Study();
}
}
//尾碼裝飾器，在調用具體功能後做點什麼
public class NextDecorator : PreDecorator
{
public NextDecorator(AbstractStudent student) : base(student)
{
}
public override void Study()
{
base.Study();
Console.WriteLine("學習辛苦啦，獎勵自己一包辣條");
}
}
//測試代碼
public class DecoratorRunner : IRunner
{
public void Run()
{
Console.WriteLine("沒有用裝飾器的基本功能：");
var student = new Student();
student.Study();
Console.WriteLine();
Console.WriteLine("使用首碼裝飾器在基礎功能之前做點什麼");
var preDecorator = new PreDecorator(student);
preDecorator.Study();
Console.WriteLine();
Console.WriteLine("使用尾碼裝飾器在首碼裝飾器功能之後做點什麼");
//註意：這裡傳入的首碼裝飾器，在首碼裝飾器的基礎之上做擴展
var nextDecorator = new NextDecorator(student);
nextDecorator.Study();
}
}
//輸出：
//沒有用裝飾器的基本功能：
//我正在學習！！！
//
//使用首碼裝飾器在基礎功能之前做點什麼
//學習前看會兒小說
//我正在學習！！！
//
//使用尾碼裝飾器在首碼裝飾器功能之後做點什麼
//學習前看會兒小說
//我正在學習！！！
//學習辛苦啦，獎勵自己一包辣條
可以看出，裝飾器其實就是利用組合+繼承(實現)+override不斷包裝和更新對象，使其功能得到擴展。裝飾器是用於替換繼承的設計模式，主要使用場景如下：
- 想擴展實現類的功能，又不想添加太多子類
- 需要動態增加和撤銷功能(例如游戲技能)
裝飾器的優點在於靈活，耦合性低，且不會改變現有結構。缺點則是嵌套過多會增加系統複雜度。
