對某個問題經常出現的、在設計中應該盡量避免的、壞的設計方案被稱為反模式。 基礎模式
委托模式
接口模式
代理模式 抽象工廠模式(Abstract Factory) ,提供壹個創建壹系列相關或相互依賴對象的接口，而無需指定它們具體的類。
生成器模式 (Builder)，將壹個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。
工廠方法模式(Factory Method) ，定義壹個用於創建對象的接口，讓子類決定將哪壹個類實例化。Factory Method使壹個類的實例化延遲到其子類。
原型模式 (Prototype) ，用原型實例指定創建對象的種類，並且通過拷貝這個原型來創建新的對象。
單例模式(Singleton)，保證壹個類僅有壹個實例，並提供壹個訪問它的全局訪問點。 適配器模式 (Adapter) ，將壹個類的接口轉換成客戶希望的另外壹個接口。Adapter模式使得原本由於接口不兼容而不能壹起工作的那些類可以壹起工作。
橋接模式(Bridge) ，將抽象部分與它的實現部分分離，使它們都可以獨立地變化。
組合模式(Composite) ，將對象組合成樹形結構以表示“部分-整體”的層次結構。它使得客戶對單個對象和復合對象的使用具有壹致性。
容器模式
修飾模式 (Decorator) ，動態地給壹個對象添加壹些額外的職責。就擴展功能而言， 它比生成子類方式更為靈活。
擴展性模式
外觀模式
享元模式
管道與過濾器模式
代理模式(Proxy) ，為其他對象提供壹個代理以控制對這個對象的訪問。 責任鏈模式 (Chain of Responsibility) ，為解除請求的發送者和接收者之間耦合，而使多個對象都有機會處理這個請求。將這些對象連成壹條鏈，並沿著這條鏈傳遞該請求，直到有壹個對象處理它。
命令模式 (Command) ，將壹個請求封裝為壹個對象，從而使妳可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日誌，以及支持可取消的操作。
柯裏化模式
事件監聽器模式
解釋器模式
叠代器模式
中介者模式
備忘錄模式 (Memento) ，在不破壞封裝性的前提下，捕獲壹個對象的內部狀態，並在該對象之外保存這個狀態。這樣以後就可將該對象恢復到保存的狀態。
觀察者模式(Observer) ，定義對象間的壹種壹對多的依賴關系,以便當壹個對象的狀態發生改變時,所有依賴於它的對象都得到通知並自動刷新。
狀態模式 (State) ，允許壹個對象在其內部狀態改變時改變它的行為。對象看起來似乎修改了它所屬的類。
策略模式 (Strategy) ，定義壹系列的算法,把它們壹個個封裝起來, 並且使它們可相互替換。本模式使得算法的變化可獨立於使用它的客戶。
模板方法模式
訪問者模式 (Visitor)，表示壹個作用於某對象結構中的各元素的操作。它使妳可以在不改變各元素的類的前提下定義作用於這些元素的新操作。
層次訪問者模式 模式 Action at a distance
模式 Balking
模式 Guarded suspension
模式 Scheduler
模式 Read write lock
模式 Double checked locking
模式 Disable job requests while running job 模式 Scheduled task
模式 User interface
模式 Disable job requests while running job 此原則是由Bertrand Meyer提出的。原文是：Software entities should be open for extension,but closed for modification。就是說模塊應對擴展開放，而對修改關閉。模塊應盡量在不修改原(是原，指原來的代碼)代碼的情況下進行擴展。那麽怎麽擴展呢？我們看工廠模式factory pattern:假設中關村有壹個賣盜版盤和毛片的小子，我們給他設計壹光盤銷售管理軟件。我們應該先設計壹光盤接口。如圖：pre______________|<>|| 光盤 ||_____________||+賣() || ||_____________|/pre而盜版盤和毛片是其子類。小子通過DiscFactory來管理這些光盤。代碼為： publicclassDiscFactory{publicstatic光盤getDisc(Stringname){return(光盤)Class.forName(name).getInstance();}}有人要買盜版盤，怎麽實現呢？
public class 小子{ public static void main(String args){ 光盤 d=DiscFactory.getDisc(盜版盤); 光盤.賣(); } }
如果有壹天，這小子良心發現了，開始賣正版軟件。沒關系，我們只要再創建壹個光盤的子類正版軟件就可以了。不需要修改原結構和代碼。怎麽樣？對擴展開放，對修改關閉。開-閉原則 工廠模式是對具體產品進行擴展，有的項目可能需要更多的擴展性，要對這個工廠也進行擴展，那就成了抽象工廠模式。 就是說要少用繼承，多用合成關系來實現。我曾經這樣寫過程序：有幾個類要與數據庫打交道，就寫了壹個數據庫操作的類，然後別的跟數據庫打交道的類都繼承這個。結果後來，我修改了數據庫操作類的壹個方法，各個類都需要改動。牽壹發而動全身!面向對象是要把波動限制在盡量小的範圍。
在Java中，應盡量針對Interface編程，而非實現類。這樣，更換子類不會影響調用它方法的代碼。要讓各個類盡可能少的跟別人聯系，不要與陌生人說話。這樣，城門失火，才不至於殃及池魚。擴展性和維護性才能提高
理解了這些原則，再看設計模式，只是在具體問題上怎麽實現這些原則而已。張無忌學太極拳，忘記了所有招式，打倒了玄冪二老，所謂心中無招。設計模式可謂招數，如果先學通了各種模式，又忘掉了所有模式而隨心所欲，可謂OO之最高境界。呵呵，搞笑，搞笑！（JR）
依賴倒轉原則抽象不應該依賴與細節，細節應當依 類為子類繼承，壹般包含這個系的***同屬性和方法。註意：好的繼承關系中，只有葉節點是具體類，其他節點應該都是抽象類，也就是說具體類是不被繼承的。將盡可能多的***同代碼放到抽象類中。 7 迪米特法則最少知識原則。不要和陌生人說話。