java設計模式之門面模式以及在java中做用

門面模式在Tomcat中有多處使用，在Request和Response對象封裝，從ApplicationContext到ServletContext封裝中都用到了這種設計模式。

一個系統能夠有幾個門面類

　　在門面模式中，一般只須要一個門面類，而且此門面類只有一個實例，換言之它是一個單例類。固然這並不意味着在整個系統裏只有一個門面類，而僅僅是說對每個子系統只有一個門面類。或者說，若是一個系統有好幾個子系統的話，每個子系統都有一個門面類，整個系統能夠有數個門面類。

爲子系統增長新行爲

　　初學者每每覺得經過繼承一個門面類即可在子系統中加入新的行爲，這是錯誤的。門面模式的用意是爲子系統提供一個集中化和簡化的溝通管道，而不能向子系統加入新的行爲。好比醫院中的接待員並非醫護人員，接待員並不能爲病人提供醫療服務。

 

門面模式的優勢

　　門面模式的優勢：

　　●　　鬆散耦合

　　門面模式鬆散了客戶端與子系統的耦合關係，讓子系統內部的模塊能更容易擴展和維護。

　　●　　簡單易用

　　門面模式讓子系統更加易用，客戶端再也不須要了解子系統內部的實現，也不須要跟衆多子系統內部的模塊進行交互，只須要跟門面類交互就能夠了。

　　●　　更好的劃分訪問層次

　　經過合理使用Facade，能夠幫助咱們更好地劃分訪問的層次。有些方法是對系統外的，有些方法是系統內部使用的。把須要暴露給外部的功能集中到門面中，這樣既方便客戶端使用，也很好地隱藏了內部的細節。

 

門面模式在Tomcat中的使用

　　Tomcat中門面模式使用的不少，由於Tomcat中有不少不一樣組件，每一個組件要相互通訊，可是又不能將本身內部數據過多的暴露給其餘組件。用門面模式隔離數據是個很好的方法。

　　下面是Request上使用的門面模式：

　　

　　使用過Servlet的人都清楚，除了要在web.xml作相應的配置外，還需繼承一個叫HttpServlet的抽象類，而且重寫doGet與doPost方法（固然只重寫service方法也是能夠的）。

 

　Request對象中的不少方法都是內部組件之間相互交互時使用的，好比setComet、setRequestedSessionId等方法（這裏就不一一列舉了）。這些方法並不對外部公開，可是又必須設置爲public，由於還須要跟內部組件之間交互使用。最好的解決方法就是經過使用一個Facade類，將與內部組件之間交互使用的方法屏蔽掉，只提供給外部程序感興趣的方法。

　　若是不使用Facade類，直接傳遞的是Request對象和Response對象，那麼熟悉容器內部運做的程序員能夠分別把ServletRequest和ServletResponse對象向下轉換爲Request和Response，並調用它們的公共方法。好比擁有Request對象，就能夠調用setComet、setRequestedSessionId等方法，這會危害安全性。

 

原文連接 http://www.cnblogs.com/java-my-life/archive/2012/05/02/2478101.html