漫谈程式码的相依性.ppt

1、漫談程式碼的相依性,Q.tw(Email/MSN)2008/10/16,程式碼間的相依性,在程式設計上，我們通常都會盡量降低程式碼之間的相依性程式碼間的高相依性會帶來許多負面的效應其中最令程式設計者頭痛的，莫過於程式碼變動所造成的衝擊當兩個程式碼元素之間存在相依性時，當被依賴的那一個元素有了變化時，就有機會造成另一個元素也受到波及，因而必須跟著一同變化當你修改某個被許多其他的程式碼元素高度依賴的程式碼元素時，可能會影響到的層面將會十分廣泛,不同粒度之程式碼元素間的相依性,所謂的程式碼元素之間的相依性，其實還是可以在不同的粒度（granularity）上去檢視

2、，例如程式庫和程式庫之間package和package之間類別和類別之間函式和函式之間無論放在那一種粒度的層級上看，高相依性都不會是一件好事大名鼎鼎的JakartaApacheProject，其中的許多程式庫都和同一專案下的許多程式庫存在著相依性採用其中一者，也得同時引入其他，造成了高度耦合的情況,程式員最關心的相依性,一般程式設計者來說，多半比較關心package間的相依性以及類別之間的相依性類別之間的相依性更是許多設計技巧與方法關注的重心本講題將以類別之間的相依性為主,何謂類別間存在相依性？,當類別A相依於類別B時，意指當我們改變B的介面時，我們可能得修改A所謂的相依性，其實是對另一類別介

3、面的依賴下述的情況都是A相依於B的例子，A存取B的值A呼叫B的函式A外貌式（signature）中的回傳型別或引數列表中含有B,UML中的相依性關係,UML中類別間可能存在相依性關係（dependencyrelationship）我們在評估兩個類別之間是否存在相依性時，其中的相依性其涵蓋範圍就不僅僅侷限於UML中所提及相依性關係，例如相依性可能源自於繼承關係,你的設計是否考量相依性？,你在進行設計的時候，是否曾經將設計的相依性高低與否納入考量呢？你是否會在設計時，試著降低類別與類別之間的相依性呢？,利用工具分析相依性,有許多工具可以協助你分析你的系統中各類別之間的相依性我所使用的一個工具能產生

4、左方的相依圖（dependencygraph）,相依圖,所謂的相依圖，即將你系統中存在相依性的類別之間以帶有箭號的線條相連接相依性是單向關係類別A相依於類別B（此時箭號指向B），不意謂著類別B也同樣相依著類別A例：DBFacade依賴SQLManager、SQLExecutor及QueryResult,從相依圖觀察設計上的問題,從相依圖中可以觀察出現有程式碼在設計上的一些問題當某個類別被許許多多的箭頭所指向時，意謂著它是被高度依賴的類別當這個類別有所變動時，可能會影響到的類別數量就會很多存在一個高度依賴其他類別的類別，同樣也不是一件好事這個類別有可能會被頻繁的更動，因為只要任一個它所依賴的類別

5、有了變化，它都有機會被波及循環相依（circulardependency）,使用相依圖觀察設計缺失的弱點,相依圖分析工具多半屬於靜態分析的形式僅能分析靜態的程式碼，而無法捕捉到系統於執行期的行為利用relfection機制的程式碼，便難以分析大量利用reflection的系統仍然是少數懂得運用reflection機制的程式員，也多半會留意相依性的議題，所以並不構成此類工具的重大缺陷,設計時將相依性時時牢記於心,在設計類別以及類別所具備的介面時，必須時時刻刻把類別間的相依性放在心裡讓你自己總是思考如何降低自己設計中類別間的相依性，進而持續的改善自己的設計許多導因自相依性的設計問題，多半都是由於設

6、計者不在意、或是不知道應該要留意設計中類別的相依性而引起的,Programtointerface,notanimplementation,GoF的DesignPatterns一書中提到設計時的一個重要原則：針對介面來撰寫程式，而不要針對實作（Programtointerface,notanimplementation）從相依性的角度來理解這個原則，原因便不言可喻倘若你的客戶端程式相依五個實作的類別，那麼它在相依圖上，就有著五條對外的連結如果這五個實作的類別有著共通的介面，那麼你就有機會讓你的客戶端程式僅相依於該介面，因此大大的降低了相依性的程度（只相依於一個介面）即便後端的實作類別有所變動，共

