針對問題：在軟體開發系統中，客戶程式經常會與複雜系統的內部子系統之間產生耦合，而導致客戶程式隨著子系統的變化而變化。 那麼如何簡化客戶程式與子系統之間的互動介面？如何將複雜系統的內部子系統與客戶程式之間的依賴解耦？
為子系統中的一組介面提供乙個一致的介面， facade 模式定義了乙個高層介面，這個介面使得這一子系統更加容易使用。——gang of four
外觀模式結構圖：
外觀模式實現**：
/**
* 例項a
* @author bruce
* */
public class a
}/**
* 例項b
* @author bruce
* */
public class b
}/**
* 例項c
* @author bruce
* */
public class c
}/**
* 外觀例項
* @author bruce
* */
public class facade
/*** 外觀介面
*/public void action()
}/**
* 測試
* @author bruce
* */
public class client
}
Design Pattern 工廠模式
當有一些要例項化的具體類，究竟例項化哪個類，要在執行時由一些條件來決定。當 使用大量具體類時，我們就要考慮使用工廠模式了。定義了乙個建立物件的介面，但由子類決定要例項化的類是哪乙個。工廠方法讓類把例項化推遲到子類。public abstract class pizzastore protected ...
design pattern 狀態模式
針對問題 有時候乙個方法可能有很多if.else來判斷狀態後再執行相關操作，當很多方法都重複的出現這樣的if.else判斷時，就可以考慮用狀態模式了。狀態模式的結構圖和策略模式一樣，事實上狀態模式和策略很相似，不同的是狀態模式除了委託狀態外，狀態實體自身持有主實體物件的引用，在狀態實體內部可以動態的...
Design Pattern 裝飾模式
動態地給乙個物件新增一些額外的職責。就增加功能來說，decorator模式相比生成子類更為靈活。對於物件功能的擴充套件,物件導向一般通過繼承來解決,但這種方式缺乏靈活性,而且隨意定義子類容易導致類層次結構過快膨脹.場景,當類的核心職責和主要行為沒有發生變化,僅僅需要動態對類物件新增一些裝飾性的功能,...