前面描述的是应用程序和类库之间的依赖关系。如果我们开发的不是类库，而是框架系统，依赖关系就会更强烈一点。那么，该如何消解框架和应用程序之间的依赖关系呢？
　　《道法自然》第5章描述了框架和类库之间的区别：
　　“框架和类库最重要的区别是：框架是一个‘半成品’的应用程序，而类库只包含一系列可被应用程序调用的类。
　　“类库给用户提供了一系列可复用的类，这些类的设计都符合面向对象原则和模式。用户使用时，可以创建这些类的实例，或从这些类中继承出新的派生类，然后调用类中相应的功能。在这一过程中，类库总是被动地响应用户的调用请求。
　　“框架则会为某一特定目的实现一个基本的、可执行的架构。框架中已经包含了应用程序从启动到运行的主要流程，流程中那些无法预先确定的步骤留给用户来实现。程序运行时，框架系统自动调用用户实现的功能组件。这时，框架系统的行为是主动的。
　　“我们可以说，类库是死的，而框架是活的。应用程序通过调用类库来完成特定的功能，而框架则通过调用应用程序来实现整个操作流程。框架是控制倒置原则的完美体现。”
　　框架系统的一个最好的例子就是图形用户界面（GUI）系统。一个简单的，使用面向过程的设计方法开发的GUI系统如图 5所示。 

　从图 5中可以看出，应用程序调用GUI框架中的CreateWindow()函数来创建窗口，在这里，我们可以说应用程序依赖于GUI框架。但GUI框架并不了解该窗口接收到窗口消息后应该如何处理，这一点只有应用程序最为清楚。因此，当GUI框架需要发送窗口消息时，又必须调用应用程序定义的某个特定的窗口函数（如上图中的MyWindowProc）。这时，GUI框架又必须依赖于应用程序。这是一个典型的双向依赖关系。这种双向依赖关系有一个非常严重的缺陷：由于GUI框架调用了应用程序中的某个特定函数（MyWindowProc）， GUI框架根本无法独立存在；换一个新的应用程序，GUI框架多半就要做相应的修改。因此，如何消解框架系统对应用程序的依赖关系是实现框架系统的关键。
　　并非只有面向对象的方法才能解决这一问题。WIN32 API早就为我们提供了在面向过程的设计思路下解决类似问题的范例。类WIN32 的架构模型如图 6所示。 

在图 6中，应用程序调用CreateWindow()函数时，要传递一个消息处理函数的指针给GUI框架（对WIN32而言，我们在注册窗口类时传递这一指针），GUI框架把该指针记录在窗口信息结构中。需要发送窗口消息时，GUI框架就通过该指针调用窗口函数。和图 5 相比，GUI框架仍然需要调用应用程序，但这一调用从一个硬编码的函数调用变成了一个由应用程序事先注册被调用对象的动态调用。图 6用一条虚线表示这种动态调用。可以看出，这种动态的调用关系有一个非常大的好处：当应用程序发生变化时，它可以自行改变框架系统的调用目标，GUI框架无需随之发生变化。现在，我们可以说，虽然还存在着从GUI框架到应用程序的调用关系，但GUI框架已经完全不再依赖于应用程序了。这种动态调用机制通常也被称为“回调函数”。
　　在面向对象领域，“回调函数”的替代物就是“模板方法模式”，也就是“好莱坞原则（不要调用我们，让我们调用你）”。GUI框架的一个面向对象的实现如图 7所示。 

　图 7中，“GUI框架抽象接口”是GUI框架系统提供给应用程序使用的接口。抽象出该接口的动机是根据“依赖倒置”的原则，消解从应用程序到GUI框架之间的直接依赖关系，以使得GUI框架实现的变化对应用程序的影响最小化。Window接口类则是“模板方法模式”的核心。应用程序调用CreateWindow()函数时，GUI框架会把该窗口的引用保存在窗口链表中。需要发送窗口消息时，GUI框架就调用窗口对象的SendMessage()函数，该函数是实现在Window类中的非虚成员函数。SendMessage()函数又调用WindowProc()虚函数，这里实际执行的是应用程序MyWindow类中实现的WindowProc()函数。在图 7中，我们已经看不到从GUI框架到应用程序之间的直接依赖关系了。因此，模板方法模式完全实现了回调函数的动态调用机制，消解了从框架到应用程序之间的依赖关系。
　　从上面的分析可以看出，模板方法模式是框架系统的基础，任何框架系统都离不开模板方法模式。Martin Fowler也说 [Folwer 2004]，“几位轻量级容器的作者曾骄傲地对我说：这些容器非常有用，因为它们实现了‘控制反转’。这样的说辞让我深感迷惑：控制反转是框架所共有的特征，如果仅仅因为使用了控制反转就认为这些轻量级容器与众不同，就好像在说‘我的轿车是与众不同的，因为它有四个轮子’。问题的关键在于：它们反转了哪方面的控制？我第一次接触到的控制反转针对的是用户界面的主控权。早期的用户界面是完全由应用程序来控制的，你预先设计一系列命令，例如‘输入姓名’、‘输入地址’等，应用程序逐条输出提示信息，并取回用户的响应。而在图形用户界面环境下，UI 框架将负责执行一个主循环，你的应用程序只需为屏幕的各个区域提供事件处理函数即可。在这里，程序的主控权发生了反转：从应用程序移到了框架。”
　　确实：对比图 3和图 7可以看出，使用普通类库时，程序的主循环位于应用程序中，而使用框架系统的应用程序不再包括一个主循环，只是实现某些框架定义的接口，框架系统负责实现系统运行的主循环，并在必要的时候通过模板方法模式调用应用程序。
　　也就是说，虽然“依赖倒置”和“控制反转”在设计层面上都是消解模块耦合的有效方法，也都是试图令具体的、易变的模块依赖于抽象的、稳定的模块的基本原则，但二者在使用语境和关注点上存在差异：“依赖倒置”强调的是对于传统的、源于面向过程设计思想的层次概念的“倒置”，而“控制反转”强调的是对程序流程控制权的反转；“依赖倒置”的使用范围更为宽泛，既可用于对程序流程的描述（如流程的主从和层次关系），也可用于描述其他拥有概念层次的设计模型（如服务组件与客户组件、核心模块与外围应用等），而“控制反转”则仅适用于描述流程控制权的场合（如算法流程或业务流程的控制权）。
　　从某种意义上说，我们也可以把“控制反转”看作是“依赖倒置”的一个特例。例如，用模板方法模式实现的“控制反转”机制其实就是在框架系统和应用程序之间抽象出了一个描述所有算法步骤原型的接口类，框架系统依赖于该接口类定义并实现程序流程，应用程序依赖于该接口类提供具体算法步骤的实现，应用程序对框架系统的依赖被“倒置”为二者对抽象接口的依赖。
　　总地说来，应用程序和框架系统之间的依赖关系有以下特点：
　　1. 应用程序和框架系统之间实际上是双向调用，双向依赖的关系。
　　2. 依赖倒置原则可以减弱应用程序到框架之间的依赖关系。
　　3. “控制反转”及具体的模板方法模式可以消解框架到应用程序之间的依赖关系，这也是所有框架系统的基础。
　　4. 框架系统可以独立重用。

依赖注入（Dependency Injection）