軟體設計美學之道第3回── 敷一下Pattern面膜，從頭開始美麗

一個好的軟體系統，除了必須符合使用者的需求之外，應該可以容易地再利用、維護及擴充。要達成這個目標，需要多少的設計思維及創意呢？若是符合這個目標的系統，一定充滿軟體美學的精神。

軟體設計其實是一種藝術，它不僅需要靈活的設計思維及技巧，還需要平衡專案的資源及使用者的期望，因此不管從工程面來看，還是從管理面來看，都是一種藝術。而要秉持軟體美學精神來開發軟體系統，其最深層的根基則必須要以「Pattern」來支撐。

相信有許多軟體開發人員會覺得：Pattern和自己開發的程式碼好像是兩回事一樣，不知如何理解及使用，更不會了解它和軟體架構、開發流程，乃至於整個開發專案的關係。美麗，應該從頭開始，開發一個好的軟體系統也是一樣，就讓我們從敷Pattern面膜開始。

我們先想像一個情境，假設你是一家比薩餐廳的大廚，現在有兩位客人向你點餐，第一個人說：「我要一份蝦仁搭配鳳梨、洋蔥的比薩，蝦仁要多一點，再加上一份灑上墨西哥辣椒、洋蔥、美式臘腸、義大利肉腸的比薩，不要太辣，外加一份法國香蒜麵包及2瓶350毫升的百事可樂」。第二個人則說：「鮮蝦鳳梨及哈辣墨西哥比薩各一份，外加一份香蒜麵包及2瓶小瓶的百事」。

如果你是大廚，你會比較希望聽到哪一種點餐方式？除此，這兩個人的點餐方式有什麼差別呢？其中最大的差別就在於第二個人使用了大家都了解的餐點名稱，大大地簡化了點餐所使用的語句，而且所表達的意思和第一個人所要的差不多。如此身為大廚的你不僅容易理解顧客所點的餐點，也容易記憶他要的東西，並且節省了彼此溝通的時間。相較之下，你聽到第一種點餐方式是不是很想把他轟出餐廳呢？

Pattern的溝通力量
我們再來看看物件導向的程式設計。一個設計老手一定熟悉許多物件導向的基本原理及設計原則，當他在解決一些設計問題時，會很自然地運用這些技巧及經驗，設計出解決各式難題的藍圖。

假設你就是這位設計老手，而你剛好要跟伙伴說明這個絕妙的設計。你可能會說：「我先建立一個super abstract class及兩個繼承於它的sub-class，並在其中一個sub-class中建立一個往super abstract class方向的association以便形成container功能，這樣就可以先完成一個遞迴的類別結構，然後在那container class實作一個final的method，用來固定的呼叫super abstract class所定義的抽象方法，這樣在未來繼承於此container class的類別階層的所有物件，都可以動態地被加入到執行時期物件模型的遞迴結構，透過分別修飾原有功能來增加新功能」，不知道說到這裡，有幾個人聽得懂的呢？

或許你可以用更簡潔的方式來表達，你可以說：「在這個部份的設計，我要建立一個Decorator Pattern」。一句再簡單不過的話，就足以表達上述那段又臭又長的演講，甚至所傳達的意思還更為清楚。這就是「共用詞彙」的力量，也是「溝通」的力量。

在前一篇「感受美麗的元素，設計思維」中有提到，大部分的軟體開發都是團隊合作，要讓大家了解自己偉大的設計，光用言語及UML來表達可能不夠，還必須注意傳達設計思維的問題。由於每一個Pattern的設計都是基於物件導向精神及原則，在應用上來看，它們保證了軟體某個程度的彈性及穩定，除此之外，「溝通」則是另一項非常重要但卻比較少人體認到的功用。從Pattern的定義來看：「一種在某個特定情境下，為了解決某種問題的解決方案。」因此，還要再加上某個特定「名稱」，才能算是個Pattern，才能和別人溝通。

3類常見的Pattern
Pattern有很多種類，只要符合定義的都可以稱做Pattern，但我們先把Pattern簡單的分為三種常見的種類，分別是「Architectural Pattern」、「Platform Pattern」及「Design Pattern」，代表三種不同層次的應用，因為每個層次都有各自不同的問題。

Architectural Pattern針對的是軟體架構，如Pipes、Broker、MVC等等。

Platform Pattern針對的是某個特定的發展平臺，例如J2EE Pattern。

而Design Pattern就是大家比較耳熟能詳的，例如四人幫（Gang of Four，簡稱GoF，這四個人分別是Gamma、Johnson、Helm、Vlissides）的聖經級著作《Design Patterns: Elements of Reusable Object-Oriented Software》一書中，所探討的是針對一般化的問題，而不是特定領域的問題。每個領域的Pattern幾乎都可以看到Design Pattern的影子，因為它提供了最基礎而穩固的設計元素。

看到這裡也許有人會說，有那麼多開放原始碼軟體可用，為何還要用Pattern呢？這其實也是個事實，我們常常尋找好用的開放原始碼Framework作為開發系統的骨幹，例如，Struts、Spring、Hibernate等等，通常我們只要加上一些客戶需求的程式碼，拼湊一番，就可以上線了，似乎用不上Pattern。但是，除了要注意開放原始碼的授權種類之外，還要注意那些Framework，是否有助於我們讓自己的程式碼容易地維護、再利用及擴充？是否有助於我們去「溝通」？再者，這些著名的Framework都是使用Pattern來設計的最佳範例，因此理解Pattern對於了解Framework的精髓，及如何整合入自己的系統，有很大的幫助，才不會誤解Framework的整合方法而張冠李戴，這就是使用Pattern的最好時機及理由。

必學23個Design Pattern
初學Pattern的人一定會覺得Design Pattern很難放到自己的設計上，這個因擾大部分來自於所學的Design Pattern太少，只學習了幾個Pattern就急於使用，就很容易會為了使用Pattern而強用Pattern，反而是化簡為繁。因此，首先要盡量讓自己對於Pattern有多一點的理解。我認為GoF所歸納出來的23個Pattern，是你該理解的最基本數量，這麼說並不代表在設計軟體中就應該全數用上，重點是當你理解那23個Pattern後，對物件導向會更有感覺，所累積的原力會讓你較容易地「感覺」出，應該使用哪些Pattern。其實在做程式碼的Refactorying時，是最好的練習時機，因為你可以從現有程式碼，慢慢修改到某個Pattern的形式，要記住的是，Pattern只是心法，如何變化出招式是靠你的美感，實際的設計是沒有必要和Pattern所定義的形式完全相同的。

《作者簡介》葉政達
艾群科技研發中心技術經理，中原大學電子工程研究所碩士。
曾任職於網際商擎科技、台聯電訊研發工程師等職，專精於OOAD、軟體架構設計、Pattern、J2EE、J2SE、行動運算應用；通過SCEA、SCWCD、SCJP等認證。曾參與電子商務系統、航空即時訂票系統、SNMP網路管理產品開發、亞太電信QMA Image Solution、Sandio Mobile Sync產品設計開發等專案規畫建置。