撰寫軟體模式

模式與食譜

一種流行且非常有效的技術寫作形式是食譜風格（例如 Perl 食譜、Rails 食譜）。食譜和模式書籍之間有許多相似之處。兩者都強調問題解決風格。

我認為兩者之間的重大差異在於建立詞彙的概念。食譜往往更具體，通常與特定的程式語言和平台相關。即使模式與平台相關，它們也會嘗試描述更通用的概念。

因此，與模式中的解決方案重點相比，食譜具有更強的問題重點。

雖然我的寫作興趣在於模式，這反映了我對一般設計原則的興趣，而不是對這兩種風格相對實用性的判斷。兩者都基於同一個基本原因而有效 - 它們根據某人今天想要完成的具體事物進行區塊化。因此，我發現兩者都非常有效。您也可以從中學習偉大的原則，但讓您進入正題的是對特定問題的解答。

模式是解決方案

幾乎所有關於模式的文章都有這樣的定義：「模式是對問題的解決方案」。儘管我並不反對這句話，但我認為它確實傾向於低估模式主要關於解決方案這一點。

我認為有必要說這一點，因為有一種神秘感往往會困擾模式。為了消除這種神秘感，我們永遠不要忘記編寫模式的全部目的是描述一個重複且有用的解決方案。成功就是以一種方式做到這一點，讓其他人可以在適當時複製該解決方案。其他一切都次要 - 這意味著無論我們選擇如何編寫模式，我們採取什麼形式 - 都必須支持這一點。我經常看到模式作者（包括我自己）迷失在特定的格式中，而忽略了這個簡單的優先事項。因此，每當寫作變得困難時，請記住重要的是解決方案。

而問題是什麼？嗯，任何解決方案都是對應問題的解決方案。沒有對應的問題，怎麼會有解決方案？了解問題（或問題，一個模式可以解決多個問題）是了解解決方案的關鍵部分。思考問題有助於你專注於「解決方案的核心」。它也有助於我們避免陷入過於工具導向的討論。因此，了解問題很重要——的確至關重要。但解決方案應仍然是模式的重點。

一個令人回味的稱呼

模式工作的有價值特徵之一是它發展出一套詞彙，讓我們可以用它來討論如何做事。透過命名重複出現的解決方案，我們可以逐漸建立一套軟體設計詞彙，超越我們通常奮戰的技術慣例問題。當我知道 Java 的監聽器和 .NET 的委派是實作觀察者模式的一種方式時，我更了解它們。名稱「觀察者」為我提供了一個切入點，讓我得以了解新的技術概念——這些概念在不同的技術中通常有不同的名稱。

選擇好的名稱很困難，我發現我甚至在接近截止期限時，也不斷地調整名稱。由於它們將成為一種詞彙，因此值得投入大量精力來取得好的名稱。想想那位滿臉皺紋的老將需要說什麼。

因此，名稱應簡短，但當然很難想出簡潔的名稱。我的名稱往往是兩個或三個字——因為我覺得大多數好的單字名稱都被取走了。

如果我看到模式是做某事的替代方式，那麼我喜歡使用不同的形容詞來修飾一個普通名詞。因此，頁面控制器和前端控制器是控制器的兩種不同形式。嚴格來說，它們是 P of EAA 中輸入控制器的形式，但我只有在真的必須時才使用三個字（就像我對單一表格繼承及其替代方案所做的那樣）。

我喜歡讓我的模式名稱成為名詞片語。模式有價值的品質之一是它們創造出一套詞彙，而使用名詞可以更容易做到這一點。動詞需要更多的語法變化才能將它們融入散文，這使得難以一致地使用名稱。我想像一位飽經風霜的老開發人員告訴她的同事：「你必須在這裡使用一個<模式名稱>」。

為什麼以及如何

當我們談論解決方案時，很容易專注於解決方案本身以及如何應用解決方案。較難談論解決方案何時適當，以及哪些條件適合或不適合它。這就是模式撰寫者強調問題的原因，因為那會讓我們的思緒集中在模式的觸發因素上。這也是模式撰寫者談論力量的原因，因為力量是一種探索模式的適應症和禁忌症的方法。

每當我認為自己有一個模式時，我都會試著思考什麼時候不會使用該模式。這常常會引導我找到替代模式，這就是為什麼我的模式通常會以替代模式群組的形式出現。

