Ruby设计模式编程之适配器模式实战攻略

适配器模式，听起来可能有点学院派，但它在日常开发中确实是个实用工具。简单来说，它用来给不同的接口“打包”，让它们对外提供统一的方式；或者让某个对象看起来像是另一个类型的对象。在静态类型语言里，适配器经常是类型系统的刚需，但在 Ruby 这种弱类型语言里，我们其实不一定非要它。不过话说回来，就算在 Ruby 里，适配器模式的意义也远超“应付类型检查”——它能帮我们写出更干净、更灵活的代码。

比如说，你一开始用了一个第三方库，代码写得很顺：

def find_nearest_restaurant(locator)
 locator.nearest(:restaurant, self.lat, self.lon)
end

你假设 locator 会有个 nearest 方法，一切看起来挺完美。但好景不长，老板说“咱们得换成另一个库”。这时你很可能本能地写一堆 if-elsif：

def find_nearest_restaurant(locator)
 if locator.is_a? GeoFish
  locator.nearest(:restaurant, self.lat, self.lon)
 elsif locator.is_a? ActsAsFound
  locator.find_food(:lat => self.lat, :lon => self.lon)
 else
  raise NotImplementedError, "#{locator.class.name} is not supported."
 end
end

这法子其实挺务实的——如果以后不会再换库，或者只有一个方法用到这个 locator，这么写也没毛病。但问题在于，你的需求会膨胀。假如再来一个 find_nearest_hospital 方法，同样的分支逻辑就得再复制一遍，三个分支、两个方法……这就开始疼了。这时你就该考虑适配器模式了。

思路很简单：为每一个库写一个适配器，让它们对外暴露完全一致的接口。剩下的代码根本不需要知道背后用的是哪个库：

def find_nearest_hospital(locator)
 locator.find :type => :hospital,
        :lat => self.lat,
        :lon => self.lon
end

locator = GeoFishAdapter.new(geo_fish_locator)
find_nearest_hospital(locator)

上面是特意造的简化例子，接下来我们看一段真实的代码故事。

实例

今天一大早，你的 leader 就匆匆忙忙跑过来：“快，紧急任务！ChinaJoy 马上就要开始了，老板要求能直观查看每个服的在线人数。” 你看了眼日期——不是吧，这哪里是马上要开始，分明已经开始了！

“没事，” leader 安慰道，“接口都提供好了，你调一下就行。” 你习惯性地接受了这种突如其来的需求。

需求是这样的：游戏有三个服，一服已经开放一段时间，二服和三服是新开的。调用 Utility.online_player_count(Fixnum)，传入对应服的编号就能拿到在线人数（1、2、3），传错则返回 -1。然后你把数据拼成 XML，显示部分由 leader 搞定。

你马上开工。先定义一个父类 PlayerCount：

class PlayerCount 
  def server_name 
    raise "You should override this method in subclass." 
  end 
  def player_count 
    raise "You should override this method in subclass." 
  end 
end 

然后三个子类分别对应三个服：

class ServerOne < PlayerCount 
  def server_name ; "一服" ; end 
  def player_count ; Utility.online_player_count(1) ; end 
end 

class ServerTwo < PlayerCount 
  def server_name ; "二服" ; end 
  def player_count ; Utility.online_player_count(2) ; end 
end 

class ServerThree < PlayerCount 
  def server_name ; "三服" ; end 
  def player_count ; Utility.online_player_count(3) ; end 
end 

再来一个 XMLBuilder 拼装 XML：

class XMLBuilder 
  def self.build_xml player 
    builder = "" 
    builder << "" 
    builder << "" << player.server_name << "" 
    builder << "" << player.player_count.to_s << "" 
    builder << "" 
  end 
end 

测试一下：

XMLBuilder.build_xml(ServerOne.new)   # 返回 -1
XMLBuilder.build_xml(ServerTwo.new)   # 正常
XMLBuilder.build_xml(ServerThree.new) # 正常

一服总是 -1！你把 leader 叫来，他一拍脑袋：“哎，是我没说清楚。一服早就有了查询功能，用的是 ServerFirst 类，当时写 Utility.online_player_count 只针对新服，没再给一服重做。这种情况可以用适配器模式——它就是为了解决接口不兼容而生。” 适配器模式的核心思想就是让两个不兼容的接口能对上话。现在 XMLBuilder 依赖 PlayerCount，而 ServerFirst 没有继承它，那就让 ServerOne 充当适配器：

