/*迪公尺特法則:如果兩個類不必彼此直接同行,那麼這兩個內就不應當發生直接的相互作用,如果其中乙個類需要呼叫另外乙個類
* 的 某乙個方法的話,可以通過第三者**這個呼叫.
* 根本思想:強調類之間的松耦合.
* 程式設計中類之間的耦合越弱,越有利於復用,乙個處在弱耦合的類被修改,不會隊友關係的類造成波及,資訊的隱藏
* 有利於類的復用.
* */
/*facade: 外觀類,知道哪些子系統負責處理請求,見客戶的請求**給適當的子系統.(他需要了解所有的子系統的方法或屬性,進行組合,以備外界呼叫.)
* 外觀模式: 為子系統中的一組提供乙個一直的介面(facade類),此模式定義了乙個高層介面,這個介面使得這一子系統
* 更加容易使用.
* 注:首先在設計初期階段,應該要有意識的將不同的兩個層分離,比如經典的三層架構(mvc),
* 其次,在開發階段子系統玩玩因為不斷的重構演化而便得越來越複雜,增加外觀facade可以提供乙個簡單的介面減少它們之間的依賴,
* 最後,在維護乙個遺留的大型系統時,這個系統已經非常難以維護和擴充套件,這是要開發乙個新的子系統,可以為系統卡發乙個外觀(facade類),來提供設計粗糙或高度複雜的遺留**的比較清晰簡單的介面,
* 讓新系統與facade物件互動,facade與遺留大媽互動所有的複雜工作.
* 跟**模式有啥區別?
* 個人覺得,**模式只是為乙個類進行**,而外觀模式為多個類進行**.
package com.zwy;
public class facadetest
}class subsystemone
}class subsystemtwo
}class facade
public void facadea()
}
設計模式之外觀模式
外觀模式提供了乙個統一的介面，用來訪問子系統中的一群介面。這樣可以避免客戶端和子系統之間的緊耦合。這種模式需要將一系列的子系統組合到外觀中，然後將具體的工作交給各個子系統去完成。如此一來，可以簡化介面的呼叫。其本質就是將系統與客戶端互動的地方封裝起來。這個模式，總體來說，很簡單，理解起來也不困難。依...
設計模式之外觀模式
外觀模式 為子系統中的一組介面提供乙個一直的介面，此模式定義了乙個高層介面，這個介面使得這一子系統更加容易使用。即通過乙個中類來完成客戶端的請求。拿機房收費系統的上機過程來說，上機需要顯示上機者的資訊，填寫上機狀態表，填寫上機記錄表。而使用者不需要知道這些功能是怎麼實現的，只需要通過介面操作就可以完...
設計模式之外觀模式
外觀模式，為子系統中的一組介面提供乙個一致的介面，此模式定義了乙個高層介面，這個介面使得這一子系統更加容易使用。在設計初期階段，應該要有意識的將不同的兩個層分離，比如經典的三層架構，層與層之間建立外觀facade。在開發階段，子系統往往因不斷的重構演化而變得越來越複雜，增加外觀模式可以提供乙個簡單的...