第5章：可複用性的軟件構建方法 5.1可複用性的度量，形態和外部觀察

大綱

什麼是軟件複用？
如何衡量「可複用性」？
可複用組件的級別和形態

• 源代碼級別複用
• 模塊級別的複用：類/抽象類/接口
• 庫級別的複用：API /包
• 系統級別的複用：框架

對可複用性的外部觀察

• 類型變化
• 例行分組
• 實施變動
• 表明獨立
• 分解常見行爲

總結

什麼是軟件複用？

軟件複用

軟件複用是使用現有軟件組件實施或更新軟件系統的過程。

軟件複用的兩個觀點

• 建立：以系統方式建立可複用資源（面向複用編程：開發出可複用的軟件）
• 使用：複用資源做爲建立新系統的構建塊（基於複用編程：利用已有的可複用軟件搭建應用系統）

爲何複用？

• 「創造可重複使用而不是暫時性文物的動力具備審美和知識以及經濟動機，而且是人類對不朽渴望的一部分。
• 它將人與其餘生物區分開來，並從原始社會文明「（Wegner，1989）。

爲何複用？

重複使用具備成本效益，而且具備及時性下降成本和開發時間

• 經過縮短軟件生產週期時間來提升軟件生產力（開發速度更快，人員更少的軟件）
• 不浪費資源沒必要要地「從新發明輪子」
• 下降維護成本（可生產更好的質量，更可靠和更高效的軟件）

通過充分測試，可靠，穩定，生成可靠的軟件

• 重複使用已經存在一段時間並被調試的功能是構建穩定子系統的基礎

重複使用標準化，在不一樣應用中保持一致

• 複用GUI庫可在應用程序中產生常見的外觀。
• 與常規，一致的設計保持一致。

重複使用成本

可複用組件的設計和構建應該採用明確，開放的方式，具備簡潔的接口規範，易於理解的文檔以及面向將來的使用。作到這些，須要代價。
複用成本很高：涉及跨越組織，技術和流程變動，以及支持這些變動的工具成本，以及培訓人員使用新工具和變動的成本。 不只面向複用編程代價高，基於複用編程代價也高

面向複用開發：開發可複用的軟件

可複用組件的開發成本高於特定等價物的成本。 這種額外的可複用性加強成本應該是一個組織而不是項目成本。 開發成本高於通常軟件的成本：要有足夠高的適應性
通用組件的空間效率可能較低，執行時間可能長於其特定的等效項。 性能差些：針對更普通場景，缺乏足夠的針對性。

基於複用開發：使用已有軟件進行開發

必須開發和維護用於體系結構，設計，文檔和代碼的組件管理工具，例如存儲庫。可複用軟件庫，對其進行有效的管理

一個關鍵問題：適應每每沒法拿來就用，須要適配

• 可能須要將額外的功能添加到組件。 添加完成後，新組件能夠從新使用。
• 能夠從組件中刪除不須要的功能，以提升其性能或減小其空間要求
• 某些組件操做的實現可能須要修改。

如何衡量「可複用性」？

衡量可複用性

軟件資產在不一樣應用場景中的重複使用頻率如何？

• 資產使用的可能性越高，其可複用性越高。
• 編寫一次，重複使用屢次。

爲重複使用此資產需支付多少費用？

• 購買資產和其餘強制性庫的成本
• 調整和擴展它的成本
• 實例化它的成本
• 更改與其交互的系統的其餘部分的成本

可複用性

可複用性意味着對構建，打包，分發，安裝，配置，部署，維護和升級問題進行一些明確的管理。

具備高可複用性的軟件資產應該：

• 簡短（小尺寸）和簡單（低複雜度）
• 便攜式和標準合規性
• 適應性和靈活性
• 可擴展性
• 通用和參數化
• 模塊化
• 易變（可變）設計假設的本地化
• 改變要求時的穩定性
• 豐富的文檔

可重複使用組件的級別和形態

複用水平

可複用組件多是代碼

• 最廣泛：大多數程序員與複用有關

可是，從更普遍和更高層次上看待能夠重複使用的觀點帶來的好處。

• 要求
• 設計和規格
• 數據
• 測試用例
• 文件

咱們在這節課中關注的是什麼

源代碼級別：方法，語句等
模塊級別：類和接口
庫級別：API

• Java庫，.jar

架構級別：框架框架

代碼複用的類型

白盒複用：源代碼可見，可修改和擴展

