Rails项目中避免滥用这三种特性

Ruby有很多令人喜爱的优质特性，但如果仅仅是为了用而用，那么好的特性也会变成坏的毒瘤。下面笔者就为大家盘点最常见的三种滥用特性。

proc/block/lambda

Rails 项目里，一般除了使用Ruby的Enumerable会使用到block，除此之外，需要自己写一个带block的方法的场景不多。lambda和proc也一样，因为在Rails 里 还是以OO风格为主，MVC各个部分被抽象成class和method，抽象的好不好是另外一个话题。 不过最近大开眼界，发现一种在Rails里一路飙proc的写法：

1 2 3 4 5 6 7 8 9

class  A    def  a      d = proc{xxxx}      b = proc{xx}      c = proc{d.call;xxx}      b.call      c.call    end end

上面代码翻译成OO代码是这样子的：

1 2 3 4 5 6 7 8 9 10 11 12 13

class  A    def  a      b      c    end    def  b    end    def  c      d    end    def  d    end end

有什么区别么?似乎没什么?proc在抽重复代码的功能上和method是等价的，不过由于proc在ruby里是二等公民，在没有独立的寄存空间，要相互调用只能写在一个方法里。抽取方法的作用不止是去重，另一个作用是分离职责。a、b、c方法都是最小的单元，有着自己的作用空间(class A内)，可以独立运行和测试。

总之，在Rails里这样用proc给人一种面向过程+函数式+面向对象合体的感觉...

元编程和monkey patch

Rails项目里元编程和monkey patch的应用场景主要是在外部 plugin不提供相应API接口的情况下去修复plugin的行为或bug。最近仍然大开眼界，看代码：

1 2 3 4 5

ActionView::Helpers::DateHelper.class_eval  do    def  time_transform_in_words(time)      time.strftime( "%m-%d-%Y %H:%M" )    end end

这本来是写一个普通helper就可以解决的问题，非要用monkey patch。一定会有同学会说，“It's no big deal.”，这不影响什么啊。其实反映的是一个人解决问题的思维习惯。举例，一个人想去邻居家做客，从墙就翻进去了，邻居问他“为啥翻墙啊?不会从门进吗?”。答曰“习惯了，都可以进去啦。” 其实他连门在哪都不知道，也不想知道。习惯用monkey patch方式解决问题的人就是上面的思路，细思极恐啊。