一般來說，設計與規劃一個軟體系統，不外乎是符合需求，具有前瞻性，創新力，或是試水溫等等，不管是哪一種，只要是一個有經驗 (或是現在就在做) 的系統設計師 (系統分析師亦然) 都會想要把軟體系統設計得具有十足的彈性，並且具有無限的擴充性，
這個題目是看了某個討論和某個噗而動念的。
一般來說，設計與規劃一個軟體系統，不外乎是符合需求，具有前瞻性，創新力，或是試水溫等等，不管是哪一種，只要是一個有經驗 (或是現在就在做) 的系統設計師 (系統分析師亦然) 都會想要把軟體系統設計得具有十足的彈性，並且具有無限的擴充性，可以適用於各種想的到的環境，簡言之，就是將軟體系統設計為一個有機體。有機體可以自由的依環境的特性而變化，在完全不用修改 (或極少修改) 的情況下即可將系統建置於任何環境中。這當然是許多軟體設計師的最高境界，但，說真的，有機體的軟體設計難度非常高，除了要有異於常人的前瞻思考外，還要有一手很高超的技術 (或是一個擁有很高超的技術的團隊) 來實現，否則想把軟體設計成有機體，幾乎是 MISSION IMPOSSIBLE。
具有機體能力的軟體，其中一項特異功能就是能適應各種環境，而想要讓程式碼能夠適應，那麼絕對不可以是靜態 (static) 的設計，而必須是全動態 (fully dynamic)，全動態的架構可以因應不同的環境快速的變更，以適配當下的環境與需求，它相對的一個詞是全靜態 (fully static)，全靜態的架構只能符合特定的情境或環境，雖然沒有全動態的彈性，但卻有無比的速度，理由很簡單，因為所有的流程都是固定的，不需要對環境做出妥協，也不需要因應環境自動調整，所以省下那些時間的結果，就是得到比全動態更優異的速度和效率。雖然靜態的好處比動態好，然而過於靜態對系統的延展性和擴充性有很大的限制，更進一步的會影響到使用年限，因為商業或系統環境是會改變的，Process 1.0 可能幾天後要改成 Process 1.1，出貨流程可能會因為倉管的要求而加入檢查機制，銷售獎金可能會因為公司改變計算方式而有所不同等等，如果軟體是靜態設計法的話，可能一天到晚都要重新 build-deploy，不斷的輪迴。
所以系統到底是要設計到多動態 (or 多靜態) 呢？
對於一個商業應用程式 (Business Application) 來說，除了基本的需求外，也需要針對可能有變化的規則 (business rules) 進行特別設計，而這個部份一定要使用動態的作法，可用的設計架構像是 Strategy Pattern 或 Abstract Factory Pattern 等，配合 Reflection 來設計，以保持該有的動態能力，也可以增加系統的可維護性。而針對一些不太會變化的部份 (如系統管理功能或是系統基礎核心) 則可以用靜態的作法，以保持該有的執行效能。
對於一個 Framework 或是核心應用程式架構 (Application Architecture) 來說，動態能力則會是重點，因為服務的對象是應用程式開發人員，所以會用到許多的動態技術，Reflection 只是小菜而已，像 attribute, Control Design, Visualization, Rendering 等等都有可能會涉獵到，以 Web Application 來說，HTML, JavaScript 真的只是一小部份而已，具有動態能力的 Framework 會隨著開發人員所設定的環境而所有變化，但也不是 100% 都動態，像是連接 Framework 和 Application 的介面 (interfaces, contracts) 就不能隨便變動，否則會有版本相容性的問題，同時各式輔助函式或工具函式，也可以以靜態方式設計，來加速處理以及提高重覆使用性 (Reusability)。
動乎？靜乎？適當的設計，讓系統動靜皆宜，有何不可？ :)
