1.外觀模式:
作用或者優點: 爲某個系統的組合功能提供一個外層,也就是客戶端使用系統的某個組合功能(需要與多個子模塊交互)時候,可以通過提供一個外層,來避免客戶端對子模塊複雜的調用,簡化了客戶端的使用步驟,客戶端只需要與外觀交互即可.
缺點或者是注意點: 外觀模式是由上到下的調用,不要存在反向的調用(防止循環調用,spring中類的注入,如果存在循環注入的話,會編譯不通過,而且也是不符合邏輯的,否則會造成結構混亂的情況,最好是有明確的上下級關係,下級不要調用(注入)上級),總之,哪些需要客戶端與外觀交互,哪些需要客戶端與子模塊交互最好有個較清晰的邊界,最好是以責任爲邊界劃分.
2.demo就不寫了,這個很容易理解,我們下面主要是拓寬一下思維,思考一下哪些地方可以使用這個模式?
首先:我們之前有個項目就是分層較多,主要是多了一層外觀,這層外觀用於controller層調用,這裏就是典型的外觀模式的使用,非常方便,結構也非常清晰,我們是按功能劃分模塊:用戶模塊,圖書模塊…
外觀怎樣實現的: 其實就是多了一層service層,這層service 用於組合用戶,圖書模塊的service功能,注意這裏只是組合,最好不要直接在這裏寫新的功能,儘可能的將功能細分下去通過調用子模塊的方式去實現客戶端需要的功能,子模塊的service去調用dao層,外觀service不直接調用dao層也就是不跨級調用.這樣就保證了模塊職責的單一性.提高了複用性,結構也能保持清晰明瞭.我覺得是外觀模式用的較好的一種方式了.
那麼,還有沒有其他的使用場景呢?
1.在對外提供api的時候,我們也可以專門爲其構建一層外觀,這層外觀只用於與對外的api接口交互,當然本身api就算是外觀了,不過,很多現實情況下,我們會對外提供多組功能相似的接口,那麼加一層外觀,更有助於內部功能子模塊的組合與複用
其他的情況目前還沒想到,
總之,外觀模式就是用來簡化調用端的調用,封裝多個模塊交互的功能,也就是組合多個模塊功能,提供一個簡單的調用入口,這樣外部調用就不需要知道模塊之間具體的交互過程,降低了使用門檻.也會比較常用的設計模式了.