脚本专栏 
首页 > 脚本专栏 > 浏览文章

Ruby元编程之梦中情人method_missing方法详解

(编辑:jimmy 日期: 2024/11/16 浏览:3 次 )

我最近读了些文章(比如这篇),宣传在 Ruby 里使用 method_missing 的。

很多人都与 method_missing 干柴烈火,但在并没有小心处理彼此之间的关系。所以,我想来探讨一下这个问题:

** 我该怎么用 method_missing **

什么时候该抵挡 method_missing 的诱惑

首先,永远不要在还没花时间考虑你用得够不够好之前,就向 method_missing 的魅力屈服。你知道,在日常生活中,很少会让你以为的那样亟需 method_missing:

日常:方法代理

案例:我需要让这个类能够使用另一个类的方法

这是我所见过最普遍的使用 method_missing 的情况。这在 gems 与 Rails 插件里头尤其流行。它的模型类似这样:
复制代码 代码如下:
class A
  def hi
    puts "Hi from #{self.class}"
  end
end

class B
  def initialize
    @b = A.new
  end

  def method_missing(method_name, *args, &block)
    @b.send(method_name, *args, &block)
  end
end

A.new.hi #=> Hi from A
B.new.hi #=> Hi from A

如此,B 就拥有了 A 的所有实例方法。但是让我们想想,在调用 @b.hi 的时候都发生了什么。你的 ruby 环境沿着继承链一路找 hi 这个方法,到最后,恰恰在丢出个 NoMethodError 前,它调了 method_missing 这个方法。

在上例中,情况并不坏,毕竟这里就两个微不足道的类需要查。但通常,我们是在 Rails 或者其他一些框架的上下文中编程。而你的 Rails 模型继承自 ActiveRecord,而它又集成自其他一大坨的类,于是现在你就有了一坨高高的堆栈要爬"codetitle">复制代码 代码如下:
class B
  define_method(:hi) do
    @b.hi
  end
end

“可是我有一大坨方法要定义!” 你抱怨

“没问题!” 我卖萌眨眼
复制代码 代码如下:
class B
  [:hi, :bye, :achoo, :gesundheit].each do |name|
    define_method(name) do
      @b.send(name)
    end
  end
end

可是我懒得把它们一个个写出来!

你有点难搞哦
复制代码 代码如下:
class A
  # ... lots of methods in here
end
class B
  A.instance_methods.each do |name|
    define_method(name) do
      @b.send(name)
    end
  end
end

那假如我要定义的方法跟原本的有那么一些些不一样呢?

容易
复制代码 代码如下:
class A
  def hi
    puts "Hi."
  end
end

class B
  A.instance_methods.each do |name|
    define_method("what_is_#{name}") do
      if @b.respond_to"Hi."
B.new.what_is_wtf #=> false

呃,代码看起来不优雅啊

那就没办法了,凑合得了。如果你想要代码更易读,可以看看我们的ruby delegation library 和 Rails ActiveRecord delegation。

好,我们总结一下,看看 define_method 的真正威力。

修改自 ruby-doc.org 上的 例子
复制代码 代码如下:
class A
  def fred
    puts "In Fred"
  end
  def create_method(name, &block)
    self.class.send(:define_method, name, &block)
  end
  define_method(:wilma) { puts "Charge it!" }
end
class B < A
  define_method(:barney, instance_method(:fred))
end

a = B.new
a.barney                                #=> In Fred
a.wilma                                 #=> Charge it!
a.create_method(:betty) { p self.to_s }
a.betty                                 #=> B

什么时候用 method_missing?

现在你估计在想,总有该用它的时候吧,不然还要它干嘛?没错。

动态命名的方法(又名,元方法)

案例:我要依据某种模式提供一组方法。这些方法做的事情顾名思义。我可能从来没有调用过这些可能的方法,但是等我要用的时候,它们必须可用。

现在才是人话!这其实正是 ActiveRecord 所采用的方式,为你提供那些基于属性的动态构建的查找方法,比如 find_by_login_and_email(user_login, user_email)。

复制代码 代码如下:
def method_missing(method_id, *arguments, &block)
  if match = DynamicFinderMatch.match(method_id)
    attribute_names = match.attribute_names
    super unless all_attributes_exists"codetitle">复制代码 代码如下:
find_by_email
find_by_login
find_by_name
find_by_id
find_by_email_and_login
find_by_email_and_login_and_name
find_by_email_and_name
# ...

假如你的模型有 10 个字段,那就是 10! (362880)个查找方法需要定义。想象一下,在你的 Rails 项目跑起来的时候,有这么多个方法需要一次定义掉,而 ruby 环境还得把它们都放在内存里头。

老虎·伍兹都做不来的事情。

** 正确的 method_missing 使用方式

(译者猥琐地注:要回家了,以下简要摘译)

1、先检查

并不是每次调用都要处理的,你应该先检查一下这次调用是否符合你需要添加的元方法的模式:
复制代码 代码如下:
def method_missing(method_id, *arguments, &block)
  if method_id.to_s =~ /^what_is_[\w]+/
    # do your thing
  end
end

2、包起来

检查好了,确实要处理的,请记得把函数体包在你的好基友,define_method 里面。如此,下次就不用找情妇了:
复制代码 代码如下:
def method_missing(method_id, *arguments, &block)
  if method_id.to_s =~ /^what_is_[\w]+/
    self.class.send :define_method, method_id do
      # do your thing
    end
    self.send(method_id)
  end
end

3、擦屁股

自己处理不来的方法,可能父类有办法,所以 super 一下:
复制代码 代码如下:
def method_missing(method_id, *arguments, &block)
  if method_id.to_s =~ /^what_is_[\w]+/
    self.class.send :define_method, method_id do
      # do your thing
    end
    self.send(method_id)
  else
    super
  end
end

4、昭告天下
复制代码 代码如下:
def respond_to?(method_id, include_private = false)
  if method_id.to_s =~ /^what_is_[\w]+/
    true
  else
    super
  end
end

要告诉别人,你的类虽然暂时还没有这个方法,但是其实是能够响应这方法的。

** 总结 **

在每个 Ruby 程序员的生活中,这仨方法扮演了重要的角色。define_method 是你的好基友,method_missing 是个如胶似漆但也需相敬如宾的情妇,而 respond_to? 则是你的爱子,如此无虞。

上一篇:ruby元编程之method_missing的一个使用细节
下一篇:Ruby的25个编程细节(技巧、实用代码段)
一句话新闻
微软与英特尔等合作伙伴联合定义“AI PC”:键盘需配有Copilot物理按键
几个月来,英特尔、微软、AMD和其它厂商都在共同推动“AI PC”的想法,朝着更多的AI功能迈进。在近日,英特尔在台北举行的开发者活动中,也宣布了关于AI PC加速计划、新的PC开发者计划和独立硬件供应商计划。
在此次发布会上,英特尔还发布了全新的全新的酷睿Ultra Meteor Lake NUC开发套件,以及联合微软等合作伙伴联合定义“AI PC”的定义标准。