• 代碼自己可用時複用代碼。 一般須要某種修改或改編
• Pro：您能夠自定義模塊以適應特定的狀況，這容許在更多狀況下複用
• Con：你如今擁有自定義的結果，因此它增長了你的代碼複雜度。 您須要內部組件的內在知識。

黑盒複用：源代碼不可見，不能修改

• 經過提供一些「膠水」來從新組合現有代碼的形式，但沒必要更改代碼自己 - 一般是由於您沒法訪問代碼。只能經過API接口來使用，沒法修改代碼
• Pro：簡潔和清潔
• Con：不少時候這是不可能的

可複用組件分佈的格式

形式：

• 源代碼
• 包，如.jar，.gem，.dll，

可複用軟件組件的來源：

• 組織的內部代碼庫（Guava）
• 第三方提供的庫（Apache）
• 語言本身提供的庫（JDK）
• 來自教程，示例，書籍等的代碼示例
• 本地代碼專家或知識淵博的同事
• 現有的系統代碼
• 開源產品（請務必遵照任何許可協議）

（1）源代碼複用

複用代碼 - 最低級別
將部分/所有複製/粘貼到您的程序中

維護問題

• 須要在多個地方更正代碼
• 使用太多的代碼（不少版本）

過程當中出現錯誤的風險很高
可能須要知道如何使用的軟件工做
須要訪問源代碼

（2）模塊級複用：類/接口

複用類
類是代碼複用的原子單元

• 不須要源代碼，類文件或jar / zip
• 只須要包含在類路徑中
• 可使用javap工具來獲取類的公共方法頭

文檔很是重要（Java API）
封裝有助於複用
代碼管理較少
版本控制，向後兼容性仍然存在問題
須要一塊兒打包相關的類 - 靜態連接

複用類的方法：繼承
Java提供了一種名爲Inheritance的代碼複用方法

• 類擴展示有類的屬性/行爲
• 另外，他們可能會覆蓋現有的行爲

不須要放置僅僅轉發或委託工做的虛擬方法
更好地捕捉現實世界
一般須要在實現以前設計繼承層次結構
沒法取消屬性或方法，所以必定要當心，不要過度

複用類的方法：委託

委託只是當一個對象依賴另外一個對象來實現其功能的某個子集時（一個實體將某個事物傳遞給另外一個實體）

• 例如分揀機正在委託比較器的功能

審慎的委託支持代碼複用

• 分揀機能夠重複使用任意的排序順序
• 比較器能夠重複使用須要比較整數的任意客戶端代碼

顯式委託：將發送對象傳遞給接收對象
隱式委託：由語言的成員查找規則

委託能夠被描述爲在實體之間共享代碼和數據的低級機制。

（3）庫級複用：API /包
庫：一組提供可複用功能的類和方法（API）

框架：能夠定製到應用程序中的可重複使用的框架代碼
框架調用回客戶端代碼

• 好萊塢原則：「不要打電話給咱們。 咱們會打電話給你。「

通常區別：庫與框架

框架做爲主程序加執行，執行過程當中調用開發者所寫的程序
開發者構造可運行軟件實體，其中涉及到對可複用庫的調用

（4）系統級複用：框架

應用程序框架

框架是子系統設計，包含一系列抽象和具體類以及每一個類之間的接口
框架：一組具體類，抽象類，及其之間的鏈接關係 - 只有「骨架」，沒有「血肉」
框架是一種抽象，其中提供通用功能的軟件能夠經過額外的用戶編寫的代碼進行選擇性更改，從而提供特定於應用程序的軟件。 開發者根據框架的規約，填充本身的代碼進去，造成完整系統

可複用性利用了應用領域知識和經驗豐富的開發人員的先前努力

• 數據處理，圖形用戶界面等
• 將框架看做是更大規模的API複用，除了提供可複用的API，還將這些模塊之間的關係都肯定下來，造成了總體應用的領域複用

框架：領域複用

系統經過添加組件來填充缺失的設計元素並實例化抽象類來實現

• 一般經過選擇性覆蓋來擴展框架; 或者程序員能夠添加專門的用戶代碼來提供特定的功能---定義從抽象類祖先繼承操做的具體類
• 鉤子方法，被應用程序覆蓋以擴展框架。 鉤子（Hook）方法系統地將應用程序域的接口和行爲與應用程序在特定上下文中所需的變體解耦。
• 控制反轉：與庫或標準用戶應用程序不一樣，控制流不是由調用者決定的，而是由框架決定的。
• 不可修改的框架代碼：框架代碼不該該被修改，同時接受用戶實現的擴展。 換句話說，用戶能夠擴展框架，但不該修改其代碼。