class ServerOne < PlayerCount 
  def initialize 
    @serverFirst = ServerFirst.new 
  end 
  def server_name ; "一服" ; end 
  def player_count 
    @serverFirst.online_player_count 
  end 
end 

改完之后，一切正常。使用的时候甚至不需要知道有 ServerFirst 这个类，直接创建 ServerOne 实例即可。

必须提醒一点：适配器模式并不是那种让架构更合理的模式，更多时候它是个“救火队员”，用来补救前期设计不合理导致的接口差异。更优的做法是设计之初就把可能的扩展考虑进去——在这个问题上，别学你的 leader。

MultiJSON

ActiveSupport 在做 JSON 解码时用了 MultiJSON，它本身就是一组针对不同 JSON 库的适配器。每种库都能解析 JSON，但做法不一样。看看针对 oj 和 yajl 的适配器（提示：命令行输入 qw multi_json 可查看源码）。

module MultiJson
 module Adapters
  class Oj < Adapter
   def load(string, options={})
    options[:symbol_keys] = options.delete(:symbolize_keys)
    ::Oj.load(string, options)
   end
  end
 end
end

Oj 适配器修改了 options 哈希，用 Hash#delete 把 :symbolize_keys 转成 Oj 认识的 :symbol_keys：

options = {:symbolize_keys => true}
options[:symbol_keys] = options.delete(:symbolize_keys) # => true
options                         # => {:symbol_keys=>true}

然后调用 ::Oj.load(string, options)。注意 ::Oj 引用的是顶层的 Oj 类，而不是 MultiJson::Adapters::Oj。

再看看 Yajl 的适配器：

module MultiJson
 module Adapters
  class Yajl < Adapter
   def load(string, options={})
    ::Yajl::Parser.new(:symbolize_keys => options[:symbolize_keys]).parse(string)
   end
  end
 end
end

它用不同的方式实现了 load——先创建一个解析器实例，再调用 parse。options 的处理也略有不同，只传递了 :symbolize_keys。这些适配器看起来不起眼，但能让你在不同 JSON 库之间自由切换，而不用到处改代码。

ActiveRecord

JSON 库通常遵循相似模式，适配起来轻松。但遇到更复杂的情况呢？ActiveRecord 为不同数据库准备了适配器。PostgreSQL 和 MySQL 都是 SQL 数据库，但差异不少，ActiveRecord 用适配器模式屏蔽了这些不同（命令行输入 qw activerecord 可查看源码）。

打开 lib/connection_adapters 目录，里面有 PostgreSQL、MySQL、SQLite 的适配器，还有一个 AbstractAdapter 作为基类。它实现了大多数数据库的通用功能，子类如 PostgreSQLAdapter 和 AbstractMysqlAdapter 再重写定制，而 AbstractMysqlAdapter 又是 MysqlAdapter 和 Mysql2Adapter 的父类。看看实际怎么协同工作的。

PostgreSQL 和 MySQL 的 SQL 方言不同：SELECT * FROM users 都能跑，但时间格式就大不一样。PostgreSQL 支持微秒级精度，MySQL 直到最近稳定版才支持。适配器怎么处理？

ActiveRecord 通过 ActiveRecord::ConnectionAdapters::Quoting 中的 quoted_date 来引用日期，这个模块被混入到 AbstractAdapter。基类实现很简单：

def quoted_date(value)
 value.to_s(:db)
end

ActiveSupport 扩展了 Time#to_s，使其能接收格式名参数。:db 对应 %Y-%m-%d %H:%M:%S：

Time.now.to_s(:db)   #=> "2014-02-19 06:08:13"
Time.now.to_s(:short)  #=> "19 Feb 06:08"
Time.now.to_s(:rfc822) #=> "Wed, 19 Feb 2014 06:08:13 +0000"

MySQL 适配器没有重写 quoted_date，所以继承了基类行为。而 PostgreSQLAdapter 做了两个修改：

