初衷 :因架構(開發)場景(需求)而使用設計模式,莫為了使用設計模式而設計架構場景!記錄此文的時候,我在想what?why?who?when?where?how?
設計模式共23種,分為三種型別
角色劃分
模式區別
常規實現
思維擴充套件
基本概念
個人建議:文字看的煩的話,可以先看圖,然後直接看**,最後在看文字描述 ~
外觀模式又名門面模式,其屬於物件結果模式的一種,當客戶類與子系統通訊時必須通過乙個統一的外部物件進行通訊(內部為多個複雜的子系統提供乙個一致的介面),使這些子系統更加容易被訪問 ;因對外有乙個統一介面,外部應用程式不用關心內部子系統的具體的細節,這樣會大大降低應用程式的複雜度,提高了程式的可維護性 ~
使用場景
優缺點優點外觀(facade)模式是「迪公尺特法則」的典型應用 缺點
角色劃分
模式區別
門面模式、**模式、中介者模式的區別
**模式和外觀者模式這兩種模式主要不同就是**模式針對的是單個物件,而外觀模式針對的是所有子類
常規實現
demo - 思想
我們作為客戶,當我們去飯館吃飯的時候,一般過程都是點餐、吃飯、走人 ~ 其實這裡點餐、吃飯、走人就是我們的一套系統,但是這裡主講的是飯店對客人的一套系統 !
如從我們進入飯店,其實就已經屬於到了飯店這個外觀角色
中,在到接待員的點餐、廚師的炒菜、服務員的送餐其實都是這個流程中的子系統角色
了,而我們作為客戶角色
只和飯店這個外觀角色進行了溝通!進沒有親自去和每乙個子系統角色交流,這就是很好的乙個外觀模式的例子 ~
作為客戶,我只需要和飯店這個外觀角色溝通即可,內部具體實現我不管 > , <
demo - 效果
子系統角色 - 接待員
import
android.util.
log;
/** * @author mrliu
* @date 2020/7/1
* desc 子系統角色 - 接待員
*/public
class
subsystem_receptionist
}
子系統角色 - 廚師
子系統角色的內部方法不需要每個都一致!畢竟每個子系統的職責不同!我這裡部分方法名(work)相同只是寫了他們的核心職責而已
import
android.util.
log;
/** * @author mrliu
* @date 2020/7/1
* desc 子系統角色 - 廚師
*/public
class
subsystem_chef
public
void
work()
public
void
after()
}
子系統角色 - 服務員/**
* @author mrliu
* @date 2020/7/1
* desc 子系統角色 - 服務員
*/public
class
subsystem_waiter
}
外觀角色 - facade/**
* @author mrliu
* @date 2020/7/1
* desc 外觀角色
*/public
class
facade
/** * 接待
*/public
void
reception()
/** * 做飯 - 前
*/public
void
cook_before()
/** * 做飯
*/public
void
cook()
/** * 做飯 - 後
*/public
void
cook_after()
/** * 送菜
*/public
void
send()
/** * 整個流程
*/public
void
serviceall()
}
客戶角色(使用)import
android.util.
log;
public
class
mainactivity
extends
}
思維擴充套件
針對以上的幾點個人建議,我優化了外觀角色、子系統角色,具體如下 ~
實現效果
外觀角色 - facade
/**
* @author mrliu
* @date 2020/7/1
* desc 外觀角色
*/public
class
facade
/** * 接待
*/public
void
reception()
/** * 做飯
*/public
void
cook_before()
/** * 做飯
*/public
void
cook()
/** * 做飯
*/public
void
cook_after()
/** * 送菜
*/public
void
send()
/** * 核心流程 - 模板方法
*/public
void
servicetmp()
/** * 整個流程 - 模板方法
*/public
void
serviceall()
}
子系統角色 - 接待員/**
* @author mrliu
* @date 2020/7/1
* desc 子系統角色 - 接待員
*/public
class
subsystem_receptionist
public
void
work()
}
子系統角色 - 廚師/**
* @author mrliu
* @date 2020/7/1
* desc 子系統角色 - 廚師
*/public
class
subsystem_chef
public
void
before()
public
void
work()
public
void
after()
}
子系統角色 - 服務員/**
* @author mrliu
* @date 2020/7/1
* desc 子系統角色 - 服務員
*/public
class
subsystem_waiter
public
void
work()
}
客戶角色(使用)import
android.util.
log;
public
class
mainactivity
extends
}
設計模式 外觀模式
外觀模式,我的理解就是將複雜的類進行重新封裝,將簡單的介面呈現出來,降低呼叫端和實際類的耦合性。拿 大話設計模式 上邊關於 和 的例子來說。對於不入門的股民來說,交易有些過於龐大,需要學習的東西很多,如果沒整明白就進行投資,很容易賠錢的。很多剛入 的股民都賠的很慘。而買 有提出了乙個新的觀念,我們買...
設計模式 外觀模式
何為外觀模式?外觀模式 為子系統中的一組介面提供乙個一致的介面,此模式定義了乙個高層介面,這個介面使得一子系統更加容易使用。它是一種結構型模式,它主要解決的問題是 元件的客戶和元件中各種複雜的子系統有了過多的耦合,隨著外部客戶程式和 各子系統的演化,這種過多的耦合面臨很多變化的挑戰。uml類圖 乙個...
設計模式 外觀模式
外觀模式說白了就是為一組介面提供乙個一致的介面。例如 定義三個類a b c,每個類各定義乙個方法。class a pubic void showa cout a showa pubic void showb cout b showb pubic void showc cout c showc 定義乙...