我特別懷疑只描述一組替代方案的完整模式語言。P of EAA 的觸發因素之一是我對那些談論用於 J2EE 的單一架構的人感到厭煩。軟體系統，即使是在企業應用程式等特定領域中，也存在於一個多元的世界。有很多種做事的方法，而且在某些特定情況下，其中大多數方法都是正確的。因此，每當你認為「你永遠不應該那樣做」時，請仔細思考。可能會有這樣的時候，而這不僅會引導你找到另一個模式——它還有助於你更好地理解你的主要模式。

程式碼範例

許多人擔心模式中的範例，尤其是程式碼範例。畢竟，模式是關於解決方案中深層的相似性，而這些相似性在我們每次使用時看起來都不同。有些讀者會將範例當成模式，將模式視為美化的巨集，這確實令人擔心。

在我看來，許多人透過範例能更了解事物。當給予一個範例時，他們就能開始抽象出一般原則。這當然是我運作的方式。因此，我寧願提供一個範例，冒著缺乏抽象化的風險，也不願避免範例而讓讀者完全迷失在抽象化中。

如果你非常擔心對某個模式的特定詮釋，那麼一個有用的方法是使用多個範例。同一個模式的不同範例有助於說明共同的主題。不同的範例可能是使用相同平台的不同方法，或使用不同的平台。

當然，有些人不會看程式碼範例，因為任何程式碼範例都包含許多細節。因此，我試著讓我的程式碼範例可跳過，我的意思是，我撰寫模式時，即使沒有程式碼範例也能理解。程式碼範例只是額外的內容。

在撰寫程式碼範例時，在複雜度上會有一種緊張感。如果我讓它太簡單，人們可能會認為它不切實際，但如果我讓它太複雜，人們必須了解許多與模式無關的東西才能理解模式。如果夠複雜，我們就會達到 Micheal Feathers 所說的 MEGO 點（「我的眼睛都花了」），而我完全失去了他們。我寧願犯太簡單的錯誤。如果我弄清楚了簡單的東西，那麼我（或其他人）稍後可以加入更多複雜的東西，並與模式之間的互動。我寧願人們理解一點，也不願無法理解很多。這種渴望受到模式分塊的加強，讀者只需要閱讀一個模式就能理解該模式。

亞歷山大形式

許多人將 Christopher Alexander 的 A Pattern Language (APL) 視為模式世界中的重要影響。Alexander 寫作建築，並對一些軟體模式的早期倡導者產生了很大的影響。他以一種特定的形式撰寫了他的模式書，在軟體模式世界中稱為 Alexandrian 形式。除了他書中的模式之外，你還可以在 Domain-Driven Design 中找到此形式的良好範例。在網路上，一個很好的範例是 Josh Kerievsky 的 Knowledge Hydrant 模式。

就像許多標準形式一樣，我們實際上看到 Alexandrian 形式在實務中有相當大的變化。我將透過引用 APL 中對此形式的描述來描述它

為方便和清楚起見，每個模式都有相同的格式。首先，有一張圖片，顯示該模式的典型範例。其次，在圖片之後，每個模式都有引言段落，說明模式的背景，解釋它如何幫助完成某些更大的模式。然後有三個菱形標記問題的開頭。菱形之後是一個標題，以粗體顯示。此標題用一或兩句話說明問題的本質。標題之後是問題的主體。這是最長的部分。它描述了模式的經驗背景、其有效性的證據、模式可以在建築物中體現的不同方式的範圍，等等。然後，再次以粗體顯示，就像標題一樣，是解決方案——模式的核心——它描述了解決所述問題所需的物理和社會關係領域，在所述背景中。此解決方案總是採用指令的形式陳述——這樣您就可以確切地知道需要做什麼來建立模式。然後，在解決方案之後，有一個帶標籤的圖表，以指示其主要組成部分。

在圖表之後，另外三個菱形，表示模式的主體已完成。最後，在菱形之後，有一個段落將模式與語言中所有那些較小的模式聯繫起來，這些模式是完成此模式、修飾它、填滿它所必需的。

-- [alexander-apl]

APL 中的模式平均每頁半打。

亞歷山大形式是一種非常敘述性的形式，標題相對較少。因此，當您閱讀它時，它往往比大多數替代方案流暢。問題和解決方案的加粗總結句很突出，並且允許您非常快速地跳過大量模式。

在使用亞歷山大形式的軟體模式中，一個常見的變化（由 Big Ball of Mud 使用）是將主體，也就是問題的主體，分成兩部分。第一部分，在問題標題之後，擴充了問題及其周圍的問題。第二部分移到解決方案摘要之後，並描述解決方案的細節。

