外觀模式 => 把很多子系統包起來 => 對外統一呼叫我就好
假設公司內部很亂 每個部門開發自己的子系統
但每件需求一定都是跨部門發生 所以我總得先Call A 部門的程式、再 B 部門的程式、再 C 部門的程式
但實際上怎麼用其他部門的程式都是固定的 我想把他們包裝起來
例如現在有三個部門 分別寫自己的系統
/// <summary>
/// 從資料庫讀出大家的考試成績
/// </summary>
class ReadSystem
{
public List<double> GetScore()
{
return new List<double> { 30, 50, 60, 80, 90, 100 };
}
}
/// <summary>
/// 老師人很好,所有人成績加 10%
/// </summary>
class UpdateSystem
{
public List<double> UpdateScore(List<double> data)
{
for (int i = 0; i < data.Count; i++)
{
data[i] *= 1.1;
}
return data;
}
}
/// <summary>
/// 刪掉不及格的人
/// </summary>
class DeleteSystem
{
public List<double> DeleteNotPass(List<double> data)
{
return data.Where(q => q >= 60).ToList();
}
}
可是實際上我呼叫就是
1. 好老師 => 有調分數 => 再看有沒有過
2. 普通老師 => 沒調分數 => 直接看有沒有過
/// <summary>
/// 主程式透過我使用其他子系統
/// </summary>
class Facade
{
//子系統宣告在 Facade 中
ReadSystem read;
UpdateSystem update;
DeleteSystem delete;
public Facade()
{
read = new ReadSystem();
update = new UpdateSystem();
delete = new DeleteSystem();
}
//Facade了解子系統怎麼叫用 並組出商業邏輯想要的結果
public List<double> KindPass()
{
var scores = read.GetScore();
scores = update.UpdateScore(scores); //有調分數
scores = delete.DeleteNotPass(scores);
return scores;
}
//Facade了解子系統怎麼叫用 並組出商業邏輯想要的結果
public List<double> NormalPass()
{
var scores = read.GetScore();
scores = delete.DeleteNotPass(scores);
return scores;
}
}
最後可以達到主程式中
/// <summary>
/// Facade 隱藏子系統是誰、並且主程式也不用知道子系統怎麼用
/// </summary>
class Program
{
static void Main(string[] args)
{
Facade facade = new Facade();
//如果遇到好老師 有哪些人可以過
facade.KindPass();
//如果遇到普通老師 有哪些人可以過
facade.NormalPass();
}
}
可以得知有幾個重點
1. 主程式只面對 Facade 不直接面對其他子系統
2. Facade 知道所有子系統怎麼用 並且包成好用的函式直接給主程式叫用
所以最後你就會發現 其實學習這麼多 DP 其實都只是在做幾件事
1. 用盡各種程式技巧把重覆的程式碼消除 => 通常就是把共用的部份再往上提一層
2. 不該知道的不透露給外面的人知道 => 知道的越少 藕合越低 有變動時要改的地方越少
其實你只要能做到這幾件事 你不使用任何 DP 也沒差
只是用了 DP 能帶給你什麼好處?
喔 我看到有個關鍵字叫 Facade、叫 Proxy、叫 Factory 那我大概知道你想做什麼
因為大家約定俗成的 把某種情境取成這個名子
所以我不從第一行看到最後一行 我也大概知道你想做什麼
哪一段的程式碼會放在哪邊
如此而已