小A：“什麼是簡單工廠模式？”
大B：“簡單工廠模式又叫靜態工廠模式，顧名思義，它是用來實例化目標類的靜態類。”
小A：“簡單工廠模式有什麼優點？”
大B：“現在我就主要通過一個簡單的實例說明簡單工廠及其優點。”
小A：“嗯。好。”
大B：“就如剛纔我講過的，有個國家的運動員協會。”
下面給出各個類的程序。
Code：[Copytoclipboard]
運動員.java
publicinterface運動員{
publicvoid跑（）；
publicvoid跳（）；
}
足球運動員.java
publicclass足球運動員implements運動員{
publicvoid跑（）{
//跑啊跑
}
publicvoid跳（）{
//跳啊跳
}
}
籃球運動員.java
publicclass籃球運動員implements運動員{
publicvoid跑（）{
//donothing
}
publicvoid跳（）{
//donothing
}
}
體育協會.java
publicclass體育協會{
publicstatic運動員註冊足球運動員（）{
returnnew足球運動員（）；
}
publicstatic運動員註冊籃球運動員（）{
returnnew籃球運動員（）；
}
}
俱樂部.java
publicclass俱樂部{
private運動員守門員；
private運動員後衛；
private運動員前鋒；
publicvoidtest（）{
this前鋒=體育協會，註冊足球運動員（）；
this後衛=體育協會，註冊足球運動員（）；
this守門員=體育協會，註冊足球運動員（）；
守門員，跑（）；
後衛，跳（）；
}
}
大B：“這就是簡單工廠模式的一個簡單實例，你應該想象不用接口不用工廠而把具體類暴露給客戶端的那種混亂情形吧？就好像沒了體育總局，各個俱樂部在市場上自己胡亂的尋找仔細需要的運動員。簡單工廠就解決了這種混亂。我們用OCP看看簡單工廠，會發現如果要對系統進行擴展的話治需要增加實現產品接口的產品類（上例表現爲‘足球運動員’，‘籃球運動員’類，比如要增加個‘乒乓球運動員’類），而無需對原有的產品類進行修改。”
小A：“這咋一看好像滿足OCP。”
大B：“但是實際上還是需要修改代碼的——對，就是修改工廠類。上例中如果增加‘乒乓球運動員’產品類，就必須相應的修改‘體育協會’工廠類，增加個‘註冊乒乓球運動員’方法。所以可以看出，簡單工廠模式是不滿足OCP的。”
小A：“那工廠方法模式哩？”
大B：“我們剛剛講了簡單工廠模式，下面繼續談談工廠方法模式。剛纔點明瞭簡單工廠模式最大的缺點——不完全滿足OCP。爲了解決這一缺點，設計師們提出了工廠方法模式。工廠方法模式和簡單工廠模式最大的不同在於，簡單工廠模式只有一個（對於一個項目或者一個獨立模塊而言）工廠類，而工廠方法模式有一組實現了相同接口的工廠類。下面我們通過修改剛纔的實例來介紹工廠方法模式。我們在不改變產品類（‘足球運動員’類和‘籃球運動員’類）的情況下，修改下工廠類的結構。”
相關代碼如下：
Code：[Copytoclipboard]
運動員.java
publicinterface運動員{
publicvoid跑（）；
publicvoid跳（）；
}
足球運動員.java
publicclass足球運動員implements運動員{
publicvoid跑（）{
//跑啊跑
}
publicvoid跳（）{
//跳啊跳
}
}
籃球運動員.java
publicclass籃球運動員implements運動員{
publicvoid跑（）{
//donothing
}
publicvoid跳（）{
//donothing
}
}
體育協會.java
publicinterface體育協會{
public運動員註冊（）；
}
足球協會.java
publicclass足球協會implements體育協會{
public運動員註冊（）{
returnnew足球運動員（）；
}
}
籃球協會.java
publicclass籃球協會implements體育協會{
public運動員註冊（）{
returnnew籃球運動員（）；
}
}
俱樂部.java
publicclass俱樂部{
private運動員守門員；
private運動員後衛；
private運動員前鋒；
publicvoidtest（）{
體育協會中國足協=new足球協會（）；
this.前鋒=中國足協，註冊（）；
this.後衛=中國足協，註冊（）；
守門員，跑（）；
後衛，跳（）；
}
}
大B：“很明顯可以看到，‘體育協會’工廠類變成了‘體育協會’接口，而實現此接口的分別是‘足球協會’‘籃球協會’等等具體的工廠類。”
小A：“這樣做有什麼好處呢？”
大B：“很明顯，這樣做就完全OCP了。如果需要再加入（或擴展）產品類（比如加多個‘乒乓球運動員’）的話就不再需要修改工廠類了，而只需相應的再添加一個實現了工廠接口（‘體育協會’接口）的具體工廠類。”
小A：“工廠方法模式是爲了克服簡單工廠模式的缺點（主要是爲了滿足OCP）而設計出來的。但是，工廠方法模式就一定比簡單工廠模式好呢？”
大B：“不一定。1、結構複雜度。從這個角度比較，顯然簡單工廠模式要佔優。簡單工廠模式只需一個工廠類，而工廠方法模式的工廠類隨着產品類個數增加而增加，這無疑會使類的個數越來越多，從而增加了結構的複雜程度。2、代碼複雜度。代碼複雜度和結構複雜度是一對矛盾，既然簡單工廠模式在結構方面相對簡潔，那麼它在代碼方面肯定是比工廠方法模式複雜的了。簡單工廠模式的工廠類隨着產品類的增加需要增加很多方法（或代碼），而工廠方法模式每個具體工廠類只完成單一任務，代碼簡潔。3、客戶端編程難度。工廠方法模式雖然在工廠類結構中引入了接口從而滿足了OCP，但是在客戶端編碼中需要對工廠類進行實例化。而簡單工廠模式的工廠類是個靜態類，在客戶端無需實例化，這無疑是個吸引人的優點。4、管理上的難度。這是個關鍵的問題。我們先談擴展。衆所周知，工廠方法模式完全滿足OCP，即它有非常良好的擴展性。”
小A：“那是否就說明了簡單工廠模式就沒有擴展性呢？”
大B：“不是的。簡單工廠模式同樣具備良好的擴展性——擴展的時候僅需要修改少量的代碼（修改工廠類的代碼）就可以滿足擴展性的要求了。儘管這沒有完全滿足OCP，但不需要太拘泥於設計理論，要知道，sun提供的java官方工具包中也有好多沒有滿足OCP的例子啊（java.util.Calendar這個抽象類就不滿足OCP）。然後我們從維護性的角度分析下。假如某個具體產品類需要進行一定的修改，很可能需要修改對應的工廠類。當同時需要修改多個產品類的時候，對工廠類的修改會變得相當麻煩（對號入座已經是個問題了）。反而簡單工廠沒有這些麻煩，當多個產品類需要修改是，簡單工廠模式仍然僅僅需要修改唯一的工廠類。”