概念:
簡單工廠模式是由乙個工廠物件決定建立出哪一種產品類的例項。
uml類圖:
分析一下，簡單工廠的角色有，工廠角色(creator)，抽象產品角色(iproduct)，以及具體產品角色(product_a，product_b)。
「工廠類」是根據客戶端傳入的引數，動態地決定建立哪個「具體產品類」（而這些個「具體產品類」又繼承至乙個父類或介面），所以簡單工廠模式屬於建立型模式。
**實現：
我想以生產汽車為例子。
首先我要有汽車類（這個可以是類，也可以是介面，抽象類應該也是可以的），然後為了簡化問題，這個汽車類只有兩種汽車，賓士和寶馬。而且為了簡化問題，這些類都只有乙個簡單的方法。然後就是乙個工廠類，這個工廠類有乙個方法就是建立汽車。
uml圖如下
具體**如下：
namespace simplyca***ctory
}//首先是抽象產品角色，汽車介面
inte***ce icar
//然後是兩個具體產品角色，寶馬和賓士,他們都要實現icar介面
class bmw:icar
}//benz類
class benz:icar
}//然後就是工廠角色，汽車工廠
class ca***ctory
return car;}}
}
可以看出以上**非常簡單，簡單工廠是非常常用的設計模式，但是他的缺點是，如果我需要再新增一種汽車，比如奧迪。那麼增加乙個奧迪汽車類這是可以的，但是需要修改ca***ctroy的createcar方法，在switch…case中新增一條case語句，這就違背了開放-封閉原則。
優點
通過使用工廠類，外界可以從直接建立具體產品物件的尷尬局面擺脫出來，僅僅需要負責」消費」物件就可以了。而不必管這些物件究竟如何建立及如何組織的．明確了各自的職責和權利，有利於整個軟體體系結構的優化。
缺點
由於工廠類集中了所有例項的建立邏輯，違反了高內聚責任分配原則，將全部建立邏輯集中到了乙個工廠類中；它所能建立的類只能是事先考慮到的，如果需要新增新的類，則就需要改變工廠類了。
當系統中的具體產品類不斷增多時候，可能會出現要求工廠類根據不同條件建立不同例項的需求．這種對條件的判斷和對具體產品型別的判斷交錯在一起，很難避免模組功能的蔓延，對系統的維護和擴充套件非常不利；
這些缺點在工廠方法模式中得到了一定的克服。
使用場景
工廠類負責建立的物件比較少;
客戶只知道傳入工廠類的引數，對於如何建立物件（邏輯）不關心；
由於簡單工廠很容易違反高內聚責任分配原則，因此一般只在很簡單的情況下應用。
工廠模式 簡單工廠
簡單工廠其實並不是乙個設計模式，反而比較像一種程式設計習慣。我個人的這樣總結簡單工廠 建立乙個類，封裝建立物件的 故事 現在我要開一家披薩店，叫bbk 必敗客 披薩，賣很多種披薩 芝士披薩 榴蓮披薩等等，我有乙個orderpizza string type 方法，根據客戶傳來的type來提供不同的披...
工廠模式 簡單工廠
工廠 處理建立物件的細節。目的 將例項化具體類的 從應用中抽離，或者封裝起來，可以避免干擾應用的其他部分。簡單工廠 簡單工廠其實不是乙個設計模式，反而像一種程式設計習慣。產品實現 desc 產品a public inte ce a class a1 implements a override pub...
簡單工廠模式，工廠模式，抽象工廠模式
三種模式看了一天，記錄下自己的理解 headfirst，比薩店為例 1，簡單工廠模式 乙個具體的工廠類 pizzafactory 乙個抽象的產品類pizza，可以派生出多個具體的產品類 客戶 pizzastore類 工廠類 pizzafactory類關聯產品類pizza，工廠生產出不同型別的pizz...