Head-First-Design-Patterns

KO | EN

gitlite — search

#react #ai #typescript #llm #golang #machine-learning #deep-learning #linux #windows #kubernetes #vue #mcp #openai #open-source

Head-First-Design-Patterns

(★ 52)

深入淺出設計模式

Head-First-Design-Patterns Latest Version Download

Download Latest Version (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Head First Design Patterns
https://github.com/bethrobson/Head-First-Design-Patterns 作者 github

# 第一章 - 介紹設計模式-歡迎到來設計模式
1.介紹設計模式 
2.類別與次類別之間的關係 
3.繼承的缺失 
4.把會變動的部分取出並「封裝」起來，好讓其他部份部受到影響。程式碼變動之後，出其不意的部分會變少，系統會變更有彈性。 
5.分開變動和不會變動的部分 
6.設計守則：寫程式是針對介面寫，而不是針對實踐方式寫 
7.「寫程式是針對介面寫」真正的意思是「寫程式是針對超型態(supertype)而寫」 
8.動態地設計行為 
9.行為封裝的大局觀 
10.設計守則：多用合成，少用繼承 
11.「策略模式」：定義了演算法家族，個別封裝起來，讓它們之間可以互相替換。此模式讓演算法的變動，不會影響到使用演算法的程式 
12.共通模式詞彙

# 第二章 - 觀察者模式
1.實做題目的需求 
2.知道目前可以得到哪些資訊 
3.認識觀察者模式 
4.觀察者模式簡單定義：報社與訂閱者的關係，但報社有更新報紙就會給予訂閱者通知，反之沒有訂閱的就不會收到通知。 
5.定義觀察者模式 
6.觀察者模式類別圖 
7.鬆綁 
8.主題和觀察者的關係 
9.使用 java 內建的觀察者模式 
10.在 JDK 中找到觀察者模式

# 第三章 - 裝飾者模式-裝飾物件
1.類別爆炸時應該怎麼去規劃 
2.開放關閉守則：類別開放以方便擴充，關閉禁止修改 
3.認識裝飾者模式 
4.定義裝飾者模式 
5.真實世界的裝飾者 java I/O 
6.設計自己的 java I/O 裝飾者

# 第四章 - 工廠模式
1.思考 new 
2.實作範例 
3.封裝建立物件 
4.將會變動的程式碼封裝到另外一個物件中，交由這個物件去專門處理，我們稱這新物件為工廠。 
5.定義簡單工廠 
6.給衍生類別使用的框架 
7.允許次類別做決定 
8.藉由工廠方法，鬆綁超類別與次類別的關係 
9.平行的類別階層 
10.定義工廠方法模式：定義了一個建立物件的介面，但由次類別決定要實體化的類別為何者。工廠方法讓類別把實體化的動作，交由次類別進行。 
11.顛覆依賴守則：依賴抽象類別，不依賴具象類別 
A：變數不可持有具象類別的參考 
B：不可讓類別繼承自具象類別 
C：不可讓次類別中的方法 override 超類別的方法 
12.定義抽象工廠模式：提供一個介面，建立相關或者相依物件之家族，而不需要明確指定具象類別 
13.抽象工廠模式與工廠模式的不同 
14.依賴抽象，不依賴具象類別 
參考網址：https://wickedlysmart.com/headfirstdesignpatterns/code.html

# 第五章 - 獨體模式
1.認識獨體模式 
2.特點：沒有公開的建構式，要實體這個類別，必須呼叫這類別其他方法(例如：getInstance() )來實體化該類別。 
3.定義獨體模式：確保一個類別只有一個實體，並給他一個存取的全域點(global point) 
4.多執行序和獨體模式 
5.使用雙重檢查上鎖減少使用同步化 
6.OO 守則：確保一個類別只有一個實體，並提供全域點存取此實體。

# 第六章 - 命令模式
1.介紹命令模式 
2.定義命令模式：將「請求」封裝成物件，以便使用不同的請求、佇列、或者日誌，參數化物件。命令模式也支援可復原作業。 
3.將命令模式套用進範例 
4.空物件，NoCommand 物件是一個空物件的範例，當需要一個沒有任何意義值時，空物件非常有用，客戶可以將處理 null 的責任轉給空物件。 
5.空物件本身也被視為一種設計模式 
6.實踐 execute() 方法 
7.實踐 undo() 方法 
8.每個遙控器都具備「集合」形式 
9.使用巨集命令 
10.命令模式更多用途：佇列請求、日誌請求

# 第七章 - 轉接器模式與表象模式
1.介紹轉接器 
2.解釋轉接器模式 
3.定義轉接器模式：將一個類別的介面，轉換成為另外一個介面以供客戶使用。轉接器讓原本介面不相容的類別可以合作無間。 
4.物件和類別轉接器 
5.實作練習 
6.裝飾者模式和轉接器模式相似與差異 
7.介紹表象模式 
8.轉接器模式的目的：改變介面符合客戶期望，表象模式目的：提供次系統一個簡化介面。 
9.定義表象模式：提供一個統一介面，用來存取次系統中的一群介面。表象定義了一個較高層次的介面，讓次系統更容易使用。 
10.設計原則：認識極少化守則：只和你的密友談話

# 第八章 - 樣板方法模式
1.將相同方法提出另做一個類別，該類別不同的方法抽象化，以提供給需要該方法的共同使用 
2.在各自方法實作各自抽象化方法 
3.認識樣板方法模式 
4.樣板方法定義一個演算法步驟，並允許次類別為一個或多個步驟，提供其實鍵方式。 
5.樣板方法模式：「將一個演算法的骨架定義在一個方法中，而演算法本身會用到一些方法，則是定義在次類別中。 
樣板方法讓次類別在不改變演算法架構的情況下，重新定義演算法中的某些步驟。」
6.對樣板方法使用掛鉤 
7.好萊塢守則：「別呼叫(打電話給)我們，我們會呼叫(打電話給)你」
8.好萊塢守則與樣板方法 
9.用樣板方法排序
10.樣板模式和策略模式的差別 
11.策略模式：「訂一個演算法家族，並讓這些演算法可以互換。正因為每一個演算法都被封裝所以使用者可以輕易使用不同演算法」 
樣板模式：「定義一個演算法大綱，交由次類別定義其中某些步驟內容，實踐不同細節但是演算法架構仍不變」 
12.策略模式以及樣板方法模式都是用來封裝演算法，但是策略是用合成，樣板方法是用繼承。 
13.工廠方法是樣板方法的一種特殊版

# 第九章 - 反覆器與合成模式
1.檢視問題(兩個不同物件如何合併) 
2.封裝重複動作-使用反覆器 
3.認識反覆器模式 
4.定義反覆器模式：「讓我們能夠取得一個聚集內的每一個元素，而不需要此聚合將其實踐方式暴露。」 
5.單一責任：「如果允許我們的聚集實踐他們內部的聚合，以及相關的操作和反覆的方法，又會如何?我們已經知道這會增加聚集的方法個數，但又怎樣?為什麼這麼做不好?」 
6.設計守則：「一個類別應該只具有一個改變的理由」 
7.類別的每個責任都有改變的淺在部分。超過一個責任就代表超過一個改變的淺在部分。這個守則告訴我們盡量讓每一個類別保持單一責任。 
8.反覆器與聚合 
9.定義合成模式：「允許你將物件合成樹狀結構，呈現「部分/整體」的階層關係。合成能讓客戶程式碼以一致的方式處理個別物件，以及合成的物件。」 
10.合成模式讓我們能夠用樹狀方式建立物件的結構，樹裡面包含了合成以及個別的物件。 
11.使用合成結構，我們能以相同的操作處理合成以及個別的物件。換句話說，在大多數情況下，我們可以忽略合成以及個別物件之間的差異。 
12.透明性：讓元件的介面同時包含一些管理子節點的操作以及葉節點的操作，如此一來客戶就可以將合成節點和葉節點一視同仁，也就是說一個元素究竟是合成節點或者業節點，客戶看不到。

# 第十章 - 狀態模式
1.策略模式是建立可以改變的演算法。 
狀態模式是藉由改變物件內部的狀態，幫助物件控制自己的行為。 
2.劇情描述狀態模式 
3.狀態模式的要點： 
A：找出所有狀態 
B：建立一個實體變數，持有目前狀態，然後定義每個狀態值 
C：將所有的動作整合 
D：建立一個類別，它的作用就像是一個狀態機。
對每一個動作都建立一個對應的方法，這些方法利用條件描述決定出在每個狀態內甚麼行為是洽當的。 
.通用技巧：在一個物件內為狀態改變建立模型。這個作法所用的技巧是利用物件內的一個實體變數持有狀態，並利用方法內的條件式程式碼轉換狀態。 
5.定義狀態介面與類別 
6.狀態模式：「允許物件隨著內在的狀態改變而改變行為，好像物件的類別改變一樣」

# 第十一章 - 代理人模式
1.簡介代理人模式 
2.遠端代理人是「遠端物件的本地代表」。 
3.何謂「遠端物件」?這是一種物件，活在不同的 JVM 記憶體堆積區(heap)中 
4.何謂「本地代表」?這是一個可以在本地端調用的物件，其行為會被轉到遠端物件中施行。 
5.你的客戶物件運作起來就像是呼叫遠端，但其實只是呼叫本地堆積區中的「代理人」物件，再由代理人處理網路溝通的低階細節。 
6.使用和介紹 Java 套件 RMI 
7.代理人執行運作的流程 
8.RMI 術語： RMI 將客戶輔助物件稱為 Stub，服務輔助物件稱為 Skeletion。 
9.製作遠端服務： 
步驟一：製作遠端介面 
步驟二：製作遠端實踐 
步驟三：利用 RMIC 產生真正的 Stub 和 Skeleton 
步驟四：開始 RMI Registry(rmiregistry) 
步驟五：開始遠端服務 
10.使用 RMI 常見錯誤： 
錯誤一：忘記啟動遠端服務之前先啟動 Rmiregistry。(想要用 Naming.rebind()，就必須先啟動 Rmiregistry。) 
錯誤二：忘記讓參數和傳出值得型態成為可序列化的型態。(該錯誤無法在編譯期間發現，只會在執行期發現) 
錯誤三：忘記提供 Stub 類別給 Client 端使用 
11.藉由調用代理人的方法，遠端方法的調用可以跨過網路，傳回字串、整數和狀態物件。 
因為我們使用的是代理人，調用方法會在遠端執行，本低端根本就不知道或者不在乎這一點(唯一例外就是：要處理遠端例外) 
12.定義代理人模式：讓某個物件具有一個替身，藉以控制外界對此物件的接觸。 
13.使用代理人模式建立代表物件，讓代表物件控制某物件的存取，被代理的物件可以是遠端的物件，建立成本高的物件或者需要安全控管的物件。 
14.簡介虛擬代理人 
15.簡述保護代理人 
16.動態代理人： 
步驟一：建立兩個 InvocationHandler 
步驟二：寫程式碼建立動態代理人 
步驟三：利用適當的代理人包裝任何 PersonBean 物件

# 第十二章 - 複合模式
1.模式通常被一起使用，並在同一個設計問題上攜手合作。 
2.複合模式：「結合兩個或多個模式再一起解決方案，以解決一般或者常發生的問題。」 
3.簡短複習各種模式 
4.認識複合模式代表 MVC(Model-View-Controller) 
5.model 利用「觀察者模式」讓 controller 和 View 可以得知狀態的改變。 
6.View 和 controller 則是實踐「策略模式」，controller 是 View 的行為，不同的行為可以換不同的 controller。 
7.View 內部使用「合成模式」管理諸多視覺化控件。 
8.MVC-WEB 的關係與 MVC-APP 的關係 
9.Model 2 Controller Servle 的介紹 
10.Model 2 模式

# 第十三章 - 與設計模式相處-真實世界中的模式(該章節無代碼)
1.模式是在某情境(Context)下，針對某個問題的某種解決方案。 
2.模式的描述就是由一個問題、一個情境、一個解決方案所構成。 
A.情境就是採取某個模式的狀態，這應該是一個不斷出現的狀況。 
B.問題就是你想在某情境下達到的目標，也可以是某情境下的限制。 
C.解決方案就是你所追求的:一個一般性的設計，用來解決限制、達到目標。 
3.根據模式的目標分成三類：生成、行為、以及結構 
A.生成模式：牽涉到將物件實體化，這類模式都提供一個方法，將客戶從所需要實體化的物件中鬆綁出來。 
B.行為模式：他的重點都在於類別和物件如何互動，以及各自的責任。 
C.結構模式：有一些模式(用在比較不常使用的技巧)尚未在本書中介紹，這些模式將在第十四章介紹。 
4.另外一種模式分類：類別模式與物件模式 
A.類別模式：會描述類別之間的關係如何透過繼承定義。類別模式的關係是在編譯時期就建立好的， 
B.物件模式：定義物件之間的關係，而且物件模式主要是利用合成定義。物件模式的關係正常是在執行時期建立的，而且更動態、更有彈性。 
5.重要警告：過度使用設計模式可能導致程式碼過度工程化。經常用最簡單的解決方案完成工作，並在真正需要模式的地方才使用。 
6.共通語彙的五種方式： 
A：在設計會議中－當你和你的團隊在會議中討論軟體設計時，使用設計模式可以幫助你們待在「設計中」久一點。從設計模式以及物件導向守則的觀點，討論設計可以避免你的團隊很快地陷入實踐的細節，也可以避免發生許多誤解。 
B：和其他開發者－當你和其他開發者討論的時候，可以使用模式。這可以幫妳其他開發者學習新模式，並建立一個社群。和別人分享你所學會的東西是很有成就感的事情。 
C：在架構文件的時候－當你在寫架構文件的時候，使用模式將會縮減文件的篇幅，一定讓讀者更清楚地瞭解你的設計， 
D：在程式碼註解以及命名慣例上－當你在寫程式碼的時候，在註解中清楚地著名你所用的模式，還有選擇類別和方法的名稱，盡可能地皆露出對應的模式。其他開發者在閱讀你的程式碼時會很感激你，它們也能夠很快地了解你的程式碼內容。 
E：將志同道合的開發者聚合再一起－分享你得知識。許多開發者都聽過模式，但並不真正了解甚麼是模式。你可以自願為它們講一堂模式介紹，或者成立讀書會。 
7.反模式：告訴你如何採用一個不好的解決方案解決一個問題。 
8.反模式的組成單元： 
A：反模式告訴我們為什麼不好的解決方案會有吸引力。 
B：反模式告訴你為何這個解決方案長遠以後會造成不好的影響。 
C：反模式建議擬改用其他的模式，提供更好的解決方案。 
9.反模式看起來總像是一個好的解決方案，但是當他被真正採用後就會帶來麻煩。藉由將反模式寫成文件，我們能夠幫助其他人辨識出不好的解決方案，以免被誤用。就如同模式一般，有許多不同種類的反模式，包含開發反模式、物件導向反模式、組織反模式、以及各種領域特定的反模式。

# 第十四章 - 附錄剩下的模式(該章節無代碼)
一、橋梁模式(Bridge Patterm) 
1.橋梁模式：使用橋梁模式(Bridge Patterm)不只改變你的實踐方式，也能改變你的抽象。 
2.為何使用橋梁模式?因為橋梁模式允許你改變實踐以及抽象，採取的作法是：將實踐和抽象放在兩個不同類別層階中。 
3.橋梁的優點： 
A：將實踐予以鬆綁，讓他和介面之間不在是永恆的狀態。 
B：抽象和實踐可以被各自擴充，不會影響到對方。 
C：對於「具象的抽象類別」所做的改變，不會影響到客戶 
4.橋梁的用途以及缺點： 
A：相當適用使用在需要誇越多個平台的圖形和視窗系統上。 
B：當你需要用不同的方式改變介面以及實現時，你會發現橋梁模式很好用。 
C：橋梁模式的缺點就是增加複雜度。

二、建立者模式(Builder Patterm) 
1.建立者模式：使用建立者模式(Builder Patterm)封裝一個產品的建構過程，並允許可依照步驟建構。 
2.為何使用建立者模式?因為我們可以將反覆的過程封裝進一個物件中，並將內部收集的資料結構隱藏，讓客戶看不到 
3.建立者的優點： 
A：將一個複雜物件的建立過程封裝起來。 
B：允許物件在多個步驟建立，並且可以改變程序(這和只有一個步驟的工廠方法不相同) 
C：將產品內部的表現方式隱藏起來，但客戶無法碰觸。 
D：產品的實踐方式可以被替換，因為客戶只可以看到抽象的介面。 
4.建立者的用途和缺點： 
A：經常被用來建立合成結構。 
B：和工廠模式相較，採用建立者模式建立物件的客戶，需要具備更多的特定領域知識。

三、責任鏈(Chain of Responsibility Patterm) 
1.當你想要讓一個以上的物件，有機會能夠處理某個請求之時候，就可以使用責任鏈模式(Chain of Responsibility Patterm)。 
2.為何使用責任鏈模式?透過責任鏈模式，你可以對某個請求感興趣的物件建立一個鏈結，每個物件依序檢視此請求並處理之，或者是將他轉給連結中的下一個物件處理。
3.責任鏈的優點： 
A：將請求地發出者和接受者之間予以鬆綁。 
B：可以簡化你的物件，因為它不需要知道此鏈結的結構。 
C：允許動態新增或者刪除責任，你可以改變鏈結的某個處理城市，或者它們的秩序。 
4.責任鏈的用途和缺點： 
A：經常被使用在視窗系統中，處理像是滑鼠和鍵盤的事件。 
B：並不保證請求一定會被執行，如果沒有任何物件處理他的話，可能會落到鏈結尾端以外(這可以是優點也可以是缺點。) 
C：可能不容易觀察執行期的行為，有礙於除錯。

四、蠅量級(Flyweight Pattern) 
1.蠅量級模式(Flyweight Pattern)：想讓某個類別的一個實體，能夠提供許多「虛擬實體」。 
2.為何使用蠅量級模式?如果不用責任鏈模式，你可以重心設計系統，只能用一個實體和一個客戶物件，維護「所有」實體狀態。 
3.蠅量級的優點： 
A：大幅縮減執行期物件的個數，節省記憶體。 
B：將許多「虛擬」物件的狀態集中管理。 
4.蠅量級的用途和缺點： 
A：當一個類別有許多的實體，而這些實體可以能夠被一致的方法控制的時候，就可以使用蠅量級模式。 
B：蠅量級模式的缺點在於，一旦你實踐了他，那所有邏輯的實體，將無法擁有獨立而不同的行為。

五、翻譯者模式(Interpreter Pattem) 
1.翻譯者模式(Interpreter Pattem)：為語言建立翻譯者。 
2.為何使用翻譯者模式?當你需要實踐一個簡單的語言，那就使用翻譯者模式定義文法的類別，並用一個翻譯者翻譯句子。每個文法規則都用一個類別代表。 
3.翻譯者模式的優點： 
A：將每一個文法規則設定成一個類別，方便於實踐語言。 
B：因為文法就是許多類別的集合，所以你可以輕易改變並擴充此語言。 
C：藉由在類別結構中加入新的方法，可以在翻譯者的同時增加新的行為，例如輸出格式的美化，或者進行複雜的程式檢查。 
4.翻譯者的用途和缺點： 
A：當你需要實踐一個簡單的語言時，使用翻譯者模式。 
B：當你有一個簡單的文法，而且簡單比效率來的重要時。 
C：可以處理編劇語言以及編成語言。 
D：當文法規則的數目太大時，這個模式可能變得非常繁雜。在這種情況下，使用剖析器/編譯器的產生器可能更為適合。

六、居間協調者(Mediator Pattern) 
1.居間協調者(Mediator Pattern)：將相關的物件之間，複雜的溝通和控制方式予以簡化。 
2.每個物件都會在自己的狀況改變時，通知居間協調者。 
3.每個物件都會對居間協調者所發出的請求做出回應。 
4.居間協調者的優點： 
A：藉由將物件彼此鬆綁，可以增加物件的再利用性。 
B：藉由將控制邏輯中央集權化，可以簡化系統維護。 
C：可以讓物件之間所傳遞的訊息變得更簡單而且大幅減少。 
5.居間協調者的用途與缺點 
A：協調者常常被用來協調相關的 GUI 元件。 
B：距今協調者模式的缺點是如果涉及不當的話，居間協調者本身會變得過於複雜。

七、助記物(Memento Pattern) 
1.助記物(Memento Pattern)：當你需要讓物件返回之前的狀態時(例如，你的使用者發出「復原」的請求)。 
2.使用助記物有兩個目標： 
A：儲存系統關鍵物件的重要狀態。 
B：維護關鍵物件的封裝。 
3.助記物的優點： 
A：將被儲存的狀態放在外面，不要和關鍵物件混在一起，這可以幫助維護內聚力。 
B：讓關鍵物件的資料封裝不受破壞。 
C：提供容易實踐的恢復能力。 
4.助記物的用途與缺點： 
A：助記物是儲存狀態。 
B：使用助記物的缺點在於儲存和回復狀態的過程可能相當耗費時間。 
C：在 Java 系統中，期時可以使用序列化(Serialization)機制儲存系統的狀態。

八、雛形(Prototype Pattern) 
1.雛形模式(Prototype Pattern)：當建立物件實體的過程很昂貴或很複合。 
2.雛型模式允許你藉由複製現有的實體，建立新的實體(在 Java 中，這通常意味著使用 clone() 方法，或者反序列化)。這個模式重點在於，客戶的程式碼在不知道特定類別違和之情況下，仍可以製造出新的實體。 
3.雛形的優點： 
A：將製造新實體過程中複雜的一切隱藏起來，讓使用者無需面對。 
B：讓客戶能夠產生未知類別的實體。 
C：在某些環境下，複製物件比建立物件更有效率。 
4.雛形的用途與缺點： 
A：在一個複雜的類別階層架構中，當系統必須從其中的許多類別產生實體化的物件時，可以考慮使用雛型模式。 
B：使用雛型模式的缺點在於物件的複製過程有時候相當複雜。

九、參觀者(Visitor Pattern) 
1.參觀者(Visitor Pattern)：當你想要為一個合成增加新的能力，且封裝並不重要時。 
2.參觀者必須參觀合成內所有元素，這樣的功能是在旅遊者(Traverser)物件中，參觀者藉由旅遊者的引導，收集合成中所有物件的狀態。 
3.一旦狀態被收集完成，客戶就可以讓參觀者對狀態進行各種操作。當需要新功能時，只要加強參觀者即可。 
4.參觀者的優點： 
A：允許你對合成結構加入新的操作，而無須改變結構本身。 
B：想要加入新的操作相當容易。 
C:參觀者所進行的操作，程式碼是集中在一起的。 
5.參觀者的用途與缺點： 
A：當採用參觀者模式的時候，就會打破合成類別的封裝。 
B：因為旅遊的功能牽涉其中，所以對合成結構的改變更為複雜。

Head-First-Design-Patterns

Head-First-Design-Patterns Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

Head-First-Design-Patterns

Head-First-Design-Patterns Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

Download README