這段文字最初是回復水木上一個mm的問題，問為什么要用工廠，整理之后，發到這里來。

工廠模式是創建模式，封裝對象的創建過程。對象的創建最簡單的方式是new出來，但是有一些情況下用new來創建對象會導致代碼難以維護。

實例來了，說我們為什么要用工廠。在某系統中要用到一個DataSource對象。而且用的很廣泛。在盤古開辟天地的時期，要獲取一個DataSource對象，是這么干的：



在很多地方寫了這樣的代碼之后，你的團隊里面的另外一個人開始與你合作做這個項目。這位仁兄拿到代碼之后發現，你寫在代碼中一共20個地方的new DataSourceImpl("dburl","user","password")里面的數據庫url,username和password和他的機器上的情況不符合，于是導致他的機器上應用跑不起來。

于是你發現，這樣做有問題。

于是你創建了一個新類，叫做DataSourceManager。干什么呢，專門來創建DataSource.



其實這個DataSourceManager已經是一個簡單的工廠了。說他簡單，是因為他的創建邏輯簡單。

經過上面的改造，你的同事拿到代碼之后高興了，發現自己只要把這個DataSourceManager里面的代碼改一改，在自己機器上就能跑起來了。于是他請你吃了哈根達斯——當然，不排除這是因為他想追你。

又過了兩天，恭喜你項目越做越大，團隊又加入了2個人。你們決定要使用版本控制工具來管理代碼。當大家都開始從svn拿最新的代碼的時候，你發現每天都會拿到新的DataSourceManager，里面變化的是各個團隊成員自己機器上的數據庫url，用戶名，密碼。而這些變化對于項目進展來說是無效的，于是你希望大家不要提交這個類。之后很快你會發現這不是最好的方法，因為每到一個新的環境，你改了DataSourceManager里面的代碼，都需要編譯相關的類，才能使用。

于是你發揮聰明才智，把數據庫用戶名密碼放在了一個properties配置文件中。暫且叫做jdbc.properties。然后經過改造，DataSourceManager變成了下面的樣子：



恭喜你，經過這樣的改造，DataSourceManager封裝了更多的創建邏輯，而你在不同的機器上部署應用的時候也不需要總是去編譯了。

過了幾天，領導對你說，現在用jdbc直接連數據庫可能會有性能問題，我們希望使用jndi，使用容器管理的數據源，但是同樣要給開發人員保持使用jdbc連接的余地。

于是你再一次的修改DataSourceManager，根據一個配置，決定是去jndi中取dataSource直接返回，還是根據用戶密碼url來創建dataSource返回。

回首往事，你將會心潮澎湃。想像一下當初如果沒有用DataSourceManager這么個東西來封裝DataSource的創建過程，而是堅持在系統的各個角落創建DataSource的話，現在要改成jndi方式得費多大勁。于是一高興，你請當初請你吃哈根達斯的那個男生吃了頓飯?？上У氖撬e誤的理解了你的意思，以為你對他有某方面的好感。

再后來的某一天，你有幸讀到了和banq吵架很火爆的閻宏博士寫的《Java與模式》，發現你所寫的DataSourceManager就是他書中闡述的工廠模式——因為其職責是封裝對象的創建過程。正好趕上陳水扁在臺灣給各名勝改名去掉中國字眼，號稱叫做正名，于是你為你的DataSourceManager也正了一下名，改叫做DataSourceFactory。

至此，你終于理解了工廠模式是干什么的，以及他為什么這么重要。

后若干歲月，你開始研究開源世界里面大大小小的輪子，某一天發現了Spring這么個東西，之后又驚奇的發現，這個東西的核心內容，竟然就是一個BeanFactory——也就一工廠。于是你融會貫通，高興之余，拒絕了那個男生對你的求愛，告訴他說你現在只對工廠感興趣，對男人沒興趣。