軟件復(fù)用本質(zhì)是為了快速適應(yīng)不斷變化的需求（adapt to changing needs ），兩者目標(biāo)是一致的，但是當(dāng)我們過于注重軟件復(fù)用（如組件復(fù)用component reuse又譯構(gòu)件復(fù)用）時，千萬需要牢記：快速適應(yīng)不斷變化的需求是根本目的，它的重要性要重于組件復(fù)用技術(shù)本身。本文試圖闡述兩者概念比較以及時下流行的組件復(fù)用技術(shù)概要。
適應(yīng)需求變化
現(xiàn)如今是一個計劃趕不上變化的時代，企業(yè)競爭力逐漸表現(xiàn)在企業(yè)適應(yīng)變化能力的競爭，誰能更快適應(yīng)市場的變化，誰就能夠在競爭中勝出，這種快速適應(yīng)能力如果靠“人民戰(zhàn)爭”無疑是不現(xiàn)實的，軟件可以幫助我們來適應(yīng)這種快速變化。
談到這里，稍微再說明一下國人軟件教育的誤區(qū)，不錯，軟件曾經(jīng)是科學(xué)計算的工具，因此，我們非常注重軟件的算法和數(shù)據(jù)結(jié)構(gòu)，甚至將之作為數(shù)學(xué)的衍生物，但是，現(xiàn)如今已經(jīng)成為一種幫助我們快速響應(yīng)變化的有力工具，如果我們的教育背景中只有算法和數(shù)據(jù)結(jié)構(gòu)，能夠編制出應(yīng)付快速變化的軟件嗎？很顯然，他們是風(fēng)馬牛不相及，由此可見國人軟件概念和軟件教育的落后性，在這樣的軟件認(rèn)識背景下，固然設(shè)計模式的崇高位置得不到確立，軟件設(shè)計被拋棄在腦后，編制出的大多數(shù)企業(yè)軟件系統(tǒng)根本不具備應(yīng)付變化的能力，程序員拒絕頻繁更改程序，甚至借助技術(shù)原因阻擾軟件的頻繁更改，這種軟件程序員和軟件用戶之間的矛盾可以稱為miscommunication， miscommunication是導(dǎo)致軟件系統(tǒng)的失敗一個重要原因。
國內(nèi)早就有言論：“不上ERP等死；上了ERP找死”，如果你的企業(yè)不上ERP，那么你的企業(yè)就不能借助軟件應(yīng)付快速的市場等環(huán)境變化，那么必然會被淘汰；但是，如果上了一個不注重“適應(yīng)需求變化”的ERP軟件系統(tǒng)，那就是企業(yè)被僵化的ERP軟件框死，喪失了使用ERP的根本目的。
適應(yīng)需求變化則成為現(xiàn)代軟件系統(tǒng)一個孜孜不倦的追求目標(biāo)，那么如何實現(xiàn)呢？
原則：給予人們可以裁剪他們系統(tǒng)的能力應(yīng)適應(yīng)需求變化，建立一個適應(yīng)需求變化的系統(tǒng)，允許系統(tǒng)在一系列小的、可控制的步驟上進(jìn)行改變?！ ?BR> 組件誕生
將不變的通用的東西抽象出來，以達(dá)到在不同項目中重用復(fù)用，將我們有限的精力集中在項目具體變化和特點上。當(dāng)然這些抽象復(fù)用的東西之間彼此必須是松耦合，這樣才能根據(jù)需求挑選組合。
讓我們先回顧一下軟件的發(fā)展史，軟件開發(fā)的發(fā)展史實際是一部我們思維不斷抽象拔高的發(fā)展過程，這種抽象概念非常類似于建模的思考方式：概要貼切地描述事物，忽視次要的細(xì)節(jié)。抽象體現(xiàn)在軟件開發(fā)上就是每個具體項目需要完成的代碼行數(shù)量越來越少。
從1970到1980這段時間，軟件開發(fā)從機(jī)器語言到匯編語言。進(jìn)而發(fā)展到高級語言，甚至一些CASE工具，面向功能編程發(fā)展到面向?qū)ο缶幊?，功能模塊重用細(xì)化到類的重用，類的重用是最初是通過設(shè)計模式實現(xiàn)的。
進(jìn)入90年代中期，誕生了基于組件的開發(fā)模式（CBD：component based development），CBD將抽象概念帶往了一個新的方向，與減少代碼數(shù)量相反，CBD將功能各個方面細(xì)化分離到不同的、相互隔離層中，如表現(xiàn)層、業(yè)務(wù)邏輯層、持久層、安全層以及核心層等，并且可以管理這些組件之間的依賴關(guān)系，通過這種分離，我們可以提純細(xì)化組件功能，進(jìn)而產(chǎn)生可以重用的框架，如Struts框架可以重用在大部分應(yīng)用系統(tǒng)的表現(xiàn)層中，，Struts+JdonFramework+Hibernate是一個框架組合，代表一種架構(gòu)設(shè)計，這種架構(gòu)設(shè)計其實可以重用在大部分應(yīng)用系統(tǒng)，這種重用我稱之為架構(gòu)級別重用。
組件復(fù)用
軟件組件(Software components)是軟件提供業(yè)務(wù)或技術(shù)功能的基本單元或元素，這些單元可以獨立地被部署、他們可以自我管理并且被虛擬部署到網(wǎng)絡(luò)的任何地方，業(yè)務(wù)組件（(Business components)執(zhí)行業(yè)務(wù)邏輯、遵循一定的業(yè)務(wù)規(guī)則并且管理相應(yīng)的數(shù)據(jù)（數(shù)據(jù)庫操作稱為manage corporate data）；而技術(shù)組件(Technical components)則提供相應(yīng)的平臺以便業(yè)務(wù)組件可以依賴其上運行，例如權(quán)限、組件管理等。
JdonFramework/Spring都屬于一種技術(shù)組件框架，而我們具體項目的業(yè)務(wù)層代碼如果能夠提煉可以復(fù)用，則是業(yè)務(wù)組件；JdonFramework/Spring則都提供了業(yè)務(wù)組件賴于運行的一些核心底層機(jī)制，特別是組件的管理，如組件的創(chuàng)建、組件的獲得、組件的資源管理、組件的消亡等生命周期支持，所以，我們可以在JdonFramework/Spring中加入自己的業(yè)務(wù)組件，當(dāng)然，JdonFramework還提供了Session等狀態(tài)管理的支持功能，為業(yè)務(wù)組件提供了更廣闊的生命周期支持。
組件復(fù)用技術(shù)以前是停留在編譯前期，也就是說：我們在編程時，導(dǎo)入所需要的其他組件Jar包，然后混同我們的項目編譯部署，但是這需要通過專業(yè)技術(shù)人員實現(xiàn)，很顯然是不能適應(yīng)原則中第一句：給予人們可以裁剪他們系統(tǒng)的能力應(yīng)適應(yīng)需求變化，[考試大整理]這里的“人們”應(yīng)該是指軟件最終用戶，應(yīng)該給予用戶自己改變系統(tǒng)的能力，也就是說：需要提供軟件系統(tǒng)運行時能夠動態(tài)改變自身的能力。
組件復(fù)用技術(shù)以前停留在軟件編譯階段，現(xiàn)在則更靠前，必須在軟件運行階段，當(dāng)然對技術(shù)要求相當(dāng)高，需要語言支持RTTI（簡單又神秘的Class.forName發(fā)揮作用了），這在"Evolution, Architecture, and Metamorphosis"一文中被認(rèn)為是Metamorphosis，現(xiàn)在由于AOP技術(shù)出現(xiàn)，AOP有一種動態(tài)Weaving技術(shù)，實際就是在軟件運行時實現(xiàn)動態(tài)攔截，這樣給予終端用戶更大的改變系統(tǒng)能力，他們基本可以以動態(tài)插拔的概念實現(xiàn)多個組件的組合運行。在"AOP vs Decorator"一文中，我把編譯階段的組件組合方式（我更愿意稱為靜態(tài)組合）和運行時組合等兩種處理方式，合并稱為過濾器模式，如果你希望采取組件可插拔式的復(fù)用，就可以使用過濾器模式。
組件可插拔更換
為什么說組件的可插拔非常重要？
組件重用目的是為了更好地適應(yīng)需求變化，但是有了組件重用不代表就快速適應(yīng)需求變化，因為組件本身也會產(chǎn)生設(shè)計錯誤（提煉得不夠抽象或者組件很難以替代），這就必然導(dǎo)致軟件系統(tǒng)得維護(hù)成本提高，那么快速適應(yīng)需求變化的目標(biāo)也就成為一紙空文。實踐證明：組件設(shè)計問題已經(jīng)成為導(dǎo)致軟件開發(fā)失敗的一個主要因素。
組件設(shè)計有兩個主要風(fēng)險：組件提純的純度和組件的替代方式。提煉的純度也就是抽象的高度，組件的抽象程度越高，當(dāng)然可重用范圍越廣，但是往往我們只有經(jīng)歷多個項目后，才發(fā)現(xiàn)自己的組件提煉還欠火候，這實際是組件的提煉過程成本。
組件提練雖然取決于人為設(shè)計因素，但是在實現(xiàn)手段上也依賴于組件的替換方式，通過經(jīng)常反復(fù)頻繁的微調(diào)和更換，才能將組件不斷提煉向理想狀態(tài)靠攏，所以，必須有一種方便的組件替換方式提供頻繁更換支持，我們總不希望更換組件象以前更換汽車發(fā)動機(jī)火花塞一樣，需要拆開汽車，打開發(fā)動機(jī)那樣麻煩吧？
參考PC電腦硬件設(shè)計：更新CPU或內(nèi)存條，只要直接插拔就可以，這些部件和母版都是一種松散的、可插拔的關(guān)系，如果軟件組件替換是動態(tài)的可插拔更加方便終端用戶在軟件系統(tǒng)交付后，根據(jù)需求改變他們的系統(tǒng)。組件可插拔本質(zhì)上是這些組件必須是化的松耦合，彼此依賴影響非常小，換句話說：如果實現(xiàn)了可插拔更換，說明你的組件已經(jīng)實現(xiàn)松耦合了。
那就有可能設(shè)計一種軟件框架：它能夠為每個部件提供非常棒的服務(wù)訪問，軟件組件是 松耦合’loosely coupled’，這些組件的大部分通過幾行代碼就可以實現(xiàn)替換。目前這種方便的實現(xiàn)方式是使用XML進(jìn)行組件的配置。
JdonFramework/Spring都是這樣的一種框架，JdonFramework更進(jìn)步的是：JF框架本身的組件也是可以替換的，例如你希望在JF中使用Spring的配置文件，那么你只要做一個Spring配置文件的解析組件，然后替換JF框架原來的XML解析器就可以了。無論EJB2/EJB3等在這方面要稍遜于Ioc/AOP框架，對于支持EJB3的JBoss 4 這樣架構(gòu)，需要動態(tài)更換AOP攔截器還不是很方便，因為JBoss 4本身組件沒有象JF那樣做到可插拔配置，不過，JBoss 5已經(jīng)開始走上這條路，使用一個微核心來管理所有的可插拔組件，我曾經(jīng)在"JBoss 5迎來中間件徹底的可配置時代"一文中提出組件是否方便替換是衡量一個組件框架的重要指標(biāo)。
在最近的TheServerSide文章’Service Access’ to the software components中，[考試大收集]主要是談?wù)摿吮憩F(xiàn)層組件的替換訪問方式，GIF這樣圖片組件不可以隨意控制調(diào)整，基本不能復(fù)用，但是通過SVG或XUI等支持XML組件動態(tài)替換技術(shù)的使用，則可以實現(xiàn)顯示圖形組件的復(fù)用。
SOA
在軟件運行時，給予用戶動態(tài)插拔式更換組件，達(dá)到復(fù)用的組件更加適合變化的需求，
這是軟件業(yè)追求的目標(biāo)，而SOA(Service Oriented Architecture)則是從另外一種方向
也是在運行時提供用戶一種改變系統(tǒng)的能力。
SCBA(Services and Components Based Architecture), SCBA是通過減少需求變化帶來的傳遞損耗和時間來實現(xiàn)的，當(dāng)需求變化時，SOA的服務(wù)將支持跟進(jìn)變化和替換。
SCBA更強(qiáng)調(diào)的是一種業(yè)務(wù)過程重用，而且是跨組織跨多個專業(yè)域范圍的，例如我以前說的四色圖實際是對跨域范圍的業(yè)務(wù)總結(jié)，特別是ERP域范圍，大多數(shù)企業(yè)系統(tǒng)都是由MI等四種原始模型組成的，例如JiveJdon3看上去只是一個論壇系統(tǒng)，實際不只是，它的Message模型可以重用在網(wǎng)站內(nèi)容系統(tǒng)、新聞發(fā)布系統(tǒng)、電子商務(wù)系統(tǒng)、倉庫管理系統(tǒng)、資源管理系統(tǒng)等跨域范圍中（部分已經(jīng)實現(xiàn)）。
既然業(yè)務(wù)過程和IT系統(tǒng)可以跨組織跨域重用，那么類似軟件系統(tǒng)的維護(hù)和開發(fā)就不必再重新開發(fā)，JiveJdon3的Message模型重用在新聞發(fā)布系統(tǒng)中，我需要把JiveJdon3的項目拷貝到新聞發(fā)布系統(tǒng)中，然后再針對新聞發(fā)布系統(tǒng)特點做些裁剪修改，這這種復(fù)制業(yè)會帶來工作量和維護(hù)量，而SCBA則可以解決這個問題，通過運行時single-copy reuse分享各種服務(wù)功能。
總結(jié)
本文總結(jié)了軟件復(fù)用的不同層次：設(shè)計復(fù)用、組件架構(gòu)復(fù)用以及業(yè)務(wù)模型復(fù)用，復(fù)用技術(shù) 的不斷發(fā)展正是由于適應(yīng)變化需求的要求不斷提高導(dǎo)致，本人從2002年開始從事復(fù)用技術(shù)研究，最初從復(fù)用層次底層設(shè)計模式開始，在國內(nèi)媒體第一次全面分析了GoF設(shè)計模式，經(jīng)過這幾年發(fā)展，親身體會復(fù)用技術(shù)已經(jīng)進(jìn)入了一個新的階段。特寫此文作為小結(jié)。
適應(yīng)需求變化
現(xiàn)如今是一個計劃趕不上變化的時代，企業(yè)競爭力逐漸表現(xiàn)在企業(yè)適應(yīng)變化能力的競爭，誰能更快適應(yīng)市場的變化，誰就能夠在競爭中勝出，這種快速適應(yīng)能力如果靠“人民戰(zhàn)爭”無疑是不現(xiàn)實的，軟件可以幫助我們來適應(yīng)這種快速變化。
談到這里，稍微再說明一下國人軟件教育的誤區(qū)，不錯，軟件曾經(jīng)是科學(xué)計算的工具，因此，我們非常注重軟件的算法和數(shù)據(jù)結(jié)構(gòu)，甚至將之作為數(shù)學(xué)的衍生物，但是，現(xiàn)如今已經(jīng)成為一種幫助我們快速響應(yīng)變化的有力工具，如果我們的教育背景中只有算法和數(shù)據(jù)結(jié)構(gòu)，能夠編制出應(yīng)付快速變化的軟件嗎？很顯然，他們是風(fēng)馬牛不相及，由此可見國人軟件概念和軟件教育的落后性，在這樣的軟件認(rèn)識背景下，固然設(shè)計模式的崇高位置得不到確立，軟件設(shè)計被拋棄在腦后，編制出的大多數(shù)企業(yè)軟件系統(tǒng)根本不具備應(yīng)付變化的能力，程序員拒絕頻繁更改程序，甚至借助技術(shù)原因阻擾軟件的頻繁更改，這種軟件程序員和軟件用戶之間的矛盾可以稱為miscommunication， miscommunication是導(dǎo)致軟件系統(tǒng)的失敗一個重要原因。
國內(nèi)早就有言論：“不上ERP等死；上了ERP找死”，如果你的企業(yè)不上ERP，那么你的企業(yè)就不能借助軟件應(yīng)付快速的市場等環(huán)境變化，那么必然會被淘汰；但是，如果上了一個不注重“適應(yīng)需求變化”的ERP軟件系統(tǒng)，那就是企業(yè)被僵化的ERP軟件框死，喪失了使用ERP的根本目的。
適應(yīng)需求變化則成為現(xiàn)代軟件系統(tǒng)一個孜孜不倦的追求目標(biāo)，那么如何實現(xiàn)呢？
原則：給予人們可以裁剪他們系統(tǒng)的能力應(yīng)適應(yīng)需求變化，建立一個適應(yīng)需求變化的系統(tǒng)，允許系統(tǒng)在一系列小的、可控制的步驟上進(jìn)行改變?！ ?BR> 組件誕生
將不變的通用的東西抽象出來，以達(dá)到在不同項目中重用復(fù)用，將我們有限的精力集中在項目具體變化和特點上。當(dāng)然這些抽象復(fù)用的東西之間彼此必須是松耦合，這樣才能根據(jù)需求挑選組合。
讓我們先回顧一下軟件的發(fā)展史，軟件開發(fā)的發(fā)展史實際是一部我們思維不斷抽象拔高的發(fā)展過程，這種抽象概念非常類似于建模的思考方式：概要貼切地描述事物，忽視次要的細(xì)節(jié)。抽象體現(xiàn)在軟件開發(fā)上就是每個具體項目需要完成的代碼行數(shù)量越來越少。
從1970到1980這段時間，軟件開發(fā)從機(jī)器語言到匯編語言。進(jìn)而發(fā)展到高級語言，甚至一些CASE工具，面向功能編程發(fā)展到面向?qū)ο缶幊?，功能模塊重用細(xì)化到類的重用，類的重用是最初是通過設(shè)計模式實現(xiàn)的。
進(jìn)入90年代中期，誕生了基于組件的開發(fā)模式（CBD：component based development），CBD將抽象概念帶往了一個新的方向，與減少代碼數(shù)量相反，CBD將功能各個方面細(xì)化分離到不同的、相互隔離層中，如表現(xiàn)層、業(yè)務(wù)邏輯層、持久層、安全層以及核心層等，并且可以管理這些組件之間的依賴關(guān)系，通過這種分離，我們可以提純細(xì)化組件功能，進(jìn)而產(chǎn)生可以重用的框架，如Struts框架可以重用在大部分應(yīng)用系統(tǒng)的表現(xiàn)層中，，Struts+JdonFramework+Hibernate是一個框架組合，代表一種架構(gòu)設(shè)計，這種架構(gòu)設(shè)計其實可以重用在大部分應(yīng)用系統(tǒng)，這種重用我稱之為架構(gòu)級別重用。
組件復(fù)用
軟件組件(Software components)是軟件提供業(yè)務(wù)或技術(shù)功能的基本單元或元素，這些單元可以獨立地被部署、他們可以自我管理并且被虛擬部署到網(wǎng)絡(luò)的任何地方，業(yè)務(wù)組件（(Business components)執(zhí)行業(yè)務(wù)邏輯、遵循一定的業(yè)務(wù)規(guī)則并且管理相應(yīng)的數(shù)據(jù)（數(shù)據(jù)庫操作稱為manage corporate data）；而技術(shù)組件(Technical components)則提供相應(yīng)的平臺以便業(yè)務(wù)組件可以依賴其上運行，例如權(quán)限、組件管理等。
JdonFramework/Spring都屬于一種技術(shù)組件框架，而我們具體項目的業(yè)務(wù)層代碼如果能夠提煉可以復(fù)用，則是業(yè)務(wù)組件；JdonFramework/Spring則都提供了業(yè)務(wù)組件賴于運行的一些核心底層機(jī)制，特別是組件的管理，如組件的創(chuàng)建、組件的獲得、組件的資源管理、組件的消亡等生命周期支持，所以，我們可以在JdonFramework/Spring中加入自己的業(yè)務(wù)組件，當(dāng)然，JdonFramework還提供了Session等狀態(tài)管理的支持功能，為業(yè)務(wù)組件提供了更廣闊的生命周期支持。
組件復(fù)用技術(shù)以前是停留在編譯前期，也就是說：我們在編程時，導(dǎo)入所需要的其他組件Jar包，然后混同我們的項目編譯部署，但是這需要通過專業(yè)技術(shù)人員實現(xiàn)，很顯然是不能適應(yīng)原則中第一句：給予人們可以裁剪他們系統(tǒng)的能力應(yīng)適應(yīng)需求變化，[考試大整理]這里的“人們”應(yīng)該是指軟件最終用戶，應(yīng)該給予用戶自己改變系統(tǒng)的能力，也就是說：需要提供軟件系統(tǒng)運行時能夠動態(tài)改變自身的能力。
組件復(fù)用技術(shù)以前停留在軟件編譯階段，現(xiàn)在則更靠前，必須在軟件運行階段，當(dāng)然對技術(shù)要求相當(dāng)高，需要語言支持RTTI（簡單又神秘的Class.forName發(fā)揮作用了），這在"Evolution, Architecture, and Metamorphosis"一文中被認(rèn)為是Metamorphosis，現(xiàn)在由于AOP技術(shù)出現(xiàn)，AOP有一種動態(tài)Weaving技術(shù)，實際就是在軟件運行時實現(xiàn)動態(tài)攔截，這樣給予終端用戶更大的改變系統(tǒng)能力，他們基本可以以動態(tài)插拔的概念實現(xiàn)多個組件的組合運行。在"AOP vs Decorator"一文中，我把編譯階段的組件組合方式（我更愿意稱為靜態(tài)組合）和運行時組合等兩種處理方式，合并稱為過濾器模式，如果你希望采取組件可插拔式的復(fù)用，就可以使用過濾器模式。
組件可插拔更換
為什么說組件的可插拔非常重要？
組件重用目的是為了更好地適應(yīng)需求變化，但是有了組件重用不代表就快速適應(yīng)需求變化，因為組件本身也會產(chǎn)生設(shè)計錯誤（提煉得不夠抽象或者組件很難以替代），這就必然導(dǎo)致軟件系統(tǒng)得維護(hù)成本提高，那么快速適應(yīng)需求變化的目標(biāo)也就成為一紙空文。實踐證明：組件設(shè)計問題已經(jīng)成為導(dǎo)致軟件開發(fā)失敗的一個主要因素。
組件設(shè)計有兩個主要風(fēng)險：組件提純的純度和組件的替代方式。提煉的純度也就是抽象的高度，組件的抽象程度越高，當(dāng)然可重用范圍越廣，但是往往我們只有經(jīng)歷多個項目后，才發(fā)現(xiàn)自己的組件提煉還欠火候，這實際是組件的提煉過程成本。
組件提練雖然取決于人為設(shè)計因素，但是在實現(xiàn)手段上也依賴于組件的替換方式，通過經(jīng)常反復(fù)頻繁的微調(diào)和更換，才能將組件不斷提煉向理想狀態(tài)靠攏，所以，必須有一種方便的組件替換方式提供頻繁更換支持，我們總不希望更換組件象以前更換汽車發(fā)動機(jī)火花塞一樣，需要拆開汽車，打開發(fā)動機(jī)那樣麻煩吧？
參考PC電腦硬件設(shè)計：更新CPU或內(nèi)存條，只要直接插拔就可以，這些部件和母版都是一種松散的、可插拔的關(guān)系，如果軟件組件替換是動態(tài)的可插拔更加方便終端用戶在軟件系統(tǒng)交付后，根據(jù)需求改變他們的系統(tǒng)。組件可插拔本質(zhì)上是這些組件必須是化的松耦合，彼此依賴影響非常小，換句話說：如果實現(xiàn)了可插拔更換，說明你的組件已經(jīng)實現(xiàn)松耦合了。
那就有可能設(shè)計一種軟件框架：它能夠為每個部件提供非常棒的服務(wù)訪問，軟件組件是 松耦合’loosely coupled’，這些組件的大部分通過幾行代碼就可以實現(xiàn)替換。目前這種方便的實現(xiàn)方式是使用XML進(jìn)行組件的配置。
JdonFramework/Spring都是這樣的一種框架，JdonFramework更進(jìn)步的是：JF框架本身的組件也是可以替換的，例如你希望在JF中使用Spring的配置文件，那么你只要做一個Spring配置文件的解析組件，然后替換JF框架原來的XML解析器就可以了。無論EJB2/EJB3等在這方面要稍遜于Ioc/AOP框架，對于支持EJB3的JBoss 4 這樣架構(gòu)，需要動態(tài)更換AOP攔截器還不是很方便，因為JBoss 4本身組件沒有象JF那樣做到可插拔配置，不過，JBoss 5已經(jīng)開始走上這條路，使用一個微核心來管理所有的可插拔組件，我曾經(jīng)在"JBoss 5迎來中間件徹底的可配置時代"一文中提出組件是否方便替換是衡量一個組件框架的重要指標(biāo)。
在最近的TheServerSide文章’Service Access’ to the software components中，[考試大收集]主要是談?wù)摿吮憩F(xiàn)層組件的替換訪問方式，GIF這樣圖片組件不可以隨意控制調(diào)整，基本不能復(fù)用，但是通過SVG或XUI等支持XML組件動態(tài)替換技術(shù)的使用，則可以實現(xiàn)顯示圖形組件的復(fù)用。
SOA
在軟件運行時，給予用戶動態(tài)插拔式更換組件，達(dá)到復(fù)用的組件更加適合變化的需求，
這是軟件業(yè)追求的目標(biāo)，而SOA(Service Oriented Architecture)則是從另外一種方向
也是在運行時提供用戶一種改變系統(tǒng)的能力。
SCBA(Services and Components Based Architecture), SCBA是通過減少需求變化帶來的傳遞損耗和時間來實現(xiàn)的，當(dāng)需求變化時，SOA的服務(wù)將支持跟進(jìn)變化和替換。
SCBA更強(qiáng)調(diào)的是一種業(yè)務(wù)過程重用，而且是跨組織跨多個專業(yè)域范圍的，例如我以前說的四色圖實際是對跨域范圍的業(yè)務(wù)總結(jié)，特別是ERP域范圍，大多數(shù)企業(yè)系統(tǒng)都是由MI等四種原始模型組成的，例如JiveJdon3看上去只是一個論壇系統(tǒng)，實際不只是，它的Message模型可以重用在網(wǎng)站內(nèi)容系統(tǒng)、新聞發(fā)布系統(tǒng)、電子商務(wù)系統(tǒng)、倉庫管理系統(tǒng)、資源管理系統(tǒng)等跨域范圍中（部分已經(jīng)實現(xiàn)）。
既然業(yè)務(wù)過程和IT系統(tǒng)可以跨組織跨域重用，那么類似軟件系統(tǒng)的維護(hù)和開發(fā)就不必再重新開發(fā)，JiveJdon3的Message模型重用在新聞發(fā)布系統(tǒng)中，我需要把JiveJdon3的項目拷貝到新聞發(fā)布系統(tǒng)中，然后再針對新聞發(fā)布系統(tǒng)特點做些裁剪修改，這這種復(fù)制業(yè)會帶來工作量和維護(hù)量，而SCBA則可以解決這個問題，通過運行時single-copy reuse分享各種服務(wù)功能。
總結(jié)
本文總結(jié)了軟件復(fù)用的不同層次：設(shè)計復(fù)用、組件架構(gòu)復(fù)用以及業(yè)務(wù)模型復(fù)用，復(fù)用技術(shù) 的不斷發(fā)展正是由于適應(yīng)變化需求的要求不斷提高導(dǎo)致，本人從2002年開始從事復(fù)用技術(shù)研究，最初從復(fù)用層次底層設(shè)計模式開始，在國內(nèi)媒體第一次全面分析了GoF設(shè)計模式，經(jīng)過這幾年發(fā)展，親身體會復(fù)用技術(shù)已經(jīng)進(jìn)入了一個新的階段。特寫此文作為小結(jié)。