- 論壇徽章:
- 0
|
設(shè)計模式在架構(gòu)設(shè)計中的運(yùn)用
1 引言
架構(gòu)是一個軟件的骨架。為了應(yīng)對需求變更，架構(gòu)設(shè)計需要有足夠的彈性去適應(yīng)變化；架構(gòu)的任何修改都將導(dǎo)致大量代碼的重寫，從而導(dǎo)致成本上升、工期延長。而設(shè)計模式本來主要是針對編碼階段的，但在進(jìn)行架構(gòu)設(shè)計時，軟件架構(gòu)師可以將組件之間的關(guān)鍵接口通過“灰包圖”的形式———指定接口類所使用的設(shè)計模式———給程序員更多的指導(dǎo)；并且讓架構(gòu)更具彈性，更能適應(yīng)各種變化。
2 架構(gòu)設(shè)計與設(shè)計模式的關(guān)系
“設(shè)計模式”是Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides在《設(shè)計模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)》中提出來的。在此書中一共介紹了23種面向?qū)ο蟮脑O(shè)計模式；根據(jù)模式的應(yīng)用目的，又將它們分為3類：創(chuàng)建型、結(jié)構(gòu)型和行為型。而設(shè)計模式的作用則可以概括為四個字：“封裝變化”。“架構(gòu)”有很多種定義，《軟件架構(gòu)設(shè)計》一書對架構(gòu)的各種定義做了詳細(xì)的分析和總結(jié)；概括出架構(gòu)不外乎包含“組件”、“交互”和“決策”三個方面。其中決策的最主要目的是要保證架構(gòu)能適應(yīng)需求變更。因此，架構(gòu)設(shè)計就是：確定系統(tǒng)有哪些組件，它們之間有什么交互，以及未來可能發(fā)生什么變化；然后決定如何去應(yīng)對變化。也就是說，在架構(gòu)設(shè)計中最重要的事情就是要“隔離變化”。
所以，設(shè)計模式是架構(gòu)設(shè)計與編碼實(shí)現(xiàn)之間的一個橋梁。
3 變化的起源
要在架構(gòu)設(shè)計中正確運(yùn)用設(shè)計模式，首先要明白有哪些變化形式；然后再考慮選擇什么設(shè)計模式去應(yīng)對此變化。在《設(shè)計模式》一書中列舉了以下導(dǎo)致需要重新設(shè)計的因素：通過顯式地指定一個類
來創(chuàng)建對象；對特殊操作的依賴；對硬件和軟件平臺的依賴；對對象表示或?qū)崿F(xiàn)的依賴；算法依賴；緊耦合；通過生成子類來擴(kuò)充功能；不能方便地對類進(jìn)行修改。單純地列舉這些因素是不夠的，還要對變化形式進(jìn)行分類，以后才能正確地應(yīng)對變化。其實(shí)程序的功能，就是子系統(tǒng)對外交互的“接口”；概念，就是“抽象類”，這也是“接口”；編碼實(shí)現(xiàn)，則是具體的“代碼”。為了盡量重用已有代碼，或者預(yù)見到代碼將來會發(fā)生變化。這些變化，最終都可以看成是代碼庫的替換。所以，架構(gòu)設(shè)計要考慮的變化就是
“交互接口”和“編碼實(shí)現(xiàn)”的變化。
4 設(shè)計模式在架構(gòu)設(shè)計中的運(yùn)用
要讓設(shè)計的架構(gòu)能適應(yīng)變化，就是要預(yù)見組件之間的交互接口和編碼實(shí)現(xiàn)將來可能發(fā)生什么變化，并對此做出正確的決策：采用正確的設(shè)計模式去封裝變化。可以將交互接口或編碼實(shí)現(xiàn)前后的變化分為4大類。下面將分別給出有效的決策方案，即：指明了關(guān)鍵類設(shè)計模式的“灰包圖”。
4.1相似接口，相同功能
在做架構(gòu)設(shè)計時，根據(jù)需要設(shè)計出的接口可能與現(xiàn)有代碼不相同；或者想暫時使用第三方的SDK實(shí)現(xiàn)，將來可能會改為自己實(shí)現(xiàn)。為了重用代碼、隔離變化，可以運(yùn)用ADAPTER模式去匹配接口；將變化封裝在一個獨(dú)立的Component內(nèi)。將來就算第三方的SDK發(fā)生了變化或替換為自己的新代碼，我們都只需重寫Adapter類，影響范圍也僅限于Component。這種情景類似于通過USB轉(zhuǎn)換頭去匹配不同大小的USB接口。
4.2不同接口，相似功能
在做架構(gòu)設(shè)計時，很多軟件都要求支持跨平臺。雖然有可能各個開發(fā)平臺的已經(jīng)有相似的功能，但他們的工作方式和開發(fā)接口卻有可能完全不同；不能使用上述ADAPTER模式去解決。在這種情況下，可以按軟件本身的需求抽象出相關(guān)的功能接口（如IWindow、I3DWindow和IFaceWindow）；然后再使用BRIDGE模式充分重用平臺已有的功能，同時又做到了隔離變化，將平臺相關(guān)的代碼限制在單獨(dú)的一個Platform包中。
4.3增替“實(shí)現(xiàn)”
有時做架構(gòu)設(shè)計時，會預(yù)見到將來也許需要調(diào)整或增加某些功能。比如原來保存功能默認(rèn)是保存成純文本格式，將來可能要讓它支持保存成RTF、HTML等；或者字符串原來是用IDEA加密，將來要換成DES加密；等等。這種情景下，關(guān)鍵是要分離接口與實(shí)現(xiàn)；可以運(yùn)用STRATEGY模式解決。
4.4精簡接口
在做架構(gòu)設(shè)計時，有時也能預(yù)見到系統(tǒng)中對象的數(shù)目會不斷增加。那么兩兩之間的交互數(shù)就會急劇上升，彼此間的依賴關(guān)系也將變得非常復(fù)雜。為了限制或控制對象之間的交互，可以利用FACADE模式將相關(guān)的對象封裝成包、模塊或子系統(tǒng)，加大組件的粒度、降低耦合；從而增加架構(gòu)的靈活性，適應(yīng)變化。
5 總結(jié)
“完美之道，不在無可增加，而在無可刪減�！痹谧黾軜�(gòu)設(shè)計時，只要先將最核心和最必要的功能設(shè)計出來，然后再考慮如何提供增加功能和預(yù)防變化的機(jī)制，就能保證設(shè)計的穩(wěn)定。設(shè)計模式是最常用的封裝變化的方法，我們要善于運(yùn)用。 |
|
免費(fèi)注冊
發(fā)表于 2011-01-06 13:01
