軟件設(shè)計(jì)模式之我見

孟令帥+李晉

摘 要：軟件設(shè)計(jì)模式就是Uml統(tǒng)一建模語言的技巧性概念，其主要研究各個(gè)類模塊和接口之間的安排與搭配，也是為程序員提供交流的一個(gè)很好的平臺。利用軟件設(shè)計(jì)模式可以做出質(zhì)量更高，代碼更少，擴(kuò)充更容易的軟件。它更像是一個(gè)工具箱，可以生產(chǎn)出更漂亮、更簡潔的代碼。

關(guān)鍵字：軟件設(shè)計(jì);設(shè)計(jì)模式;建模語言

中圖分類號：TB472 文獻(xiàn)標(biāo)識碼：A

軟件設(shè)計(jì)模式（Design pattern）是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。使用設(shè)計(jì)模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。軟件設(shè)計(jì)模式主要分為創(chuàng)建型模式、結(jié)構(gòu)型模式、行為型模式三種，其中創(chuàng)建型模式用來處理對象的創(chuàng)建過程，結(jié)構(gòu)型模式用來處理類或?qū)ο蟮慕M合，行為型模式用來對類或?qū)ο笤鯓咏换ズ驮鯓臃峙渎氊?zé)進(jìn)行描述。

1、設(shè)備軟件系統(tǒng)的特點(diǎn)

為增加新的處理新工藝變化而需要的功能，我們會修改設(shè)備軟件的主程序或部分組件源代碼，這樣不僅修改代碼量比較大，延誤了軟件更新的及時(shí)性要求，而且降低了原軟件系統(tǒng)的可靠性，為設(shè)備的使用留下隱患;對于為修改工藝方法發(fā)生的軟件系統(tǒng)的改動，則對應(yīng)的設(shè)備軟件的主程序修要修改的部分大大增加，甚至更改程序的主框架，使程序不易擴(kuò)展，造成程序的可移植性大大的降低，不利于系統(tǒng)的升級，增加維護(hù)成本，因此，我們引入了設(shè)計(jì)模式的概念。

2、設(shè)計(jì)模式的分類

2.1創(chuàng)建型模式

創(chuàng)建型模式用來處理對象的創(chuàng)建過程，主要包含以下5種設(shè)計(jì)模式：抽象工廠模式（Abstract Factory）、生成器模式 （Builder）、工廠方法模式（Factory Methord） 、原型模式 （Prototype） 、單例模式（Singleton）。Abstract Factory是應(yīng)對一系列對象的創(chuàng)建的問題，正如前面文章中舉的例子，對于創(chuàng)建一個(gè)汽車對象來說，Abstract Factory模式更關(guān)注一系列的對象的創(chuàng)建，或者說是汽車類型中的各個(gè)部分，如：Wheel、Engine、Body等等類型的創(chuàng)建。換句話說關(guān)注點(diǎn)在這一系列對象上。Builder是應(yīng)對一個(gè)復(fù)雜對象創(chuàng)建的問題，或者說是針對這個(gè)復(fù)雜對象中的子對象的創(chuàng)建的問題。以汽車的例子來說，我覺得比起Abstract Factory模式，Builder模式相對注重汽車類型（上面所說的“復(fù)雜對象”）本身以及其各個(gè)部分（Wheel、Engine、Body等等）類型的創(chuàng)建。Builder模式要求這個(gè)復(fù)雜的類型（汽車）中的各個(gè)子類型的結(jié)合部分相對穩(wěn)定，用例子說明就是對于汽車來說，無論用什么配件組裝，個(gè)個(gè)配件的組裝方式都一樣，有相對穩(wěn)定的接口。對于這輛車你用什么牌子的Wheel、什么牌子的Engine可能變化會很大很頻繁。

2.2行為型設(shè)計(jì)模式

