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 Adef 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方式解決問題的人就是上面的思路，細思極恐啊。