“Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.”—Alan Perlis, “Epigrams on Programming”
(Esse artigo tem exemplos em Java e Ruby. Estou ignorando as sutis diferenças entre closures e blocos de código no Ruby)
Outro dia, num papo nerd com um colega (“O Francês”), ele me disse que não via nenhuma utilidade para closures com bons olhos a inclusão de Closures no Java. Que até já tinha olhado e brincado um pouco, mas que tudo que closures fazem é perfeitamente possível de fazer sem usá-las.(É... ele me fez corrigir o texto :) )
Bom, ficou bem difícil argumentar aquilo no momento. Realmente, tudo que se pode fazer com closures também é possível fazer sem, da mesma maneira que é possível escrever um programa web em C (muita gente ainda faz e adora) ou escrever um aplicativo comercial em Assembly.
Depois dessa conversa comecei a tentar catalogar usos interessantes de closures. Pode ser que isso não convença ninguém de que são úteis, mas ao menos me serviu para organizar minhas próprias idéias. A seguir listo uma série de usos bem interessantes e bastante comuns de closures.
Bom, minha intenção não é explicar o que são closures – para isso o Akita tem um excelente artigo – mas sim mostrar onde o uso de closures é legal.
Callbacks
Talvez um dos melhores usos de closures sejam callbacks), ou seja, uma função que será executada posteriormente. Trocando em miúdos, é um código que queremos que seja executado quando algum evento acontece no sistema, por exemplo quando um botão é pressionado (conhecido como “events”...), quando uma aplicação inicia, quando algo é gravado ou alterado (“triggers” ou “listeners”...?), ou quando algum estado no sistema muda (“hooks”...?).
Cada linguagem tem sua solução para implementar callbacks, como ponteiros para funções (C e afins), a função como “cidadão de primeira classe” (Python, Javascript), classes anônimas (Java), “delegates” (C#) ou … closures, óbvio (que é solução para Smalltalk e Ruby)!
Cada um defende sua linguagem como gosta, mas independente disso, closures são muito práticas. Eu posso definir um callback de um botão da seguinte forma:
(Código em Ruby/GTK2)
# Cria um botão
button = Gtk::Button.new("Click me")
# Quando clicar, imprime "Cliquei no botão"
button.signal_connect("clicked") { puts "Cliquei no botão" }
A parte do ’{ puts “Cliquei no botão” }’ é um closure. Nesse caso, é o código que vai ser usado quando o botão for ativado (“puts” é para imprimir o texto na console).
Simples assim, sem declarações, sem pré-requisitos, sem detalhes. Simplesmente “toma aqui esse código para executar depois”.
Iteradores (“visitors”)
Estamos sempre processando coleções e iterando sobre elementos. Na maior parte dos casos, um simples loop resolve o problema, mas em outros, somos obrigados a repetir o mesmo loop em uma série de métodos diferentes pois as operações são parecidas, mas não idênticas. Em outros casos a lógica de iteração é um pouco mais complexa e se mistura com a lógica que processa cada elemento.
Closures são fantásticos para resolver esses problemas. Vejamos um exemplo que aconteceu recentemente comigo. Eu precisava substituir o mapeamento do Hibernate em umas 400 classes java. Fiz um pequeno método que encontrava as classes e para cada uma encontrada, eu aplicava a lógica de substituição.
O método para percorrer as classes ficou assim:
def on_java_classes
Find.find(@root) do |file_name|
yield(file_name) if file_name =~ /\/vo\/.*\.java$/
end
end
Esse método percorre toda a árvore de diretórios abaixo de @root e se o arquivo encontrado estiver sob um diretório “vo” e terminar com ”.java”, o bloco de código é executado.
E para usar o método para trocar um mapeamento fica assim:
on_java_classes do |file_name| change_hibernate_mapping(file_name) end
É lógico que eu poderia usar esse loop e meu método tudo em um bolo só, mas agora eu tenho um método genérico que me permite percorrer essas classes e executar o que eu quiser com elas sem duplicar a lógica que itera sobre as classes. Posso, por exemplo, listar todos os mapeamentos, contar quantos “VOs” tenho, vasculhar se existem mapeamentos fora do padrão e outras coisas do tipo.
A coisa fica tão transparente, que posso usar coisas como “next” (para processar o próximo elemento) e “break” (para parar a iteração) dentro dos closures e eles funcionam como esperado. Por exemplo, se eu quisesse apenas fazer um teste com os 10 primeiros arquivos, poderia colocar um “break” no meio, dessa forma:
i = 1
on_java_classes do |file_name|
break if i > 10 # passou de 10 arquivos, caia fora do método
change_hibernate_mapping(file_name)
i += 1
end
Processamento “durante”
Quase todas as operações que fazemos de IO precisam de algo para “abrir” a operação e garantir que ela seja “fechada” quando terminamos o que precisamos. Isso vale para streams, arquivos, sockets, transações, record sets e sei lá mais quantas coisas.
Isso implica em uma lógica bastante incoveniente que costuma ser repetida à exaustão: abra conexão, execute o que precisar, garanta que foi fechado (normalmente com um bloco para tratamento de exceção).
Conexões com bancos de dados são particularmente um porre, porque costumam abrir e fechar vários objetos.
Com closures, resolvemos isso com facilidade. Aqui um exemplo de como se usar o Ruby-DBI da maneira tradicional. O exemplo foi tirado da própria página do Ruby-DBI, mas com o tratamento de exceções apropriado.
require 'dbi'
dbh = nil
begin
dbh = DBI.connect('DBI:Mysql:test', 'testuser', 'testpwd')
sth = nil
begin
sth = dbh.prepare('select * from simple01')
sth.execute
while row = sth.fetch do
p row
end
# Precisamos tentar fechar o statement, não importa qual o erro
ensure
sth.finish if sth
end
# Precisamos tentar fechar a conexão também
ensure
dbh.disconnect if dbh
end
Com closures, a coisa fica bem mais simples. Podemos criar coisas para serem executadas ao redor do bloco de código e simplesmente esquecermos da necessidade de ficar abrindo e fechando objetos. (Aviso: o DBI já tem métodos que funcionam assim).
Primeiro, criamos dois métodos:
# Esse método cuida de abrir a conexão, executar algo
# e garantir q a conexão seja fechada.
def connect(uri, user, password)
dbh = nil
begin
dbh = DBI.connect(uri, user, password)
yield(dbh)
ensure
dbh.disconnect if dbh
end
end
# Esse método executa algo para cada registro recuperado
# em um SQL. Ele cuida de fechar os objetos envolvidos
# no processo.
def for_each_record_in(dbh, sql)
sth = nil
begin
sth = dbh.prepare(sql)
sth.execute
while row = sth.fetch do
yield(row)
end
ensure
sth.finish if sth
end
end
E agora, o código para fazer exatamente a mesma coisa que o primeiro exemplo passa a ser:
connect('DBI:Mysql:test', 'testuser', 'testpwd') do |connection|
for_each_record_in(connection, 'select * from simple01') do |record|
p record
end
end
Toda vez que precisamos de um código “de preparação” e um código “de finalização” podemos usar closures para poupar trabalho. Além das óbvias vantagens de redução de duplicação, fica bem mais difícil esquecer de fechar algo :)
Só para constar, existe um padrão pra isso, é o “Open During” do Kent Beck. Está no livro dele de “Best Smalltalk Patterns”.
Lógica condicional
Não somente de “ifs” e “switches” vivem os condicionais. Com closures, podemos simular condicionais para condições mais complexas.
Digamos que eu tenha um analisador de texto que me retorne palavrões encontrados em um HTML qualquer. Caso eu encontre qualquer palavrão, quero mostrar uma mensagem de erro.Uma maneira de fazer isso seria assim:
# O método "find_dirty_words me retorna a coleção de palavrões # encontrados no texto. dirty_words = html.find_dirty_words unless words.empty? show_error_message(html, dirty_words, "Bad, bad, no cookies for you.") end
Por outro lado, posso criar isso em um método com closures dessa maneira:
class Html
def when_dirty_words_found
dirty_words = html.find_dirty_words
yield(dirty_words) unless words.empty?
end
end
E agora, posso usar assim:
html.when_dirty_words_found do |dirty_words| show_error_message(html, dirty_words, "Bad, bad, no cookies for you.") end
Aliás, agora posso executar qualquer lógica com esses palavrões. Posso tentar limpá-los, contar sua frequência (estatística?), colocá-los em uma lista negra e assim por diante.
O melhor exemplo real de execução condicional com closures talvez seja o uso de REST no Rails (veja o método “respond_to” no “Listing.5”).
Domain Specific Language
Arrisco dizer que é impossível implementar uma boa DSL Interna (definição segundo Martin Fowler) sem closures.
Isso porque eles permitem uma grande flexibilidade na sintaxe, permitindo que você use os closures como blocos de código que podem ser armazenados, executados, repetidos, omitidos, reestruturados, postergados ou quaisquer que sejam as transformações necessárias para sua DSL funcionar.
Exemplos ótimos de DSL são o XML Builder e o Rake. Com pouco esforço você conseguem sintaxes perfeitas que se encaixam dentro do Ruby como se fosse parte da linguagem.
Veja por exemplo, como construir um xml com o XML Builder:
require 'builder'
xml = Builder::XmlMarkup.new(:target=>STDOUT, :indent=>2)
xml.usuario(:id => 127) do
xml.nome("Ronie")
xml.sobrenome("Uliana")
xml.idade(31, :type => "integer")
xml.preferencias do
["strogonoff", "lasanha", "bolo de carne"].each do |item|
xml.comida(item)
end
end
Isso gera o seguinte xml:
<usuario id="127"> <nome>Ronie</nome> <sobrenome>Uliana</sobrenome> <idade type="integer">31</idade> <preferencias> <comida>strogonoff</comida> <comida>lasanha</comida> <comida>bolo de carne</comida> </preferencias> </usuario>
Nesse exemplo, cada aninhamento é um closure, e o builder os rastreia para saber como montar o xml. Muito simples e prático, na verdade.
Generators
Esse eu confesso que nunca me resolveu nenhum grande problema até o momento, mas é uma técnica boa para se ter no cinto de utilidades.
Basicamente, é uma função que retorna outra, a primeira “configura” a segunda. Um exemplo simples que achei foi esse aí abaixo. Ele gera um closure que adiciona sempre o mesmo número ao número passado como parâmetro. Por exemplo, gero uma closure que adiciona sempre 5 a qualquer número que eu passe para ela. No exemplo abaixo criei dois desses, um “adicionador de cincos” e um “adicionador de oitos”.
O exemplo é meio bobo, mas se você pensar um pouco vai achar possibilidades interessantes para isso. Não sei se essas idéias seriam práticas, mas com certeza serão interessantes.
def create_adder(number)
lambda {|x| number + x}
end
add5 = create_adder(5)
add8 = create_adder(8)
puts add5.call(10) # retona 15, ou seja, 10 + 5
# "add5.call(10)" é a mesma coisa que fazer add5<sup><a href="#fn10">10</a></sup>
# Pra facilitar, vamos usar essa notação nos exemplos abaixo
puts add8[ 30 ] # retona 38, ou seja, 30 + 8
puts add8[ add5[ 1 ] ] # retona 14, ou seja, 1 + 5 + 8
puts add5[ add5[ add5[ 0 ] ] ] # retorna 15... adivinha porquê :)
Um bocado complicado de entender? Bom, “lambda” é uma função que pega um bloco de código (o que está entre ”{}”) e retonar uma closure de verdade. Na prática, estou retornando uma função que será atribuída a uma variável para ser executada mais tarde. A parte legal é que essa função é “configurada” com o parâmetro “number”.
Esse é realmente embaçado, acho que fazer um equivalente em Java pode ajudar alguns (só espero não complicar o resto do povo)
public class ClosureExample {
public static interface Adder {
public int call ( int x );
}
public static Adder createAdder ( final int number ) {
return new Adder () {
public int call ( int x ) {
return x + number;
}
};
}
public static void main ( String [] args ) {
Adder add5 = createAdder ( 5 );
Adder add8 = createAdder ( 8 );
System.out.println ( add5.call ( 10 ) );
System.out.println ( add8.call ( 30 ) );
System.out.println ( add8.call ( add5.call ( 1 ) ) );
System.out.println ( add5.call ( add5.call ( add5.call ( 0 ) ) ) );
}
}
Com uma pequena variação disso da para fazer acumuladores. Ou seja, uma função que preserva a memória cada vez que é executada.
def create_accum
memory = 0
lambda{|x| memory += x}
end
accum = create_accum
puts accum[ 5 ] // retorna 5
puts accum[ 10 ] // retorna 15
puts accum[ 130 ] // retorna 145
Conclusão
Closures são muito úteis para várias tarefas comuns da computação. Não é porque sua linguagem favorita não tem e você acha que se vira muito bem nela que Closures deixam de ter sua utilidade. :)
Fechando o artigo do mesma maneira que abri:
“Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.”—Alan Perlis, “Epigrams on Programming”
Have a nice coding! :)