控制反轉(Inverse of Control)

由第三方的容器來控制對象之間的依賴關係，而非傳統實現中由代碼直接操控。
控制權由代碼中轉到了外部容器，帶來的好處就是下降了對象之間的依賴程度，提升靈活性和可維護性。

框架設計

框架與應用程序不一樣

• 抽象級別不一樣，由於框架爲相關問題家族提供解決方案，而不是單一解決方案。
• 爲了適應這一系列問題，該框架是不完整的，包含熱點和掛鉤以容許定製

框架能夠用擴展它們的技術來分類。

• 白盒框架
• 黑盒框架

白盒和黑盒框架

白盒框架：

• 經過繼承和動態綁定實現的可擴展性。
• 經過繼承框架基類並重寫預約義的鉤子方法來擴展示有功能
• 一般使用模板方法模式等設計模式來覆蓋鉤子方法。

黑盒框架

• 經過爲可插入框架的組件定義接口來實現可擴展性。
• 經過定義符合特定接口的組件來複用現有功能
• 這些組件經過委託與框架集成。

類庫與框架

類庫：

• 較少的域特定
• 提供更小的複用範圍。
• 類庫是被動的; 對控制流程沒有限制。

框架：

• 類爲相關應用系列合做。
• 框架活動; 影響控制流程。

在實踐中，開發人員常用兩種：

• 框架一般在內部使用類庫來簡化框架的開發。
• 框架事件處理程序使用類庫來執行基本任務（例如字符串處理，文件管理，數值分析......）。

組件與框架

組件

• 類的獨立實例
• 鏈接在一塊兒造成完整的應用程序。
• 黑盒定義了一套連貫的操做，
• 能夠基於接口的語法和語義使用。
• 組件甚至能夠在二進制代碼級複用。

•優勢是應用程序不必定須要在組件更改時從新編譯。
構架：

• 常常用於開發組件
• 組件一般插入黑盒框架。

可複用性的外部觀察

對可複用性的外部觀察
類型可變
功能分組
實現可變
表示獨立
共性抽取

類型可變
可複用組件應該是類型參數化的，以便它們能夠適應不一樣的數據類型（輸入，計算和輸出）;

• 可重複使用的模塊應該適用於許多不一樣類型的元素，而不須要開發人員對軟件文本進行手動更改。

換句話說，咱們須要一個用於描述類型參數化模塊的工具，這個模塊也被稱爲通用模塊。
通用性：可複用組件應該是通用的。
類型可變（泛型）：適應不一樣的類型，且知足LSP

實現可變
在實踐中有不少種適用的數據結構和算法。
咱們不能指望單個模塊可以處理全部可能性，這種變化確實是這樣; 這將是巨大的。
咱們須要一系列模塊來涵蓋全部不一樣的實現。
實現可變：ADT有多種不一樣的實現，提供不一樣的表示和抽象功能，但具備一樣的規範（前置條件，後置條件，不變式），從而能夠適應不一樣的應用場景

功能分組
一個自給自足的可複用模塊須要包含一組功能，每一個操做一個功能。
完整性
提供完備的細粒度操做，保證功能的完整性，不一樣場景下複用不一樣的操做（及其組合）

表示獨立性
可複用模塊的通常形式應該使客戶可以指定一個操做而不知道它是如何實現的。
表示獨立性是信息隱藏規則的延伸，對於大型系統的順利開發相當重要：實施決策常常會改變，客戶應該受到保護。 內部實現可能會常常變化，但客戶端不該受到影響。
表示獨立反映了客戶對可複用性的見解 - 忽略內部實現細節和變體的能力
表示獨立性，信息隱藏

共性抽取
分解共同行爲，反映了供應商的觀點，更通常地反映了可複用類的開發者的觀點。
目標是利用家庭或實施子系列中可能存在的任何通用性。
將共同的行爲（共性）抽象出來，造成可複用實體
如上所述，在某些問題領域可用的各類實現一般須要基於模塊族的解決方案。
這些類別中的每個都涵蓋了許多變體，但一般能夠在這些變體之間找到顯着的共性。

總結

什麼是軟件複用？
如何衡量「可複用性」？
可複用組件的級別和形態

• 源代碼級別複用
• 模塊級複用：類/接口
• 庫級：API /包
• 系統級複用：框架

對可複用性的外部觀察

• 類型可變
• 功能分組
• 實現可變
• 表示獨立
• 共性抽取