Ruby設計模式編程之適配器模式實戰攻略_ruby專題

適配器模式
適配器模式可以用於對不同的介面進行封裝以及提供統一的介面，或者是讓某一個對象看起來像是另一個類型的對象。在靜態類型的程式設計語言裡，我們經常使用它去滿足類型系統的特點，但是在類似Ruby這樣的弱類型程式設計語言裡，我們並不需要這麼做。儘管如此，它對於我們來說還是有很多意義的。
當使用第三方類或者庫的時候，我們經常從這個例子開始（start out fine）：

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

我們假設有一個針對locator的介面，但是如果我們想要find_nearest_restaurant能夠支援另一個庫呢？這個時候我們可能就會去嘗試添加新的特殊的情境的處理：

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." endend

這是一個比較務實的解決方案。或許我們也不再需要考慮去支援另一個庫了。也或許find_nearest_restaurant就是我們使用locator的唯一情境。
那假如你真的需要去支援一個新的locator，那又會是怎麼樣的呢？那就是你有三個特定的情境。再假如你需要實現find_nearest_hospital方法呢？這樣你就需要在維護這三種特定的情境時去兼顧兩個不同的地方。當你覺得這種解決方案不再可行的時候，你就需要考慮適配器模式了。
在這個例子中，我們可以為GeoFish以及ActsAsFound編寫適配器，這樣的話，在我們的其他代碼中，我們就不需要瞭解我們當前正在使用的是哪個庫了：

def find_nearest_hospital(locator) locator.find :type => :hospital,        :lat => self.lat,        :lon => self.lonendlocator = GeoFishAdapter.new(geo_fish_locator)find_nearest_hospital(locator)

特意假設的例子就到此為止，接下來讓我們看看真實的代碼。

執行個體
今天一大早，你的leader就匆匆忙忙跑過來找到你：“快，快，緊急任務！最近ChinaJoy馬上就要開始了，老闆要求提供一種直觀的方式，可以查看到我們新上線的遊戲中每個服的線上人數。”
你看了看日期，不是吧！這哪裡是馬上要開始了，分明是已經開始了！這怎麼可能來得及呢？
“沒關係的。”你的leader安慰你道：“功能其實很簡單的，介面都已經提供好了，你只需要調用一下就行了。”
好吧，你勉為其難地接受了，對於這種突如其來的新需求，你早已習慣。
你的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 

接著定義三個統計類繼承PlayerCount，分別對應了三個不同的服，如下所示：

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 << "<root>"     builder << "<server>" << player.server_name << "</server>"     builder << "<player_count>" << player.player_count.to_s << "</player_count>"     builder << "</root>"   end  end 

這樣的話，所有代碼就完工了，如果你想查看一服線上玩家數只需要調用:

XMLBuilder.build_xml(ServerOne.new) 

查看二服線上玩家數只需要調用：

XMLBuilder.build_xml(ServerTwo.new) 

查看三服線上玩家數只需要調用：

XMLBuilder.build_xml(ServerThree.new) 

咦？你發現查看一服線上玩家數的時候，傳回值永遠是-1，查看二服和三服都很正常。
你只好把你的leader叫了過來：“我感覺我寫的代碼沒有問題，但是查詢一服線上玩家數總是返回-1，為什麼會這樣呢？”
“哎呀！”你的leader猛然想起，“這是我的問題，前面沒跟你解釋清楚。由於我們的一服已經開放一段時間了，查詢線上玩家數量的功能早就有了，使用的是ServerFirst這個類。當時寫Utility.online_player_count()這個方法主要是為了針對新開的二服和三服，就沒把一服的查詢功能再重複做一遍。這種情況下可以使用適配器模式，這個模式就是為瞭解決介面之間不相容的問題而出現的。”
其實適配器模式的使用非常簡單，核心思想就是只要能讓兩個互不相容的介面能正常對接就行了。上面的代碼中，XMLBuilder中使用PlayerCount來拼裝XML，而ServerFirst並沒有繼承PlayerCount，這個時候就需要一個適配器類來為XMLBuilder和ServerFirst之間搭起一座橋樑，毫無疑問，ServerOne就將充當適配器類的角色。修改ServerOne的代碼，如下所示：

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

 
這樣通過ServerOne的適配，XMLBuilder和ServerFirst之間就成功完成對接了！使用的時候我們甚至無需知道有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   #...

