總結假設我們有個需求是實現加減乘除運算的，需要我們程式設計**去實現他。
先上**
操作相關的類
/**
* 所有運算操作的父類
* */
inte***ce operation
/** * + 操作
* */
class operationadd implements operation
}/**
* - 操作
* */
class operationsub implements operation
}/**
* * 操作
* */
class operationmul implements operation
}/**
* / 操作
* */
class operationdiv implements operation
}
/**
* 工廠類
* */
public class factory
return operation;}}
public static void main(string args) catch (exception e)
if(null != operation)
}
**看完了，我們來看看為什麼要這樣寫，明明乙個方法能解決的事情為什麼要弄出來那麼多個類？
我們現在假設有兩種情況，一種是全部寫在乙個方法中，像這樣：
public bigdecimal getresult(int numa,int numb,string operationstr) throws exception
}
自然，簡單工廠就是b解決方案
需求：假如我現在需要在加一種運算，如：根號
a解決方案：
怎麼做：在getresult方法中增加乙個switch分支
好處：方便，直接加就好了
缺點：需要改動已有**，可能會出現各種問題
b解決方案：
怎麼做：新增乙個類實現operation父類，實現getresult方法，在switch中增加乙個分支
好處：不需要對已有的業務**進行改動
缺點：麻煩，需要新增乙個類
需求：假如說，我現在需要將 / 運算結果四捨五入取整
a解決方案：
怎麼做：在switch的+分支下進行改動
好處：方便
缺點：需要改動已有**，可能會出現各種問題
b解決方案：
怎麼做：到operationadd類中，修改**
好處：不需要對已有的業務**進行改動
缺點：好像沒什麼缺點(如果說要去找這個operationadd類，麻煩，那也算乙個缺點吧)
a解決方案：這個看看就知道，全部**都寫在一起，耦合度當然高
b解決方案：分成乙個個類，乙個個方法，降低了耦合度
可能因為需求太小，很多人還是任務，a的解決方案很不錯，但是，正常專案中不可能乙個需求兩行**就解決了，需要大量的業務**，如果全部都寫在同乙個方法中，到時候找起來就很難找，而且很容易牽一髮而動全身，因此，到底哪種方法好，就自己看吧，畢竟打**只是實現乙個功能的方式而已，你也可以用其他方式去實現他。
工廠模式 簡單工廠
簡單工廠其實並不是乙個設計模式，反而比較像一種程式設計習慣。我個人的這樣總結簡單工廠 建立乙個類，封裝建立物件的 故事 現在我要開一家披薩店，叫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...