靜態類和單例模式區別

觀點一：（單例）
單例模式比靜態方法有不少優點：
首先，單例能夠繼承類，實現接口，而靜態類不能（能夠集成類，但不能集成實例成員）；
其次，單例能夠被延遲初始化，靜態類通常在第一次加載是初始化；
再次，單例類能夠被集成，他的方法能夠被覆寫；
最後，或許最重要的是，單例類能夠被用於多態而無需強迫用戶只假定惟一的實例。舉個例子，你可能在開始時只寫一個配置，可是之後你可能須要支持超過一個配置集，或者可能須要容許用戶從外部從外部文件中加載一個配置對象，或者編寫本身的。你的代碼不須要關注全局的狀態，所以你的代碼會更加靈活。

觀點二：（靜態方法）靜態方法中產生的對象，會隨着靜態方法執行完畢而釋放掉，並且執行類中的靜態方法時，不會實例化靜態方法所在的類。若是是用singleton,   產生的那一個惟一的實例，會一直在內存中，不會被GC清除的(緣由是靜態的屬性變量不會被GC清除)，除非整個JVM退出了。這個問題我以前也想幾天，而且本身寫代碼來作了個實驗。

觀點三：（Good！）

因爲DAO的初始化，會比較佔系統資源的，若是用靜態方法來取，會不斷地初始化和釋放，因此我我的認爲若是不存在比較複雜的事務管理，用singleton會比較好。我的意見，歡迎各位高手指正。  

http://blog.csdn.net/v1v1wang/article/details/5511756

-----------------------------------------------------------------------------------------------------------

 

這裏暫且把單例模式限定爲不是全用靜態函數實現的。

1。使用的方便性：若是須要初始化工做，單例模式能夠在構造函數裏面完成，全靜態函數的類須要一個額外的函數來完成初始化工做，並且使用者若是沒有調用這個initialize函數，那麼後續的操做就會有問題，構造函數會被默認調用，因此使用起來比較簡單，對使用者作出了最少的假設。

2。初始化時機：單例模式初始化比較靈活，能夠在須要的時候初始化，而全靜態函數必然致使成員全爲靜態成員，靜態成員是在編譯時就初始化好了。若是初始化成本比較昂貴，而且程序裏面未必必定使用這個類，那這將是單例模式的一個很大優點。順便說一下全局變量，全局變量的初始化順序是未指定的。

例如 全局變量int a； int b；編譯器是先初始化a仍是先初始化b？我想你們只能靠猜，或者在某個編譯器上實驗一下給出答案，一旦要是有個新編譯器，結果又會是什麼樣子呢？

3。最重要的區別：單例模式能夠有多態，而全靜態的類不能支持多態。

http://www.cnblogs.com/phoebus0501/archive/2011/03/12/1982408.html

 

數據庫操做類不宜使用singleton模式

不要將數據庫鏈接作成單例，由於一個系統可能會與數據庫有多個鏈接，而且在有鏈接池的狀況下，應當儘量及時釋放鏈接。Singleton模式因爲使用靜態成員存儲類實例，因此可能會形成資源沒法及時釋放，帶來問題。

 

作項目作的多了，因此考慮問題的方向也不同了。之前剛開始只是以實現功能爲目的，美觀、實現方式、代碼邏輯、執行效率等等，幾乎不考慮。

然而要想成爲合格的軟件設計師，軟件的設計就必須全面周到，不只僅只是考慮如何開發，更多的要考慮軟件的發展和維護。

因此平時的學習中多思考多理解是很是重要的。

在學習DRP中，咱們都知道王勇把業務邏輯層（Manager、servlet）都幾乎作成的單例模式。我當時就思考爲什麼他要這麼作呢？

漸漸的我明白了，並且是切身的理解了。

在用.net開發web項目的時，在UI層咱們要實例化BLL層的類，然而正由於是web開發，若是按照咱原來的寫法（以下）

protected void Page_Load(object sender, EventArgs e)

{

    if (!Page.IsPostBack)

    {
            News news = new NewsManager().SelectById(newsid); //News：新聞實體類，爲Model層。 NewsManager：BLL層的類

    }

}

那麼客戶端只要與服務器須要交互一次就要執行一次Page_Load事件【由於與服務器交互後客戶端瀏覽器會刷新頁面】，那麼就要實例化一次NewsManager()，這還僅僅是Page_Load的事件，每每還會有別的事件，好比按鈕單擊事件，由於UI層與BLL層的交互是很是平凡的。

試想下這麼屢次重複的New的次數，是多麼的浪費資源啊，即使把NewsManager設置成該頁面的全局變量，仍是免不了每刷新一次就實例化一次的弊端。

 

因此 把BLL層的類作成單例模式是出於對服務器資源優化的一個應用。

關於單例模式的應用，我目前瞭解到的有：配置文件、打開窗口、工廠模式的工廠類、再有就是今天說的BLL層管理類。

若是各位還有對於單例模式應用和技巧的看法還請多多請教

 

 

BO層爲何設計爲單例模式？

一、首先要理解每個BO實例是用來處理用戶的一類請求操做的，即然是用來處理一類操做，那麼全部的操做均可以用一個實例來完成即單例，只要不存在實例變量，那麼就不會發生線程安全的問題。此時若是設計爲多例的，而且不存在實例變量的狀況，那麼新實例和舊實例是沒有任何區別的，都是執行同一類操做，處理用戶的同一類請求。那麼這時多實例只會佔用更多的內存空間，沒有任何益處。

 

二、理解線程棧的問題。對於用戶的每一次請求操做，都有一個線程來負責該用戶的請求處理，那麼這個線程在處理用戶業務的同時，會在內存中分配一段內存區域，該內存區域存放了用戶所調用的方法中的變量，咱們稱該內存區域爲線程棧，線程棧中除了存有方法中的局部變量外，還持有調用該方法的單實例對象的一個引用。由於每個線程棧都存儲了當前單實例對象對應方法中局部變量的不一樣版本，那麼這樣每個線程的方法操做都不會影響其餘線程的方法操做，因此不存在線程安全的問題了。

 

總結：業務層是用來處理用戶的業務邏輯操做的，概念上講業務層的對像應該設計爲只存在操做方法，而不該該有實例變量的狀況會更加符合業務層處理業務操做的概念。單例強呀！