浏览 569 次
|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间:2008-04-16 关键字: meta programming
需求源于分离职责, 对一些涉及多个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
声明:JavaEye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
|
|
| 返回顶楼 | |
|
最后更新时间:2008-04-16
既然只能给service调用,那就应该在service里定义那些方法。
没必要定义了private和protected再hack。 不过这个meta的想法不错。 |
|
| 返回顶楼 | |
|
最后更新时间:2008-04-16
zeroleonhart 写道 既然只能给service调用,那就应该在service里定义那些方法。
没必要定义了private和protected再hack。 不过这个meta的想法不错。 service只是组装者,方法是定义在不同的model,service:model是多对多 |
|
| 返回顶楼 | |
|
最后更新时间:2008-04-16
通过OO的思想,model本身就应该看成DAO+serivce的综合体
“操作多个model”的操作方法都应该放在其中的一个在逻辑地位上处于主体的model上。 再把一些方法抽取到lib里。 如果为了“操作多个model”的方法而去增加service层,即说明设计不够合理导致任务不能或不容易解耦。 此时应该调整设计,抽象出新的对象。 |
|
| 返回顶楼 | |
|
最后更新时间:2008-04-16
7thbyte 写道 通过OO的思想,model本身就应该看成DAO+serivce的综合体
“操作多个model”的操作方法都应该放在其中的一个在逻辑地位上处于主体的model上。 再把一些方法抽取到lib里。 如果为了“操作多个model”的方法而去增加service层,即说明设计不够合理导致任务不能或不容易解耦。 此时应该调整设计,抽象出新的对象。 关于这个问题可以另开贴讨论 当然你的做法是对的,优先考虑,但是方法多了就没这么简单了,简单说起来多一个service层维护起来方便 |
|
| 返回顶楼 | |





