軟件設計最大的敵人，就是應付需求不斷的變化。變化有時(shí)候是無(wú)窮盡的，于是項目開(kāi)發(fā)就在反復的修改、更新中無(wú)限期地延遲交付的日期。變化如懸在頭頂的達摩克斯之劍，令許多軟件工程專(zhuān)家一籌莫展。正如無(wú)法找到解決軟件開(kāi)發(fā)的“銀彈”，要徹底將變化扼殺在搖籃之中，看來(lái)也是不可能完成的任務(wù)。那么，積極地面對“變化”，方才是可取的態(tài)度。于是，極限編程（XP）的倡導者與布道者Kent Beck提出要“擁抱變化”，從軟件工程方法的角度，提出了應對“變化”的解決方案。而本文則試圖從軟件設計方法的角度，來(lái)探討如何在軟件設計過(guò)程中，解決未來(lái)可能的變化，其方法就是——封裝變化。
設計模式是“封裝變化”方法的最佳闡釋。無(wú)論是創(chuàng )建型模式、結構型模式還是行為型模式，歸根結底都是尋找軟件中可能存在的“變化”，然后利用抽象的方式對這些變化進(jìn)行封裝。由于抽象沒(méi)有具體的實(shí)現，就代表了一種無(wú)限的可能性，使得其擴展成為了可能。所以，我們在設計之初，除了要實(shí)現需求所設定的用例之外，還需要標定可能或已經(jīng)存在的“變化”之處。封裝變化，最重要的一點(diǎn)就是發(fā)現變化，或者說(shuō)是尋找變化。
GOF對設計模式的分類(lèi)，已經(jīng)彰顯了“封裝變化”的內涵與精髓。創(chuàng )建型模式的目的就是封裝對象創(chuàng )建的變化。例如Factory Method模式和Abstract Factory模式，建立了專(zhuān)門(mén)的抽象的工廠(chǎng)類(lèi)，以此來(lái)封裝未來(lái)對象的創(chuàng )建所引起的可能變化。而B(niǎo)uilder模式則是對對象內部的創(chuàng )建進(jìn)行封裝，由于細節對抽象的可替換性，使得將來(lái)面對對象內部創(chuàng )建方式的變化，可以靈活的進(jìn)行擴展或替換。
至于結構型模式，它關(guān)注的是對象之間組合的方式。本質(zhì)上說(shuō)，如果對象結構可能存在變化，主要在于其依賴(lài)關(guān)系的改變。當然對于結構型模式來(lái)說(shuō)，處理變化的方式不僅僅是封裝與抽象那么簡(jiǎn)單，還要合理地利用繼承與聚合的方法，靈活地表達對象之間的依賴(lài)關(guān)系。例如Decorator模式，描述的就是對象間可能存在的多種組合方式，這種組合方式是一種裝飾者與被裝飾者之間的關(guān)系，因此封裝這種組合方式，抽象出專(zhuān)門(mén)的裝飾對象顯然正是“封裝變化”的體現。同樣地，Bridge模式封裝的則是對象實(shí)現的依賴(lài)關(guān)系，而Composite模式所要解決的則是對象間存在的遞歸關(guān)系。
行為型模式關(guān)注的是對象的行為。行為型模式需要做的是對變化的行為進(jìn)行抽象，通過(guò)封裝以達到整個(gè)架構的可擴展性。例如策略模式，就是將可能存在變化的策略或算法抽象為一個(gè)獨立的接口或抽象類(lèi)，以實(shí)現策略擴展的目的。Command模式、State模式、Vistor模式、Iterator模式概莫如是?；蛘叻庋b一個(gè)請求（Command模式），或者封裝一種狀態(tài)（State模式），或者封裝“訪(fǎng)問(wèn)”的方式（Visitor模式），或者封裝“遍歷”算法（Iterator模式）。而這些所要封裝的行為，恰恰是軟件架構中最不穩定的部分，其擴展的可能性也最大。將這些行為封裝起來(lái)，利用抽象的特性，就提供了擴展的可能。
利用設計模式，通過(guò)封裝變化的方法，可以最大限度的保證軟件的可擴展性。面對紛繁復雜的需求變化，雖然不可能完全解決因為變化帶來(lái)的可怕夢(mèng)魘，然而，如能在設計之初預見(jiàn)某些變化，仍有可能在一定程度上避免未來(lái)存在的變化為軟件架構帶來(lái)的災難性傷害。從此點(diǎn)看，雖然沒(méi)有“銀彈”，但從軟件設計方法的角度來(lái)看，設計模式也是一枚不錯的“銅彈”了。