行為型模式用來對類或?qū)ο笤鯓咏换ズ驮鯓臃峙渎氊?zé)進(jìn)行描述，主要包含11種設(shè)計(jì)模式。允許多個(gè)類處理同一個(gè)請求，而不必了解彼此的功能。他在類之間提供一個(gè)松散的耦合。類之間唯一的聯(lián)系就是相互之間的傳遞請求。請求在類之間傳遞，直到其中一個(gè)類處理它為止。當(dāng)一個(gè)對象向多個(gè)對象發(fā)送相同的信息時(shí)，就需要一種策略來確定由哪個(gè)對象對所發(fā)送的信息進(jìn)行處理，而這樣的處理對象也只能有一個(gè)。使用case語句或if語句的方法會給程序的維護(hù)帶來很大難度，這就需要職責(zé)鏈模式來完成。職責(zé)鏈模式將發(fā)送對象和接收對象進(jìn)行了解耦，以更好的應(yīng)對變化。職責(zé)鏈模式將接收對象形成一個(gè)鏈，發(fā)送對象將信息發(fā)送給接收對象鏈中的一個(gè)對象，這時(shí)，信息就沿著對象鏈向下傳送，直到有一個(gè)對象對信息進(jìn)行處理。

2.3結(jié)構(gòu)型模式

結(jié)構(gòu)型設(shè)計(jì)模式是從程序的結(jié)構(gòu)上解決模塊之間的耦合問題。包括以下七種模式：Adapte適配器模式：Adapter模式通過類的繼承或者對象的組合側(cè)重于轉(zhuǎn)換已有的接口，類適配器采用“多繼承”的實(shí)現(xiàn)方式，帶來了不良的高耦合，所以一般不推薦使用。對象適配器采用“對象組合”的方式，更符合松耦合精神。Bridge橋接模式：將抽象部分與實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立的變化。減少因變化帶來的代碼的修改量。Composite組合模式：將對象組合成樹形結(jié)構(gòu)以表示“部分-整體”的層次結(jié)構(gòu)。Composite模式使得客戶對單個(gè)對象和組合對象的使用具有一致性。從而解決了解決客戶程序與復(fù)雜對象容器的解耦，即：通過繼承統(tǒng)一的接口，我們可以將容器對象及其子對象看成同一類對象使用，以減少對象使用中的復(fù)雜度。Decorator裝飾模式：動態(tài)地給一個(gè)對象添加一些額外的職責(zé)。就增加功能來說，Decorator模式相比生成子類更為靈活。Decorator模式采用對象組合而非繼承的手法，實(shí)現(xiàn)了在運(yùn)行時(shí)動態(tài)的擴(kuò)展對象功能的能力，而且可以根據(jù)需要擴(kuò)展多個(gè)功能，避免了單獨(dú)使用繼承帶來的“靈活性差”和“多子類衍生問題”。同時(shí)它很好地符合面向?qū)ο笤O(shè)計(jì)原則中“優(yōu)先使用對象組合而非繼承”和“開放-封閉”原則。Facade外觀模式：為子系統(tǒng)中的一組接口提供一個(gè)一致的界面，簡化接口。Flyweight享元模式：運(yùn)用共享技術(shù)有效地支持大量細(xì)粒度的對象。面向?qū)ο蟮乃枷牒芎玫亟鉀Q了抽象性的問題，一般也不會出現(xiàn)性能上的問題。但是在某些情況下，對象的數(shù)量可能會太多，從而導(dǎo)致了運(yùn)行時(shí)的代價(jià)。那么我們?nèi)绾稳ケ苊獯罅考?xì)粒度的對象，同時(shí)又不影響客戶程序使用面向?qū)ο蟮姆绞竭M(jìn)行操作。Proxy代理模式：為其他對象提供一種代理以控制這個(gè)對象的訪問。解決直接訪問某些對象是出現(xiàn)的問題。從代碼的角度看Adapter適配器模式和Proxy代理模式有些類似，前者是解決現(xiàn)有對象在新的環(huán)境中所遇到的問題，后者是解決直接訪問對象時(shí)出現(xiàn)的問題，這兩種模式從使用角度看都是解決直接訪問對象時(shí)出現(xiàn)的問題，只是含義不十分相同。

3、結(jié)束語

通過對設(shè)計(jì)模式的研究，我們的軟件研發(fā)人員不僅能設(shè)計(jì)出滿足客戶需求并且靈活、易擴(kuò)展、復(fù)用性強(qiáng)的軟件系統(tǒng)，同時(shí)還能使我們的設(shè)計(jì)者深入了解面向?qū)ο蟮木幊趟枷耄岣弑旧淼囊曇凹皩?shí)際研發(fā)水平。

參考文獻(xiàn)：

[1]張海攀.信息系統(tǒng)軟件體系結(jié)構(gòu)設(shè)計(jì)研究[N].電腦報(bào)，2014

[2]丁黎明. 構(gòu)件技術(shù)的中間件開發(fā)研究[J].企業(yè)文化，2014