def quoted_date(value)
 result = super
 if value.acts_like?(:time) && value.respond_to?(:usec)
  result = "#{result}.#{sprintf("%06d", value.usec)}"
 end
 if value.year < 0
  result = result.sub(/^-/, "") + " BC"
 end
 result
end

它先调用 super 得到基础格式，然后检测 value 是否类似 Time（acts_like? 是 ActiveSupport 的扩展），如果有微秒就追加。负数年份则加上 "BC"——这是 PostgreSQL 的实际要求：

SELECT '2000-01-20'::timestamp;      -- 2000-01-20 00:00:00
SELECT '2000-01-20 BC'::timestamp;   -- 2000-01-20 00:00:00 BC
SELECT '-2000-01-20'::timestamp;     -- ERROR

这只是 ActiveRecord 适配多个数据库的冰山一角，却帮你免去了无数细节差异带来的困扰。

另一个差异是建表时主键的处理：

# AbstractMysqlAdapter
NATIVE_DATABASE_TYPES = {
 :primary_key => "int(11) DEFAULT NULL auto_increment PRIMARY KEY",
}
# PostgreSQLAdapter
NATIVE_DATABASE_TYPES = {
 primary_key: "serial primary key",
}

两种适配器都能理解 ActiveRecord 中 :primary_key 的表示方式，但在创建新表时会翻译成不同的 SQL。下次你写 migration 或执行查询时，不妨想想这些适配器为你默默做了多少事。

DateTime 和 Time

MultiJSON 和 ActiveRecord 实现了经典的适配器，但 Ruby 的灵活性也提供了另一种思路。DateTime 和 Time 都表示时间，内部处理不同，但暴露的 API 极其相似（命令行 qw activesupport 可查看）：

t = Time.now
t.day   #=> 19     (Day of month)
t.wday  #=> 3     (Day of week)
t.usec  #=> 371552   (Microseconds)
t.to_i  #=> 1392871392 (Epoch seconds)

d = DateTime.now
d.day   #=> 19     (Day of month)
d.wday  #=> 3     (Day of week)
d.usec  #=> NoMethodError
d.to_i  #=> NoMethodError

ActiveSupport 通过直接修改 DateTime 和 Time 来抹平差异——为缺少的方法补上实现。例如 DateTime#to_i：

class DateTime
 def to_i
  seconds_since_unix_epoch.to_i
 end
 def seconds_since_unix_epoch
  (jd - 2440588) * 86400 - offset_in_seconds + seconds_since_midnight
 end
 def offset_in_seconds
  (offset * 86400).to_i
 end
 def seconds_since_midnight
  sec + (min * 60) + (hour * 3600)
 end
end

它用 DateTime 已有的 API 组合出了与 Time 匹配的方法。如果前面的适配器可以叫“外部适配器”，这个就是“内部适配器”——直接修改类本身。但这种方式受限于已有 API，可能带来一些微妙的矛盾：

datetime == time #=> true
datetime + 1   #=> 2014-02-26 07:32:39 (加一天)
time + 1     #=> 2014-02-25 07:32:40 (加一秒)

加 1 的结果不同。ActiveSupport 提供了 change 和 Duration 等工具来保证行为一致，但你仍需注意这些差异。这是不是好模式？方便是方便，但坑也摆在那。

总结

设计模式不是 Ja va 的专利。Rails 用适配器模式为 JSON 解析、数据库维护提供了统一接口。借助 Ruby 的灵活性，像 DateTime 和 Time 这样的类可以被直接修改来提供相似接口。Rails 源码简直是真实世界设计模式的宝库。

顺便提几个本文中间出现的有趣代码技巧：

• hash[:foo] = hash.delete(:bar) 是重命名哈希表键值的巧妙写法。
• 调用 ::ClassName 会引用顶层的类。
• ActiveSupport 为 Time、Date 等类添加了可选格式参数 format。
• sprintf 可以用来格式化数字。

想探索更多？回去看看 MultiJSON 如何处理解析格式，仔细阅读你所用数据库的 ActiveRecord 适配器代码，或者浏览 ActiveSupport 中用于 XML 适配的 XmlMini——它和 MultiJSON 的 JSON 适配器很类似。里面还有很多值得学习的东西。