設計模式(一) 簡單工廠模式
layout: post title: 設計模式(一) 簡單工廠模式 tags:
- Design_Patterns categories:
- Design_Patterns description: 我一直認為編程思想源於生活,很多一起學習的同學,總是有疑惑,我學的這些東西到底有什麽用? 如果能舉個例子,引入一定場景和故事.他們或許就很快明白了! 我很喜歡劉欣的<<碼農翻身>> 用故事給技術加點料! 他是我學習的榜樣 問題故事化!!!
設計模式(一) 簡單工廠模式
1. 引子
我一直認為編程思想源於生活,很多一起學習的同學,總是有疑惑,我學的這些東西到底有什麽用? 如果能舉個例子,引入一定場景和故事.他們或許就很快明白了! 我很喜歡劉欣的<<碼農翻身>> 用故事給技術加點料! 他是我學習的榜樣 問題故事化!!!
2. 故事繼續...
很不幸 我需要大費周章的和我的同事解釋什麽是工廠模式??
很多類都有什麽什麽XXXFactory類 通常按照尿性還有一個createXXX()
比如我們的 阿裏爸爸的Druid DruidDataSourceFactory.createDataSource(); 等等.
其實這就有工廠模式的體現,
工廠模式分為三種
- 簡單工廠模式
- 工廠模式
- 抽象工廠模式
3. 簡單工廠模式
先來個官方的解釋:
簡單工廠模式:簡單工廠模式其實不能算是一個設計模式,反而比較像一種編程習慣..............(省略300字)
我對工廠模式的理解源於我自己,編程只是我的副業 我其實是開火鍋店的,哈哈哈
4. 我的火鍋店
家族流傳的手藝 祖傳的火鍋底料制作秘方 是我開火鍋店的資本
開始我這邊只是一個小店 我一直使用祖傳的一套秘方經營著我的小店 很幸運 大家的反響很好 剛開業不到3個月,大家的口口相傳 讓我的火鍋店生意火爆 很多周邊城市的人們湧向這座小縣城 只為那舌尖上的一絲快感......
日益增多的客流量 讓我們每天的經營都是一次挑戰 但是我作為這家店的主人 依舊自信滿滿 大學學習的erp課程 讓我有一套優秀的管理方案 這套方案將會一直沿用 但是客人越來越多 口味也越來越多 我家的牛肉味火鍋已經不能滿足大眾的口味了 最近肯德基推出懷舊系列 嫩牛五方 可口可樂推出了櫻桃口味的可樂 網上火起來的華農兄弟讓大家知道了竹鼠 前幾天還有客人問我是否有竹鼠火鍋........
必須添加新的菜品! 不作出改變就得迎來死亡!
於是我們按照顧客的要求添加了很多新的口味火鍋,有牛肉火鍋,羊肉火鍋,菌菇火鍋,.........當然還有竹鼠火鍋 於是現在的火鍋店成了這樣: 方形為類
graph RL; shop[MyStore<br/>1.優秀的管理方法]; id[BeefHuoguo]-->shop; id2[LambHuoguo]-->shop; id3[BambooRatHuoguo]-->shop; id4[.....]-->shop;當然我是一個熟悉OO思想的人----找出應用中可能需要變化之處,把他們獨立出來,不要和那些不需要變化的代碼混在一起
對於火鍋的制作 有很多重復的操作 比如加湯 加油 加入 調料包 加熱等等 我把這些公共的步驟寫在墻上 大家都按這個操作步驟來就可以了
所以我們可以把這些相同的部分抽象出來:
圓形為抽象類
graph RL; abstract((Huoguo<br/>1.加油方法<br/>2.加調料方法<br/>3.加熱方法))-->shop[MyStore<br/>1.優秀的管理方法]; id[BeefHuoguo]-.->abstract; id1[LambHuoguo]-.->abstract; id3[BambooRatHuoguo]-.->abstract; id4[.....]-.->abstract;於是我們有了一層抽象類-----火鍋 這些都是湯底的種類,子類有自己的實現 而重復的方法從父類繼承
5. 工廠的加入
為了進一步加快速度 跟上信息化時代 同時減少開支 減少那些制作火鍋的大媽們 我讓我機械系的同學小王 連夜趕制了一臺機器 用來制作火鍋底料 這臺機器只需要輸入需要的火鍋類型 他就可以生產出火鍋!我把這個機器叫做HuoguoFactory
實現如下:
public class HuoguoFactory{
public Huoguo createHuoguo(String name){ //拿到火鍋的方法
Huoguo huoguo = null;
if(name.equals("BeffHuoguo")){
huoguo = new BeffHuoguo();
}else if(name.equals("LambHuoguo")){
huoguo = new LambHuoguo();
}else if(name.equals("BambooRatHuoguo")){
huoguo = new BambooRatHuoguo();
}
......
return huoguo;
}
}
現在的工作流程是這樣了: 虛線為繼承/實現關系
graph RL; HuoguoFactory[HuoguoFactory<br/>內部維護一個方法用來向使用者返回Huoguo]-->shop[MyStore<br/>內部有一個HuoguoFactory的引用<br/>1.優秀的管理方法]; abstract((Huoguo<br/>1.加油方法<br/>2.加調料方法<br/>3.加熱方法))-->HuoguoFactory id[BeefHuoguo]-.->abstract; id1[LambHuoguo]-.->abstract; id3[BambooRatHuoguo]-.->abstract; id4[.....]-.->abstract;6. 簡單工廠模式
好了 這就是我火鍋店的現狀
擁有了一臺生產不同火鍋的機器-----火鍋工廠
這就是我理解的簡單的工廠模式:
簡單工廠有一個Factory工廠實體類,我們可以直接將參數交給工廠類,而不需要針對具體類new 對象 工廠類相當於對不同實現類對象創建了一個抽象層,對使用者來說是透明的(比如對於火鍋店主的我 我根本不需要知道火鍋工廠內部是怎麽工作的 我只知道輸入一個火鍋名字 3分鐘後就會有一盆香噴噴的火鍋產出 端給客人就好了) 去除了對類實現的依賴,所以在一定程度上實現了解耦!
對於火鍋店的管理者 也就是我 如果沒有小王提供的火鍋機器 沒有這個緩沖層 我就需要在工廠的使用者MyStore中判斷創建那種火鍋 管理火鍋店的事情和制作火鍋的步驟都由我這個店長控制 太麻煩了 我只想專註我的管理 所以利用火鍋工廠 將這個業務分離出去 這樣我就可以一心的分配我的員工幹活了 該接待的接待 該打掃的打掃 火鍋制作就不需要操心了!!!
設計模式(一) 簡單工廠模式