軟件設(shè)計最大的敵人，就是應付需求不斷的變化。變化有時候是無窮盡的，于是項目開發(fā)就在反復的修改、更新中無限期地延遲交付的日期。變化如懸在頭頂?shù)倪_摩克斯之劍，令許多軟件工程專家一籌莫展。正如無法找到解決軟件開發(fā)的“銀彈”，要徹底將變化扼殺在搖籃之中，看來也是不可能完成的任務。那么，積極地面對“變化”，方才是可取的態(tài)度。于是，極限編程（XP）的倡導者與布道者Kent Beck提出要“擁抱變化”，從軟件工程方法的角度，提出了應對“變化”的解決方案。而本文則試圖從軟件設(shè)計方法的角度，來探討如何在軟件設(shè)計過程中，解決未來可能的變化，其方法就是——封裝變化。

設(shè)計模式是“封裝變化”方法的最佳闡釋。無論是創(chuàng)建型模式、結(jié)構(gòu)型模式還是行為型模式，歸根結(jié)底都是尋找軟件中可能存在的“變化”，然后利用抽象的方式對這些變化進行封裝。由于抽象沒有具體的實現(xiàn)，就代表了一種無限的可能性，使得其擴展成為了可能。所以，我們在設(shè)計之初，除了要實現(xiàn)需求所設(shè)定的用例之外，還需要標定可能或已經(jīng)存在的“變化”之處。封裝變化，最重要的一點就是發(fā)現(xiàn)變化，或者說是尋找變化。

GOF對設(shè)計模式的分類，已經(jīng)彰顯了“封裝變化”的內(nèi)涵與精髓。創(chuàng)建型模式的目的就是封裝對象創(chuàng)建的變化。例如Factory Method模式和Abstract Factory模式，建立了專門的抽象的工廠類，以此來封裝未來對象的創(chuàng)建所引起的可能變化。而Builder模式則是對對象內(nèi)部的創(chuàng)建進行封裝，由于細節(jié)對抽象的可替換性，使得將來面對對象內(nèi)部創(chuàng)建方式的變化，可以靈活的進行擴展或替換。

至于結(jié)構(gòu)型模式，它關(guān)注的是對象之間組合的方式。本質(zhì)上說，如果對象結(jié)構(gòu)可能存在變化，主要在于其依賴關(guān)系的改變。當然對于結(jié)構(gòu)型模式來說，處理變化的方式不僅僅是封裝與抽象那么簡單，還要合理地利用繼承與聚合的方法，靈活地表達對象之間的依賴關(guān)系。例如Decorator模式，描述的就是對象間可能存在的多種組合方式，這種組合方式是一種裝飾者與被裝飾者之間的關(guān)系，因此封裝這種組合方式，抽象出專門的裝飾對象顯然正是“封裝變化”的體現(xiàn)。同樣地，Bridge模式封裝的則是對象實現(xiàn)的依賴關(guān)系，而Composite模式所要解決的則是對象間存在的遞歸關(guān)系。

行為型模式關(guān)注的是對象的行為。行為型模式需要做的是對變化的行為進行抽象，通過封裝以達到整個架構(gòu)的可擴展性。例如策略模式，就是將可能存在變化的策略或算法抽象為一個獨立的接口或抽象類，以實現(xiàn)策略擴展的目的。Command模式、State模式、Vistor模式、Iterator模式概莫如是?；蛘叻庋b一個請求（Command模式），或者封裝一種狀態(tài)（State模式），或者封裝“訪問”的方式（Visitor模式），或者封裝“遍歷”算法（Iterator模式）。而這些所要封裝的行為，恰恰是軟件架構(gòu)中最不穩(wěn)定的部分，其擴展的可能性也最大。將這些行為封裝起來，利用抽象的特性，就提供了擴展的可能。

利用設(shè)計模式，通過封裝變化的方法，可以最大限度的保證軟件的可擴展性。面對紛繁復雜的需求變化，雖然不可能完全解決因為變化帶來的可怕夢魘，然而，如能在設(shè)計之初預見某些變化，仍有可能在一定程度上避免未來存在的變化為軟件架構(gòu)帶來的災難性傷害。從此點看，雖然沒有“銀彈”，但從軟件設(shè)計方法的角度來看，設(shè)計模式也是一枚不錯的“銅彈”了。