原文地址：Metaprogramming Dynamic Methods: Using Public_send
作者：Friends of The Web的开发者Vaidehi，OneAPM官方技术博客编译整理。
在上周，我写了一些让我感到非常骄傲的代码！当时，我正努力解决一个有趣的问题，这个问题也是我最近开发的一款应用中所遇到的。于是我把脑海中想到的第一种解决办法很快付诸了实践。然后，当我回过头来查看文本编辑器，并认真审阅完自己所写的代码时，终于意识到：这些代码真的很赞！
一周以来，我不断回顾那些代码段，沉思到底是什么原因令她如此美丽。而我又做了什么不一样的事情，竟让自己的内心充满了骄傲。我认为是元编程，这是我能够第一时间想到的答案。元编程（Metaprogramming）是指某类计算机程序的编写，这类计算机程序编写或者操纵其他程序（或者自身）作为它们的数据，或者在编译时完成部分本应在运行时完成的工作。当然，其中涉及到很多不同的技巧和方法，我也不是专家。但是我的确学到了一个元方法 public_send ，接下来我分享一下自己的使用心得。
GOTTA DISPATCH? DO IT DYNAMICALLY.
其实，不仅仅只是Ruby，编程世界中的一切都只是一种抽象。我们只不过对那些晦涩难懂的机器语言包裹了一层“糖衣”，让程序员的生活变得更为简便，让代码更具美感罢了。但归根结底，这只是对其他事物的一种抽象而已。当我们通过元编程进行重构时，理解的是同样的抽象概念，而且我们必须牢记这一点。同时，当我们试图发现代码中的共性问题时，这也意味着，我们可以封装并抽离那段代码的部分功能。
我最喜欢的抽象实例是method dispatching，通过这种方法我们将信息传递给一个对象，当然，这也是我们经常做的事情。因为Ruby中的所有事物都是一个对象，只要你想调用某个对象完成某件任务，你就不得不向它发送信息。我们应该庆幸，因为Ruby是如此强大，我们用来发送信息的方法就刚好就叫做：send。
其实，send方法在程序中被调用的次数远超过我们的想象。比如，当我们打开操控台，做一些简单的数学运算：
2.2.0 > 3 + 4
=> 7
而我们真正做事情的是：给整数3这个对象发送一个信息，告诉它与另一个对象（整数4）进行加法动作。
2.2.0 > 3.send(:+, 4)
=> 7
send 方法用字符串或者一个符号为参数，并以此做为方法名。换言之，方法名总是第一个参数，而第二个参数将以自变量的形式传给该方法。
此时，如果你想执行3加4的加法操作，就会变得很容易。但是，谁会一直做如此简单的加法计算呢？显然没有。你很可能还会执行3加5，加6，一直加到无穷等等。
而使用dynamic dispatching 就可以拯救你！
Dynamic dispatching，就如同上面这幅略显奇怪但是相当可爱的动态图，因为涉及向对象发送不同的信息(read: methods) ，同时因情况的差异，还会产生方法不断改变的警告。Dynamic dispatching 允许我们在程序中面向对象发送不同的方法，而且无需告知其他对象所发送信息的内容。如果你需要再一个特定的环境下调用一个方法，但是不清楚该方法是如何执行的，那么此时就是Dynamic dispatching 出场的最佳时机。
我们可以看一下这个例子。
YOU CAN SEND WHUTEVA YOU LIKE
你可以使用 send 方法，来向一个对象“send”不同的方法，但这只占据了一半的乐趣，另一半在于搞清楚什么时候去实际的应用它。
此刻，让我来给大家展示一下，最近如何在应用中使用 Dynamic dispatching 来触发特定的方法。在本文中，我使用了一个电子书店的例子，希望大家能够接受。
在我的书店中，拥有一个开放购买的图书列表，列表以页码为单位来进行展示，且每本书在界面中只有有限的展示空间。作为网站的管理员，我必须决定针对不同的书应该如何进行更好的展示。一些书有非常漂亮的封面，我会想用封面的缩略图作为他们主要的“viewable attribute”，因为我使用了 paperclip 插件，这点很容易实现。
然而，有些书压根就没有封面。比如，浩如烟海的莎士比亚戏剧集，如果以“作者”做为“viewable attribute”，能更好地能吸引读者。而《权力的游戏》系列图书若以书名作为“可见属性”，显然更具吸引力。
所以，我该如何处理这个问题呢？首先，让我们看一下有没有任何共性的存在。
1. Look For Patterns
诚然，我们都希望界面中的每个 Book 对象都能用它最主要的可见属性来展示。我们遇到的问题是管理员会为每个 Book 对象选择不同的属性，再设置其为“viewable”，因此我们无法预测这个属性是title ，author ，还是是一张图像。但是，我们的确知道每个 book 对象都需要某个“viewable attribute”。
这点很酷！所以这里就发现了一个共性：我们需要展示一个属性，但是我们并不知道它会是什么。或者说，其实我们知道？
2. Consider The Data
当下我们为该应用建立一个管理员界面时，我们清楚的知道每本书都有一个title，一个author。书的封面可以是有选择性的(此处我们称其为media )，但另外两个属性则不一定。这意味着我们要对 Book 对象进行一次验证：
class Book < ActiveRecord::Base
validates_presence_of :title, :author
end
经过验证值之后，我进一步思考Book 对象肯定也会有的其他属性，首先进入我脑海的就是viewable_by属性。我们可以设想一下，管理员必须将某个属性设为“viewable”，当他更新此对象时，“viewable”就可能改变。因此，对每个 Book 对象来说都是独一无二的，这也意味着我们可以放心地将其保存在数据库中。
所以，我们可以通过代码迁移在数据库中增加viewable_by属性，并且设置成不可为null，同时将默认值设为Book’s title：
class AddViewableByToBooks < ActiveRecord::Migration
def change
add_column :books, :viewable_by, :string, null: false, default: "title"
end
end
这个迁移看起来非常简单，但是，but it is its very simplicity that lends itself so elegantly to some serious metaprogramming that we’ll do next.
3. Encapsulate And Abstract
最后这部分的确最难理解，但也最炫酷。现在，我们的数据库里多了一列，且字符串类型的值是title ， author，media中的一个，管理员可以随意改变或更新这些值。显而易见，这些值的更改不可避免，但是有一点不变：we’re still going to want to render the value of whatever attribute is marked as “visible” – that is to say, whatever string value is saved as viewable_by .
此时，我们可以回头想想之前定义的那个共性。我们知道，属性会不断改变，但是我们对它的操作仍然保持了一致性。不论 Book 对象的viewable_by属性是什么，我们都会展示这个属性。而且我们会跟该对象发送信息：“嘿，书先生，你可见的那个属性，不论它是什么，都是你用来展示自己的值！”
And this is where we can use send to encapsulate and abstract this away into a single method call。首先，我们要增加一个方法来检查可见属性是不是一个图象，如果是的话，我们会将其交给paperclip插件来进行展示：
def show_cover?
self.viewable_by == 'media'
end
如果viewable_by属性的值为media，该方法会返回true，否则返回false。我们可以将这个布尔返回值用在一个条件语句中：
def book_html
if show_cover?
# Code here will generate and return
# an html image tag to render in view.
else
send(self.viewable_by)
end
end
上面的代码怎么了？如此炫酷！book_html方法要么展示一张缩略图(我们会写别的代码来实现)，要么返回一个title 对象或者author对象。当然，真正炫酷的地方在于，我们可以在表中添加其他属性，像year或者genre，并在此基础上显示html网页，只需要这些属性保存在viewable列中。
这到底是怎么运行的？其实，每次我们在数据库里创建新列时，我们都获得了两个重要的方法：读和写。这意味着我们拥有了title=和 title两个方法。
如果我们回顾一下 send 方法的工作原理，就会知道send 会将一个字符串或一个符号作为参数，该参数也是被调用的方法名。当我们调用 send 方法并将self.viewable_by 的值传给它时，我们实际上是在调用一个Book实例的send(“title”) 方法。这会调用该Book实例的title 属性，并将那本书的书名以字符串的形式返回。
这段代码炫酷的地方在于它非常灵活，同时还能将一种共性抽象为动态的方法调用，只在合适的时间对恰当的对象发起请求。但是，这段代码中还存在一个大问题，接下来让我们把它解决掉。
TO SEND OR TO PUBLIC SEND? THAT IS THE QUESTION
很多控诉 send 方法的证据都源于此： send 会将private methods发送给对象。这在应用内部是相当危险的，而且也让应用在应对外部恶意攻击���显得相当脆弱。
一种快速的修正方法就是使用 pubic_send ，它的功能与你所想的完全一致：只将公共可读取的方法发送给它的接收对象，所以我们最终的代码如下：
class Book < ActiveRecord::Base
validates_presence_of :title, :author
def show_cover?
self.viewable_by == 'media'
end
def book_html
if show_cover?
# Code here will generate and return
# an html image tag to render in view.
else
public_send(self.viewable_by)
end
end
end
赞！作为我们元编程的首次尝试，这段代码并没有显得很寒碜。
虽然做起来很难，但在重构和元编程方面，你也不必太苛求自己。老实说，随着时间的累积，你可以多加练习，逐渐的增长见识，那么编程能力自然也能够得到提高。最终，你会开始察觉那些出现了一次又一次的共性，并开始学会选择正确的工具来解决这些问题。
尽管需要额外的努力，我认为尝试不同的元编程技巧对未来大有裨益，多读多写代码亦是如此。重写之前的代码来实现一些元编程技巧，你可以修改应用中过于死板的代码，将之变得更为灵活、动态。
如果这些话听起来有些吓人，那是因为事实本就如此！但是这并不是不可能的，正如我最近取得的进展，我也希望正在阅读此文的你也能有所斩获。幸运的是，Ruby提供了很多工具，帮我们将死板的代码实现了元程序化。而问题就在于了解那些工具，并在合适的时机能够使用它。我相信，如果你体验了一次元编程，你肯定会欣喜万分，也许还会像小猫一样发出欢乐的尖叫，我想那将是世上最可爱的事情了。
