適當的使用設計模式。設計模式代表了先進的軟件設計思路。在框架中適當的使用設計模式有助于改進框架的結構。例如在上例中，擴展點的設計就采用了回調的設計模式。在框架設計中不宜采用過多的設計模式，這會使得框架理解起來困難。當然也有反例。
反例-Junit Framework。作為自動化單元測試框架，Junit在簡小的設計中采用了大量的設計模式，包括Command模式、Template Method模式、Collecting Parameter模式、Pluggable Selector模式、Adapter模式、Composite模式等。
簡化框架的使用。在上例中，框架的擴展點設計完畢后，使用框架的代碼仍然比較復雜，回調接口和匿名類仍然會把人弄的有些莫名其妙。所以，為了使框架使用方便，一定程度的簡化還是需要的。
在Junit框架中，我們只需要讓測試方法以test開頭就能夠自動進行測試，而這種功能是Command模式無法提供的。按照Command模式的要求，一個測試類只能包括一個測試方法。原因就在于Junit中利用了Pluggable Selector模式、Adapter模式、以及反射技術對Command模式作了新的封裝：
protected void runTest() throws Throwable {
Method runMethod= null;
try {
runMethod= getClass().getMethod(fName, new Class[0]);
} catch (NoSuchMethodException e) {
assert("Method \""+fName+"\" not found", false);
}
try {
runMethod.invoke(this, new Class[0]);
}
// catch InvocationTargetException and IllegalAccessException
}
隔離第三方技術。
當前的軟件開發向著協作的方向發展。在這種情況下，大量的第三方軟件出現了。軟件業的分工將會給軟件業帶來繁榮，但是對于軟件組織來說，就需要考慮第三方軟件的成本、生命力、本組織系統對其的依賴程度等問題。這部分的工作應該交給框架。讓框架來負責把核心應用和第三方技術隔離開來。例如，作為企業應用的開發者，我發現在數據庫層次上的變化實在是太大了，新的xquery查詢語言、ORM技術，這些都使得應用系統需要不斷的變化。這無疑給應用系統增加了風險。因此，我決定設計一個抽象的層次，把這些技術和核心應用隔離起來。抽象層次只負責向數據庫詢問符合某種條件的數據，至于這個查詢采用sql還是xquery來處理那都沒有關系。因此技術細節被隔離了。
另一個實例
文章來源于領測軟件測試網 http://www.kjueaiud.com/
