可擴展性是系統設計中一個關鍵概念，它指的是系統為了適應未來需求的變化，具備的一種擴展能力。這意味著當新需求出現時，系統可以通過最小的或沒有修改來支持這些需求，而無需進行全面的重構或重建。隨著軟件系統的固有多變性，不斷有新需求提出，這使得可擴展性成為軟件開發中的一個重要考慮點。面向對象的編程思想和設計模式的發展，都是為了更好地應對和解決可擴展性的挑戰。設計模式的廣泛應用顯示了對可擴展性的高度重視，幾乎成為了每一位技術專家的共識。

為了構建一個具有良好可擴展性的系統，主要需要滿足兩個前提條件：準確預測未來的變化，以及有效封裝這些變化。然而，實現這兩個條件并非易事，下面我將詳細探討這個主題。

與硬件或建筑項目不同，軟件系統的一個顯著特點是其發布后仍然能夠持續進行修改和更新。這一特性意味著軟件系統需要不斷地適應和實現新的需求。理想情況下，如果能夠在不修改現有代碼或僅通過少量修改來滿足這些新需求，對所有相關方來說無疑是最佳場景。反之，如果每出現一個新需求就需要對系統進行大規模改動，不僅成本高昂，而且開發人員、產品經理、甚至老板都會感到不滿——這種頻繁的大幅度修改既耗時又耗力。因此，架構設計的一個關鍵目標是盡可能預見未來的變化，并設計出能夠靈活適應這些變化的架構，使得當新需求出現時，可以輕松地說：“我們已經考慮到了這一點，現有架構可以輕松支持這個新功能，僅需幾天的工作量。”

然而，現實往往遠比理想復雜。正如一句古老的諺語所言：“唯一不變的是變化本身”。這意味著在架構設計時，考慮到可擴展性變得尤為重要。比如，在設計一個后臺管理系統時，如果選擇使用MySQL作為數據庫，是否需要預留空間以便將來可能切換到Oracle？在決定使用HTTP作為接口協議時，是否需要考慮未來可能支持ProtocolBuffer？甚至更進一步，是否需要考慮VR技術可能帶來的影響，以確保架構的長期可擴展性？如果嘗試預測和準備每一個可能的變化，架構師可能會感到不堪重負，導致設計過于龐大而難以實施。但另一方面，如果完全不進行未來規劃，新需求的到來可能會迫使系統進行重構，這同樣意味著前期的投入和努力可能會付之東流。

應對變化

第一種應對變化的常見方案是將“變化”封裝在一個“變化層”，將不變的部分封裝在一個獨立的“穩定層”

圖片

無論采取哪種形式，通過剝離變化層和穩定層的方式應對變化，都會帶來兩個主要的復雜性相關的問題。

區分變化與穩定層

在系統架構設計中，識別哪些部分容易發生變化（變化層）與哪些部分相對穩定（穩定層）是關鍵的第一步。然而，區分這兩層并非總是直接明了的，比如不同的數據庫選擇或接口協議可能容易識別，但在實際情況中，不同設計者可能對哪些層次屬于變化層，哪些屬于穩定層有不同的見解。這種差異可能會在架構審查過程中引發激烈的討論。

設計變化層與穩定層間的接口

接口的設計是連接變化層與穩定層的橋梁，對于確保系統的整體穩定性和可擴展性至關重要。穩定層的接口應當盡可能的穩定，而對于變化層，設計一個能夠適應不同實現方式并在引入新功能時仍保持兼容性的接口則更加復雜。以數據庫為例，不同數據庫（如MySQL、Oracle、DB2）之間在某些操作（如數據插入或更新）的實現上可能存在差異，這就需要在設計存儲層訪問接口時做出選擇：是采用特定數據庫的實現方式，還是設計一個能夠自適應不同數據庫特性的通用接口？這個例子揭示了設計接口時需要面對的挑戰。

另一種常用的方法來應對系統變化是區分“抽象層”與“實現層”。在這種架構策略中，抽象層保持穩定，為系統的核心和通用功能提供定義，而實現層則具有可變性，可以根據不同的業務需求進行定制化開發。當需要引入新功能時，僅需添加新的實現即可，而不需要對抽象層進行修改。設計模式和規則引擎就是這種策略的經典實踐案例。鑒于大多數技術專業人士對設計模式已相當熟悉，我將以設計模式為例進一步闡述這種方法的復雜之處。

裝飾者模式提供了一種相較于傳統繼承更為靈活的方式來擴展功能。以《設計模式》一書中的“TextView”類示例為例，通過使用裝飾者模式，可以非常靈活地為TextView添加各種額外功能，如邊框、滾動條、背景圖片等，而這些功能的組合并不會影響到基本的實現規則，只需遵循裝飾者模式的設計即可實現。然而，與傳統的類實現相比，裝飾者模式的確引入了更多的復雜性。原本可能通過單個函數或類就能完成的任務，現在需要分解成多個類，并且這些類之間的關系和調用方式都必須遵循裝飾者模式的設計原則。

同樣，規則引擎的設計理念與設計模式持有相同的目標——通過靈活的設計達到系統的可擴展性。然而，這種“靈活性”本身就帶來了設計上的復雜性。不僅如此，僅僅是要徹底理解并掌握23種設計模式本身就是一個挑戰。