7、通的介面也能扮演著緩衝的角色，有機會吸收掉實作類別造成的衝擊，也就不致於影響到客戶端程式,相依距離,在相依圖上兩類別間若存在一條路徑，那麼當它們之間的距離愈遠，對其中一個類別所做的修改，會波及到另一個類別的機會就會愈低兩類別之間間接的層級愈高，愈能抵抗改變的影響高間接層次的缺點程式中若處處充滿著間接的設計，也會衍生出效率及可讀性的問題,降低相依性是許多設計模式的重心,例如Faade,*圖引自DesignPatterns,byErichGamma,RichardHelm,RalphJohnson,JohnVissidesAddison-Wesley(October1994),高相依性程式碼的缺點

8、,高相依性的程式碼會成為軟體開發時的諸般障礙，例如：對某程式模組所做的更動，會波及到許多的程式模組因為高度的相依性，很難單獨對單一模組進行理解，因為特定的一項操作多半會牽扯進多個程式模組之間的相依互動使得想要重覆運用程式模組更為困難，因為引入某一模組也被迫引入更多該模組所相依的其餘模組，單一模組的獨立重覆運用性便大幅降低,為何造成高相依性的局面,抽象化的程度不夠，或根本不做抽象化模組化程度不夠，造成模組內聚力低，耦合力高,讓抽象化程度愈高，愈有機會讓相依性變低,建立抽象化層級是抵抗改變的一大支柱在相依圖上兩類別間若存在路徑，那麼當它們之間的距離便可被視為是二者之間的相依間接層級當二者之間的間接

9、層級愈高時，當某一類別發生變動，此變動的影響傳遞至另一個類別的機會就會愈低針對抽象的介面來撰寫程式，相較於針對實作細目來撰寫程式，被改變所影響的機會就小多了,抽象介面能緩衝改變所造成的衝擊,抽象介面便能隔離客戶端與實作細目，形成扮演改變發生時的緩衝角色加上Authenticator後，Client和RDBMSAuthenticator之間的相依距離由1變為2在設計時，要盡可能的讓客戶端程式碼面對最抽象的介面，如此一來，便能讓客戶端程式碼所受到的威脅降到最低,相依的類別個數亦影響受到改變的機會,除了相依圖上兩類別間的相依距離之外，相依圖上某類別所相依的類別個數，也會影響到某類別受到改變的機會換成

10、圖論（graphtheory）的術語，就是它的外分支度（outdegree）,高外分支度的設計,調整後較低外分支度的設計,Authenticator的外分支度仍舊還是四呀？！,聚合力和耦合力，是由LarryConstantine所提出的軟體品質評量指標聚合力，指的便是位於同一個模組內之組成的相關程度與其他模組間相依性低的模組，我們稱它為低耦合（lowcoupling）的模組上述的相依圖所表示的設計，Authenticator及其四個實作類別事實上是位於同一個程式庫中它們之間的高相關度代表著整個程式庫具有較高的內聚力,相依性極限,雖然我們應該在設計上盡量的消除相依性我們會發現解決設計問題時，每個

11、不同的問題都有其本質的相依性極限我們只能將相依性降低到某種程度當我們在消去不必要的相依性之後，透過設計，我們可以調整相依的關係將相依性的連結移至同一模組內，反而可以轉化耦合及聚合的性質,相依關係連結數為四,相依關係連結數為五,妥善的安置相依關係,後者的相依關係連結數反而增加了但將一個原先為高耦合低聚合的設計，轉變成為一個低耦合高聚合的設計這正突顯出設計良窳與否的重要性我們沒有額外多寫程式碼，不過只是單純的調整類別間的關係，就能將一個具有不佳特質的設計，轉變成為一個具有良好特質的設計,相依關係的強度,兩類別間存在相依關係，代表著一類別的變動可能會傳遞到另一類別但是否會發生傳遞的情況，和相依關係的強度也有關聯同是類別間的相依關係，事實上也有強弱的分別例如，繼承關係便是一種很強的相依關係例如，僅只指涉到類別名稱、但卻未存取其資料成員或函式，便是一種較弱的相依關