1.1.2《應用程式框架的特點》

 

1.1.2 應用程式框架的特點

應用程式框架相比其它程式結構而言具有五大主要特點：模組化、可重用性、可擴充性、簡單性和可維護性2，儘管這些特點並非應用程式框架所完全特有，但它卻很好地保持了這些特點的平衡性，對於編寫結構複雜、需求多變的大中型應用軟體系統而言不啻為最佳選擇之一。

模組化

應用程式框架可以從邏輯上被劃分為多個邏輯獨立的層次或模組。模組化並非應用程式框架的獨特之處，許多應用程式都具備這個的特點，它的好處是將整個應用獨立為多個關聯的模組，從而提高了應用的彙總性，降低了應用的耦合性。各個獨立的模組通過統一的管道或協議進行通訊互動，這樣，當一個模組內部發生重大改變時，只要它的通訊入口和出口保持不變，就不會影響到系統中其它模組的有效性和可靠性。

從開發效率的層面上而言，模組化是實現“人盡其能”的好方式。將應用劃分為不同的模組，可以使用不同能力和技術的人員分別擔當但同時完成。如B/S結構的應用，可以讓美工負責介面端（UI層）的設計，熟悉ASP.NET、JSP的程式員負責應用程式層，熟悉伺服器編程的人員開發Web Service，精通資料庫設計的人員負責資料庫。這樣齊頭並進的開發效率較之程式員從頭到腳大包大攬無疑高效得多。

可重用性

代碼的可重用性是衡量代碼品質的一個重要標誌。無論是使用函數、類還是其它更高層次的重用模型，都是為了在某種程度上提高重用性，使程式員避免編寫重複的代碼。而在應用程式框架中，可重用的不僅僅是函數和類，更包括多個類組成的一套邏輯和設計模式。可以簡單地認為，設計架構的主要目的之一便是為了實現代碼的重用。

可重用性並不是一件容易辦到的事情，相反，設計具有良好可重用性的系統不僅困難而且需要不斷迭代式設計。在物件導向語言中，一個類型被其它對象互動引用後，很容易在修複該類型某個邏輯錯誤時導致其它對象的邏輯錯誤呈指數級產生，這種所謂的“特徵互動作用”是設計致命的邏輯錯誤之一，也是可重用性的最大敵人。

最簡單的代碼重用類型是使用函數庫（Library），高品質的相關函數可以組合為一個可分發庫，但這些函數之間並不一定存在緊密的聯絡，使用者必須從函數庫中找出合適的函數，它的使用效率取決於使用者對函數庫的熟悉程度和文檔的完善程度。

比函數庫複雜一些的是類庫，類庫提供了類（Class）而非單一的函數，一個類通常會包含具有一些關聯關係的函數，使得這些函數更容易區分；除此以外，類庫通常還會使用抽象類別進行層次設計，這樣能夠使類的功能函數在使用上更加簡單。

設計模式（Design Model）是另一種更進階的重用，它描述的是如何高效地建立物件導向系統的各個部分，如何在某種情況下使用特定的策略來解決具體問題，這種重用涉及到物件導向的方法學。

架構重用是一種集合了類庫、設計模式、工作模式（有時還有函數庫）的重用模式，它重用的不僅僅是具體功能和解決問題的抽象策略，還包括解決問題的具體流程和規則。從重用程度而言，應用程式框架是最進階的重用模式。

應用程式框架與函數庫的差別在於，後者只是提供了多組離散的，內部沒有或很少量邏輯關係的函數集，這些函數的調用順序和調用關係並不明確，就好像使用Win32 API開發Windows程式一樣，一個簡單的表單設計就必須有上百行代碼，而且使用者還必須牢記API的使用順序；而使用MFC架構編寫表單，代碼數量就少的多，程式員需要考慮的內部細節也少得多，因為MFC已經將大量不必要暴露的細節隱藏在架構幕後，開發人員不必關心那些通用的、繁瑣的實現。除此以外，Visual C++還為開發人員提供了多種工作模式，即開發不同類型程式的一般模板、嚮導和方法，所有這些都是應用程式框架與一般函數庫之間的最大差別。

