Ruby元编程 打破private protected限制

需求源于分离职责, 对一些涉及多个model的业务，专门分出一个service层来负责，一个service的方法就是装配不同model提供的方法，这些model的方法应该只能被service调用，而不能被controller调用，那就将这些方法设置为private或者protected（绝对限制是做不到的，起码跟普通方法有所区别，不能直接调用），外部只能用send来调用，但如果调用多的话，一是难看且麻烦，二是影响性能，那就meta programming一下吧

思路是动态产生调用者类的子类，然后委托该子类调用父类的private或protected方法，如果调用者是单件类(metaclass)的话那就到此结束了，但如果是实例，调用private方法还是不行，那就是保存实例到子类对象中，同时打开实例类，生成private方法的一个代理，然后子类调用保存的实例调用代理方法，代码与例子如下

=begin
Example:

class A
  class << self
    private
    def t1
    "t1"
    end
  end

  def initialize(a = nil)
    @a = a
  end
  private
  def t1
    @a
  end
end


A.extend(BreakProtect) #or class A; include BreakProtect; end
p A.break_protect.t1
p A.new("leon").break_protect.t1 # or for reuse, a = A.new("leon").break_protect; a.t1
=end

module BreakProtect
  def self.extended(obj)
    set_sub(obj)
  end
  def self.included(obj)
    set_sub(obj)
  end
  def self.set_sub(obj)
    obj.class_eval %{
    class #{obj.to_s}_Sub < #{obj.to_s}
      def initialize(parent)
        @parent = parent
      end
      def self.method_missing(method_id, *args)
        class_eval %\{
                    def self.#\{method_id\}(*args)
                      @parent.nil? ? super : @parent.#\{method_id\}
                    end
                  \}
                  send(method_id, *args)
      end
      def method_missing(method_id, *args)
        if private_methods.include?(method_id.to_s)
          instance_eval %\{
                      class ::#{obj.to_s}
                        def #\{method_id\}_to_protect(*args)
                          #\{method_id\}
                        end
                        protected :#\{method_id\}
                      end
                      def #\{method_id\}(*args)
                        if @parent.nil?
                          super
                        else
                          @parent.#\{method_id\}_to_protect
                        end
                      end
                    \}
        else
          instance_eval %\{
                      def #\{method_id\}(*args)
                        @parent.nil? ? super : @parent.#\{method_id\}
                      end
                    \}
        end
        send(method_id, *args)
      end
    end
    def break_protect
      #{obj.to_s}_Sub.new(self)
    end
    def self.break_protect
      #{obj.to_s}_Sub
    end
  }
  end
end

评论

4 楼 lllyq 2008-04-16  

7thbyte 写道

通过OO的思想，model本身就应该看成DAO+serivce的综合体

“操作多个model”的操作方法都应该放在其中的一个在逻辑地位上处于主体的model上。
再把一些方法抽取到lib里。

如果为了“操作多个model”的方法而去增加service层，即说明设计不够合理导致任务不能或不容易解耦。
此时应该调整设计，抽象出新的对象。

关于这个问题可以另开贴讨论
当然你的做法是对的，优先考虑，但是方法多了就没这么简单了，简单说起来多一个service层维护起来方便

3 楼 7thbyte 2008-04-16  

通过OO的思想，model本身就应该看成DAO+serivce的综合体

“操作多个model”的操作方法都应该放在其中的一个在逻辑地位上处于主体的model上。
再把一些方法抽取到lib里。

如果为了“操作多个model”的方法而去增加service层，即说明设计不够合理导致任务不能或不容易解耦。
此时应该调整设计，抽象出新的对象。

2 楼 lllyq 2008-04-16  

zeroleonhart 写道

既然只能给service调用，那就应该在service里定义那些方法。
没必要定义了private和protected再hack。
不过这个meta的想法不错。

service只是组装者，方法是定义在不同的model，service:model是多对多

1 楼 zeroleonhart 2008-04-16  

既然只能给service调用，那就应该在service里定义那些方法。
没必要定义了private和protected再hack。
不过这个meta的想法不错。