Todo o código incluído neste texto foi projetado para ser executado interativamente no interpretador irb. Você pode copiar os trechos de código daqui para o interpretador na ordem em que aparecem e tudo deve funcionar como esperado. Mas digo logo que eu não garanto que isso aconteça, então use por sua conta e risco.
Todo mundo que programa em Ruby já deve ter definido métodos em classes
singleton ou, para usar um termo mais na moda, em eigenclasses. Mesmo quem não
sabe o que diabos é isso muito provavelmente já as usou sem saber. Até há bem
pouco tempo atrás eu não tinha a mínima idéia da existência dessas coisas, mas
um dia precisei usá-las. Mais ou menos como todo mundo que programa em Haskell
acaba um dia escrevendo um tutorial sobre Monads, todo mundo que tenta um pouco
de metaprogramação em Ruby acaba escrevendo seus próprios artigos sobre eigenclasses. Essa é a minha tentativa de tornar o assunto um pouco menos obscuro
para mim mesmo e para os demais. Depois eu conto o que estava querendo fazer,
vamos primeiro tentar entender essas classes diferentes.
Primeiramente, as classes singleton não têm muito a ver com o padrão Singleton. O termo provavelmente foi escolhido pela alusão à unicidade, mas as similaridades páram por aí. Classes singleton são classes que,
como no padrão, estão associadas a um único objeto. Porém, diferente da implementação comum do padrão,
o objeto não é instância dela, mas de outra classe. O maior problema com o termo
"classe singleton" é a confusão com o nome do padrão, por isso muita gente tem procurado
usar outros termos, como o diferentíssimo eigenclass (que até hoje eu não sei se deu ou roubou o nome do blog do Mauricio Fernandez).
Em Ruby todo objeto possui uma eigenclass associada (para ser realmente preciso, alguns
objetos não possuem, mas vamos assumir que não sabemos disso por enquanto). Os
métodos definidos nesta classe especial ficam disponíveis somente para o objeto
associado e para nenhuma outra instância da mesma classe. Para obter acesso a
ela, pode-se usar a expressão "class << obj; self; end" (onde
obj é o objeto do qual se quer a eigenclass). Quem pretende usar este
tipo de metaprogramação com freqüência pode fazer
como o why
e guardar esta expressão num método em um arquivo qualquer para referência
futura:
class Object
def eigenclass
class << self; self; end
end
end
A eigenclass é única para cada objeto e diferente da classe a partir da qual o objeto foi criado.
a = Object.new
b = Object.new
a.class == Object # => true
a.eigenclass == a.class # => false
a.eigenclass == b.eigenclass # => false
a.eigenclass # => #<Class:#<Object:0xb7ced878>>
Isso quer dizer que métodos adicionados e/ou modificados a estas classes estarão
disponíveis para um objeto apenas. Isso é usado com alguma freqüência para
definir métodos de classe, algo que todo mundo já fez uma vez na vida. Classes
são objetos também, instâncias da classe Class, e possuem uma eigenclass
associada como a maioria dos objetos em Ruby. Por isso podemos definir métodos
de classe:
MyClass = Class.new
MyClass.eigenclass.send :define_method, :instance_count do
@count || 0
end
MyClass.eigenclass.send :define_method, :instance_count_inc do
@count = instance_count + 1
end
MyClass.send :define_method, :initialize do
self.class.instance_count_inc
end
a, b = MyClass.new, MyClass.new
MyClass.instance_count # => 2
Muito para engolir de uma vez só? Eu também achei no início, mas descobri que
fica mais fácil quando se tenta entender uma coisa de cada vez. A primeira é o
método define_method da classe Module (lembre que a classe Class herda de
Module, portanto este método também está disponível para classes). Este método
pode ser usado no lugar da palavra-chave def para (re)definir métodos
de instância dinamicamente. Ele recebe um nome e um bloco para ser
usado como corpo do método. Este é um método privativo, ou seja, só pode ser chamado sobre um
objeto por ele mesmo. Para contornarmos esta limitação usamos o send (por
isso ele aparece ali em cima).
Uma sutileza do define_method é que ele define métodos acessíveis a partir
das instâncias da classe, não da classe em si. A classe MyClass é instância de outra
classe diferente (a classe Class, como está explícito na primeira linha do bloco de código anterior) e se quisermos definir um método para ela,
podemos chamar o define_method em Class:
Class.send :define_method, :instance_count do
@count || 0
end
O problema dessa abordagem é que define o método para todas as instâncias da classe Class.
MyClass.instance_count # => 2
Object.instance_count # => 0
Module.instance_count # => 0
Obviamente existem instâncias da classe Object (posso contar pelo menos sete só
nos dois trechos de código acima), mas o contador de instâncias não funciona direito porque precisa ser incrementado durante a inicialização dos objetos. Isso pode causar um
pouco de confusão e polui o código das classes que não precisam do recurso de
contagem. Uma coisa que realmente não queremos é poluir os programas dos
outros sem necessidade, então é melhor darmos um jeito de definir o método somente
para as classes em que vamos usá-lo.
O problema é que se chamarmos define_method nas classes em si, estaremos
definindo métodos para as instâncias delas e o contador não vai ter muita
utilidade. Por outro lado, se usarmos o define_method de Class, vamos
injetar código em classes demais. Para nos tirar dessa sinuca de bico, eis que surge a magnânima eigenclass. Antes de entender o que está acontecendo, vamos limpar a
sujeira:
Class.send :remove_method, :instance_count
Object.instance_count # NoMethodError
MyClass.instance_count # => 2
Como pode ver, isso remove o método instance_count de todas as classes, exceto
da MyClass. Ela é poupada porque tem o método definido na sua eigenclass, uma
classe intermediária que não aparece na hierarquia de classes, mas que é
consultada antes da classe real e das superclasses quando uma chamada de método
é recebida. Por isso que no trecho de código original em que definimos o
instance_count as duas primeiras definições são solicitadas à eigenclass, não
à classe. Por outro lado, a última definição é feita para a própria classe
MyClass, para redefinir o método de inicialização de suas instâncias de modo a
aumentar o contador.
Tudo isto poderia ter sido feito com o uso da palavra-chave def e do atalho
def objeto.nome_do_metodo, mas resolvi usar define_method porque ilustra
como gerar métodos dinamicamente (e também porque é mais divertido, ora bolas).
A palavra-chave def pode ser usada para definir métodos em qualquer objeto
(não só classes) e o define_method também, mas por que alguém em sã
consciência iria querer fazer isso?
Bom, há várias razões, mas vou descrever apenas o uso que citei no início do
texto. No Mediacloth há uma classe
responsável por resolver nomes de página wiki para URLs que geralmente é usada
somente para ter um dos métodos sobre-escritos. Sem a magia negra de eigenclass
os clientes vão normalmente estender esta classe e definir um trecho
de código personalizado para este método:
class MyLinkHandler < MediaWikiLinkHandler
def link_attributes_for(page)
{ :href => "http://example.com/wiki/#{page}", :class => "internal" }
end
end
generator = MediaWikiHTMLGenerator.new
generator.link_handler = MyLinkHandler.new
Não seria bom se o resolvedor de referências pudesse ser definido com uma
chamada de construtor apenas?
generator = MediaWikiHTMLGenerator.new
generator.link_handler = MediaWikiLinkHandler.new do |page|
{ :href => "http://example.com/wiki/#{page}", :class => "internal" }
end
Esse efeito pode ser obtido com uma alteração simples no initialize da classe
original. O código fica parecido com o que está aí embaixo:
class MediaWikiLinkHandler
def initialize(&block)
eigenclass.send(:define_method, :link_attributes_for, block) if block
end
end
Com Ruby 1.9 tudo isso vai ficar muito mais fácil, já que o método
define_singleton_method (que já é usado por muita gente) será incluído na
distribuição padrão, como o
Taq já notou. De qualquer modo, este
exercício ainda continua válido como forma de aprendizado. É para isto que
estamos aqui, não?
