0. 什么是细化?
细化是Ruby2.0增添的体验版特性，但如今它已经算是标准库的一部分了。它主要用于修改指定类的对应方法，并且对目标方法的修改只在指定的区域内生效，而不会对全局产生副作用。
Refinements
我们都知道Ruby赋予了我们很高的开发权限，它甚至允许我们Hack内置类或者模块所包裹的方法，给予我们编程最大的灵活性。但是这种操作是全局性的，有很强的副作用，我们通常称这种修改为Monkey Patching(猴子补丁)。而细化就是为避免这种全局性的修改，他赋予我们能够在我们可以控制的范围内修改Ruby相关的类的能力。
细化从体验特性成为标准特性这一点来看，它已经得到了社区的认可。它使我们能够编写出更安全的Ruby代码，那下面我详细地来谈谈细化。
1. 简单的细化
下面通过代码来看细化
module A
refine String do
def inspect
"bug"
end
end
end
if __FILE__ == $0
puts "Ruby".inspect
using A
puts "Ruby".inspect
end
脚本运行的结果是
"Ruby"
bug
1) 工作机制
上面的代码是最简单的细化，我在模块A里面对String类的String#inspect方法进行修改，在需要用到这种修改的时候，我们使用using语法。那么在using后面的区域(直到脚本末尾)就可以使用我们细化过的方法版本。而这种修改不会对全局的String#inspect方法造成影响。在使用using之前，我们调用的仍然是原始版本的String#inspect。
2) 局限性
在Refinements Doc，里面有这样一句描述了这一点
Refinements only modify classes, not modules so the argument must be a class.
说明了在refine关键字后面只能跟类名，而不能跟模块名字。也就是说我们只能够对类进行细化。相比猴子补丁的我们可以在任何地方打开对应的模块 或者类并进行修改的强大功能来说，细化确实有那么点局限。
2. 细化的作用范围
1) 直到脚本尽头
如果细化的作用范围是using之后的区域，而且作用范围不是全局的，那么我们似乎可以认为在脚本的末尾细化的作用范围也就结束了。举个比较简单的例子验证一下, 我在脚本say.rb写下如下代码
# say.rb
module A
refine String do
def reverse
'I love ruby'
end
end
end
using A
class String
def say
reverse
end
end
然后在另一个脚本引入这个文件
# main.rb
require './say'
if __FILE__ == $0
puts "number".reverse
puts "number".say
end
猜测一下打印结果会是什么？
rebmun
I love ruby
我们其实只在say.rb里面使用的细化，并且我们新的函数String#say调用了细化过的String#reverse方法。但是这种改变只在脚本say.rb文件的using语句之后才会生效。到了 main.rb脚本的时候String#reverse就像没有改变过一样。可见在say.rb脚本中的using的作用其实并没有来到main.rb。在脚本的末尾，它的作用也结束了。
2) 作用域门
Ruby有区别于JavaScript的地方是，JavaScript的作用域几乎都是扁平的，但是Ruby里面要构造扁平化作用域需要用到代码块。用关键字def定义的函数或者方法会设置一道作用域门，经过这道门就会创建一个新的作用域，而该作用域里面无法访问到外面的变量。比如
world = "world"
def hello
"hello #{world}"
end
if __FILE__ == $0
p hello
end
其实运行会报错
'hello': undefined local variable or method 'world' for main:Object (NameError)
我们无法访问到def关键字前面定义的 world 变量。要想构造扁平化作用域我们应该怎么做？Ruby里面我们可以使用代码块来做这个事情。这里我们需要点元编程的知识，用代码块来包裹方法体即可
world = "world"
define_method :hello do
"hello #{world}"
end
if __FILE__ == $0
p hello
end
这样就可以得到我们想要的结果了
"hello world"
下面来看看用不同的方式来定义的方法，细化的表现行为有什么不同
class C
def hello
"C#hello"
end
end
module Modify
refine C do
def hello
"C#hello in Modify"
end
end
end
def call_hello(instance)
instance.hello
end
define_method :call_hello_code_block do |instance|
instance.hello
end
if __FILE__ == $0
using Modify
puts C.new.hello
puts "call_hello result #{call_hello(C.new)}"
puts "call_hello_code_block result #{call_hello_code_block(C.new)}"
end
在Modify模块里面细化C类，并在后面分别通过def关键字以及define_method(代码块)两种方式来定义行为一样的方法。在运行脚本的时候分别打印两个方法的结果看有什么不同。
C#hello in Modify
call_hello result C#hello
call_hello_code_block result C#hello in Modify
可见
在using关键字后面C类会调用的是细化过的方法，打印出"C#hello in Modify"。
如果我们调用def关键字定义的方法的时候就会使用了原始版本的C#hello打印出"C#hello"，这是因为我们定义该方法的时候，其实还没有使用using关键字，而def关键字是一个作用域门它创建了自己的作用域。
使用代码块来包裹方法体的时候，其实我们可以理解为，它跟1中的调用语句其实是在同一个作用域。因此他们得到的结果是一样的。得到了"C#hello in Modify"
3. 使用细化来使打印语句无效化
回头看之前写的一篇文章提出的问题Ruby动态删除方法中的打印语句，我把文章贴到Ruby社区得到了社区朋友的提点，他说用细化可以很简单的做到这点。
在我看来，用refine重写p方法使其p任何内容时都返回nil即达到目的。
毕竟我们不会以猴子补丁的方式来修改p方法，细化似乎是个不错的选择
1) 思路
如果要细化打印语句#p方法，首先要知道#p属于哪个类或者模块。
[25] pry(main)> p_method = Object.method :p
=> #
[26] pry(main)> p_method.owner
=> Kernel
方法#p其实来自与模块Kernel而不是Object类本身。但是我们前面也提到，细化只能针对类，而不能针对模块，那我们该怎么办？无妨，既然Object类已经包含了Kernel模块了，我们其实可以直接从Object类下手，直接细化Object#p，代码可以写成这样子
define_method :method_with_print do
p "begin method"
puts "This is '#{self.method(:method_with_print).name}' method"
p "end method"
end
module A
refine Object do
def p(*args)
nil
end
end
end
if __FILE__ == $0
method_with_print
using A
method_with_print
end
为了让后面的细化能够影响到之前定义的方法#method_with_print我不使用def关键字来定义方法(它会创建自己的作用域，导致后面的细化无法生效)，而是使用define_method来定义方法。最终结果应该就像我们期望的那样, 使用细化之后Object#p方法不会打印任何东西
"begin method"
This is 'method_with_print' method
"end method"
This is 'method_with_print' method
如果非要用def关键字的话，还可以沿用原来提出的获取目标方法的定义字符串，在细化的作用域内使用Kernel#eval重新定义该方法。代码如下
require 'pry'
def method_with_print
p "begin method"
puts "This is '#{self.method(:method_with_print).name}' method"
p "end method"
end
module A
refine Object do
def p(*args)
nil
end
end
end
if __FILE__ == $0
method_with_print
using A
# 获取目标方法的定义字符串
method_source = Object.method(:method_with_print).source
# 在细化作用域重新定义方法
eval(method_source)
method_with_print
end
两份脚本的运行结果是一样的，但个人更喜欢第一份脚本的代码。用代码块来包裹方法体的话会形成扁平化作用域，便可以在使用using语句后我们能够直接调用细化过的方法。这样感觉看起来更优雅，可以少写一些代码。
4. 尾声
Thanks
原谅我在这篇文章贴了不少代码，还有啰嗦了一大堆。本章主要介绍了一下细化功能以及细化的作用范围。但这篇文章肯定无法涵盖细化的所有方面，如果后期对细化有所补充会另起一文继续讲述。很感谢您能看完。
Happy Writing and Coding !!
238
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
