平台使用手冊

使用 Astah Professional
 >你們是正式旅程的菁英冒險者，必須配上最好的武器才行。 學院提供最好的教育服務、武器和內容，剩下的就靠你們了！

如何使用課程贊助給大家的專業 UML Editor — Astah Pro？

體驗旅程專業工具 - Astah UML Editor

副本零：冒險者指引

Showdown ! 撲克牌遊戲建模 ★

Uno Card ✭

處方診斷系統 ✭

資訊兵主控制器 ✭

軟體設計的關鍵，永遠都不在「你學過多少學問」，而是在於「你在接收到複雜的需求時」，你到底能不能立刻就知道下一步要幹什麼？

如果知道第一步要做什麼，那才能推出「第二步」，以此類推。

所以你最先需要的是「思路」，而不是「設計模式」，於是第一個道館中，我們只在乎「思路」，而且是「行雲流水的思路」。

而水球所整理的這一套「水球流 OOAD — 迭代式物件導向分析和設計」，就是一種可以立即落地的思路了。

「接收到任意需求時，不求完美一次到位、而求多次行雲流水地交付。」

只要你做得到這件事，我就讓你取得此道館的徽章。

第一道館：行雲流水的設計底層思路

設計的關鍵是：把無形變有形

UML 不是拿來寫文件用的

行雲流水的 OOA | OOD | OOP

上這門課一定要有「空杯心態」

OOA / OOD / OOP 概念複習題

軟體抽象之一：點的萃取

練武 - 點的萃取

軟體抽象之二：萃取行為及操作

軟體抽象之三：線的萃取

兩種更強的關聯：聚合＆複合

線上的點：關聯類別

軟體抽象之四：區分結構、行為和侷限

Astah：類別圖教學

練武 - 單句分析 （初級）

練武 - 單句分析 （進階）

OOD 階段一：用行為模型來梳理實作

用 Astah 循序圖來讓「象棋」領域模型動起來

OOP 技法一：依賴

OOP 技法二：關聯

OOP 技法三：關聯類別

OOP 技法四：抽象類別

OOP 按圖施工（懶人包）

OOD 階段二：封裝｜解耦｜萃取

副本一：行雲流水的設計底層思路

實作交友配對系統 ★

RPG ✭

導航系統 ✭

在學完 OOAD 之後，你已經掌握了設計的關鍵「有形的思考」，那麼接下來呢？

「要成為設計的高手，顯然這裡就是入口。」

我們即將在這個道館中學習 Christopher Alexander 的模式思維，結合 OOADP 的框架，將 Alexander 的模式思維落地到軟體領域中。

「最好的設計是『剛剛好』的設計，而不是漂亮和浮誇的設計。」

Christopher Alexander 的模式思維，將進一步地帶領你掌握「減法設計」。

「我們不再做出複雜化或是浮誇的設計，而是用心察覺設計上的約束，並精準解決問題。」

在本道館的單元中，我就會教你如何用 「察覺 Forces → 辨識衝突的 Forces → 定義 Problem → 精準辨識要套用的 Pattern → 套用 Pattern 得到新版的類別圖」來獲得最剛好的設計。

「Forces」正是帶領我們做出更細膩設計推理的關鍵，但同時 Forces 對新手而言也比較抽象，需要一定時間的感受才能掌握精髓。

所以在這個道館中，你的目標很簡單，就是「盡可能的模仿水球我的思維」。

先不要想太多，先盡情地模仿我，模仿了一次、兩次、三次，幾乎所有學員都是模仿到了第四次之後，就能開始舉一反三、超脫框架。

來試試看你能模仿到什麼程度吧！

注意，如果你的 OOAD 類別圖中「沒有模仿我的設計思路」，那就會直接挑戰失敗唷。

第二道館：Christopher Alexander 設計模式

寫一個牌類遊戲框架！ ★★

走到了這裡，就代表你已經學會了「Christopher Alexander 設計模式」以及第一則最最最基礎的「策略模式」了，對吧？

什麼？你覺得策略模式的 Form 很簡單？
哈哈，那是當然的，這可是最基礎的設計模式。

但最重要的是，你的思路是否有因此成長？

記得，這門課主張「設計要客觀」且「有憑有據」，所以你千萬不要小看你所學的第一個模式，其實你正在學的並不是「怎麼套策略模式」，而是如何有憑有據地：「察覺 Forces、定義 Problem，並一步一步地做依賴反轉，來形塑出策略模式」。
在套用策略模式時，每一個步驟都要盡可能客觀、有憑有據，以及關注點分離，才能形塑出最精準的策略模式的套用結果。

這就是為什麼我們的每一部設計模式的觀光景點中，都會用逐步推理的方式來分析、思考和套用模式。
而為了讓你好上手這種思路，我特地選了最基礎的策略模式來讓你小試身手呢。

我們再練習一次吧，這一次，我們要學的不是策略模式，而是在套用完策略模式之後，你很有可能會想要接著套用的「樣板方法」。

在學新的設計模式的時候，同時也會學到「新的 Force」。通常這個訓練過程要反覆三次以上，就會能夠舉一反三。

那麼，這次你的目標一樣也是盡可能在 OOAD 時模仿我影片中的思路，那麼來吧，歡迎你來挑戰道館三！

第三道館：掌握「樣板方法」 - 最基礎的控制反轉

碰撞偵測＆處理 ★

