ChenGen

在擴展框架的時候，我們常常會遇到“控制反轉”這個現象，確實，它很多時候都被用來定義框架的特性。

現在我們來考慮一個簡單的例子，假設我在寫一個通過命令行的方式從用戶那里獲取信息的程序，我的程序會這樣寫：

  #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 命令）。窗口系統基于我在創建窗口時所作的綁定來決定何時調用那些方法，所以控制被反轉了—不是有我的程序來調用窗口，而是由窗口來調用我的程序—這中現象就叫做“控制反轉”。

框架的一個很重要的特性就是，用戶定義方法常常由框架自身來調用，而不是由用戶的代碼來調用?？蚣艹３０缪葜鞒绦虻慕巧珌韰f調應用程序的活動。這種控制反轉是框架成為一個強大的可以擴展的骨架。用戶提供的方法對框架提供的一般性算法進行裁剪來提供更特殊的應用。--Ralph Johnson and Brian Foote

控制反轉是使框架不同于庫的一個關鍵的部分。庫在本質上是一系列你可以調用的方法，現在一般組織成類的形式，每次調用都會完成一些工作，然后將控制權返回給調用者。

框架內部嵌套了一些抽象的設計，有很多內建表現。為了使用它，你需要通過繼承或者插件的方式將你的程序插入到框架的一些位置，然后框架會在這些地方調用你的代碼。

有多種方法向框架插入你需要被調用的代碼。在上面的例子中，我們通過在在文本框上調用 bind 方法，同時將消息名稱作為參數傳給它，后面再跟一個用“{}”括起來的方法，來向框架插入代碼。當文本框檢測到一個消息的時候，就會調用在“{}”中的方法。使用“{}”是一中很方便的方式，但是很多編程語言都不支持這中方式。

另一種方法是框架定義一些消息，然后在用戶代碼中注冊這些消息。.NET就是這樣一個平臺，它在語言方面擁有這樣的特性，可以讓用戶在窗口上定義一些消息，然后可以將方法綁定到這些消息上。

上面的這些方法（他們實際上是相同的）在單個case上面工作得很好，但是有時候需要在單個單元擴展上面綁定多個方法的調用，在這種情況下，框架可以定義一個接口，用戶代碼通過實現這個接口來實現相關的調用。（這段話我也似懂非懂）

EJBs是這種形式的控制反轉的一個很好的例子。當你在開發一個 session bean 的時候，你可以實現多個在不同生命周期點上被 EJB 容器調用的方法。例如，一個 Session Bean 接口定義了 ejbRemove、ejbPassivate和ejbActivate。你不需要關心這些方法什么時候被調用，而只需要關心它們做些什么。由容器來調用用戶的程序，而不是用戶的程序來調用容器。