12.享元模式設計思想
目錄介紹
- 01.享元模式基礎介紹
- 1.1 享元模式由來
- 1.2 享元模式定義
- 1.3 享元模式場景
- 1.4 享元模式思考
- 1.5 核心思想是什麼
- 02.享元模式原理與實現
- 2.1 羅列一個場景
- 2.2 用例子理解享元
- 2.3 內部和外部狀態
- 2.4 享元模式實現
- 03.享元模式分析
- 3.1 享元模式VS單例
- 3.2 享元模式VS快取
- 3.3 享元模式VS物件池
- 04.享元模式應用解析
- 4.1 Integer享元模式應用
- 4.2 String享元模式應用
- 4.3 執行緒池享元模式應用
- 4.4 Handler享元模式應用
- 05.享元模式總結
- 5.1 有哪些優點
- 5.2 有哪些弊端
- 5.3 休閒棋類應用
- 5.4 文字編輯器應用
- 5.5 應用環境說明
- 5.6 享元模式擴充套件
推薦一個好玩網站
一個最純粹的技術分享網站,打造精品技術程式設計專欄!程式設計進階網
https://yccoding.com/
01.享元模式基礎介紹
1.0 本部落格AI摘要
享元模式是一種用於效能最佳化的設計模式,透過共享相同或相似物件來減少記憶體佔用。本文件詳細介紹了享元模式的基礎概念、實現原理、應用場景及優缺點,並透過具體例子如Integer、String、執行緒池和Handler等展示了其實際應用。
此外,還探討了享元模式與其他設計模式的結合使用,以及在休閒棋類和文字編輯器中的應用。適合需要最佳化系統效能和資源利用率的開發者參考。
1.1 享元模式由來
物件導向技術可以很好地解決一些靈活性或可擴充套件性問題,但在很多情況下需要在系統中增加類和物件的個數。
當物件數量太多時,將導致執行代價過高,帶來效能下降等問題。舉一個簡單例子,比如handler傳送訊息,建立大量的訊息message物件,就用到了享元模式。
享元模式由來,主要是解決物件太多建立的問題:更多內容
- 享元模式透過共享技術實現相同或相似物件的重用。
- 在享元模式中通常會出現工廠模式,需要建立一個享元工廠來負責維護一個享元池(Flyweight Pool)用於儲存具有相同內部狀態的享元物件。
1.2 享元模式定義
享元模式(Flyweight Pattern):
運用共享技術有效地支援大量細粒度物件的複用。系統只使用少量的物件,而這些物件都很相似,狀態變化很小,可以實現物件的多次複用。
享元模式的核心思想是將具有相同內部狀態的物件共享,以減少記憶體佔用。更多內容
- 當需要建立一個物件時,首先檢查是否已經存在具有相同內部狀態的物件。
- 如果存在,則重用該物件,而不是建立一個新的物件。如果不存在,則建立一個新的物件並將其新增到共享池中,以供以後使用。
在享元模式中,物件分為兩種型別:內部狀態(Intrinsic State)和外部狀態(Extrinsic State)。
內部狀態是物件共享的部分,它不會隨著外部環境的變化而改變。外部狀態是物件特定的部分,它會隨著外部環境的變化而變化。
1.3 享元模式場景
享元模式使用場景
- 大量相似物件的情況: 當一個應用程式使用大量相似物件,且這些物件可以被共享時,使用享元模式可以減少記憶體佔用。典型的例子是文字編輯器中的字元物件,其中相同字元只需建立一次並共享。
- 快取: 享元模式可以用於實現快取,特別是在需要頻繁訪問、計算成本高昂的資料時。將已經計算好的資料快取起來,並在需要時重用,可以提高系統的效能。
- 連線池: 在資料庫連線池、執行緒池等資源池的設計中,享元模式也經常被應用。共享可用的連線或執行緒物件,避免頻繁地建立和銷燬。更多內容
工作中遇到場景
- 快取,字串常量池,執行緒池,連線池
作用
- 提高效能:生成物件成本比較高,生成之後快取起來
- 降低記憶體消耗:能用一個物件就別建立兩個物件
1.4 享元模式思考
享元模式的一些關鍵要點:
- 內部狀態是可以共享的,它儲存在享元物件內部,並且不會隨著外部環境的變化而改變。
- 外部狀態是不可共享的,它由客戶端傳遞給享元物件,並且會隨著外部環境的變化而變化。
- 享元工廠(Flyweight Factory)負責建立和管理享元物件。它維護一個享元物件的池,根據客戶端的請求返回已存在的享元物件或建立新的享元物件。
- 客戶端透過享元工廠獲取享元物件,並將外部狀態傳遞給享元物件。客戶端可以共享相同的享元物件,從而減少記憶體佔用。
1.5 核心思想是什麼
享元模式的核心思想是將物件的內部狀態和外部狀態分離。更多內容,內部狀態可以被多個物件共享,而外部狀態則由客戶端傳遞給享元物件。透過共享內部狀態,可以減少物件的數量,從而減少記憶體佔用。
02.享元模式原理與實現
2.1 羅列一個場景
接單做網站:要求做產品展示網站,有的人希望是新聞釋出形式的,有的人希望是部落格形式的,也有還是原來的產品圖片加說明形式的。
因為他們找我們來做的人的需求只是有一些小小的差別。但是不可能有100家企業來找你做網站,你難道去申請100個伺服器,用100個資料庫,然後用類似的程式碼複製100遍,去實現嗎?
不使用享元模式 - 接單做網站。
public class FlyweightWebSite {
public static void main(String[] args) {
test1();
}
public static void test1() {
WebSite fx = new WebSite("產品展示");
fx.use();
WebSite fy = new WebSite("產品展示");
fy.use();
WebSite fz = new WebSite("產品展示");
fz.use();
WebSite fl = new WebSite("部落格");
fl.use();
WebSite fm = new WebSite("部落格");
fm.use();
WebSite fn = new WebSite("部落格");
fn.use();
}
//網站
public static class WebSite {
private String name = "";
public WebSite(String name) {
this.name = name;
}
public void use() {
System.out.println("網站分類:" + name);
}
}
}
2.2 用例子理解享元
如果要做三個產品展示,三個部落格的網站,就需要六個網站類的例項,而其實它們本質上都是一樣的程式碼,如果網站增多,例項也就隨著增多。更多內容
利用享元模式做成第一版本的網站,程式碼如下所示:
public static void test2() {
System.out.println("使用享元模式做的第一版網站");
WebSiteFactory webSiteFactory = new WebSiteFactory();
AbsWebSite siteCategory = webSiteFactory.getWebSiteCategory("產品展示");
siteCategory.use();
AbsWebSite siteCategory1 = webSiteFactory.getWebSiteCategory("產品展示");
siteCategory1.use();
AbsWebSite siteCategory2 = webSiteFactory.getWebSiteCategory("產品展示");
siteCategory2.use();
AbsWebSite siteCategory3 = webSiteFactory.getWebSiteCategory("部落格");
siteCategory3.use();
AbsWebSite siteCategory4 = webSiteFactory.getWebSiteCategory("部落格");
siteCategory4.use();
AbsWebSite siteCategory5 = webSiteFactory.getWebSiteCategory("部落格");
siteCategory5.use();
System.out.println("總共建立了 " + webSiteFactory.getWebSiteCount() + " 個例項");
}
/**
* 網站抽象類
*/
public abstract static class AbsWebSite {
public abstract void use();
}
/**
* 具體網站類
*/
public static class ConcreteWebSite extends AbsWebSite {
private String name = "";
public ConcreteWebSite(String name) {
this.name = name;
}
@Override
public void use() {
System.out.println("網站分類:" + name);
}
}
/**
* 網站工廠類
*/
public static class WebSiteFactory {
private HashMap<String, AbsWebSite> flyweights = new HashMap<>();
/**
* 獲得網站分類
*
* @param key key
* @return AbsWebSite
*/
public AbsWebSite getWebSiteCategory(String key) {
if (!flyweights.contains(key)) {
flyweights.put(key, new ConcreteWebSite(key));
}
return flyweights.get(key);
}
/**
* 獲得網站例項個數
*
* @return 數量
*/
public int getWebSiteCount() {
return flyweights.size();
}
}
上面案例遇到了一些問題
基本實現了享元模式的共享物件的目的,也就是說,不管建個網站,只要是 ‘產品展示’ ,都是一樣的,只要是 ‘部落格’ ,也是完全相同的。
但這樣是有問題的,以上這樣建的網站不是一家客戶的,它們的資料不會相同,所以至少它們都應該有不同的賬號。這樣寫沒有體現物件間的不同,只體現了它們共享的部分。
2.3 內部和外部狀態
內部狀態 - 外部狀態 - 享元模式 - 接單做網站
在享元物件內部並且不會隨環境改變而改變的共享部分,可以稱為享元物件的內部狀態,隨環境改變而改變的、不可以共享的狀態就是外部狀態。
事實上,享元模式可以避免大量非常相似類的開銷。在程式設計中,有時需要生成大量細粒度的類例項來表示資料。如果能發現這些例項除了幾個 引數外基本上都是相同的,有時就能夠大幅度地減少需要例項化的類的數量。如果能把那些引數移到類例項的外面,在方法呼叫時將它們傳遞進來, 就可以透過共享大幅度地減少單個例項的數目。
也就是說,享元模式 Flyweight 執行時所需的狀態有內部的也可能有外部的,內部狀態儲存於 ConcreteFlyweight 物件之中,而外部物件則應該考慮由客戶端物件儲存或計 算,當呼叫Flyweight物件的操作時,將該狀態傳遞給它。
客戶的賬號就是外部狀態,應該由專門的物件來處理。更多內容
/**
* 使用者類,用於網站的客戶賬號,是"網站"類的外部狀態。
*/
public static class User {
private String name;
public User(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
/**
* 網站抽象類
*/
public abstract static class AbsWebSite2 {
public abstract void use(User user);
}
public static class ConcreteWebSite2 extends AbsWebSite2 {
private String name = "";
public ConcreteWebSite2(String name) {
this.name = name;
}
@Override
public void use(User user) {
System.out.println("網站分類:" + name + " 來自客戶:" + user.getName() + "的需求");
}
}
列印資料如下所示,這樣就可以協調內部與外部狀態了。
使用享元模式做的第二版網站,新增外部狀態
網站分類:產品展示 來自客戶:打工充0的需求
網站分類:產品展示 來自客戶:打工充1的需求
網站分類:產品展示 來自客戶:打工充2的需求
網站分類:部落格 來自客戶:打工充3的需求
網站分類:部落格 來自客戶:打工充4的需求
網站分類:部落格 來自客戶:打工充5的需求
總共建立了 2 個例項
2.4 享元模式實現
享元模式實現的角色
- Flyweight:享元物件抽象基類或介面。
- ConcreteFlyweight:具體的享元物件。
- FlyweightFactory:享元工廠,負責管理享元物件池和建立享元物件。
- UnsharedConcreteFlyweight:非共享具體享元類
享元模式的基本實現程式碼如下所示
/**
* 享元模式基本實現,比較官方的demo案例
*/
public class FlyweightDemo {
public static void main(String[] args) {
int extrinsicState = 30;
FlyweightFactory factory = new FlyweightFactory();
Flyweight flyweightA = factory.getFlyweight("A");
flyweightA.operation(--extrinsicState);
Flyweight flyweightB = factory.getFlyweight("B");
flyweightB.operation(--extrinsicState);
Flyweight flyweightC = factory.getFlyweight("C");
flyweightC.operation(--extrinsicState);
// 不要共享的
UnsharedConcreteFlyweight unsharedFly = new UnsharedConcreteFlyweight();
unsharedFly.operation(--extrinsicState);
}
/**
* Flyweight類是所有具體享元類的超類或介面,透過這個介面, Flyweight可以接受並作用於外部狀態。
*/
public static abstract class Flyweight {
public abstract void operation(int extrinsicState);
}
/**
* ConcreteFlyweight是繼承Flyweight超類或實現Flyweight介面,併為內部狀態增加儲存空間。
* 需要共享的具體Flyweight子類
*/
public static class ConcreteFlyweight extends Flyweight {
@Override
public void operation(int extrinsicState) {
System.out.println("需要共享的具體Flyweight子類:" + extrinsicState);
}
}
/**
* 需要共享的具體Flyweight子類
* UnsharedConcreteFlyweight是指那些不需要共享的Flyweight子類。因為Flyweight介面共享成為可能,但它並不強制共享。
*/
public static class UnsharedConcreteFlyweight extends Flyweight {
@Override
public void operation(int extrinsicState) {
System.out.println("不需要共享的具體Flyweight子類:" + extrinsicState);
}
}
/**
* 享元工廠
*/
public static class FlyweightFactory {
private final HashMap<String, Flyweight> flyweights = new HashMap<>();
/**
* 初始化工廠三個例項
*/
public FlyweightFactory() {
flyweights.put("A", new ConcreteFlyweight());
flyweights.put("B", new ConcreteFlyweight());
flyweights.put("C", new ConcreteFlyweight());
}
/**
* 根據客戶端請求,獲得已生成的例項
*
* @param key key
* @return Flyweight
*/
public Flyweight getFlyweight(String key) {
return flyweights.get(key);
}
}
}
03.享元模式分析
3.1 享元模式VS單例
在單例模式中,一個類只能建立一個物件,而在享元模式中,一個類可以建立多個物件,每個物件被多處程式碼引用共享。
實際上,享元模式有點類似於之前講到的單例的變體:多例。更多內容
區別兩種設計模式,不能光看程式碼實現,而是要看設計意圖,也就是要解決的問題。
- 儘管從程式碼實現上來看,享元模式和多例有很多相似之處,但從設計意圖上來看,它們是完全不同的。
- 應用享元模式是為了物件複用,節省記憶體,而應用多例模式是為了限制物件的個數。
3.2 享元模式VS快取
在享元模式的實現中,我們透過工廠類來“快取”已經建立好的物件。
這裡的“快取”實際上是“儲存”的意思,跟我們平時所說的“資料庫快取”“CPU 快取”“MemCache 快取”是兩回事。
我們平時所講的快取,主要是為了提高訪問效率,而非複用。
3.3 享元模式VS物件池
簡單解釋一下物件池。
像 C++ 這樣的程式語言,記憶體的管理是由程式設計師負責的。為了避免頻繁地進行物件建立和釋放導致記憶體碎片,我們可以預先申請一片連續的記憶體空間,也就是這裡說的物件池。
每次建立物件時,我們從物件池中直接取出一個空閒物件來使用,物件使用完成之後,再放回到物件池中以供後續複用,而非直接釋放掉。
物件池、連線池(比如資料庫連線池)、執行緒池等也是為了複用,那它們跟享元模式有什麼區別呢?更多內容
雖然物件池、連線池、執行緒池、享元模式都是為了複用,但是摳一摳“複用”這個字眼的話,物件池、連線池、執行緒池等池化技術中的“複用”和享元模式中的“複用”實際上是不同的概念。
池化技術中的“複用”可以理解為“重複使用”,主要目的是節省時間(比如從資料庫池中取一個連線,不需要重新建立)。在任意時刻,每一個物件、連線、執行緒,並不會被多處使用,而是被一個使用者獨佔,當使用完成之後,放回到池中,再由其他使用者重複利用。
享元模式中的“複用”可以理解為“共享使用”,在整個生命週期中,都是被所有使用者共享的,主要目的是節省空間。
04.享元模式應用解析
4.1 Integer享元模式應用
先來看下面這樣一段程式碼。你可以先思考下,這段程式碼會輸出什麼樣的結果。
private static void test() {
Integer i1 = 31;
Integer i2 = 31;
Integer i3 = 129;
Integer i4 = 129;
System.out.println(i1 == i2);
System.out.println(i3 == i4);
//true
//false
}
你可能會覺得,i1 和 i2 值都是 56,i3 和 i4 值都是 129,i1 跟 i2 值相等,i3 跟 i4 值相等,所以輸出結果應該是兩個 true。但其實這是錯誤的。因為Integer用到了快取池的概念……
需要弄清楚下面兩個問題:
- 如何判定兩個 Java 物件是否相等(也就程式碼中的“==”運算子的含義)?
- 什麼是自動裝箱(Autoboxing)和自動拆箱(Unboxing)?
所謂的自動裝箱,就是自動將基本資料型別轉換為包裝器型別。所謂的自動拆箱,也就是自動將包裝器型別轉化為基本資料型別。更多內容
Integer i = 31; //自動裝箱 底層執行了:Integer i = Integer.valueOf(31);
int j = i; //自動拆箱 底層執行了:int j = i.intValue();
為何 i3==i4 判定語句也會返回 false
這正是因為 Integer 用到了享元模式來複用物件,才導致了這樣的執行結果。
當我們透過自動裝箱,也就是呼叫 valueOf() 來建立 Integer 物件的時候,如果要建立的 Integer 物件的值在 -128 到 127 之間,會從 IntegerCache 類中直接返回,否則才呼叫 new 方法建立。
public static Integer valueOf(int i) {
if (i >= IntegerCache.low && i <= IntegerCache.high)
return IntegerCache.cache[i + (-IntegerCache.low)];
return new Integer(i);
}
這裡的 IntegerCache 相當於生成享元物件的工廠類,只不過名字不叫 xxxFactory 而已。
4.2 String享元模式應用
再來看下,享元模式在 Java String 類中的應用。同樣,我們還是先來看一段程式碼,你覺得這段程式碼輸出的結果是什麼呢?
private static void test2() {
String s1 = "打工充";
String s2 = "打工充";
String s3 = new String("打工充");
System.out.println(s1 == s2);
System.out.println(s1 == s3);
//true
//false
}
跟 Integer 類的設計思路相似,String 類利用享元模式來複用相同的字串常量(也就是程式碼中的“打工充”)。
JVM 會專門開闢一塊儲存區來儲存字串常量,這塊儲存區叫作“字串常量池”。
4.3 執行緒池享元模式應用
4.4 Handler享元模式應用
Handler 訊息機制中的 Message 訊息池就是使用享元模式複用了 Message 物件。
遇到問題說明:如果使用 new Message() 會構造大量的 Message 物件。透過new建立Message就會建立大量重複的Message物件,導致記憶體佔用率高,頻繁GC等問題。
使用享元模式:使用 Message 時一般是用 Message.obtain 來獲取訊息。透過享元模式建立一個大小為50的訊息池,避免了上述問題的產生。
Message享元模式分析:Message相當於承擔了享元模式中3個元素的職責,既是Flyweight抽象,又是ConcreteFlyweight角色,同時又承擔了FlyweightFactory管理物件池的職責。
注意點:Message的享元模式並不是經典的實現方式,它沒有內部,外部狀態,集各個職責於一身,甚至更像一個物件池。更多內容
05.享元模式總結
5.1 有哪些優點
優點
- 記憶體最佳化:透過共享物件的內部狀態,可以大大減少物件的數量,從而節省記憶體空間。
- 效能提升:減少物件數量和記憶體佔用可以提高系統的效能,特別是在處理大量細粒度物件時。
- 可擴充套件性:享元模式可以輕鬆擴充套件以支援新的外部狀態,而無需修改現有的共享物件。
- 物件複用:透過共享物件,可以實現物件的複用,避免重複建立相同的物件,提高系統的效率和資源利用率。
5.2 有哪些弊端
缺點:
- 共享物件可能引入執行緒安全問題:如果多個執行緒同時訪問和修改共享物件的狀態,需要考慮執行緒安全性,以避免併發訪問引發的問題。
- 物件狀態的外部化:為了實現物件共享,部分物件狀態需要外部化,這可能會增加程式碼複雜性和維護成本。
5.3 休閒棋類應用
享元模式更多的時候是一種底層的設計模式,但現實中也是有應用的:
比如休閒棋類。
如果不用享元模式會怎麼樣?
像象棋,一盤棋理論上有32棋子,那如果用常規的物件導向方式程式設計,每盤棋都可能有至少32個棋子物件產生。
一個遊戲廳中有成千上萬個“房間”,每個房間對應一個棋局。棋局要儲存每個棋子的資料,比如:棋子型別(將、相、士、炮等)、棋子顏色(紅方、黑方)、棋子在棋局中的位置。
思考一下下面的問題
一臺伺服器就很難支援更多的玩家玩圍棋遊戲了,比如1萬棋局玩家,那就會有大量的物件,畢竟記憶體空間還是有限的。
那麼我們如何去避免大量細粒度的物件,同時又不影響客戶程式,是一個值得去思考的問題。有沒有什麼辦法來節省記憶體呢?
用了享元模式主要是節省資源和降低損耗
比如說休閒遊戲開發中,像象棋,它們都有大量的棋子物件,分析一下,它們的內部狀態和外部狀態各是什麼?更多內容
象棋只有紅黑兩色、跳棋顏色略多一些,但也是不太變化的,所以顏色應該是棋子的內部狀態,而各個棋子之間的差別主要就是位置的不同,所以方位座標應該是棋子的外部狀態。
在使用享元模式之前,記錄1萬個棋局,我們要建立 32 萬(32*1 萬)個棋子的物件。利用享元模式,我們只需要建立32個享元物件供所有棋局共享使用即可,大大節省了記憶體。
5.4 文字編輯器應用
使用享元模式的一個常見例子是文字編輯器中的字元物件。
在一個文字檔案中,可能有大量的字元物件,它們的外部狀態(例如位置、字型、顏色等)可能不同,但內部狀態(例如字元程式碼、字元寬度等)是相同的。
透過共享具有相同字元程式碼的字元物件,可以大大減少記憶體使用。
5.5 應用環境說明
享元模式適用於大量細粒度物件的場景
透過共享物件的內部狀態來減少物件數量和記憶體佔用,從而提高系統效能和資源利用率。
它在需要重複建立相似物件的情況下特別有用,並且適用於多執行緒環境,但需要注意執行緒安全性。更多內容
5.5 如何判斷是否用享元
在以下情況下可以使用享元模式:
- 一個系統有大量相同或者相似的物件,由於這類物件的大量使用,造成記憶體的大量耗費。可以使用享元模式來複用已有物件,提高系統效能。
- 物件的內部狀態相同或相似,而外部狀態有所不同時,可以將這些外部狀態傳入物件中。
- 使用享元模式需要維護一個儲存享元物件的享元池,而這需要耗費資源,因此,應當在多次重複使用享元物件時才值得使用享元模式。
5.6 享元模式擴充套件
享元模式與其他模式的聯用
- 在享元模式的享元工廠類中通常提供一個靜態的工廠方法用於返回享元物件,使用簡單工廠模式來生成享元物件。
- 在一個系統中,通常只有唯一一個享元工廠,因此享元工廠類可以使用單例模式進行設計。
- 享元模式可以結合組合模式形成複合享元模式,統一對享元物件設定外部狀態。
06.享元模式總結
6.1 總結一下學習
6.2 更多內容推薦
模組 | 描述 | 備註 |
---|---|---|
GitHub | 多個YC系列開源專案,包含Android元件庫,以及多個案例 | GitHub |
部落格彙總 | 匯聚Java,Android,C/C++,網路協議,演算法,程式設計總結等 | YCBlogs |
設計模式 | 六大設計原則,23種設計模式,設計模式案例,物件導向思想 | 設計模式 |
Java進階 | 資料設計和原理,物件導向核心思想,IO,異常,執行緒和併發,JVM | Java高階 |
網路協議 | 網路實際案例,網路原理和分層,Https,網路請求,故障排查 | 網路協議 |
計算機原理 | 計算機組成結構,框架,儲存器,CPU設計,記憶體設計,指令程式設計原理,異常處理機制,IO操作和原理 | 計算機基礎 |
學習C程式設計 | C語言入門級別系統全面的學習教程,學習三到四個綜合案例 | C程式設計 |
C++程式設計 | C++語言入門級別系統全面的教學教程,併發程式設計,核心原理 | C++程式設計 |
演算法實踐 | 專欄,陣列,連結串列,棧,佇列,樹,雜湊,遞迴,查詢,排序等 | Leetcode |
Android | 基礎入門,開源庫解讀,效能最佳化,Framework,方案設計 | Android |
23種設計模式
23種設計模式 & 描述 & 核心作用 | 包括 |
---|---|
建立型模式 提供建立物件用例。能夠將軟體模組中物件的建立和物件的使用分離 |
工廠模式(Factory Pattern) 抽象工廠模式(Abstract Factory Pattern) 單例模式(Singleton Pattern) 建造者模式(Builder Pattern) 原型模式(Prototype Pattern) |
結構型模式 關注類和物件的組合。描述如何將類或者物件結合在一起形成更大的結構 |
介面卡模式(Adapter Pattern) 橋接模式(Bridge Pattern) 過濾器模式(Filter、Criteria Pattern) 組合模式(Composite Pattern) 裝飾器模式(Decorator Pattern) 外觀模式(Facade Pattern) 享元模式(Flyweight Pattern) 代理模式(Proxy Pattern) |
行為型模式 特別關注物件之間的通訊。主要解決的就是“類或物件之間的互動”問題 |
責任鏈模式(Chain of Responsibility Pattern) 命令模式(Command Pattern) 直譯器模式(Interpreter Pattern) 迭代器模式(Iterator Pattern) 中介者模式(Mediator Pattern) 備忘錄模式(Memento Pattern) 觀察者模式(Observer Pattern) 狀態模式(State Pattern) 空物件模式(Null Object Pattern) 策略模式(Strategy Pattern) 模板模式(Template Pattern) 訪問者模式(Visitor Pattern) |
6.3 更多內容
- GitHub:https://github.com/yangchong211
- 我的程式設計網站:https://yccoding.com
- 部落格彙總:https://github.com/yangchong211/YCBlogs
- 設計模式專欄:https://github.com/yangchong211/YCDesignBlog
- Java高階進階專欄:https://github.com/yangchong211/YCJavaBlog
- 網路協議專欄:https://github.com/yangchong211/YCNetwork
- 計算機基礎原理專欄:https://github.com/yangchong211/YCComputerBlog