單例模式是屬於比較常用的一例，乙個類（class）在記憶體中只有乙個例項。
常用方式如下:
第一種（餓漢式）：
public class singleton
//在自己內部定義自己乙個例項，是不是很奇怪？
//注意這是private 只供內部呼叫
private static singleton instance = new singleton();
//這裡提供了乙個供外部訪問本class的靜態方法，可以直接訪問
public static singleton getinstance()
}
第二種方式：（懶漢式）
public class singleton
}
比較安全的使用方式是第一種private static singleton instance = new singleton();
單例的陷井：
多個虛擬機器
當單例類被執行在多個虛擬機器下的時候，在每個虛擬機器都可以建立乙個例項對歇腳。像使用了ejb，jini，rmi技術的分布式系統的時候，因為中介軟體遮蔽了分布式系統在物理上的差異，這個時候想知道在哪個虛擬機器下執行著哪個單例物件很困難。因此在使用分布式技術時，應該避免使用
多個類載入器
在這種情況，由狀態的單例模式也會給系統帶來隱患。因此除非系統由協調機制，在一般情況下不要使用存在狀態的單例模式。
錯誤的同步處理
在使用上面介紹的懶漢式單模式的時候，同步得理恰當與否也是很，不然要能達不到想要的單例效果，還可能引發死鎖等。因此在使用懶漢式單例模式時一定要對同步有所了解，不過使用餓漢式單例模式就可以避免這個問題。
子類破壞了物件控制
如果構造器變得不再私有，就有可能失去對物件的控制
序列化（可序列化）
為了使乙個單例類變成可序列化的，僅僅在宣告中新增「implements serializable"是不夠的，因為乙個序列化的物件在每次反序列化的時候，都會建立乙個新的物件，而不僅僅是乙個對原有物件的引用，為了防止這種情況，可以在單例類中加入readresolve方法
public final class singleton implements serializable
private static final singleton instance = new singleton ();
public static singleton getinstance()
private object readresolve() throws objectstreamexception
}
物件的反序列化並不僅侷限於上述方式，還存在基於 xml模式的物件序列化方式，這種方式也存在上述的問題，所以在使用的時候還要格外小心。
原文：
設計模式之略見一斑 外觀模式Facade
外觀模式又稱門面模式，它是為了給子系統中提供乙個一致的介面，從面定義了乙個高層介面 這個介面使得這一子系統更加容易使用。定義中提到的子系統指在設計中為了降低複雜性根據一定的規則，對系統進行的劃分，子系統封裝有一些類，客戶程式在使用子系統的時候，可能會像下圖一樣零亂。上面的實現中，客戶緊緊依賴在子系統...
設計模式之略見一斑 建造模式builder
建造模式是將複雜的內部建立封裝在內部，對於外部呼叫的人來說，只需要傳入建造者和建造工具，對於內部是如何建造成成品的，呼叫者無需關心。建造模式很象抽象工廠模式，細微的區別的大概只有在反覆使用的方能體會。舉個簡單的例子，如汽車，有很多部件，車輪，方向盤，發動機還有各種小零件等等，部件很多，但遠不止這些，...
設計模式之略見一斑 建造模式builder
建造模式是將複雜的內部建立封裝在內部，對於外部呼叫的人來說，只需要傳入建造者和建造工具，對於內部是如何建造成成品的，呼叫者無需關心。建造模式很象抽象工廠模式，細微的區別的大概只有在反覆使用的方能體會。舉個簡單的例子，如汽車，有很多部件，車輪，方向盤，發動機還有各種小零件等等，部件很多，但遠不止這些，...