java23種設計模式中最常用的9種 
1 Factory Pattern（工廠模式） 　　上榜理由：將程序中創建對象的操作，單獨出來處理，大大提高了系統擴展的柔性，接口的抽象化處理給相互依賴的對象創建提供了最好的抽像模式。 　　

2 Facade Pattern（門面模式） 　　上榜理由：將表現層和邏輯層隔離，封裝底層的複雜處理，為用戶提供簡單的接口，這樣的例子隨處可見。門面模式很多時候更是一種系統架構的設計，在我所做的項目中，就實現了門面模式的接口，為複雜系統的解耦提供了最好的解決方案。 　　

http://www.dotblogs.com.tw/joysdw12/archive/2013/03/13/96531.aspx

http://study.qqcf.com/web/230/24589.htm

  Singleton  (獨身模式或叫單例模式)：確保一個類只有一個實例，並提供對該實例的全局訪問。

I. 單一職責原則
1. 簡介
單一職責原則（Single Responsibility Principle，SRP）其定義為：應該且僅有一個原因引起類別的變更。假設我們設計一個業務角色存取控制的模型，傳統上我們將增加用戶、用戶管理等功能都寫入同一個介面中，如圖1-1。這樣的設計方式會一團糟，不易於維護。我們應該把用戶的屬性與行為分開，將用戶資訊抽取成一個業務物件（Business Object，BO），把行為抽取成業務邏輯（Business Logic，Biz），按照這個思路就可以將類別圖修正為圖1-2。利用介面導向就可以依需求全部實做，或是只當其中單一功能，UserInfo要獲得用戶資訊，就當作IUserBO的實做類別，若希望能操作用戶行為，就當作IUserBiz的實做類別及可。


圖 1-1 傳統用戶資訊維護類別圖

圖 1-2 職責劃分後的類別圖

2. 單一職責原則的好處
單一職責原則提出了一個程式設計的標準，用“職責”或“變化原因”來衡量介面或類別設計是否優良，但是這些都是不可度量的，會因專案而異，因環境而異。單一職責原則好處如下：
 類別的複雜度降低：實現什麼職責都有清晰明確的定義。
 可讀性提升：複雜度降低可提升可讀性。
 可維護性提升：複雜度降低易於維護。
 變更引起的風險降低：修改介面只會影響相應有實做的類別，降低改錯風險。

3. 實踐原則
對於介面，很容易就可以做到單一職責。但是對於類別實做就得多方面考慮，生搬硬套單一職責類別可能會造成類別數量劇增，過度細分則會增加系統維護的複雜性，因此可以靈活運用。單一職責也適用於方法，一個方法盡可能只做一件事情，譬如定義一個修改用戶密碼方法，就別把此方法合併到修改用戶資訊方法中，簡而言之，單一職責方法清晰明確，可以避免別人還要猜測方法的邏輯，維護較為容易。對於單一職責原則，建議為介面一定要做到單一職責原則，類別的設計則盡量做到只有一個原因引起的變化，方法則盡可能只做一件事情

Android按鈕狀態(Button State)

• Step 1: Right click on your project at Package explorer(left side in eclipse)
• Step 2: goto Android.

• Step 3: In Library section Add Library...(google-play-services_lib)
  see below buttes

How to fix Android SDK Content Loader stuck at 0% in Eclipse