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