Oj的適配器修改了options雜湊表，使用Hash#delete將:symbolize_keys項轉換為Oj的:symbol_keys項：

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

接下來MultiJSON調用了::Oj.load(string, options)。MultiJSON適配後的API跟Oj原有的API非常相似，在此不必贅述。不過你是否注意到，Oj是如何引用的呢？::Oj引用了頂層的Oj類，而不是MultiJson::Adapters::Oj。
現在讓我們看看MultiJSON又是如何適配Yajl庫的：

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

這個適配器從不同的方式實現了load方法。Yajl的方式是先建立一個解析器的實力，然後將傳入的字串string作為參數調用Yajl::Parser#parse方法。在options雜湊表上的處理也略有不同。只有:symbolize_keys項被傳遞給了Yajl。
這些JSON的適配器看似微不足道，但是他們卻可以讓你隨心所欲地在不同的庫之間進行切換，而不需要在每一個解析JSON的地方更新代碼。
ActiveRecord
很多JSON庫往往都遵從相似的模式，這讓適配工作變得相當輕鬆。但是如果你是在處理一些更加複雜的情況時，結果會是怎樣？ActiveRecord包含了針對不同資料庫的適配器。儘管PostgreSQL和MySQL都是SQL資料庫，但是他們之間還是有很多不同之處，而ActiveRecord通過使用適配器模式屏蔽了這些不同。(提示: 命令列中輸入qw activerecord查看ActiveRecord的代碼)
開啟ActiveRecord程式碼程式庫中的lib/connection_adapters目錄，裡邊會有針對PostgreSQL,MySQL以及SQLite的適配器。除此之外，還有一個名為AbstractAdapter的適配器，它作為每一個具體的適配器的基類。AbstractAdapter實現了在大部分資料庫中常見的功能，這些功能在其子類比如PostgreSQLAdapter以及AbstractMysqlAdapter中被重新定製，而其中AbstractMysqlAdapter則是另外兩個不同的MySQL適配器——MysqlAdapter以及Mysql2Adapter——的父類。讓我們通過一些真實世界中的例子來看看他們是如何一起工作的。
PostgreSQL和MySQL在SQL方言的實現稍有不同。查詢語句SELECT * FROM users在這兩個資料庫都可以正常執行，但是它們在一些類型的處理上會稍顯不同。在MySQL和PostgreSQL中，時間格式就不盡相同。其中，PostgreSQL支援微秒層級的時間，而MySQL只是到了最近的一個穩定發布的版本中才支援。那這兩個適配器又是如何處理這種差異的呢？
ActiveRecord通過被混入到AbstractAdapter的ActiveRecord::ConnectionAdapters::Quoting中的quoted_date引用日期。而AbstractAdapter中的實現僅僅只是格式化了日期：

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

Rails中的ActiveSupport擴充了Time#to_s，使其能夠接收一個代表格式名的符號型別參數。:db所代表的格式就是%Y-%m-%d %H:%M:%S：

# Examples of common formats: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 resultend

它在一開始便調用super方法，所以它也會得到一個類似MySQL中格式化後的日期。接下來，它檢測value是否像是一個具體時間。這是一個ActiveSupport中擴充的方法，當一個對象類似Time類型的執行個體時，它會返回true。這讓它更容易表明各種對象已被假設為類似Time的對象。（提示: 對acts_like?方法感興趣？請在命令列中執行qw activesupport，然後閱讀core_ext/object/acts_like.rb）
第二部分的條件檢查value是否有用於返回毫秒的usec方法。如果可以求得毫秒數，那麼它將通過sprintf方法被追加到result字串的末尾。跟很多時間格式一樣，sprintf也有很多不同的方式用于格式化數字：

sprintf("%06d", 32) #=> "000032"sprintf("%6d", 32) #=> "  32"sprintf("%d",  32) #=> "32"sprintf("%.2f", 32) #=> "32.00"

最後，假如日期是一個負數，PostgreSQLAdapter就會通過加上”BC”去重新格式化日期，這是PostgreSQL資料庫的實際要求：

