适当的使用设计模式。设计模式代表了先进的软件设计思路。在框架中适当的使用设计模式有助于改进框架的结构。例如在上例中，扩展点的设计就采用了回调的设计模式。在框架设计中不宜采用过多的设计模式，这会使得框架理解起来困难。当然也有反例。
反例-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来处理那都没有关系。因此技术细节被隔离了。
另一个实例
文章来源于领测软件测试网 https://www.ltesting.net/
