在扩展框架的时候，我们常常会遇到“控制反转”这个现象，确实，它很多时候都被用来定义框架的特性。

现在我们来考虑一个简单的例子，假设我在写一个通过命令行的方式从用户那里获取信息的程序，我的程序会这样写：

  #ruby
  puts 'What is your name?'
  name = gets
  process_name(name)
  puts 'What is your quest?'
  quest = gets
  process_quest(quest)

在交互的过程中，我的程序处于控制状态：它决定何时问问题、何时给出回应、何时处理结果。

然而，如果我通过窗口的方式来做，那么我会通过配置窗口来实现：

  require 'tk'
  root = TkRoot.new()
  name_label = TkLabel.new() {text "What is Your Name?"}
  name_label.pack
  name = TkEntry.new(root).pack
  name.bind("FocusOut") {process_name(name)}
  quest_label = TkLabel.new() {text "What is Your Quest?"}
  quest_label.pack
  quest = TkEntry.new(root).pack
  quest.bind("FocusOut") {process_quest(quest)}
  Tk.mainloop()

在控制流程上，这两个程序有很大的不同，尤其在控制方法 process_name 和 process_quest 的调用上。在命令行的形式中，我的程序决定何时调用这些方法；而在使用窗口的例子中，则不是由我的程序来决定，我把控制交给了窗口系统（通过 Tk.mainloop 命令）。窗口系统基于我在创建窗口时所作的绑定来决定何时调用那些方法，所以控制被反转了—不是有我的程序来调用窗口，而是由窗口来调用我的程序—这中现象就叫做“控制反转”。

框架的一个很重要的特性就是，用户定义方法常常由框架自身来调用，而不是由用户的代码来调用。框架常常扮演主程序的角色来协调应用程序的活动。这种控制反转是框架成为一个强大的可以扩展的骨架。用户提供的方法对框架提供的一般性算法进行裁剪来提供更特殊的应用。--Ralph Johnson and Brian Foote

控制反转是使框架不同于库的一个关键的部分。库在本质上是一系列你可以调用的方法，现在一般组织成类的形式，每次调用都会完成一些工作，然后将控制权返回给调用者。

框架内部嵌套了一些抽象的设计，有很多内建表现。为了使用它，你需要通过继承或者插件的方式将你的程序插入到框架的一些位置，然后框架会在这些地方调用你的代码。

有多种方法向框架插入你需要被调用的代码。在上面的例子中，我们通过在在文本框上调用 bind 方法，同时将消息名称作为参数传给它，后面再跟一个用“{}”括起来的方法，来向框架插入代码。当文本框检测到一个消息的时候，就会调用在“{}”中的方法。使用“{}”是一中很方便的方式，但是很多编程语言都不支持这中方式。

另一种方法是框架定义一些消息，然后在用户代码中注册这些消息。.NET就是这样一个平台，它在语言方面拥有这样的特性，可以让用户在窗口上定义一些消息，然后可以将方法绑定到这些消息上。

上面的这些方法（他们实际上是相同的）在单个case上面工作得很好，但是有时候需要在单个单元扩展上面绑定多个方法的调用，在这种情况下，框架可以定义一个接口，用户代码通过实现这个接口来实现相关的调用。（这段话我也似懂非懂）

EJBs是这种形式的控制反转的一个很好的例子。当你在开发一个 session bean 的时候，你可以实现多个在不同生命周期点上被 EJB 容器调用的方法。例如，一个 Session Bean 接口定义了 ejbRemove、ejbPassivate和ejbActivate。你不需要关心这些方法什么时候被调用，而只需要关心它们做些什么。由容器来调用用户的程序，而不是用户的程序来调用容器。