Ruby 1.8.7：拦截对象的链式方法

Question

我有一个类，它包装任意数据的单元格；有点像过滤器。这些单元位于后端数据存储中。但这应该尽可能透明。

编写简单的访问器非常简单：

def foo
  # fetch backend cell value and return it
end
def foo=(val)
  # store val in backend cell
end

我发现棘手的部分是拦截和跟踪方法，如果数据未被包装，这些方法通常会影响数据。例如，如果数据是数组，则 obj.foo << 17 会将一个元素添加到数组中原位。我想在后端存储的数据上维护这种行为（ie，obj.foo << 17 导致存储的值也添加了一个元素） 。我想也许 method_missing 会有所帮助：

def method_missing(meth, *args)
  methsym = meth.to_sym
  curval = self.get
  lastval = curval.clone
  opresult = curval.__send__(methsym, *args)
  if (curval != lastval)
    self.set(curval)
  end
  return opresult
end

但是与 reader 访问器结合使用时，对操作的控制已经超出了我的范围，因为它返回的东西不是东西本身。 （即，如果后端数据是一个数组，我将返回它的副本，并且该副本正在被修改并且永远不会发送回给我。

）这可能吗？如果是这样，我该怎么办？ （这可能是非常明显的，我只是想念它，因为我累了——或者也许不累。:-)

谢谢！

[编辑]

换句话说..#method_missing 允许您挂钩未知方法的调用过程。我正在寻找一种类似地挂钩调用过程的方法，但对于所有方法，已知和未知。

谢谢！

Answer 1

您需要将类返回的每个对象包装在一个元对象中，该元对象了解后端，并可以根据需要更新它。

在您的示例中，您需要返回一个可以处理插入、删除等的数组包装对象。

--- 编辑 ---

您可以添加一个“单例方法”，而不是创建大量包装类。返回的对象，特别是如果您可以轻松识别可能需要特殊处理的方法。

module BackEndIF
  alias :old_send :__send__
  def __send__ method, *args
    if MethodsThatNeedSpecialHandling.include?(method)
       doSpecialHandling()
    else
      old_send(method,args)
    end
  end
end

#in your class:
def foo
   data = Backend.fetch(query)
   data.extend(BackEndIF)
   return data
end

我认为任何基于方法缺失的方法都不会起作用，因为您返回的对象确实具有相关的方法。 （即数组确实有一个运算符<<，它没有丢失）

或者，也许您可​​以使用 method_missing 做一些事情，就像您概述的那样。
创建一个像这样的元对象：

class DBobject
   def initialize(value, db_reference)
      @value = value
      @ref = db_reference
    end
   def method_missing(meth, *args)
     old_val = @value
     result = @value.__send__(meth, *args)
     DatabaseUpdate(@ref, @value) if (@value != old_val)
     return result   
   end
end

然后 foo 返回一个 DBObject.new(objectFromDB, referenceToDB)。

Answer 2

我通过借用 Delegator 模块解决了这个问题。 （下面的代码不保证工作；我已经手动编辑了一些细节。但它应该提供要点。）

• 在获取（读取器访问器）时，将值注释为使用修改后的方法传回：

  def enwrap(目标)
    #
    # 无耻地从 delegator.rb 讨价还价
    #
    eigenklass = eval('class << target ; self ; end')
    保留 = ::Kernel.public_instance_methods(false)
    保留 -= [ 'to_s', 'to_a', '检查', '==', '=~', '===' ]
    开关={}
    target.instance_variable_set(:@_method_map, swbd)
    target.instance_variable_set(:@_datatype, target.class)
    对于 self.class.ancestors 中的 t
      保留 |= t.public_instance_methods(false)
      保留 |= t.private_instance_methods(false)
      保留 |= t.protected_instance_methods(false)
    结尾
    保存<< '单例方法添加'
    target.methods.each 执行 |method|
      接下来 if (preserved.include?(method))
      swbd[方法] = target.method(method.to_sym)
      target.instance_eval(<<-EOS)
        def #{方法}(*args, &块)
          iniself = self.克隆
          结果 = @_method_map['#{method}'].call(*args, &block)
          if (self != iniself)
            #
            # 存储改变后的实体
            #
            newklass = self.class
            iniklass = iniself.instance_variable_get(:@_datatype)
            除非 (self.kind_of?(iniklass))
              开始
                引发 RuntimeError('类不匹配')
              救援运行时错误
                如果（$@）
                  [电子邮件受保护]_if { |s|
                    %r"\A#{Regexp.quote(__FILE__)}:\d+:in `" =~ s
                  }
                结尾
                增加
              结尾
            结尾
            # 在这里更新后端
          结尾
          返回结果
        结尾
      EOS
    结尾
  end # def enwrap 结束
  

• 在存储（写入器访问器）上，剥离我们添加的单例方法：

  def unwrap(目标)
    重新映射 = target.instance_variable_get(:@_method_map)
    返回 nil 除非 (remap.kind_of?(Hash))
    remap.keys.each 执行|方法|
      开始
        eval("类 << 目标 ; remove_method(:#{method}) ; end")
      救援
      结尾
    结尾
    target.instance_variable_set(:@_method_map, nil)
    target.instance_variable_set(:@_datatype, nil)
  end # def 展开结束
  

因此，当请求该值时，它会在返回之前添加“包装”方法，并且在执行任何操作之前删除单例存储在后端。任何更改该值的操作也会作为副作用更新后端。

目前实施的这项技术有一些不幸的副作用。假设带有包装变量的类在 backend 中实例化，并且通过 ivar_foo 访问其中一个变量：

backend.ivar_foo
=> nil
backend.ivar_foo = [1, 2, 3]
=> [1,2,3]
bar = backend.ivar_foo
=> [1,2,3]
bar << 4
=> [1,2,3,4]
backend.ivar_foo = 'string'
=> "string"
bar
=> [1,2,3,4]
backend.ivar_foo
=> "string"
bar.pop
=> 4
bar
=> [1,2,3]
backend.ivar_foo
=> [1,2,3]

但这更多的是目前对我来说好奇心比问题更重要。 :-)

感谢您的帮助和建议！