文章目錄
- 4.1 結構型設計模式
- 4.1.1 簡介
- 4.1.2 常見的幾種結構型設計模式
- 4.2 理解門面設計模式
- 4.2.1 門面設計模式概述
- 4.2.2 門面設計模式的作用
- 4.3 UML類圖
- 4.3.1 門面
- 4.3.2 系統
- 4.3.3 客戶端
- 4.4 門面模式的代碼實現
- 4.4.1 場景:
- 4.4.2 python實現
- 4.5 原理:最少知識原則
- 4.6 門面模式的優缺點
- 4.6.1 門面模式優點
- 4.6.2 門面模式缺點
門面模式屬于結構型設計模式的一種,下面我們先了解一下結構型設計模式:
4.1 結構型設計模式
4.1.1 簡介
● 結構型模式描述如何將對象和類組合成更大的結構。
● 結構型模式是一種能夠簡化設計工作的模式,因為它能夠找出更簡單的方法來認識或表示實體之間的關系。
● 在面向對象世界中,實體指的是對象或類。
● 類模式可以通過繼承來描述抽象,從而提供更有用的程序接口,而對象模式則描述了如何將對象聯系起來從而組合成更大的對象。結構型模式是類和對象模式的綜合體。
4.1.2 常見的幾種結構型設計模式
下面給出結構型設計模式的幾個例子。你會注意到,它們都是通過對象或類之間的交互來實現更高級的設計或架構目標的。
● 適配器模式:將一個接口轉換成客戶希望的另外一個接口。它試圖根據客戶端的需求來匹配不同類的接口。
● 橋接模式:該模式將對象的接口與其實現進行解耦,使得兩者可以獨立工作。
● 裝飾器模式:該模式允許在運行時或以動態方式為對象添加職責。我們可以通過接口給對象添加某些屬性。
4.2 理解門面設計模式
4.2.1 門面設計模式概述
門面(facade)在隱藏內部系統復雜性的同時,為客戶端提供了一個接口,以便它們可以非常輕松地訪問系統。下面,我們以店主為例進行介紹。
現在,假設你要到某個商店去買東西,但是你對這個商店的布局并不清楚。通常情況下,你會去找店主,因為店主對整個商店都很清楚。只要你告訴他/她要買什么,店主就會把這些商品拿給你。這不是很容易嗎?顧客不必了解店面的情況,可以通過一個簡單的接口來完成購物,這里的接口就是店主。
4.2.2 門面設計模式的作用
門面設計模式實際上完成了下列事項
● 它為子系統中的一組接口提供一個統一的接口,并定義一個高級接口來幫助客戶端通過更加簡單的方式使用子系統。
● 門面所解決問題是,如何用單個接口對象來表示復雜的子系統。實際上,它并不是封裝子系統,而是對底層子系統進行組合。
● 它促進了實現與多個客戶端的解耦。
4.3 UML類圖
就像你在UML圖中看到的那樣,這個模式有3個主要的參與者:
● 門面:門面的主要責任是,將一組復雜導致系統封裝起來,從而為外部世界提供一個舒適的外觀。
● 系統:這代表一組不同的子系統,使整個系統混雜在一起,難以觀察或使用
● 客戶端:客戶端與門面進行交互,這樣就可以輕松地與子系統進行通信并完成工作了。不必擔心系統的復雜性。
下面,我們將會從數據結構的角度進一步介紹這3個主要參與者。
4.3.1 門面
以下幾點可以幫助我們更好地理解門面
● ·它是一個接口,它知道某個請求可以交由哪個子系統進行處理。
● 它使用組合將客戶端的請求委派給相應的子系統對象。例如,如果客戶端正在了解哪些工作已完成,則不需要到各個子系統去,相反,它只需要聯系完成工作的接口(門面)就可以了
4.3.2 系統
在門面的世界里,系統就是執行以下操作的實體
● 它實現子系統的功能,同時,系統由一個類表示。理想情況下,系統應該由一組負責不同任務的類來表示。
● 它處理門面對象分配的工作,但并不知道門面,而且不引用它。
例如,當客戶端向門面請求某項服務時,門面會根據服務的類型來選擇提供該服務的相應子系統。
4.3.3 客戶端
以下是我們對客戶端的描述
● 客戶端是實例化門面的類
● 為了讓子系統完成相應的工作,客戶端需要向門面提出請求。
4.4 門面模式的代碼實現
4.4.1 場景:
假設你要在家中舉行一場婚禮,并且由你來張羅這一切。這真是一個艱巨的任務。你必須預訂一家酒店或場地,與餐飲人員交代酒菜、布置場景,并安排背景音樂。
之前,你可能需要自己搞定一切,例如找相關人員談話、與他們進行協調、敲定價格等。那么現在你就很輕松了,你可以直接去找會務經理,讓他為你處理這些事情。會務經理負責跟各個服務提供商交涉,并為你爭取最優惠的價格。
4.4.2 python實現
#!/usr/bin/env python
# -*- coding: UTF-8 -*-# 門面類 會務經理:通過組合創建子系統的對象
class EventManager(object):def __init__(self):print("Event Manager:: Let me talk to the folks\n")def arrange(self):self.hotelier = Hotelier()self.hotelier.bookHotel() # 定酒店self.florist = Florist()self.florist.setFlowerRequirements() # 定花self.caterer = Caterer()self.caterer.setCuisine() # 準備宴席self.musician = Musician()self.musician.setCuisine()# 門下調用的子系統1
class Hotelier(object):def __init__(self):print("Arranging the Hotel for Marriage? --")def __isAvailable(self):print("Is the Hotel free for the event on given day?")return Truedef bookHotel(self):if self.__isAvailable():print("Registered the Booking\n\n")# 門下調用的子系統
class Florist(object):def __init__(self):print("Flower Decorations for the Event? --")def setFlowerRequirements(self):print("Carnations,Roses and Lilies would be used for Decorations \n")# 門下調用的子系統
class Caterer(object):def __init__(self):print("Food Arrangements for the Event --")def setCuisine(self):print("Chinese & Continental Cuisine to be served\nin")# 門下調用的子系統
class Musician(object):def __init__(self):print("Musical Arrangements for the Marriage --")def setCuisine(self):print("Chinese & Continental Cuisine to be served\n\n")# 客戶端類,調用門面的一方
class You(object):def __init__(self):print("開始籌備一場婚禮!!!")def askEventManager(self):print("聯系門面類,讓其來組織各項事務\n\n")em = EventManager()em.arrange()def __del__(self):print("籌備結束!!!")# 調用
you = You()
you.askEventManager()
4.5 原理:最少知識原則
門面模式背后的設計原理就是最少知識原則,它指導我們設計系統時要減少對象之間的交互,就像跟你親近的只有某幾個朋友那樣。實際上,它意味著:
● 在設計系統時,對于創建的每個對象,都應該考察與之交互的類的數量,以及交互的方式;
● 遵循這個原則,就能夠避免創建許多彼此緊密耦合的類的情況;
● 如果類之間存在大量依賴關系,那么系統就會變得難以維護。如果對系統中的任何部分進行修改,都可能導致系統的其他部分被無意改變,這意味著系統會退化是應該堅決避免的。
4.6 門面模式的優缺點
4.6.1 門面模式優點
由于門面模式提供了簡化的接口,這使得客戶端不必擔心子系統的復雜性;
4.6.2 門面模式缺點
門面提供了一個簡化的接口供客戶端與子系統交互。本著提供簡化接口的精神,應用可能會建立多個不必要的接口,這就增加了系統的復雜性并且降低了運行時的性能。