摘要:所以,也要慎用當你的項目中,產品越來越多,創建者的數量也隨之臃腫,下一篇將介紹抽象工廠方法的變體原型模式,這種模式可以減少必須創建的類。
抽象工廠方法模式
在工廠方法模式中,我們通過中間件的方式,形成了以下格式的分離:
使用者
↓
創建者
↓
具體產品
這樣,我們無論怎樣修正具體產品,都不會影響使用者。現在,我們可以做出來一群小工廠,他們有各自的產品,但形成了模式層面的重復,那么我們如何化解這種重復呢?
在本篇,將通過抽象工廠方法模式——抽象 - 工廠方法 - 模式,來完成對小公司的整合,最初設計(母公司 - 子公司):
接下來,我們要通過抽象類解決多個業務并行的問題。
現在,我們要寫一個PIM的數據格式解碼器 - Personal Information Manage,會產生預約(Appt)、待辦事宜(Ttd)、聯系人(Contact)三種數據格式。
我們就可以設計出下列UML:
通過CommsManager抽象類,我們可以生成具體的所有子公司(子類)。
但事實上,這也一定程度的顯示了為什么有些公司做不好某些行業,一旦他哪怕是間接介入子公司,也會影響子公司的血統(這個想法我最早接觸于吳軍先生的《浪潮之巔》)。
實現abstract class CommsManager { abstract function getHeaderText(); abstract function getApptEncoder(); abstract function getTtdEncoder(); abstract function getConteactEncoder(); abstract function getFootText(); } class BloggsCommsManager extends CommsManager { function getHeaderText() { return "BloggsCal header "; } function getApptEncoder() { return new BloggsApptEncoder(); } function getTtdEncoder() { return new BloggsTtdEncoder(); } function getConteactEncoder() { return new BloggsConteactEncoder(); } function getFootText() { return "BloggsCal footer "; } }
在這里,我們用了工廠模式(目錄在最后)。設計模式之間經常這樣協作,一個模式的創建,可以成為另一個模式的一部分。
這方面的想法就是源于模式本身:他是經過無數次同條件下,實踐得出的最優解——未來如果有更好的條件,這個最優解就仍然有優化的空間 / 或者沒有存在的。
結果模式的意義:
徹底的將 業務需求 與 實現細節 分割,現在,我們可以隨意的改動編碼格式,而不用擔心業務層產生BUG;
通過強制整合,所有Blogger格式的內容,都通過Blogger創建者類來實現,不會出錯;
當然,添加新產品則是令人苦惱的,為了創建新產品的具體實現,我們必須修改抽象創建者、和他的每一個具體實現。
PHP目前還沒有強制規定 方法的返回類型,這產生了一些額外的靈活性。(強制規定返回類型,一般為JAVA之類的 強類型-面向對象-語言)
abstract class CommsManager { const APPT = 1; const TTD = 2; const CONTACT = 3; abstract function getHeaderText(); abstract function mark( $flag_int ); abstract function getFootText(); } class BloggsCommsManager extends CommsManager { function getHeaderText() { return "BloggsCal header "; } function mark( $flag_int ) { switch ($flag_int) { case self::APPT: return new BloggsApptEncoder(); case self::TTD: return new BloggsTtdEncoder(); case self::CONTACT: return new BloggsConteactEncoder(); } } function getFootText() { return "BloggsCal footer "; } }
類的接口變得更加緊湊,但也有一定的代價,我們放棄了詳細的數據格式方法,而是將其中心化了,客戶無法確認是否實現了需要的具體產品。
所以,也要慎用~
當你的項目中,產品越來越多,創建者的數量也隨之臃腫,下一篇將介紹抽象工廠方法的變體:原型模式,這種模式可以減少必須創建的類。
面向對象設計模式 - 目錄
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/22580.html
摘要:工廠方法模式面向對象的設計強調抽象類高于實踐,盡可能的將代碼設計的一般化,而非特殊化也就是降低耦合,提升標準性。于是,前輩們便設計了特定類處理實例化的工廠方法。實現這個時候我們引入工廠方法模式,設置類創造者,類產品,。面向對象設計模式目錄 工廠方法模式 面向對象的設計強調抽象類高于實踐,盡可能的將代碼設計的一般化,而非特殊化——也就是降低耦合,提升標準性。于是,前輩們便設計了特定類處理...
摘要:原型模式平行的繼承層次使用工廠模式在大型設計中,必須去維護大量的產品類。上文中,稱之為特殊的耦合在這里我們介紹一種其抽象工廠模式的變體原型模式。面向對象設計模式目錄 原型模式 平行的繼承層次使用工廠模式在:大型設計中,必須去維護大量的產品類。(上文中,稱之為特殊的耦合) 在這里我們介紹一種其抽象工廠模式的變體:原型模式。它使用clone關鍵詞,來復制具體產品類,使得具體產品類能完成自我...
摘要:我們今天也來做一個萬能遙控器設計模式適配器模式將一個類的接口轉換成客戶希望的另外一個接口。今天要介紹的仍然是創建型設計模式的一種建造者模式。設計模式的理論知識固然重要,但 計算機程序的思維邏輯 (54) - 剖析 Collections - 設計模式 上節我們提到,類 Collections 中大概有兩類功能,第一類是對容器接口對象進行操作,第二類是返回一個容器接口對象,上節我們介紹了...
摘要:面向對象設計的五大原則單一職責原則接口隔離原則開放封閉原則替換原則依賴倒置原則。主要是針對繼承的設計原則,繼承與派生多態是的主要特性。 面向對象設計的五大原則:單一職責原則、接口隔離原則、開放-封閉原則、替換原則、依賴倒置原則。這些原則主要是由Robert C.Martin在《敏捷軟件開發——原則、方法、與實踐》一書中總結出來,這五大原則也是23種設計模式的基礎。 單一職責原則 Sin...
閱讀 1207·2019-08-30 15:55
閱讀 954·2019-08-30 15:55
閱讀 2150·2019-08-30 15:44
閱讀 2879·2019-08-29 14:17
閱讀 1130·2019-08-29 12:45
閱讀 3301·2019-08-26 10:48
閱讀 3133·2019-08-23 18:18
閱讀 2599·2019-08-23 16:47