很好，你現在不只會處理最基礎的行為變化（套用策略模式），還懂得用在多道行為之間「留同存異」來萃取出樣板。

有沒有開始感受到自己越來越懂得設計出良好的程式架構「因應需求的變化」？

「在這個世界上，唯一不變的事情，就是事事會變。」確實，人們很常這樣說。

但是這門課會這樣說： 「不過，我只要弄懂所有可能的變化形式，那我就能一直應變。」

需求雖然一直變，但是變的方式有哪些？

我們現在只學到了一種變的方式，就是策略模式所處理的「基礎行為變動性 Force」，讓 Client 得以直接抽換類別的某部分行為，在多種行為中選擇其中一種。

現在，是時候學習「第二種行為變動性的 Force」。 很多時候，我們根本不知道 Client 想要的是什麼，只能先解析 Client 的輸入意圖之後，才知道要到底要如何處理他的輸入。

你不只需要學習第二種行為變動性的 Force，還需要好好區分目前所學的這兩種之間有什麼差別。

如果你要挑戰道館，那麼我一定會問你這個問題。來吧！強者們！來挑戰吧！

第四道館：精準辨識不同行為變化的約束

大老二撲克牌遊戲！ ★★

各位強者們好！

我們現在已經學會了三個設計模式了：策略模式 (Strategy Pattern)、樣板方法 (Template Method) 以及責任鍊模式 (Chain of responsibility Pattern)。