我聽過理查德·加百利批評這一點，理由是它迫使你重複許多關於替代方案和權衡的討論。我之前沒有想太多，但我發現我同意他的觀點。切斷主體會破壞模式的流暢性，並在你擔心問題是否應該在問題部分或解決方案部分討論時，讓它變得更加支離破碎。

大多數模式書籍將模式組織成相對獨立的部分，就像參考書一樣。 Evans 將模式嵌入到一般敘事書籍的流程中。亞歷山大形式幫助他做到這一點，因為模式的流動比結構更嚴謹的模式形式更具敘事性。

GOF 形式

GOF 形式是開創性的 四人幫 書中使用的形式，這本書真正將模式引入軟體世界。這是一個非常結構化的形式，將模式分成許多標題：意圖、動機、適用性、結構、參與者、協作、後果、實作、範例程式碼、已知用途和相關模式。GOF 模式相當大，每一個都有十幾頁。

波特蘭形式

波特蘭形式的名稱來自於波特蘭奧勒岡州的幾個人，在第一次模式會議上都使用了類似的形式。一個很好的線上範例是 [cunningham-checks]。

波特蘭形式完全是文字的，而且非常簡短，通常每一個模式不到一頁。幾段文字描述問題，然後是強調排版的「因此」一詞，接著是幾段描述解決方案的文字。

Coplien 形式

之所以這麼稱呼，是因為它最常與吉姆·科普林聯繫在一起，我也聽說它被稱為標準形式，儘管我不確定這些人指的是哪個標準。一個很好的線上範例是 [coplien-fault-patterns]。

我看到這個形式有很大的變化。關鍵元素是問題、背景、力量和解決方案的標題部分。大多數作者也會新增一些額外的部分。每個部分都是幾段文字，力量部分通常是項目符號清單。這種形式的模式通常相當簡短——幾頁。

POSA 形式

此表單的名稱源自 POSA 一書。與 GOF 類似，它是一個非常結構化且相當大的表單，儘管它們的標題不同：摘要、範例、背景、問題、解決方案、結構、動態、實作、已解決範例、變體、已知用途、後果，以及另請參閱。這些模式通常長度僅超過十幾頁。此表單的一個重要部分是，這些模式之前有一個敘述章節，用於總結模式並描述整體主題。

P of EAA 形式

我稱之為標準表單有點厚臉皮，因為除了我之外沒有人使用它。但我已經撰寫模式很長一段時間了，嘗試過各種不同的風格，而這是我最喜歡的。它相當敘述性，包含幾個部分：它的運作方式、何時使用它，以及一個或多個範例。長度平均約八頁，但從一頁到十幾頁不等。 這 是最近的一個範例。

將模式安排成結構

人們遇到的常見問題是如何建構他們正在撰寫的模式。模式鼓勵分塊，而且專注於這些塊很容易。但您如何將這些塊放入有意義的事物中？我看到許多人努力為模式集合建立整體結構。

我最大的建議是「別擔心它 - 我不擔心」。我比較喜歡專注於個別模式，描述我遇到的有趣解決方案。一旦我開始收集一組模式，我接著會思考它們應該如何建構，並尋找需要更多模式來涵蓋的明顯空白。

特別是，您不必花費大量時間嘗試在深入探討模式之前就建立一個整體結構。我發現，在我深入探討描述它們的細節之前，我並不太了解這些模式。

請記住，最後擁有許多組織不良的好模式比擁有結構良好但底層模式較弱的模式更有價值。

模式與模式語言

我常常對人們圍繞模式所召喚出的許多神秘感感到困擾。引起這種紛爭的常見領域之一是模式和模式語言的問題。這通常伴隨著「這不是模式語言，它只是模式目錄」的說法。

模式語言背後的想法再次來自 Alexander。這個想法是您擁有一組具有結構的模式，這些結構會引導您從一個模式到另一個模式。您通常從一些非常策略性的模式開始，每個模式都會引導您到一個點，您必須決定套用其他模式。模式語言具有連接各種模式的流程。

如果模式語言對您來說很容易，那就很好 - 但我不認為一本只是模式鬆散集合的書是一件壞事。我的書中肯定沒有任何一本是模式語言，GOF 也不例外。模式語言也很難撰寫 - 我看過人們試圖將它們組合在一起而陷入困境。請記住，模式的價值在於它們所說的內容的實用性，在這個意義上，我將模式語言視為一種建構機制 - 而相同的評論適用於我上面所說的。

（知識水龍頭 是模式語言的良好線上範例。）

