考慮一個日志記錄工具。目前需要提供一個方便的日志API，使得客戶可以輕松地完成日志的記錄。該日志要求被記錄到指定的文件中，記錄的內容屬于字符串類型，其值由客戶提供。我們可以非常容易地定義一個日志對象：
　

public class Log { 　public void Write(string target, string log) 　{ 　　//實現內容; 　} }

　　當客戶需要調用日志的功能時，可以創建日志對象，完成日志的記錄：
　

Log log = new Log(); log.Write(“error.log”, “log”);

　　然而隨著日志記錄的頻繁使用，有關日志的文件越來越多，日志的查詢與也變得越不方便。此時，客戶提出，需要改變日志的記錄方式，將日志內容寫入到指定的數據表中。顯然，如果仍然按照前面的設計，具有較大的局限性。 現在我們回到設計之初，想象一下對于日志API的設計，需要考慮到這樣的變化嗎？這里存在兩種設計理念，即漸進的設計和計劃的設計。從本例來分析，要求設計者在設計初就考慮到日志記錄方式在未來的可能變化，并不容易。再者，如果在最開始就考慮全面的設計，會產生設計上的冗余。因此，采用計劃的設計固然具有一定的前瞻性，但一方面對設計者的要求過高，同時也會產生一些缺陷。那么，采用漸進的設計時，遇到需求變化時，利用重構的方法，改進現有的設計，又需要考慮未來的再一次變化嗎？這是一個見仁見智的問題。對于本例而言，我們完全可以直接修改Write()方法，接受一個類型判斷的參數，從而解決此問題。但這樣的設計，自然要擔負因為未來可能的再一次變化，而導致代碼大量修改的危險，例如，我們要求日志記錄到指定的Xml文件中。

　　所以，變化是完全可能的。在時間和技術能力允許的情況下，我更傾向于將變化對設計帶來的影響降低到最低。此時，我們需要封裝變化。

　　在封裝變化之前，我們需要弄清楚究竟是什么發生了變化？從需求看，是日志記錄的方式發生了變化。從這個概念分析，可能會導致兩種不同的結果。一種情形是，我們將日志記錄的方式視為一種行為，確切的說，是用戶的一種請求。另一種情形則從對象的角度來分析，我們將各種方式的日志看作不同的對象，它們調用接口相同的行為，區別僅在于創建的是不同的對象。前者需要我們封裝“用戶請求的變化”，而后者需要我們封裝“日志對象創建的變化”。

　　封裝“用戶請求的變化”，在這里就是封裝日志記錄可能的變化。也就是說，我們需要把日志記錄行為抽象為一個單獨的接口，然后才分別定義不同的實現。如圖一所示：

　

圖一：封裝日志記錄行為的變化

轉帖于：軟件水平考試_考試吧