如何完善自己的設計模式 (Design Pattern)？ 設計模式系列文 (下)
前言
本系列文 (設計模式系列文)已經在上篇介紹了「什麼是設計模式？」，也在中篇介紹了「如何撰寫設計模式?」，本篇將要來談談真正在參與發表Pattern相關的論文的時候，有什麼技巧可以讓自己撰寫完的設計模式更為完善 (特別是針對審稿時需注意的事項)。
在完成設計模式撰寫後 (如經歷本系列文中篇所描述的設計模式撰寫流程)，很遺憾的是，此時完成的設計模式其實還算是初稿 (Draft)，而這份初稿需要透過自身反覆審查且最好有一個對設計模式描述架構有深入了解與研究的人來幫忙審稿，以確認你所產出的設計模式是足夠完備、解決方案 (Solution)可通用於所描述特定情境下所發生的問題 (Problem)、或可能因為情境 (Context)所涵蓋的範圍過大，以至於可以將模式拆成細分成更多子模式 (Subpattern)等等。
而上述設計模式作者與審稿人互相溝通的過程 (通常是指審稿人給修改建議，然後作者依循其建議修改 Pattern 的迭代過程)，稱之為 Shepherding (牧羊)。在 Shepherding 的過程，Pattern 作者的角色為 Sheep (羊)，而審稿人的角色為Shepherd (牧羊人)，整個過程就如同牧羊人在調教羊的過程。通常發表於 PLoP ( 對重要的Pattern 系列會議)的論文都要經過Shepherding的過程，然而，由於不同的 Shepherding 的過程的品質可能良莠不齊，於是 The Language of Shepherding 這篇文章就被發表來透過不同 Pattern 點出 Shepherding 的過程常見的問題，並給予解決這些問題一套遵循的模式，而這篇 Paper 也將成為參與 PLoP 系列會議的作者與審稿人必讀的聖經。該 Paper 中的 Pattern 分成兩個層面：(1) 針對 「 Shepherd 與 Sheep 的互動過程中常遇到的問題」；(2) 針對「 審稿時常見的問題」。而本文將透過介紹上述的第二層面中相關的 Pattern (並加入一些自己等經驗與看法)，來引導讀者精進與完善設計模式。
如何完善已完成的設計模式？
以下的Pattern是按照 Shepherding 過程 Sherpherd 審稿的順序整理，讀者在修改自己已初步完成的設計模式時，也可以對照下面列出的 Pattern。
註：以下模式皆源自 The Language of Shepherding
Big Picture
如何掌握設計模式的主旨？
設計模式的初稿通常都難以理解。而描述的太簡潔的往往缺乏實質的內容；相反的，而內容太龐大 (描述的多而深入) 往往因為太專注細節的描述而模糊的模式的核心概念。
Therefore：
Shepherd 在剛剛接觸設計模式的時候必須要先閱讀 Problem 與 Soultion 的部份來掌握該模式的大綱，這主要是因為 Sheep 通常最注重在解決方案的設計部份，並將所有對模式的想法，灌輸在 Solution 中。
Matching Problem and Solution
如何確定模式真的是模式的樣子 (pattern-ish)？
在撰寫模式的時候常常會先寫好 Solution (因為可能在不斷實作中領悟到通用的解決方法)，而後再去設計模式的問題，所以在審稿的時候，常常讀起來不清楚這個模式的真正目的是什麼。
Therefore：
審稿的時候要確認設計模式的 Solution 有完整的針對 Problem 解決，解決方案也不能超過 Problem 的範圍 (剛剛好就好，不能多餘)，之後在加強其中其中 (Problem 或 Solution)不足的部分。
Convincing Solution
如何提高設計模式的可信度 (believable)
有時候 Solution 提供的解決方案根本無濟於事，看起來沒有實現的能力。
Therefore：
一般的 Pattern 在看完 Solution通常要有 “原來可以這麼解決” 的感覺 (“Aha” effect)。如果沒有，則必須要提供真正實作應用的細節，才能更使人信服。
Forces Define Problem
如何更深層的了解問題？
很多設計模式的初稿，對於 Problem的敘述都很薄弱。
“If the solution is the heart of the pattern, the problem is its soul.”
Therefore：
需要透過 Force 來具體化對 Problem 的敘述。而作者需要以迭代的方式不斷修正與增強對 Force 與Problem 的敘述，透過列出具體化不同的 Force，尋找交集後，最後為其總結出核心問題 (Problem)。
Balanced Context
如何為 Pattern 劃定出合適的範圍？
在撰寫設計模式的 Context 的時候，常常不小心把情境的範圍界定的太大或太小，也往往忽略了界定該情境應用Pattern之後可能的結果。
Therefore：
在撰寫設計模式時，必須要具體思考並說明情境使用與不適用這個模式前後的差異，這樣不僅能夠賦予模式的使用者對模式應有的期望，也能幫助我們界定剛好符合所提出模式的範圍。
War Stories
如何推進模式前進？
有時不管如何 Sheep 如何修改或更正 Shepherd 的建議，Shepherd 還是覺得設計模式描述的不清楚、缺乏對該模式的實際應用想像。
Therefore：
這時 Shepherd 應要要求 Sheep 提供設計模式應用的真實案例，幫助對模式的想像更為生動實際。
Form Follows Function
如何將設計模式套用到一個新的格式 (form)？
有時 Sheep 所選擇的 Pattern 的格式，沒辦法完善表達 (或不適合)所提出的設計模式。這可能是因為 Sheep 對 Pattern 的格式並不熟悉 (可能只知道一、兩個)，或是因為要把格式整個換掉需要花費相當大的功夫，因此選擇不換。
Therefore：
Shepherd 需要一步一步的引導 Sheep 修改原本模式所應用的格式 (一次改一些就好)。而終極的目的是 “Making the form serve the pattern”。
Small Patterns
如何使設計模式變得更可消化 (digestible)
設計模式常常經由不斷的修正 (或是因為 Sheep不願意對已完成的內容做刪減)後，內容變得非常的龐大。
Therefore：
先放任內容增加，最後在做刪減。刪減可以透過移除不必要的區塊，或是將過於龐大的模式，拆分成多個小模式 (要做到一個模式只能有一個 Context, Problem 與 Solution)
結語
本文為設計模式系列文的最後一篇文章，主要透過藉由提供與介紹在 Pattern 相關會議中審稿時常見的問題，說明了「如何完善自己的設計模式？」。回想一開始寫這個系列文的動機是希望能夠將在碩士班時期，對設計模式的研究經驗，分享給更多鑽研軟體工程領域的人，利用設計模式的思考邏輯，幫助在設計開發軟體系統或是面臨相關軟體問題時，提升設計品質與縮短開發設計的時間。而回溯設計模式的發展史，可以察覺其實設計模式這套思維最早應用在建築界，才警覺這個系列文的目標受眾應是針對不同領域的讀者。因此，在撰寫本系列文時，去除了軟體工程的成分，希望能引導更多不同領域的讀者了解設計模式的精髓，並將設計模式應用於解決各領域或日常生活的問題。
