l

2014年3月26日 星期三

Top-down和Bottom-up設計方法

Mar. 12 08:40~10:10

image


Top-down(由上而下)和Bottom-up(由下而上)是兩種設計與解決問題的技巧。前者對問題先有一個整體的概念,然後再逐步加上設計細節,最後讓整體的輪廓越來越清楚。後者則是先將解決問題可能所需的基本元件、方案給準備好,然後再將這些基本元件組合起來,由小而大最後得到整體。

「由上而下」或「由下而上」這兩種解題方法,有時個別套用便可解決問題,有時則是在思考模式採取「由上而下」,把問題先分析、拆解之後,再採取「由下而上」的方式完成整體實作。

這兩個概念,其實很簡單,資訊相關科系大學生在學習程式設計的時候應該都會學到,沒什麼大不了的。但是其實案情並沒有那麼單純。Teddy在〈如何選擇第一個Pattern來設計軟體架構?〉提到:

Alexander說,套用pattern形成pattern language的精神是一種「整體先於部分,然後透過差異化的過程將整體逐步展開」

Alexander的pattern language設計方法就是一種「由上而下」的設計方法?鄉民們可能會想:「由上而下就由上而下,那又怎麼樣?」接下來看一下GoF Design Patterns的設計方法。Erich Gamma(GoF的第一作者)在一次訪問中提到

Alexander had a very ambitious goal which was to create architectures that improve the quality of life. To achieve this Alexander developed a pattern language. This is a set of patterns that build on each other. A pattern language guides a designer's application of individual patterns to the entire design. When we started design patterns we were not that ambitious. We used a more bottom-up approach based on micro-architectures.

以上這段英文請鄉民們花點時間稍微讀一下(保持原汁原味就不解釋了),接下來還有一段:

Rather than coming up with a set of interwoven patterns top-down, micro-architectures are more independent patterns that eventually relate to each other bottom-up. A pattern language guides you through the whole design, whereas we have these little pieces, bites of engineering knowledge. I confess that this is less ambitious, but still very important and useful. (註:micro-architectures就是design patterns)

***

讀完這兩段英文句子之後,先有一個概念:

Alexander的Pattern/Pattern Language設計方法是一種由上而下的方法,而GoF Design Pattern是一種由下而上的方法。

鄉民甲:那又怎樣啦?!疑惑

Alexander認為,如果要完成一個「整體性的設計」,無法經由「由下而上」的組合過程來達到。因為如果沒有先具備「整體」的概念,則「由下而上」的過程最後組裝出來的產品或是設計很可能會「長歪掉」。例如,你想要製造一朵真花,你必須從種子開始培育(由上而下)。如果將花瓣、花蕊、花粉、花蜜等採用由下而上的方式組合起來,你只能得到一朵「人造花」。

在上面第一段英文句子裡面,Gamma說:「Alexander had a very ambitious goal which was to create architectures that improve the quality of life.」Alexander的想法是希望設計可以達到Quality Without A Name的境界,從而改善人類的生活。因此Gamma說Alexander對於「設計」有一個雄心壯志的目標。

GoF Design Pattern則沒有那麼遠大的目標,主要的用途就是解決比較小的設計問題。至於採用「由下而上」的方式套用了一堆Design Pattern之後所形成的「整體」長得如何,是否「完整」,則不是Design Pattern所能或所想要解決的問題。這也是為什麼很多人,尤其是初學者,套用了一堆Design Pattern之後,雖然解決了一些特定的設計問題,但從軟體架構整體來看,設計的品質還有很大的改善空間。

***

鄉民甲:所以Teddy你的意思是說GoF Design Pattern比較不好?

達摩大師:無所謂好壞,端看造化而定。

Gamma自己評論說道:「I confess that this is less ambitious, but still very important and useful.」雖然GoF Design Pattern不像Alexander的Pattern Language有那麼大的企圖心,但還是很重要且有用的方法。

鄉民甲:Teddy,你搞得我頭好痛啊疑惑

GoF Design Pattern出版至今已快20年了,當初剛出版的時候軟體領域的Pattern被整理出來的還不夠多,無法形成一個「生態系」。所以學習個別Pattern就好像是在「背單字」,至於可以用這些單字來組成何種概念,就只能「兄弟登山,各自努力」,交由個別程式開發人員自己去創造、發現。有些人成功,可以用GoF Design Pattern做出很棒的設計,有些人比較不成功,GoF Design Pattern搞了很久,系統的軟體架構還是長得像「違章建築一樣」。

這20年來,軟體領域的Pattern越來越多,從分析、架構、設計、實作、測試、流程、介面設計等,各種尺度的Pattern已經很完備了。把這「一拖拉庫」的Pattern全部視為一個整體然後由上而下,一個Pattern一個Pattern套用,就很接近Alexander的Pattern Language的境界。也就是說,在設計軟體架構的時候,可以靈活採用「由上而下」、「由下而上」,或是兩者合用的策略。

***

GoF Design Pattern用了一陣子但是對於設計軟體架構還是覺得力不從心?此為正常現象,因為「Design Pattern就是只是Design Pattern,只解決較小尺度的軟體設計問題,並不是Architecture Pattern」。當「由下而上」的方法卡住時,可以考慮先跳到「半空中」,採取「由上而下」的角度來看問題,說不定卡住的地方一下子就豁然開朗。

***

友藏內心獨白:我還是不明白啊…Orz。

4 則留言:

  1. 不好意思,有一個小建議,就是引用的文字可以不要用斜體的,看起來比較舒服。可以使用類似這樣的:http://css-tricks.com/examples/Blockquotes/

    回覆刪除
  2. 您的建議非常好,因為我寫 blog 是使用 Windows Live Writer,我沒特別研究怎麼在 blog 裡面去設定不同段落的顯示方式,所以就直接用最簡單的方式來撰寫。傷到各位鄉民們的眼睛還請見諒.....Orz(我已經取消斜體字了)。

    回覆刪除
  3. 我個人經驗是這樣.
    1. 跨系統架構,著重各系統間的合作與整合,這部分用上很多 Enterprise integration 的相關知識,但是主要處理的大多是系統間的介面、資料流、匹配性 (如 8x5 系統配 24x7 系統就不匹配),要用 service 還是 queue ,要怎麼 redo 這類。
    2. 系統內的設計,這部分會用上很多 design pattern,我通常會畫個大概,根據複雜度定個大概的策略,稍微設計一下就開工了,但是這部份很取決於團隊的成熟度,如果是好手很多,我會放手給第一線的成員做設計,如果菜鳥居多,我會設計的仔細一點,甚至寫好pseudo code,也會盯設計盯得緊一點。
    3. 實作面的設計,這部分屬於 clean code, api design , implementation pattern 和 refactor skill,和 coding guideline, naming convention 的範疇,其實做得好的人不多。
    另外我認為從上而下的設計,那必須從需求開始,系統要怎麼滿足使用者? 商業目的為何? 這些問題不談清楚,沒有辦法由上而下。
    一點淺見與同好分享。

    回覆刪除
  4. Why Patterns Keep Code Simple
    https://levelup.gitconnected.com/why-patterns-keep-code-simple-b2abece11a98

    回覆刪除