代碼復用是絕大多數程序員所期望的，也是OO的目標之一。總結我多年的編碼經驗，為了使代碼能夠最大程度上復用，應該特別注意以下幾個方面。
對接口編程
"對接口編程"是面向對象設計（OOD）的第一個基本原則。它的含義是：使用接口和同類型的組件通訊，即，對於所有完成相同功能的組件，應該抽象出一個接口，它們都實現該接口。具體到JAVA中，可以是接口（interface），或者是抽象類（abstract class），所有完成相同功能的組件都實現該接口，或者從該抽象類繼承。我們的客戶代碼只應該和該接口通訊，這樣，當我們需要用其它組件完成任務時，只需要替換該接口的實現，而我們代碼的其它部分不需要改變！
當現有的組件不能滿足要求時，我們可以創建新的組件，實現該接口，或者，直接對現有的組件進行擴展，由子類去完成擴展的功能。
優先使用對象組合，而不是類繼承
"優先使用對象組合，而不是類繼承"是面向對象設計的第二個原則。並不是說繼承不重要，而是因為每個學習OOP的人都知道OO的基本特性之一就是繼承，以至於繼承已經被濫用了，而對象組合技術往往被忽視了。下面分析繼承和組合的優缺點：
類繼承允許你根據其他類的實現來定義一個類的實現。這種通過生成子類的復用通常被稱為白箱復用(white-box reuse)。術語"白箱"是相對可視性而言：在繼承方式中，父類的內部細節對子類可見。
對象組合是類繼承之外的另一種復用選擇。新的更復雜的功能可以通過組合對象來獲得。對象組合要求對象具有良好定義的接口。這種復用風格被稱為黑箱復用(black-box reuse)，因為被組合的對象的內部細節是不可見的。對象只以"黑箱"的形式出現。
繼承和組合各有優缺點。類繼承是在編譯時刻靜態定義的，且可直接使用，類繼承可以較方便地改變父類的實現。但是類繼承也有一些不足之處。首先，因為繼承在編譯時刻就定義了，所以無法在運行時刻改變從父類繼承的實現。更糟的是，父類通常至少定義了子類的部分行為，父類的任何改變都可能影響子類的行為。如果繼承下來的實現不適合解決新的問題，則父類必須重寫或被其他更適合的類替換。這種依賴關系限制了靈活性並最終限制了復用性。
對象組合是通過獲得對其他對象的引用而在運行時刻動態定義的。由於組合要求對象具有良好定義的接口，而且，對象只能通過接口訪問，所以我們並不破壞封裝性；只要類型一致，運行時刻還可以用一個對象來替代另一個對象；更進一步，因為對象的實現是基於接口寫的，所以實現上存在較少的依賴關系。
優先使用對象組合有助於你保持每個類被封裝，並且只集中完成單個任務。這樣類和類繼承層次會保持較小規模，並且不太可能增長為不可控制的龐然大物（這正是濫用繼承的後果）。另一方面，基於對象組合的設計會有更多的對象(但只有較少的類)，且系統的行為將依賴於對象間的關系而不是被定義在某個類中。
注意：理想情況下，我們不用為獲得復用而去創建新的組件，只需要使用對象組合技術，通過組裝已有的組件就能獲得需要的功能。但是事實很少如此，因為可用的組件集合並不豐富。使用繼承的復用使得創建新的組件要比組裝已有的組件來得容易。這樣，繼承和對象組合常一起使用。然而，正如前面所說，千萬不要濫用繼承而忽視了對象組合技術。
相關的設計模式有： Bridge、Composite、Decorator、Observer、Strategy等。
下面的例子演示了這個規則，它的前提是：我們對同一個數據結構，需要以任意的格式輸出。
第一個例子，我們使用基於繼承的框架，可以看到，它很難維護和擴展。
abstract class AbstractExampleDocument
{
// skip some code ...
public void output(Example structure)
{
if( null != structure )
{
this.format( structure );
}
}
protected void format(Example structure);
}
