What:
SimpleFactroyPattern,由一個工廠類根據傳入的引數,動態的決定建立哪一個產品類(這些產品類繼承自一個類或者介面)。
Why:
封裝建立物件的細節,客戶端呼叫時只需要關注所需的物件,而不必關心建立的細節,減少類之間的依賴。
How:
簡單工廠中包含的角色及其職責
工廠類(Factory):簡單工廠模式的核心,負責實現建立所有勢力的內部邏輯,工廠類可以直接由外接呼叫以建立所需的物件。
抽象產品類(Product):簡單工廠模式中所有具體產品類的父類,它負責描述所有例項共有的特性及行為。
具體產品類(ConcreteProduct):簡單工廠模式中建立咪表,所有建立的物件都是充當這個覺得的某個具體類的例項。
使用簡單工廠模式前:類圖如下所示,客戶端對於具體產品類的依賴性很強。
假設現在有這麼一個情景:現在有一家公司老闆想要聽取一下幾個崗位對於公司未來的發展的看法,所以需要不同崗位的員工談一下相關的看法板,老闆分析一下各崗位員工對於公司發展前景的看法。
在現實的生活當中,稍微大一點的企業,老闆都是會有助理的,老闆告訴助理,然後讓助理去通知各個員工。其實在這裡老闆就是客戶端,祕書就是工廠類,員工是抽象產品類,具體崗位的員工就是具體產品類。
如果沒有祕書,老闆要怎麼做?老闆需要知道各個崗位的相關員工,然後通知他們完成這麼一項任務,那麼公司各個崗位員工老闆都必須要清楚,而且要清楚他們的聯絡方式,再一一通知相關的員工,如果現實中老闆這樣事必躬親,那得到了員工的意見,估計也不會有太多的時間思考公司怎麼發展。
那麼我們增加了一個老闆助理會有什麼好處呢?由祕書來完成通知員工的細節,裡面怎麼喊道相關員工由祕書來完成,老闆不必關心,只需要告訴祕書現在需要哪個崗位的人來面談,哪個崗位就是這裡傳入工廠方法的引數了。
使用工廠模式後:客戶端對於具體產品類不再依賴,達到解耦的目的。
抽象產品類:員工類
abstract class Employee { //提出意見 internal abstract void PutForwardSuggestions(); }
具體產品類:工程師
class Engineer : Employee { internal override void PutForwardSuggestions() { Console.WriteLine("工程師代表意見:定期進行技能培訓,提升員工的業務水平"); } }
具體產品類:財務
class Accountant : Employee { internal override void PutForwardSuggestions() { Console.WriteLine("財務代表意見:引入財務軟體,將使公司的財務管理更加的方便"); } }
工廠類:祕書
class Assistant { //找到老闆制定崗位的員工 internal static Employee LookForEmployee(string positionName) { Employee result = null; if (positionName == "engineer") { result = new Engineer(); } else if (positionName == "accountant") { result = new Accountant(); } return result; } }
客戶端呼叫:
class Program { static void Main(string[] args) { Employee firstEmpolyee = Assistant.LookForEmployee("engineer"); firstEmpolyee.PutForwardSuggestions(); Employee secondEmpolyee = Assistant.LookForEmployee("accountant"); secondEmpolyee.PutForwardSuggestions(); Console.ReadLine(); } }
執行結果:
簡單工廠模式的缺點:所有的建立邏輯集中在工廠類中,隨著具體產品類不斷的增加時,每一次都需要對工廠類進行修改,違反了開放封閉原則,擴充套件性不好。