SELECT '2000-01-20'::timestamp;-- 2000-01-20 00:00:00SELECT '2000-01-20 BC'::timestamp;-- 2000-01-20 00:00:00 BCSELECT '-2000-01-20'::timestamp;-- ERROR: time zone displacement out of range: "-2000-01-20"

這隻是ActiveRecord適配多個API時的一個極小的方式，但它卻能協助你免除由於不同資料庫的細節所帶來的差異和煩惱。
另一個體現SQL資料庫的不同點是資料庫表被建立的方式。MySQL以及PostgreSQL中對主鍵的處理各不相同：

# AbstractMysqlAdapterNATIVE_DATABASE_TYPES = { :primary_key => "int(11) DEFAULT NULL auto_increment PRIMARY KEY", #...}# PostgreSQLAdapterNATIVE_DATABASE_TYPES = { primary_key: "serial primary key", #...}

這兩種適配器都能夠明白ActiveRecord中的主鍵的表示方式，但是它們會在建立新表的時候將此翻譯為不同的SQL語句。當你下次在編寫一個migration或者執行一個查詢的時候，思考一下ActiveRecord的適配器以及它們為你做的所有微小的事情。
DateTime和Time
當MultiJson以及ActiveRecord實現了傳統的適配器的時候，Ruby的靈活性使得另一種解決方案成為可能。DateTime以及Time都用於表示時間，但是它們在內部的處理上是不同的。雖然有著這些細微的差異，但是它們所暴露出來的API卻是極其類似的（提示：命令列中執行qw activesupport查看此處相關代碼）：

t = Time.nowt.day   #=> 19     (Day of month)t.wday  #=> 3     (Day of week)t.usec  #=> 371552   (Microseconds)t.to_i  #=> 1392871392 (Epoch secconds)d = DateTime.nowd.day   #=> 19     (Day of month)d.wday  #=> 3     (Day of week)d.usec  #=> NoMethodError: undefined method `usec'd.to_i  #=> NoMethodError: undefined method `to_i'

ActiveSupport通過添加缺失的方法來直接修改DateTime和Time，進而抹平了兩者之間的差異。從執行個體上看，這裡就有一個例子示範了ActiveSupport如何定義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) endend

每一個用於支援的方法，seconds_since_unix_epoch，offset_in_seconds，以及seconds_since_midnight都使用或者擴充了DateTime中已經存在的API去定義與Time中匹配的方法。
假如說我們前面所看到的適配器是相對於被適配對象的外部適配器，那麼我們現在所看到的這個就可以被稱之為內部適配器。與外部適配器不同的是，這種方法受限於已有的API，並且可能導致一些麻煩的矛盾問題。舉例來說，DateTime和Time在一些特殊的情境下就有可能出現不一樣的行為：

datetime == time #=> truedatetime + 1   #=> 2014-02-26 07:32:39time + 1     #=> 2014-02-25 07:32:40

當加上1的時候，DateTime加上了一天，而Time則是加上了一秒。當你需要使用它們的時候，你要記住ActiveSupport基於這些不同，提供了諸如change和Duration等保證一致行為的方法或類。
這是一個好的模式嗎？它理所當然是方便的，但是如你剛才所見，你仍舊需要注意其中的一些不同之處。
總結
設計模式不是只有Java才需要的。Rails通過使用設計模式以提供用於JSON解析以及資料庫維護的統一介面。由於Ruby的靈活性，類似DateTime以及Time這樣的類可以被直接地修改而提供相似的介面。Rails的源碼就是一個可以讓你挖掘真實世界中不同設計模式執行個體的天堂。
在這次的實踐中，我們同時也發掘了一些有趣的代碼：

• hash[:foo] = hash.delete(:bar)是一個用於重新命名雜湊表中某一項的巧妙方法。
• 調用::ClassName會調用頂層的類。
• ActiveSupport為Time、Date以及其他的類添加了一個可選的代表格式的參數format。
• sprintf可以用于格式化數字。

想要探索更多的知識？回去看看MultiJson是如何處理以及解析格式的。仔細閱讀你在你的資料庫中所使用到的ActiveRecord的適配器的代碼。瀏覽ActiveSupport中用於xml適配器的XmlMini，它跟MultiJson中的JSON適配器是類似的。在這些裡面還會有很多可以學習的。