模式的粒度

我擔心的最大問題之一，就是我的模式在概念上有多大。這不是指撰寫模式需要多少頁，而是模式涵蓋多少概念層面。

當你開始深入探討模式時，你會開始意識到，你經常可以在將兩個相關概念轉換為獨立模式，或將它們組合為單一模式的變體之間做出選擇。GOF 中的一個好例子是 Proxy 模式，它描述了四個變體（遠端代理、虛擬代理、保護代理和智慧指標）。你可以將它們寫成四個獨立模式，或寫成一個具有四個變體的模式，或寫成一個摘要模式，並為每個變體提供四個進一步的模式。

這個問題沒有簡單的答案，或者至少如果有的話，我很想了解答案是什麼。決定模式之間的界線在哪裡，是我最難以解決的問題之一。

我斷言的一件事是，如果你確實將它們拆分，就不要嘗試同時擁有整體模式。因此，當我研究用於對物件關係模式中的繼承進行對應的模式時，我為單一表格繼承、類別表格繼承和具體表格繼承選擇了不同的模式。我沒有嘗試擁有整體的「繼承對應」模式來將它們聯繫在一起。這確實意味著「何時」區段中會有一些重複，因為我必須在每種情況下討論這三者之間的權衡。我可以接受一些重複（只是不要剪貼文字，每次都用不同的方式撰寫）。在敘述中有一個聯繫在一起的部分，這是我風格中敘述目的的一部分。

具體說明

在模式審查中出現的一個常見問題是，為一個網域撰寫的模式似乎也適用於其他網域。Alice 撰寫了一個關於資料庫互動的模式，Bob 說類似的建議也適用於網路通訊，並建議讓模式更通用。

一般來說，我反對這種概括。關鍵問題在於作者的經驗。如果 Alice 了解資料庫，但不了解網路程式設計，那麼她寫的模式應該描述資料庫的情況。讀者可以考慮將其應用於他們的專業領域，但是否適用由讀者決定。讀者比作者更能做出這樣的判斷。

任務而非工具

軟體寫作最大的問題之一是專注於工具，而不是任務。以工具為導向的書籍說：「這裡有一個工具箱，我會說明如何使用每個工具」。以任務為導向的書籍說：「這裡有一堆你必須完成的任務，以下是執行方式（在此過程中向你展示工具）」。以工具為導向的書籍較容易撰寫，特別是軟體手冊，因為很容易查看架構（例如）並識別工具。

但以任務為導向的書籍好多了。人們不會拿著一本書說：「我如何使用這個小工具」，而是需要完成某項任務並試圖找出如何執行。使用工具書籍時，他們會花時間查看可能的工具，看看是否能提供幫助；這很好，但如果他們能直接找到任務，那就更好了。這就是食譜型書籍如此方便的原因 - 它們專注於任務。

模式總是面臨以工具為導向的危險 - 畢竟我們使用模式所做的，就是試圖識別概念性工具。因此，很容易最終將一本書變成以工具為導向的新命名工具指南。

這就是問題部分對模式的重要性。儘管我們最終會識別工具，但我們可以透過仔細思考每個模式（工具）解決的問題，來減輕以工具為導向的危險。我們可以自由地選擇模式邊界的形狀，事實上，這種自由正是模式寫作如此困難的原因。盡可能讓工作以任務為導向，有助於以有用的方式劃定這些界限。

這裡沒有新東西

人們常抱怨模式書籍，說它們對有經驗的開發人員來說沒有什麼新東西。這不僅是真的，而且也是模式的重點。

模式的存在是為了擷取領域知識，而不是提出原始想法。因此，模式書籍不可避免地不會為在某個領域工作一段時間的人們增加驚人的新想法。但即便如此，我認為模式書籍對那些不需要學習這些想法的人來說仍然扮演著重要的角色。這個角色是幫助有經驗的人將他們的經驗傳達給周圍經驗較少的人。很少有團隊完全由經驗豐富的開發人員組成。有經驗的領導者可以做到的最重要的事情之一，就是傳授她的技能。

因此，如果你正在評估你所專精領域中的一些模式，不要期望學到新事物。相反地，評估它們如何幫助你將你的知識傳達給其他人。透過自己使用它們並觀察它們是否能幫助人們掌握重要概念，來嘗試它們。

這也是為何模式書籍也應歷久彌新。即使我們的技術日新月異，許多軟體設計的基本原理並不會快速改變。因此，如果一本模式書籍較舊，請不要過於擔心。