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

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

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

副本零：冒險者指引

Showdown ! 撲克牌遊戲建模 ★

Uno Card ✭

處方診斷系統 ✭

資訊兵主控制器 ✭

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

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

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

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

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

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

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

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

UML 不是拿來寫文件用的

行雲流水的 OOA | OOD | OOP

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

OOA / OOD / OOP 概念複習題

軟體抽象之一：點的萃取

練武 - 點的萃取

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

軟體抽象之三：線的萃取

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

線上的點：關聯類別

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

Astah：類別圖教學

練武 - 單句分析 （初級）

練武 - 單句分析 （進階）

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

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

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

OOP 技法一：依賴

OOP 技法二：關聯

OOP 技法三：關聯類別

OOP 技法四：抽象類別

OOP 按圖施工規則（Java 版）

OOP 按圖施工規則（Python 版）

OOP 按圖施工規則（Golang 版）

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

實作交友配對系統 ★

RPG ✭

導航系統 ✭

策略模式——你的配對策略是什麼呢？
難度：★☆☆☆☆

你正在開發一個交友配對系統 (Matchmaking System)。

你手邊有一大群對象 (Individual) 資料，每一筆資料皆記載著以下欄位：

編號 (ID)：正整數 (>0)，每位對象的編號都不同。
性別 (Gender)：MALE 表示男生、FEMALE 表示女生
年紀 (Age)：正整數；至少 18 歲。
自我介紹 (Intro)：長度約 0~200 的文字。
興趣 (Habits)：可以為多個興趣，每個興趣以 1~10 長度的文字表示，每個興趣之間以一個逗號隔開。例如：打籃球, 煮菜, 玩遊戲
座標 (Coord)：以 (x, y) 表示該用戶所在的 x 軸和 y 軸的位置。

第二道館：Christopher Alexander 設計模式

2.2.H：【樣板挑戰】★★寫一個牌類遊戲框架！

樣板方法——寫一個牌類遊戲框架吧！
難度：★★☆☆☆

需求
你要實作以下兩款簡單的牌類遊戲，而你的任務是將程式中重複程式碼的部分減至越少越好。

第一款：簡易撲克牌比大小遊戲
- 這款遊戲能支援四位玩家：玩家可以為真實玩家 (Human Player) 也能為電腦玩家 (AI Player)。

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

2.3.H：【責任鏈挑戰】★ 碰撞偵測＆處理

責任鏈模式——碰撞偵測＆處理