模組化與可重用性並沒有直接的關係，模組化的軟體並非都有很好的重用效能，可重用的組件也並非一定被模組化。通常來說，模組化實現分治策略，可重用性是在不同的地方對功能的重複利用3。

可擴充性

可擴充性是應用程式框架最顯著的特徵之一，它意味著應用程式框架的功能具有生長的能力。沒有擴充能力的應用程式框架毫無使用的價值和意義，因為架構本身就是為了提供一個統一的上下文環境給具體的應用使用。應用程式框架的可擴充性使得我們能夠基於一個平台實現不同的功能，滿足不同的應用，當然，許多應用需要平台本身的支援。

架構的可擴充性主要是通過繼承和彙總兩種方式實現的。繼承方式是指通過衍生類別繼承基類，通過重用基類的功能並定義新功能的方式實現功能擴充；彙總方式是指調用不同的類型組合為一個新類型而擴充出全新的功能。這兩種方法之間並不一定存在最好的模式，開發人員應該在合適的場合使用它們，但一般而言，我們推薦首選彙總而不是繼承來擴充功能。

以MFC架構為例，擴充它的主要手段是在繼承不同的基類上開發出具有新功能的類而達到擴充目的；在外掛程式式架構中，外掛程式類型則通過實現架構公布的介面完成擴充功能。

簡單性

架構的簡單性並不能使用架構向外延展群組件開發的難易程度來衡量，事實上，沒有哪一個架構能夠保證基於自身開發的程式在邏輯設計和代碼工作量上比不使用架構開發更有優勢。架構的簡單性體現在架構提供了一個明確的工作模式，即開發某種類型擴充外掛程式的一般實現步驟，架構外掛程式內在的關聯和管理由架構本身控制而無需架構的使用者考慮，使用者可能根本不熟悉架構的內部協作結構，但擴充外掛程式的開發可以很簡單地在統一步驟的基礎上進行升華和細化。

架構簡單性還體現在它一般都有一個具有內在邏輯關聯和豐富功能的“輔助類庫”，開發人員能夠充分利用架構已經存在的協助工具功能和代碼。如在.NET Framework中，如安全、加密、資料流等一般功能都完全可以直接從架構類獲得而無需程式員自己開發實現。

可維護性

可維護性是業務需求變化後應用能夠方便地進行改變的能力。為了使架構能夠為不同的應用共用使用，它可以由與業務完全無關的萬用群組件組成，而應用代碼基於這些萬用群組件基礎上實現，這樣使應用需求的改變對架構本身的影響降為最低；架構也可以劃分多個層次，底層是通用層，而在通用層上的各層逐級加入與不同層次應用相關的元素，這樣某個應用改變後的代碼修改工作量能夠盡量減少而不會牽一髮而系全身。

 

應用程式框架具備以上這些優點，但它最激動人心的優勢莫過於提供了一個統一的“舞台”，並協調了舞台上表演的各位“演員”的內部互動，對於“演員”的成長，架構也提供了一套培養模式和許多額外協助。

應用程式框架設計的困難之處在於，設計者如何把握各種應用的共性與特性，並在這些共性與特性基礎上抽象出通用的邏輯並能夠重用它們；架構設計者如何確定架構的通用點和擴充點，這些通用點和擴充點抽象程度是否合理？

應用程式框架設計之初的分析工作非常抽象，因此，一開始便要求設計一個完美的架構內容是非常困難的，除非一開始開發人員就有一個完善的需求設計。在相當多的情況下，架構設計者必須改變和調整設計之初對通用點和擴充點的設計；在架構雛形設計完成後，由於新的應用組件加入架構或現存的架構組件發生變化，設計者需要修改架構使它能夠適應新的改變。因此，架構設計是一個迭代過程，設計人員必須不斷地根據應用的需求進行分析、設計、實現和測試，只有這樣，架構雛形才能成長為一個健壯、靈活和具有較高擴充性的平台。

2  XinChen，應用程式框架的設計與實現──.NET平台， 北京：電子工業出版社 2006

3  Christian Gross,.NET2.0模式開發實戰 北京：人民郵電出版社 2007 p5