原文在這：http://www.ddj.com/architect/184415594?cid=Ambysoft
爲了獲得面向對象重用的好處，你必須懂得各類的面向對象重用手法，並且要知道在哪裏以及如何運用它們。
可重用性是面向對象技術的一大特點。然而遺憾的是，這個特性往往不容易應用於實踐中。原因是，重用也並不是免費的，並不是說你使用一些面向對象開發工具就可以簡單達到的。相反，你必須付出很大的努力才能達到較好的重用。第一個要面對的問題是，應該是重用而不是僅僅是代碼重用。代碼重用是重用技術中效率最低的一種方式。這裏不要誤解我的意思，代碼重用還是一種好的方法，但是有可能對你的其他地方的重用造成一些隱患。我們是在開發應用程序，而不僅僅是寫代碼，所以你應該更多的考慮重用而不是代碼重用。下面，讓我們詳細地看看各類的重用技術，看看當你在開發應用程序的時候，什麼地方你可以使用它們。
代碼重用
代碼重用爲最常見的一種重用方式，可能是同一個應用程序中一些部分源代碼的重用，也可能不同應用程序中重用。在最好的情況下，可以通過共享一些類或者一些功能塊或程序段（C++中可行，Smarttalk和Java不不行）來達到代碼重用。在最壞的情況下，可以通過複製，然後修改代碼來達到代碼重用。在業界，一種可悲的現狀是，代碼複製爲開發者使用的唯一的一種代碼重用方式。
代碼重用的一個關鍵點是，你已經弄清楚了源代碼。需要的話，你可以自己修改來重用，或者讓別人幫你修改。這樣有好有壞。通過閱讀代碼，雖然這樣做常常比較慢，但是你可以決定是否使用它。但是，另一方面，由於整個代碼都給你了，而代碼的最初編寫者可能沒有很好地編寫一些文檔，這樣則可能增加你理解代碼的時間，結果減少代碼重用帶來的好處。
代碼重用最主要的好處是可以減少你實際需要編寫的代碼量，從而間接減少了開發和維護的成本。缺點是代碼重用的效果僅僅侷限於開發，而且它常常會增加應用程序的耦合性。
繼承重用
繼承重用意味着在你的應用程序中使用繼承，從而可以直接使用一些已經存在的類實現好的行爲。繼承是面向對象的基本概念，它可以讓你對“is a”，"is like"，"is kind of"等概念進行建模。例如，爲了開發一個“ CheckingAccount”的類，你可以讓它繼承自" SavingsAccount"，然後直接重用後者實現的所有行爲。
繼承重用的好處是你可以直接使用先前開發好的行爲，這樣能同時減少開發和維護的成本。但是，很遺憾，繼承重用存在一些缺點。第一，繼承的錯誤使用常常會導致開發者無法進行模塊重用，而模塊重用可以提供更高層面的重用。第二，初級開發者往往會忽視對繼承的迴歸測試（在一個子類中運行父類的測試用例），從而導致脆弱的類繼承體系，最終難以維護以及增強。如你所見，這也是重用，但是應該避免。
模板重用
模板重用爲文檔重用的一種形式。它一般指組織內部一些重要的文檔、模型、源代碼的共同格式或風格。例如，組織內部很常見的一些共用的模板，如用例、狀態報告、開發進度安排、變更報告、需求、類文件以及方法註釋等。文檔模板的主要優點是可以增加文檔的一致性和質量，而缺點是開發可能根據自己的想法修改模板，但是修改後沒有與項目成員說明。
使用模板的最好效果是，你可以讓開發者非常簡單的使用他們。我見過一些模板的實現， 簡單的如Mirosoft的Word文檔的模板，複雜的如Lotus Notes，帶有一個可以被所有開發者共享的數據庫。你的組織也必須提供一些培訓，以便組織內的每個人都能正確地知道在何時如何使用何種模板。
組件重用
組件重用指在你的應用程序開發過程中使用先前已經構建、而且完全封裝好的組件。組件一般是自成體系的，並且僅封裝了一個完整概念。與代碼重用不用，組件重用無需你去看源代碼；而與繼承重用不同，組件重用無需你使用子類。Java Bean和ActiveX爲比較常見的組件。
組件重用有幾個優點。第一，組件重用比代碼重用或繼承重用提供更廣泛的可重用性。因爲組件是自成體系的，所以使用時你僅需插入他們，然後他們即可工作。第二，一些通用平臺（如Win32操作系統，Java虛擬機）的廣泛使用開闢了一個巨大的組件市場，第三方的計算機廠家可以自己開發並且以一個比較低的價格銷售這些組件。組件重用的缺點是，組件一般比較小而同時封裝了一個完整的概念，所以往往需要大量的與他相關的開發包。
用戶接口是使用組件的最簡單的方式，如狀態欄、圖形化組件、圖形化按鈕等。但是別忘了，除了用戶接口外對一個應用程序來說還有很多其他方式。你可以獲取一個封裝了操作系統網絡能力的組件，或者一個封裝了持久層能力的組件（如與關係數據庫交換的組件）。如果你想構建自己的組件，那麼確保他們僅僅只做一件事情。例如，一個用於編輯信件地址的組件就具有很好的重用性，因爲你可以很多需要編輯郵件地址的場合。而一個可以用於編輯信件地址、E-Mail地址和電話號碼的組件則不是很好重用，因爲沒有多少場合同時需要這三個特性。相反，最好是構建三個這樣可重用的組件，在需要的地方挨個使用即可。當一個組件只封裝了一個概念的時候，它是一個內聚的組件。
框架重用
框架重用是指使用一系列已經實現好的、與某項技術或商業領域相關的、提供基礎功能的類。開發者以框架爲基礎開始構建他們自己的應用程序。在此過程中，80%的通用基礎框架已經構建好了，你只需增加與你應用相關的20%即可。實現了GUI基礎組件的框架是一個很常見的例子。有各式各樣的框架應用不用的領域，如保險業、人力資源、製造業、銀行業、電子商務。框架重用是一種領域層面的高級重用技術。
框架提供了對問題域的一個基本解決方式，並且封裝了一些比較複雜的邏輯，而這些邏輯的開發可能需要花費數年的時間。然而很不幸，框架重用需面對一些不足。複雜的框架難於掌控，對部分開發者來說，需要一個較長的學習時間。框架往往是與平臺相關的，這樣會使得你的應用與某個計算機廠商綁定，從而增加應用的風險。雖然框架實現了你需要的80%的邏輯，但是它們往往是最簡單的那80%；而比較困難的那部分，比如商業邏輯或者對你組織而已需要特殊處理的邏輯，則還需要你自己來實現。框架之間通常不能同時工作，除非他們是來自同一個計算機廠商或者是協會的。他們往往需要你改變自己的應用來適應框架的變化，而不說使用其他方式。
現有重用
現有重用是指使用先前已經開發好的一些東西，如用例、標準文檔、領域模型、流程、綱要和一些可以讓你的新項目儘快開始的參考項目。現有重用有幾種不同的級別，有完全的重用，如：你可以完全把現有的項目作爲你的新項目或者把它使用到新項目中，也有很少重用，如，你可以看看以前的項目，獲得一些想法標準文檔，如編碼標準和用戶接口標準是一些很好的現有的東西，可以作爲一些模型文檔和方法指導文檔在項目之間重用。我們也能夠通過一般數據接口或者通過使用面向對象的方式進行包裝來重用現有項目。
現有重用強調項目之間的一致性以及減少對每個新項目管理上負擔。另一個好處是，你可以買到一些現有的東西或者在網上找到這類東西，如：用戶接口標準（大部分平臺都有），主流語言的編碼標準，面向對象方法來的標準，建模符號的標準（早就出現很多年了）。現有重用的最大缺點是，它常常被一些頑固不化的程序員認爲過度使用了，因爲你僅僅是把一些標準和流程從一張桌子搬到另一個。總之，現有重用非常重要而它是一種需要長時間積累的技術，不應該忽略它。
模式重用
模式重用是指重用一些公開的、文檔化的的方法來解決一些常見問題。模式一般由單個類圖來描述，通常有一到五個類。使用模式重用，你不是重用代碼，而是重用這些代碼背後的思想。模式是一種很高層面的重用，而且有很長的生存期——至少超過你正在使用的計算機語言，而且有可能超過面向對象語義本身。
接觸點模式（ The Contact Point ），從我的書（Building Object Applications That Work）修改而來，使用了UML（統一建模語言）類圖進行建模，展示了一種能夠跟蹤你的組織與其他商業組織之間的接觸點的通用模式。這個模式說明你可以把E-Mail地址、通信地址、電話號碼等看做同一類東西，可以稱之爲對象接觸點，通過這些接觸點，你的組織可以與其他商業組織（如：客戶、員工、供應商等）進行交互。這個模式增加了你應用程序的可擴展性。舉例說，你不僅可以郵寄一份發票給客戶，同樣也可以使用E-Mail或者傳真給客戶；無需郵寄一個光盤或錄像帶到某個通信地址，你可以以電子的方式傳送這類產品。接觸點模式是以上這類事情成爲可能的關鍵一環。我已經在機構應用中成功的使用了此分析模式，並且重用了這個模型最困難的部分——模式背後的思想。模式重用是一種高層面的重用，你可以跨越多種語言和平臺來實現這種重用。模式封裝了開發中最重要的一個方面——解決問題的方法。模式增加了系統的可維護性，並且通過使用被廣大經驗豐富的面向對象開發者所認可的解決問題的通用方式，來增強你的應用程序。模式重用的缺點是，模式無法提供即時的解決——你必須編寫代碼來實現模式。
領域組件重用
領域組件重用是指對大型的、可重用的商業組件的識別以及開發。一個領域組件是能提供一組內聚的功能的相關領域和商業類的集合。例如，一個電信公司的組件圖上有幾個領域組件，每個封裝了很多類。服務提供組件封裝了100多個類，從處理長途電話的類，到有線電視的，到互聯網服務的都有。在你的組織中，一個新項目一般通過架構驅動的建模過程來識別出各個領域組件，然後在開發過程中進行修改和增強。
領域組件能夠提供最強的可重用性，因爲領域組件封裝了大規模的、內聚的商業行爲，而這些商業行爲可以應用到很多應用程序中。你在針對某一領域進行開發的所以東西，都應該考慮重用。領域組件是高效的架構級工具，他對商業行爲進行了很好的封裝以便日後重用。
對於以上這些重用方法，一個好消息是你能同時使用他們。沒錯，框架重用往往把你限定在某些框架或者一些標準或者一些指導方針中。但是，你同樣可以和框架重用一起使用其他重用。現有重用和組件重用是兩種開發新項目最簡單的方式；通過一點研究，你很快就會發現可以重用的東西。
你可以在網上買一個文檔模板，但是如果你的組織內部沒有很好訂閱開發過程的話，你可能無法享受模板帶來的好處。繼承重用和模式重用是建模者需要掌握的，他們會發現，應用這類重用是必修的一課。
從實踐角度說，我一般會使用現有重用和組件重用來訓練我的建模人員，然後讓他們適當的使用繼承重用和模式重用；使用架構驅動的開發方式來識別和開發領域組件；至於開發人員，我很信任他們，他們可以使用任何他們能用的重用方式。
從類的角度看待重用
現在，我們已經有了一些重用的工具，下面讓我們看看如何應用他們。四層的類架構說明了在每一層如何使用重用。因爲每一層有它自己獨特的屬性和開發要求，所以在每一層也應該使用適當的重用方法。讓我們來看看每層的具體情況。
用戶接口層封裝了屏幕和報表等，一些用戶用於與你的應用程序交互的東西。對於用戶接口層，最常見的重用方式顯然爲界面的組件重用。開發者常常會購買一些開發包，如：滾動條、圖表、列表和其他一些界面組件。現有重用對這層也很重要，例如，一些特有的用戶接口或者報表格式標準的重用。在設計用戶界面時，最重要的事情是一致性，而在你的應用程序中遵循一定的標準和指導原則是實現一致性的最簡單的方式。
業務層封裝了你的應用程序需要解決的問題的處理邏輯。模式重用，特別是分析模式重用，對業務層而言很重要。同樣，對業務層而言，框架重用以及一類基本業務類包的使用，也很重要。雖然這三種重用方式還相當地不成熟，但是他們正在很多商業領域中快速地發展。大量的模式正在從學校和企業中誕生，而一些基礎框架正在被大型的諮詢和技術公司創造，這些公司往往在一個或多垂直領域擁有領先水平。
然而，對於你的組織而言，更重要的是引入領域組件的重用。領域組件是以架構驅動、以重用爲目的開發的一個重要副產品。
持久層封裝並且抽象了你用於長期存儲對象的不同持久化機制，例如：關係數據庫、對象數據庫或一般的文件方式。對這一層而言，最重要的重用方式爲框架重用和組件重用。這是因爲你能夠購買完整實現的或者部分實現的持久層的包。使用設計模式重用的可能性也很大，因爲對持久層的設計方式已經有一些公開的出版物了。同時，組織內部的數據字典的現有重用也是有可能的。
系統層封裝和抽象了對操作系統的操作，如網絡、硬件和其他一些應用。設計模式的重用，尤其對硬件和應用的封裝，對系統層而且很常見，對一些包裝類的組件重用和現有重用也很常見。
在這所有四層中，代碼重用和繼承重用顯然都是適合的。當然，你也可以說在用戶接口層也可以使用模式重用。在整個項目中，對標準文檔、開發文檔的格式和流程的模板重用，具有重要意義。
成功使用重用的祕訣
你如何才能真正地達到面向對象的重用呢？我想你所需要做的，就是走出去，買一些工具或者存儲庫來存儲的你的可重用的東西作爲一個開始。當然了，重用不僅僅只是工具。事實上，很多組織的重用失敗就是因爲太注意了工具，而不是流程。這裏是一些重用的建議：
當一個東西被不同的組、使用在不同的項目至少三次以上後，你才能稱它爲可重用的。你可以在設計的適合就考慮重用，但是隻有當此應用的某些部分被使用了三次以上時，你才能說這個重用是成功的。
可重用的東西必須有很好文檔，同時還要有一個或幾個展示如何使用它們的實際例子。同時，文檔還應該說明什麼時候適合用它，什麼時候不應該用，以便開發者能知道它使用的場合。
把重用應用於實際的唯一方法是你時刻在爲重用做準備。你必須劃出一些必要的時間和資源，來確保你的工作可以重用。如果你不回顧並且花一些時間來總結一下你的工作的話，你是不可能做到重用的。因爲項目的壓力總在促使你把這些事情放到一邊。底線是，重用的管理（明確地重用一些東西、持續地增加一些可能重用的東西到重用庫中）是否是你工作的一部分，如果不是，則無需考慮。
重用是一種態度。當你開始一個項目時，你需要考慮的第一件事情就是你是否可以在應用中的某些部分重用其他項目的一些東西。可能其他人已經把你需要的東西做好了，可能你可以購買到一些組件或者可重用的東西。另一方面，你必須樂意與其他人分享你的工作成果，這樣他們就能重用你的東西了。一個優秀的項目領導者，必須時常地去發現一些可以重用的機會，去促進重用，並且最終使得他的隊伍從中受益。在開發的各個階段尋找重用，是實現重用的一個很好的方式：在建模階段，尋找繼承重用和模式重用；在編碼階段，尋找組件重用和代碼重用。
經常地，你可能不得不與“非創造者”（NIH）症狀做鬥爭。這個問題會阻止你在你的團隊中傳播重用的思想。對於NIH症狀，開發者會拒絕重用其他開發者的東西，因爲這個東西不是由他們自己開發的。 Pure hogwash，一名專業開發者，時常在其他項目中尋找一些他可以重用的東西，因爲這樣可以讓他們在開發自己的應用某些部分時，免去一些領域相關的工作。我的經驗是，比較專業的開發着往往樂意使用其他開發者的工作成果，當然，這些工作必須是高質量的、有很好文檔的、並且簡單易懂的。NIH症狀是虛構的，如果是真的，那麼面向對象開發環境就不會有這麼多類包了，當然，也用不着數百家公司出賣可重用的組件和框架了。
語言上的溝通往往是人們發現重用的一個方式。不錯，重用庫中放了很多好東西，但是，它跟你組織內部其他一些官方的束縛差不多。你可以通過官方渠道或者通過非正式的網絡渠道獲取重用庫中的東西，當然，你也可以從朋友那裏獲取。
重用是一個組織的事情，而不是一個項目的事情。很多組織因爲不知道重用的範圍而導致重用失敗。項目之間的重用能使你從重用中受益，不要僅在單個項目中重用。很多組織因爲在第一個項目中無法達到重用而過早地放棄了重用，其實這是很愚蠢的，因爲剛開始的時候，你確實沒有什麼可重用的東西。這也是使用架構驅動開發的一個重要原因，因爲它往往能看到比一個單獨項目更長遠的東西，這些東西能滿足整個組織的需要，並且對於那些重要的需求，在任何地方都應該考慮重用的規劃。
那種在任何地方都適用的重用是不實際的。有很多種方式可以實現重用，不同的層次上有不同需求需要不同的重用方式的組合。你必須知道並且根據情況做合理的計劃。
至於“不用重新發明輪子”這個說法，首先你需要知道的是，你手上有不止一個輪子供你使用。你可以重用源代碼、組件、現有的開發需要的東西、模式和模板。但是更重要的是，你需要知道，你的工作是不可重用的，因爲它是面向對象的。相反，你需要花時間在上面，讓他們可以重用。