在復雜的工程管理系統(tǒng)中,經(jīng)常需要創(chuàng)建不同類型的任務、資源或報告對象,這些對象雖然遵循共同的接口,但具體實現(xiàn)卻因類型而異。如果直接在業(yè)務邏輯中通過new關鍵字實例化具體類,會導致代碼高度耦合,難以擴展和維護。此時,工廠方法模式(Factory Method Pattern)便提供了一個優(yōu)雅的解決方案。
工廠方法模式定義了一個用于創(chuàng)建對象的接口,但讓子類決定實例化哪一個類。工廠方法使一個類的實例化延遲到其子類。它通過將對象的創(chuàng)建過程封裝起來,使得客戶端代碼無需關心具體的創(chuàng)建細節(jié),只需依賴抽象接口,從而實現(xiàn)了依賴倒置原則,提高了系統(tǒng)的靈活性和可擴展性。
假設我們正在開發(fā)一個工程管理服務平臺,需要處理多種類型的工程任務,例如:設計任務、采購任務、施工任務。每種任務都有共同的屬性(如任務ID、名稱、負責人)和共同的行為(如啟動、暫停、生成報告),但它們的執(zhí)行邏輯和報告格式完全不同。
不使用模式的痛點:
客戶端代碼可能會充斥著大量的if-else或switch-case判斷:`java
if (taskType.equals("DESIGN")) {
task = new DesignTask();
} else if (taskType.equals("PROCUREMENT")) {
task = new ProcurementTask();
} else if (taskType.equals("CONSTRUCTION")) {
task = new ConstructionTask();
}
task.execute();`
這種代碼對修改是封閉的,每當新增一種任務類型,就必須修改所有創(chuàng)建任務的地方,違反了開閉原則,且難以進行單元測試。
Task接口,聲明所有任務共有的方法,如execute()和generateReport()。Task接口,創(chuàng)建DesignTask、ProcurementTask、ConstructionTask等具體類,實現(xiàn)各自特有的業(yè)務邏輯。TaskFactory抽象類,其中聲明一個抽象的工廠方法createTask(),返回類型為Task。這個類也可以包含一些與任務創(chuàng)建相關的基礎邏輯。DesignTaskFactory、ProcurementTaskFactory。每個具體工廠負責實現(xiàn)createTask()方法,返回對應的具體任務對象。重構后的客戶端調(diào)用:`java
// 客戶端代碼只依賴于抽象工廠和抽象產(chǎn)品
TaskFactory factory = new DesignTaskFactory(); // 具體工廠可通過配置、依賴注入等方式獲得
Task task = factory.createTask(); // 創(chuàng)建具體產(chǎn)品的細節(jié)被隱藏
task.execute();`
Task接口和TaskFactory抽象交互。監(jiān)理任務)時,只需新增對應的SupervisionTask類和SupervisionTaskFactory類,無需修改任何現(xiàn)有的工廠和客戶端代碼。在更復雜的工程管理服務中,工廠方法模式可以進一步演化:
createTask()方法可以接收參數(shù)(如任務配置參數(shù)),使得工廠能根據(jù)參數(shù)創(chuàng)建更符合上下文的對象。createTask()這個步驟作為模板方法中的一個可變環(huán)節(jié)。###
在工程管理服務這類業(yè)務對象多樣、且可能頻繁擴展的系統(tǒng)中,工廠方法模式通過將對象的創(chuàng)建與使用分離,為我們構建了一個靈活、穩(wěn)固的架構基礎。它不僅是解決對象創(chuàng)建問題的利器,更是面向?qū)ο笤O計原則(如開閉原則、依賴倒置原則)的生動實踐。正確運用此模式,能顯著提升工程管理軟件應對需求變化的能力。
如若轉(zhuǎn)載,請注明出處:http://www.gymkit.cn/product/45.html
更新時間:2026-01-21 22:37:49