難度：★☆☆☆☆

 你需要開發一個簡單的 DEMO 程式，程式的運作如下：
 程式開始時首先會準備好世界 (World)：
 這個世界是一維的 (長度為 30)。世界中存在著許多生命 (Sprite)，初始有 10 個生命，每個生命都會被隨機賦予一個初始的座標 (數值範圍 0~29；0 代表世界的最左側，29 代表世界的最右側）代表他的初始位置。

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

2.B 魔王題：★★大老二撲克牌遊戲！

魔王題：大老二撲克牌遊戲
難度：★★☆☆☆

魔王對冒險者們的喊話
各位冒險者們好！我們已經學會了三個設計模式了：策略模式 (Strategy Pattern)、樣板方法 (Template Method) 以及責任鍊模式 (Chain of responsibility Pattern)。

各位在這三個設計模式的挑戰題中，因為已經明確知道該任務的設計模式為何，因而可以很容易地知道要套什麼模式比較好。但是魔王題就不一樣了，你現在會收到一份莫名其妙的需求，然後你必須自己察覺需求中形成的 Forces，理性地在適合的地方套用設計模式。

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

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

各位冒險者，我們要正式進入副本二啦！

 >「一趟旅程之所以精彩，是因為它讓我們看見了不同的日落。」

歡迎來到這個副本，我們總算要好好認識一下何謂「軟體設計模式」了。

在軟體領域⋯⋯技術不斷更迭，工程師被迫不斷追求新的技術。在企業求職的紛擾下我們深怕自己不把技術學好就失去了競爭力，但同時也慢慢地忘了，其實在軟體領域中有一些「技能」是千古不變的——那正是「對軟體本質的掌握」，也低估了將這類「本質」技能精通之後對自己職涯的大量好處。

這項本質是什麼？那就是以下這個式子：

軟體設計模式理論：「因為釋放了 Forces，所以你重獲了生命力」

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

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

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

軟體設計模式觀念複習

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

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

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

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

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

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

練武 - 依賴反轉之重構三步驟

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

複習 - 策略模式

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

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

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

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

練武 - 萃取樣板

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

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

複習 - 樣板方法

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

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

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

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

樣板思維暖身帖

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

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

 走吧！

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

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

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

複習 - 責任鏈模式

萃取的標準流程：依賴反轉之重構三步驟
這篇文將會和各位詳細解釋，軟體設計學中最重要的一個步驟：「萃取 (Abstract)」。 各位成為軟體設計達人的第一個特訓就是讓大家了解「萃取的標準流程」。

各位冒險者必須熟悉他、刻意練習「如何萃取」，並且大量活用他。 在一定時間內，你就會發現：「自己的設計越來越精準，契合需求、不多、不少——剛剛好。」 在這之後，你會開始享受變強的感覺，並在旅程中的每一道挑戰題中，持續優化這項技能。

是的，萃取是非常重要的能力，而我為「萃取的標準流程」取了一個不錯聽的名字， 這個名字雖然有點長，但是是精闢的，可以幫助大家從名字中聯想到其他在軟體設計中也會提到的其他術語。

萃取的標準流程＝「依賴反轉之重構三步驟」

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

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

開閉原則 (Open-Closed Principle)

關鍵決策：到底哪裡需要遵守「開閉原則」？

策略 vs. 責任鏈 Forces 

練武 - 三種基礎行為 Forces

副本二：Christopher Alexander 設計模式

3.1.H：【觀察者挑戰】★ Youtube 訂閱機制

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

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

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

3.2.H：【指令詳解】★ 快捷鍵設置機制

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

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

3.3.H：【狀態挑戰】★★ 二維地圖冒險遊戲

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

難度：★★☆☆☆

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

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

3.B 魔王題：★★★ 真・RPG 之對戰遊戲

魔王題：真・RPG 之對戰遊戲

難度：★★★☆☆

魔王對冒險者們的喊話
對程式設計人員而言，開發這種 RPG 遊戲非常有挑戰性。因為 RPG 遊戲往往都必須建構出一個元素完整的世界，而世界的內容必須足夠豐富才能獲得玩家青睞，無論是 RPG 中玩家方的英雄主角或是戰鬥中可能面對的敵方對手，彼此擁有的行為或是戰鬥技能都大不相同，而且每個技能的效果還十分多變——你可能聽過⋯⋯治癒系技能？高傷害單體攻擊技？低傷害群體攻擊技？群體 DEBUFF 技能？犧牲輔助技？RPG 遊戲設計需求上的多變性使其程式設計十分有挑戰性，藉由優雅的程式設計來建構出一個豐富的 RPG 遊戲世界，正是學習軟體設計最大的愉悅。

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

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

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

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

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

複習 - 觀察者模式

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

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

複習 - 指令模式

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

 狀態模式——寶藏地圖

 難度：★★☆☆☆ 

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

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

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

複習 - 狀態模式

練武 - 所有行為模式 Forces

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

4.1.H：★★ 處方診斷系統

★★：門面模式——處方診斷系統

難度：★★☆☆☆

A. 需求

醫院正在開發一個「處方診斷系統」，英文稱之為 Prescriber System。但由於醫院的技術人員不足，因此請你負責設計和開發處方診斷系統中的核心模組。開發完畢之後，醫院中的所有技術人員會利用你的核心模組來客製化他們所需的處方診斷系統。你的核心模組必須支援以下需求。

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

4.2.H：★ 好友關係分析器

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

難度：★☆☆☆☆

A. 需求

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

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

4.3.H：★ 【延遲載入】員工資料表存取

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

難度：★☆☆☆☆

A. 需求

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

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

4.4.H：★★ 日誌框架

複合模式——日誌框

難度：★★☆☆☆

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

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

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

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

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

裝飾者模式——服務探索/負載平衡 (Service Discovery/ Load Balancing) 機制
難度：★☆☆☆☆

你要實作一個服務探索機制！在微服務 (Microservices) 時代興起之後，各式各樣的微服務設計模式也被提出，而服務探索機制 (Service Discovery) 就是其中的一部分。

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

4.B 魔王題：★★★★ 社群機器人引擎 | 有限狀態機框架

現在呀，冒險者，你終於來到了副本四的魔王題。

副本四的魔王題會要求不同面向上的深度能力。雖說設計模式能在設計上提供良好的指導，幫助我們理解分析和逐個擊破問題，不過有一項能力是必須上高強度鍛鍊後才能練就的，那就是「萃取能力」。

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

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

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

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

架構 - 分層及劃分邊界

複習 - 門面模式

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

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

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

架構 - 透過依賴反轉，做到單向依賴原則

複習 - 轉接器模式

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

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

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

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

複習 - 代理人模式

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

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

架構 - 複雜結構及變動性

練武 - 分層及劃分邊界

複習：複合模式

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

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

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

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

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

複習：裝飾者模式

練武 - 插件式架構

副本四：規模化架構思維

5.1.H：★ 單體模式——計算模型

★ 單體模式——計算模型

難度：★☆☆☆☆

A. 需求

- 你要開發一個「計算模型 (Computation Model)」套件，套件中提供三種模型，分別稱之為Reflection、Scaling、Shrinking，每一種計算能力不同。

- 所有模型皆提供同一種計算，這種計算被稱之為「線性轉換 (Linear Transformation)」。套件的使用者將會傳入大小為 1000 的浮點數陣列，或稱之為向量 (Vector)，模型對這個向量做某種線性轉換之後，會回傳一個新的，大小同樣為 1000 的浮點數陣列，也被稱之為線性轉換過後的向量。

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

5.2.H：★★ 工廠方法——基因演算法套件

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

難度：★★☆☆☆

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

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

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

5.3.H：★ 抽象工廠——ASCII 介面主題 (ASCII UI Theme)

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

難度：★☆☆☆☆

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

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

5.B 魔王題：★★★★ 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 的流程會比較長，會用十分循序漸進的方式帶你認識抽象工廠模式，請你將重點放在思路上。

那麼就來吧，上需求！

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

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

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

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

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

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

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