還從中學到了多道 Forces：
1. 基礎行為變動性 Force （策略）
2. 責任鏈的行為變動性 Force：「輸入 → 解析輸入意圖 → 處理輸入」
3. 程式碼重複 Force
4. 擴充性 / 彈性 / 開閉原則 Force (三者都是擴充性的別名）

那在過去的三個道館呢，由於你已經明確知道「該道館要你挑戰的設計模式可能為何」，因此你可以很容易地「知道」要套什麼模式比較好。

但是！這一題魔王題就不一樣了！
你現在會收到一份莫名其妙的需求，然後你必須自己察覺需求中形成的 Forces，理性地在適合的地方套用多個設計模式，這就是所謂的綜合模式的實戰演練。

在這個道館中，我即將出一題「大老二撲克牌遊戲」的綜合實戰演練給你，好好表現吧，強者們。

「你說⋯⋯『大老二撲克牌遊戲』不是實戰演練，是很幼稚的專案嗎？」
不，相信我，大多數企業專案面對的領域模型的邏輯複雜度都沒有比大老二來得困難，大老二撲克牌遊戲中無論是遊戲流程、牌型判斷還是人工智慧，都是一般企業商業邏輯難度的數倍以上。意即，如果你能寫得好大老二，企業中的商業邏輯對你來說幾乎是易如反掌。

所以來吧，按下挑戰按鈕，相信你自己，你受了這麼多訓練，就代表——你絕對能夠順利挑戰成功這個道館。
當你讀著這段話時，記得，水球我永遠相信你做得到的，我在第五道館等你，Let’s move on。

第五道館：綜合模式實戰演練 - Big 2

破除迷思：為什麼四人幫設計模式反而給你添了了更多麻煩？ 

前導片：失傳的設計模式

思維升級：Christopher Alexander 模式六大要素及模式語言

Christopher Alexander 模式六大要素及模式語言

歡迎各位來到了要打通各位韌度二脈的副本——軟體設計模式。「軟體設計學」博大精深，如同去欣賞一棟建築物的品質般如此抽象又主觀，而從主觀背後的邏輯中萃取出理論便是每一門學說最大的目的。我們精通這些理論，正是為了能夠有效且理性的方式來去欣賞更多不同的軟體設計、並且做出良好的設計決策，而非總是被自身的直覺和經驗牽著鼻子走。

軟體設計模式觀念複習

我們曾在 OOA 中提過抽象類別 (Abstract Class) 的概念：我們之所以將一個類別定義為「抽象」，主要是因為 「此類別具備著抽象的動作/操作 (Abstract operation)」。如果該類別不具備任何抽象動作，則你目前還沒有十足的理由將此類別宣告為抽象類。

進入到物件導向設計 (Object-Oriented Design, OOD) 階段之後，我們就要開始在類別圖中認識一項新的設計元素：介面 (Interface）。

所以，我們用一篇文章和一則簡單案例的時間來理解「抽象類別」和「介面」之間的差異吧！

你必須了解何謂「萃取」 (Abstract)｜抽象類別 vs. 介面

各位冒險者，準備好要學習第一個設計模式了嗎？ 不管你已經聽過多少次「策略模式」的概念，這支影片都保證會刷新你的三觀！

景點 - 策略模式｜基礎水平行為擴充

歡迎進入到策略模式的挑戰題！第一個模式特別重要！我們來做一點思維上的練習，然後再來進入實作題吧！

複習 - 策略模式

樣板方法模式是一種行為型設計模式，它提供了一個演算法的框架，將演算法的結構和某些步驟的實現延遲到子類中。樣板方法的目的是提供一個共用的演算法框架，使得不同的子類可以根據自己的需求進行具體的實現。

 這樣做的好處是避免了代碼重複，提高了代碼的可維護性和可擴展性。同時，樣板方法還使得演算法的結構更清晰，易於理解和修改。

景點 - 樣板方法｜留同存異的萃取能力

萃取樣板，就是最小的控制反轉

用樣板方法來實現「控制反轉」

練武 - 萃取樣板

樣板方法——寫一個牌類遊戲框架吧！
「技術框架正是樣板方法的集成。」
樣板方法是最簡單的模式，但卻是技術框架中最重要的設計。

樣板方法的實作題難上了許多，是時候善用旅團中的全力來一同過關斬將了！

複習 - 樣板方法

在這一份樣板方法特訓帖中，我會透過兩道循序漸進的題目，來讓你好好地暖一暖你的樣板思維。

 小試身手：提取樣板方法 — 去除重複程式碼

 給予以下兩個類別，程式碼的意圖被我刻意使用雜亂的命名掩飾掉了，明眼人可能一下就看出兩個類別在做什麼，但是為了鍛鍊你的萃取能力，你暫時只需要關注在程式碼本身就行。

 這一題小試身手就是：你必須套用樣板方法來完全去除兩個類別中所有重複的程式碼。

樣板思維暖身帖

「責任鏈上的每個物件，就像公司中那些本位主義的員工，不在其位，不謀其政。有了責任鏈之後，老闆只須發號施令就行了，不再關心究竟責任會落到誰的身上。」

 責任鏈模式透過優雅的依賴注入，讓需求處理者一個串著一個， 在許多專案中，常常最有生產力價值的——就是這條責任鏈，因為他支撐起了整個專案的擴充性。

 走吧！

景點 - 責任鏈模式｜解析後水平行為擴充

責任鏈模式—— 讓功能由少變多的模式啊！

 這是副本二的最後一個任務了！學院也不私藏地在體驗旅程中就將其中一個能夠有效改變思維的模式贈送給大家了！責任鏈模式一下子的就擴大了軟體擴充的各種可能，但在套用時一定要冷靜地察覺清楚 Forces，要不然你有可能會淪為「看到 if-else 就想套用模式」的錯誤觀念唷！

複習 - 責任鏈模式

第一個該學的SOLID原則：開閉原則 (Open-Closed Principle)
SOLID到底重不重要嗎？
「開閉原則 (Open-Closed Principle)」是軟體設計原則SOLID Principle中提出的一項原則。

大家應該在寫程式之後，最常聽到的原則應該就是"SOLID"了。 不過呀，SOLID就是最典型的「易學難精」的知識，有八成的夥伴在職場上，其實都聽過好多次SOLID了， 但仍會礙於實務經驗的不足，而即便聽了多年，也都無法真正理解原則背後最在乎的事情。

開閉原則 (Open-Closed Principle)

精準區分策略＆責任鏈 Forces

練武 - 精準區分策略＆責任鏈 Forces

補帖 - 無招勝有招：依賴反轉之重構三步驟

副本二：Christopher Alexander 設計模式

Youtube 訂閱機制 ★

觀察者模式——Youtube 訂閱機制
難度：★☆☆☆☆

需求
你要簡單撰寫一個模擬 Youtube 頻道 (Channel) 和 頻道訂閱者 (Channel Subscriber) 之間互動的程式。

第六道館：掌握響應式行為約束

快捷鍵設置機制 ★

主控制器 (MainController) 需要實作一套快捷鍵設置機制，該機制可用於與軍用裝置進行操作。主控制器上有一副鍵盤，由 a-z 26 個按鍵組成。軍方有兩種軍用裝置：坦克 (Tank) 和通訊設備 (Telecom)，它們具有不同的操作需求。

第七道館：透過「指令」來綁定行為

二維地圖冒險遊戲 ★★

★★：狀態模式——二維地圖冒險遊戲

難度：★★☆☆☆

你要撰寫一個文字版的二維地圖冒險遊戲。使用二維陣列來呈現一個地圖 (Map)，地圖上每一個物件(Map Object) 都用一個符號表示。 並用箭頭符號（↑→↓←）呈現主角 (Character) 的位置，以及主角面向的方位 (Direction)。玩家藉由輸入指令來操控主角。 這樣一來就能夠設計一個二維地圖冒險遊戲了！

第八道館：用「狀態機」來精準套用「狀態模式」

真・RPG 之對戰遊戲 ★★★

如果你通過了上一個道館，說明你可能已經熟悉，如何透過「Force 關鍵句型」來定位和分類 Forces，並且從 Forces 從適當定義 Problem，最後精準套用設計模式。

這門課最重要的就是這個思路，只有懂得定位和分析問題，才知道如何「一一套用最適當的解方」。

所以這等能力啊，你只練一次是不夠的，你要不斷挑戰更複雜、更有心機、更刁鑽的系統需求。然後這份需求中，又充滿各式各樣的 Problem 要你去解，這樣你才能在思路上有所成長！

於是，你準備好了嗎？這個道館的題目很有挑戰性喔，至少要套用到「五個設計模式」才能解決所有設計問題喔！

## 再學三個行為型模式，才有辦法通過此道館訓練！

什麼？你說現在你只會三個模式是吧？只會「策略模式、樣板方法和責任鏈模式」。

不要緊，在挑戰這一個道館之前，我們再學另外三個重要的進階行為型模式吧，也就是「觀察者模式、指令模式和狀態模式」。

既然你會多學另外「三個行為型模式」，就說明你會多認識三種「行為相關的 Force」，那這三個分別是「響應式行為變動性、行為賦予和狀態型行為變動性」。切記，要用上一章所教的「Force 關鍵句型」來精準區分這幾種之間的不同。

最後我再囉唆幾句，當你在挑戰本道館的題目時，你初次看的時候可能會覺得題目有一點點長，但不必急躁，你需要做的是「一句一句做單句分析」，每一句都確保你把該抓的「行為」和「行為相關的 Forces」都抓到，這樣才有足夠的底蘊在 OOD 時抓到足夠多的 Problem。

反之，如果你的行為抓得不夠多、Forces 抓得不夠清楚、分類不夠到位，那就一定會少套設計模式，而讓整體架構設計做不到需求所要求的擴充性。

記得，這一題至少要套用到「五個設計模式」才能解決所有設計問題喔！

並且，當你在挑戰道館時，我會請求你闡述一下你遇到了哪些設計問題，請用「先用白話文的方式講 Force，再總結成 Problem」的方式闡述，最後再說「所以你套了什麼模式」，這樣表達力就會非常好，就像我實戰景點影片中所示範的那般。

加油！相信你自己。這個道館通過之後，你就是一半的強者了，好好上課吧！

第九道館：白段複雜行為實戰演練 - RPG

總算進到了「進階型模式」這個副本了！前一個副本都還算是「暖身階段」，我們用了一個副本的時間來熟悉 OOD 的內涵，以及套用設計模式的感覺。在打完副本二的魔王題之後，想必各位都已經深深地感受到軟體設計的曲高和寡之處了吧？

副本三的魔王很強喔！因此，我們要來讓實力再往上昇華一層才行！從觀察者模式開始吧！Go～～

景點 - 觀察者模式｜響應式行為變化

基礎行為 vs. 響應式行為變化 Forces

複習 - 觀察者模式

在行為型設計模式中，觀察者模式（Observer Pattern） 最常對應到「Force-行為變動性 (響應式)」這道和行為變化相關的 Force，此 Force 又稱之為「響應式行為變動性 (Reactive Behavioral Variation, 簡寫為Rx-BV）」。

Force-行為變動性（響應式）：關鍵句型

這個模式旨在找出所有行為最抽象的共同點，並以此共同點為基準來將「行為物化」！當成功把「一道行為」視為是物件之後，我們就能存放它或是關聯它啦！

景點 - 指令模式｜解耦操作及能力

複習 - 指令模式

在行為型設計模式中，如果要套用指令模式，則必定你會先察覺到存有 Force-行為賦予 的情境。於是我們來更精準地定義一下 Force-行為賦予 的關鍵句型。

Force-行為賦予：關鍵句型

★★：狀態模式——寶藏地圖

 狀態模式——寶藏地圖

 難度：★★☆☆☆ 

你要撰寫一個文字版的二維地圖冒險遊戲。使用二維陣列來呈現一個地圖 (Map)，地圖上每一個物件(Map Object) 都用一個符號表示。 並用箭頭符號（↑→↓←）呈現主角 (Character) 的位置，以及主角面向的方位 (Direction)。玩家藉由輸入指令來操控主角。 這樣一來就能夠設計一個二維地圖冒險遊戲了！

景點 - 狀態模式｜梳理複雜行為變化

用「有限狀態機」來梳理複雜行為

複習 - 狀態模式

在行為型設計模式中，在套用狀態模式（State Pattern） 之前，必定會先察覺到「Force-行為變動性（狀態型）」這道 Force。

Force-行為變動性（狀態型）：關鍵句型

練武 - 所有行為模式 Forces

副本三：掌握所有複雜行為變動

處方診斷系統 ★★

恭喜你來到了旅程的黑段部分！

經歷了白段的前五個道館訓練的你，現在肯定能在寫程式之前就能精準分析多道 Problems 並且一一套用設計模式，你已經有了架構師最重要的「抽象能力」。

## 軟體架構師的鑑別度：抽象能力

那麼，架構師到底需要什麼能力呢？什麼是關鍵能力，能直接區分出一般軟體工程師和軟體架構師之間的差別？

1. 架構師負責針對企業需求及架構現況，盤點出各項待解難題，並針對持續增量的新需求來制定最剛好的架構方針，或是制定模組化、模組與模組之間相依關係及擴充路徑的方針。此為「宏觀」的設計能力。

2. 架構師偶爾可能也要充當資深工程師，下去針對各個模組的程式架構做出大幅度的調整，以調整過後的版本作為範例來指導其他工程師對齊實踐。此為「微觀」的設計能力。

總結來說，所謂的架構師，就是「任何一個層級的架構都難不倒他」才叫架構師嘛！從「宏觀」到「微觀」的設計能力你都要有，不管是從宏觀走到微觀 (Top-Down)，還是從微觀走到宏觀（Bottom-Up) 的能力你都要有。

## 從「微觀」一路練到「宏觀」的設計能力

那這門課至今啊，我們所鍛鍊的都是「微觀」的設計能力，直接定義了程式架構的性質，好比我們花了大多數時間在學的行為型模式啊，基本上都是在斷定「到底程式中哪些行為需要遵守開閉原則？如果有此等需求，那我該怎麼重構？」

而從這個道館開始呢，要往上一個層級了，既然你會套設計模式了，就說明你已經知道該如何做最基本的程式架構。那下一步就是要學習「結構型模式」和「基本架構學問」來更充分地做到「精準的模組化設計」。

別急呢，從這個道館開始吧！

先學學門面模式這個最簡單的結構型模式吧，從中你不只會了解到「門面如何幫助解耦」，還會進一步了解到「阿～原來門面切分不同類型模組之間的邊界」。

然後，用這個道館的二星題目來學以致用吧。

這一題只有兩顆星，只要你單句分析做得沈穩，基本上應該會覺得「自己是相當游刃有餘」的，因為你可是從三顆星的第五道館來的呢，你早已變強了，黑段的強者們。

Let's move on。

第十道館：基礎架構思維及邊界劃分

好友關係分析器 ★

轉接器模式——好友關係分析器

難度：★☆☆☆☆

A. 需求

在現代網路社群平台上，人們透過社群平台的好友功能，可以與他人互相結為好友。現在你要開發一個簡易的好友關係分析器，我們首先使用此分析器制定的格式來撰寫一部分人們的好友關係腳本 (Script)（i.e., 使用一個特殊的語法格式來描述每個人分別有哪些好友），然後將此腳本餵入分析器，接著你就能夠讓分析器分析一些關係組成。

第十一道館：跨越邊界 - 依賴反轉及轉接器

【延遲載入】員工資料表存取 ★

代理人模式——【延遲載入】員工資料表存取

難度：★☆☆☆☆

A. 需求

你有一張員工資料表檔案，你需要為此資料表設計一個資料存取工具 (姑且稱它為 Database)。

第十二道館：透過「代理模式」來介入存取控制

日誌框架 ★★

複合模式——日誌框

難度：★★☆☆☆

背景知識：何謂日誌 (Logs)？

寫日誌 (Logging) 指的是在應用程式運行時，輸出訊息來描述每一個時間點的運行狀況，以便開發者偵錯。這些輸出的訊息就被稱之為是「日誌 (Logs) 」。而隨著應用程式的規模增大，日誌需要妥善的配置，如使用分級機制來管理日誌，以便開發者能在上千上萬行的日誌中快速找到重要的資訊。

但是要如何允許開發者輕易地配置日誌？於是各個程式語言都會發展出對應的日誌框架。

第十三道館：掌握樹狀結構 - 「複合模式」

服務探索/負載平衡 (Service Discovery/ Load Balancing) 機制 ★

黑段的強者啊，有沒有覺得自己離「軟體架構師」又更進一步了呢？

在上個道館中，你開始接收有別於行為型模式的訓練，你的關注點開始從「封裝行為變種」等微觀設計，前往「模組化架構設計」的宏觀。

那有了基本的感受之後，一樣，接下來，我們一樣再橫向學習更多不同思想。

## 學習更多結構型模式，來豐富解決設計問題的認知

你可以相信，橫向學這些「結構型模式」對成為一位軟體架構師一定是有所幫助的，否則我不會放在課程中。

（那些相較沒幫助、或是概念重複較高的四人幫模式，我都不會放在這門課中教，也不認為你有必要去學習。）

結構型模式有趣的點，就是每個模式都會「用不同的情境和視角，教會你更多一些對不同種結構設計」的認知。

我們學這些模式並不一定只是為了學以致用，更多時候是建立更豐富的認知。

好比你不會太常用到「代理人模式」，但也只有在學習代理人模式的過程中，你才會從中學到「代理結構」可以長什麼樣子。

那這份對於結構的認知，更不只適用於微觀的程式設計，還能適用於宏觀的模組化設計。（你把模組當成類別看待就行了）

## 熟悉各種結構，然後來挑戰吧！

總結來說，以這門課的 OOAD / Christopher Alexander 模式作為基礎，來學習這些有趣易懂的結構型模式有以下兩大好處。

1. 熟悉五種不同結構設計的用途：轉接/相容、代理、隱藏結構複雜度及變化、行為組合。
2. 熟悉新的結構相關的 Forces，擴大自己設計模式思路的適用範圍。

好，那等你學完這些結構型模式之後啊，接著就來練習實作一個「服務探索機制套件 (Service Discovery Library)」吧！

第十四道館：透過複雜結構來組合行為 - 「裝飾者模式」

社群機器人引擎 | 有限狀態機框架 ★★★★

黑段的強者，你終於走到這裡了。

你知道嗎，很少工程師能夠在「真的實際寫程式」之前，就把規劃做得這麼快、這麼完整，這都是需要大量 OOAD 的苦工和汗水才做得到的。

能走到這裡，你的學習成效早就已經見證了，就在你的類別圖設計上。

那麼，你一定很希望自己能夠精益求精，變得更強對吧？

要變得更強，只有一種做法——「那就是寫更難的題目」。

那麼，你就一定也很好奇，水球到底能不能考倒現在的你，對吧？現在的你不只能抓出各式各樣的 Problem，還能夠快速套用多個模式依序化解程式複雜度。

你一定很好奇，再更難的題目長什麼樣子，對吧？

## 四星難題的邏輯大公開

這個道館的題目是「四顆星」的題目，所以你一定會從中「被挑戰」到，而從中成長，這是非常神奇的一件事。

但只要你懂我出題目的邏輯，就知道為什麼水球能夠這麼精準地控制學員每個時期的學習成效：
1. 一顆星的題目：鍛鍊的重點是思路，只需要把 OOAD 做 60% 完整度，程式碼就不會寫得太挫折。
2. 兩顆星的題目：需求中的概念複雜度為一星題的兩倍到三倍，OOAD 需要做到 90% 的完整度，才不至於漏抓 Problem 或者在實作時感到挫折。
3. 三顆星的題目：需求中的 Forces 衝突組（也就是 Problem）至少超過 3 個，且每種 Problem 不同，至少要套用三個模式才能化解，否則寫程式時會很挫折。
4. 四顆星的題目：不只是不同類型 Problem 的數量超過 3 個，還涉及 2 個以上的模組，並且最核心的模組至少從 「7~10 種」不同應用模組的行為中「萃取出最剛好的共同之處」，如果OOAD 不夠完整、萃取不夠細心，則是連寫都寫不太出來。

從四星題目的出題邏輯來看，你有沒有發現，要變得更強的關鍵是什麼？

## 變得再更強的關鍵能力：萃取

那就是「萃取」——「留同存異」的能力。

還記得在道館三時，你曾寫過一個撲克牌遊戲框架對嗎？
當時你只需要針對「Uno」和「比大小遊戲」兩種應用模組來萃取剛剛好的撲克牌框架就好。

那可想而知，如果你的應用越豐富，你要從這麼多各式各樣的不同應用中萃取出「核心框架」，肯定是非常考驗你 OOAD 的完整度以及細心。

如果你跳了太多步驟，那最後就會因為「抽象層面上的資訊不足」而施力點不足，因而找不到剛剛好的「萃取」，這樣在寫程式的時候就會開始「有點痛苦」。

所以各位強者們，一起來享受這一題吧。
雖然有可能會被題目挑戰到，但千萬別忘記，受挫才是正常的，受挫才是變強的捷徑。

這一題只要練過去了，我和你發誓，你要去自幹 Web framework 或其他 Framework 可能對你來說都不算是什麼難題了，因為這一題絕對比 Web Framework 的複雜度來得高。

也就是說，你離成為硬核 Coding 高手，就只有一步之遙了。

請你好好享受這道題目中的所有 Forces，願 Forces 與你同在！

Let's move on.

第十五道館：高級複雜框架實戰 - 有限狀態機應用框架

各位冒險者好，很開心我們終於來到了新的副本， 結構型模式 （Structural Pattern）。

我們花了兩個副本的時間在精通「行為型模式」，在處理行為變動 Forces 的時候，我們感受到的是「大量行為變動」帶來的高邏輯複雜度，而透過行為型模式，我們就能有效地化解複雜度，讓物件各司其職。

景點 - 門面模式｜隱藏結構

複習 - 門面模式

架構 - 終於要教怎麼「劃分邊界」了

大補帖 - 軟體架構學：大道至簡

大家好！接下來的這個模式，相對來說比較輕鬆愜意。我們要來認識的是一個非常常用的結構型模式——轉接器模式。只要你的軟體結構在分層上做得越淋漓盡致，那就越常需要使用轉接器模式。

並且，在這部影片中，我們還會藉由轉接器模式的案例，來進一步討論「如何用意圖的高低層次來嚴格定義『依賴反轉』以及『依賴反轉原則 (Dependency Inversion Principle, DIP)』」

景點 - 轉接器模式｜跨越邊界

複習 - 轉接器模式

大家好。 今天我們又要再認識一個十分常用的結構型模式——代理人模式 (Proxy pattern)。

代理人模式的概念也很簡單，但是卻隨處都能見到它的影子，而代理人模式的應用有著許多十分知名的案例——延遲載入、Copy-On-Write、遠端代理等應用！

來吧！我們來認識這個有趣的模式。

景點 - 代理人模式｜控制存取

複習 - 代理人模式

在結構型副本中，我們已經認識了門面模式、轉接器模式和代理人模式，這三個模式雖然解決了不同的 Problem，但大家的 Form 中都存在一個相同的特性——那就是：「他們都背著 Client，偷偷地組織物件」。那今天啊我們要來做一個總結，像這種「隱藏結構複雜度的事」啊，還是「複合模式 (Composite Pattern)」做得最極致—— 背著 Client 種出一棵樹都能不讓 Client 發現呢。那麼，你準備好要來認識結構型模式副本中最重要的模式了嗎！

景點 - 複合模式｜樹狀結構的透明度

複習：複合模式

我們總算來到結構型模式副本中的最後一個景點啦！

在學習裝飾者模式之前，記得要先了解上一個景點 — 「複合模式」唷！

這是結構型模式中的最後一個景點了，摸了「複雜結構」這麼久了，是不是開始有點懷念「複雜行為」帶來的挑戰性呀？

那麽，結合結構和行為兩者的「裝飾者模式」將會為這副本劃下一個非常浪漫的結尾，你即將學到如何使用強大的結構來組合多變的行為！各位準備好了嗎？Let’s Go！

景點：裝飾者模式｜解決組合爆炸

複習：裝飾者模式

副本四：規模化架構思維

單體模式——計算模型 ★

黑段的強者，讓我問問你一個問題吧。

當你已經學會了各式各樣的模式，知道如何拆解複雜行為，同時又知道如何做出宏觀、微觀的架構設計之後。

下一件事要學什麼？

很簡單，那肯定就是要讓「所有東西動起來」啊！

做了這麼多結構設計拆了一堆小實作、一堆小插件之後，如果這些東西無法被有效地創建、組織起來，那也是沒用的啊！

而這個過程中最需要細心學習的是什麼？
那就是「創建物件」。

所以囉，架構設計固然重要，但是想辦法把「所有物件」都在正確的時機創建出來也很重要，這也是為什麼我們最後才開始學「與物件創建相關的 Forces」，涉及到「單體」、「工廠方法」和「抽象工廠」三個主要模式，學完這三個就夠了。

準備好了嗎？這是最後一個需要先吸收知識才能實戰的道館了！

Let's move on

第十六道館：單體模式及資源限制約束

工廠方法——基因演算法套件 ★★

工廠方法 ★★：基因演算法套件

難度：★★☆☆☆

A. 背景
你在一間全台最大的電商購物網站中任職技術顧問。

由於公司今年營收十分得好，決定要擴建新產品團隊，在核心競爭力上研發技術來打造更體貼的電商購物網站，像是：

第十七道館：劃破一切的「生命週期約束」

抽象工廠——ASCII 介面主題 (ASCII UI Theme) ★

★ 抽象工廠——ASCII 介面主題 (ASCII UI Theme)

難度：★☆☆☆☆

你正在開發一個基於 ASCII 文字的介面套件 (ASCII UI)，你希望這個套件能幫助開發者繪製以 ASCII 文字組成的字串作為命令行程式的 UI。然而，你想要實現「ASCII 主題風格 (Theme)」的切換功能，以便開發者能在不修改既有程式碼的前提下，自由切換不同 ASCII 主題風格。

第十八道館：二維度的模組化一致性

IoC 容器魔王參見 ★★★★

你要開發一個「單字學習系統 (Vocabulary Learning System)」，這個系統的功能架構如以下所示：
    1. 管理單字 (Manage words)：讓使用者能管理自己的單字庫中的單字。
        1. 查詢單字 (Search words)：輸入一個單字，系統上網幫忙查詢單字定義，並印出。使用者也能在此時決定將此單字加入單字庫 (Word Repository) 中。
        2. 新增單字 (Add new words)：輸入一系列單字，系統上網幫忙查詢這一系列單字，並將查詢成功的單字加入單字庫中。
        3. 刪除單字 (Delete words)：輸入一系列單字，系統從單字庫中尋找這些單字，並將他們刪除。
    2. 複習單字 (Review words)

第十九道館：高級複雜框架實戰 - 控制反轉框架

我們來到創建型模式副本中的第一個景點——單體模式 (Singleton Pattern) 啦！ 對於新手而言，這可能是所有模式中「形式」最簡單，一下下就套完了的模式，所以你會倍感親切；而對於老手而言，我們要來聊聊進階的的單體模式話題：「單體模式究竟是不是『反模式 (Anti-Pattern)』？」

景點：單體模式｜資源約束

複習：單體模式

大家好，我是水球潘。歡迎各位來到創建型模式副本中的第二個模式，工廠方法 (Factory method)！

這個模式算是大家最耳熟能詳的模式之一啦！不過，不過，也是最容易濫用的模式。欸？怎麼又是這個開場白，好像在單體模式中也有說過。

是的，工廠方法的形式也非常簡單，但同時也是非常容易濫用的，此影片會透過一個很實用的案例，來帶你感受一下工廠方法這個新模式面對的 Forces， 並且你要好好注意：水球到底是如何去佐證工廠方法的套用必要性的？

那麼就來吧，上需求！

景點：工廠方法｜生命週期約束

只有存在「生命週期約束」時，才需要工廠

大家好，我是水球潘。歡迎各位來到創建型模式副本中的最後一個模式，抽象工廠(Abstract Factory Pattern)！

在上一個景點中，我們學到了「工廠方法 (Factory Method)」，那現在怎麼又要再學一個「工廠」的模式呢？

肯定是因為還有新的 Forces 還沒學完嘛，你以為「創建型模式」就「只是 new Product」而已嗎？一旦產品組合複雜起來之後，那麼工廠也是需要管理的呢。

這一次的需求會比較複雜，且 OOAD 的流程會比較長，會用十分循序漸進的方式帶你認識抽象工廠模式，請你將重點放在思路上。

那麼就來吧，上需求！

景點：抽象工廠｜從行為型模式一路到套創建型模式

副本五：生命週期及控制反轉

自幹一個 Web Framework ★★★★

各位黑段強者們好，我們終於來到了本課程的「終極副本」。這個副本就只有一個魔王題，也就是我—— Web Framework。在這個魔王題中，你即將打造屬於你的大型系統作品。

我並不會給你太多的拘束，我僅提供給你一份完整的需求作為「你思考的起點」，當你開發出此份需求要求的初版 Web Framework 之後，接著我會繼續帶領你在「功能/非功能設計」上自由發揮、優化或是演化，只要你持續待在旅程中，水球領主就會持續引導你去挑戰 Web Framework 更多複雜的技術細節，直到你做出一份使你非常滿意的大型作品為止。

這份作品將不屬於水球軟體學院，屬於你自己。這份作品包含你在整個過程中繪製的初版物件導向分析圖、設計圖，展現你游刃有餘思路的各組 Well-defined context，和你為每一道 problem 精準套用的設計模式——這一切都將屬於你個人，是你學有所成、是超越八成工程師實力水準的展現，是這旅程的尾聲，但同時也是你在軟體去登峰造極之路的開頭。

給自己多一點時間來享受這份題目吧，我們身為工程師，能在有生之年內去細心雕磨一款屬於自己的作品並不容易。在過去五個副本中，我要求你當一位稱職的工程師，大多數時間都在訓練你如何迎合他人的需求，並快狠準地處理各種需求。不過現在，你可以當藝術家了，Make the big thing of yours!

在開始閱讀需求之前，我想要再次提醒你一件重要的事，這份需求和以往需求相同的地方是，皆涉及了大量的領域知識，不過比較不同的地方是，這份需求涉及的是 Web 技術知識，而且這份需求更像是「技術規格文件」。所以這一題的難度是建立在「技術規格」的實作上，你個人即將扮演著一間 SI 廠商，你需要獨立分析這份技術規格文件，然後著手開發。

不過走到這裡了，又怎麼會再害怕「領域知識」呢，不管是撲克牌遊戲的知識、交友配對的知識、RPG 遊戲、醫院診斷系統的 Know-how、還是服務探索機制的架構知識和這份 Web Framework 背景知識，只要是知識，就能仰賴物件導向分析與設計的技巧，有效地在需求分析、設計和開發上 make progress。（你甚至可以當作是買了水球的軟體設計模式精通之旅後，還附送水球的 Web 知識教學。）

不瞞你說，這正是為什麼我想要以「Web Framework」作為旅程的結尾，Web Framework 涉及三大構成艱難需求的要素：

1. Web Framework 涉及豐富無形且扎實的 Web/Http 技術背景知識。
2. Web Framework 是許多公司後端開發賴以維生的框架，仰賴十分卓越的易用性和擴充彈性。
3. Web Framework 的規模可大可小，只要你有耐心，你便能獨自一人開發出大規模的精緻系統。

你的初版 Web Framework 可能只有 2000 行的程式碼，但接著在新功能需求的添加下，你會再添加到 4000 行程式碼。接著再考慮「資安相關」的需求，你的框架將演化成 16000 行程式碼。16000 行其實已經算是成熟的商用套件了，如 Javascript 後端開發者常用的 express.js，也差不多位於這個行數區間。接著你肯定還會想繼續加強細節（畢竟這作品可是你引以為傲的孩子），你會開始引入各種 middware，在架構上不斷積累至 40000 多行程式碼——不斷變強、變強，再變強。

如果你是後端工程師，那很好，在完成這副本之後，你可以聲稱你自幹過一套 Web Framework，並在各種面試場合下分享他，這已經勝過了八成的面試者。而如果你是前端工程師，那更好，你不只展現出跨領域學習的潛能，習得了後端知識，甚至還做了一件後端工程師都不太敢做的事 — 你身為前端工程師，竟然在不熟悉後端開發的情況下，就開發出 Web Framework？這太扯了。

閱讀到這裡之後，相信各位冒險者應該都已經「非常手癢」了吧。

我們開始吧！給自己弄一杯好喝的咖啡或是鮮奶茶，打開你的 UML Editor。

第二十道館：黑段複雜框架考驗 - Web Framework 實戰

各位冒險者好，我們終於來到了本課程的「終極副本」。這個副本就只有一個魔王題，也就是我—— Web Framework。在這個魔王題中，你即將打造屬於你的大型系統作品。

6.B 魔王題：★★★★ 自幹一個 Web Framework

副本六：自幹高度擴充性的 Web Framework

各位冒險者們好，這邊有一項很重要的請求，要請各位喜歡本旅程教學內容的夥伴幫忙一下。那就是如果你喜歡軟體設計模式精通之旅的教學和服務，請留一下個人評價，為水球我的教學品質背書！

【批改示範】副本二魔王題 Big 2

副本七：領航員特訓

通過第九道館：實戰演練

通過第九道館後完成白段完課會議

經過了副本三的旅程，你應該已經找到一種「在思考上至少一直能抓到施力點」、讓一切設計「剛剛好」的感覺。

無論需求多複雜，你也習慣透過「有形的思路」，來促進設計。接下來就是開始應用所學挑戰白段的最終大魔王，加油，我會一直陪著你前進！

白段任務三

通過第八道館：實戰演練

速戰速決或實戰演練進行挑戰並通過第一道館

通過第一道館

你在這門課中踏出學習的第一步。

再接再厲挑戰第一道館吧，在第一道館你會開始應用副本一中學到的技巧，戴上 OOAD 的眼鏡。

加油，挑戰完第一道館吧！

新手任務二

完成新手任務一

通過第二道館：實戰演練

通過第三道館

通過第四道館

通過第五道館

戴上了 OOAD 眼鏡的你有感覺到自己變強了嗎？ 

你已經在這門課中踏出學習的第一步，和大多數工程師相較之下，你更有學習的衝勁和意願，加油，我也是這樣一路練上來的 💪🏻

接下來繼續成長，察覺 Forces 吧！

白段任務一

私訊分享影片心得

依序看完以下幾部影片：
1. 設計的關鍵是：把無形變有形
2. UML 不是拿來寫文件用的
3. 行雲流水的 OOA | OOD | OOP
4. 上這門課一定要有「空杯心態」
5. 軟體抽象之一：點的萃取
6. 練武 - 點的萃取

看完這些影片後，請至 Messenger 私訊和我分享一下你的心得

新手任務一

通過第六道館

通過第七道館

在副本二的旅程中對「怎麼抓 Force」和「怎麼有憑有據地套模式」，已經打好一層「基礎」了。接下來就要慢慢「增加專案的規模大小」，並開始學比較特別的行為型模式。

加油，繼續前進吧！

軟體設計模式道館

相關課程：

挑戰獎勵：