codificando.com

Depois de programar algum tempo em Ruby, me senti muito incomodado em ter que repetir um determinado código para manter minha estrutura respeitando a Law of Demeter. Pra quem não está familiarizado, segue um simples exemplo em Rails:

#models
class Post < ActiveRecord::Base
  has_many :comments
end

class Comment < ActiveRecord::Base
  belongs_to :post
end

#view - erb|haml
@comment.post.title
@comment.post.name
@comment.post.something_else

O exemplo é um pouco forçado, mas o problema claro do exemplo é que estamos conhecendo demais sobre o objeto post dentro de comment. Se for necessário alguma alteração em algum dos atributos que estamos acessando diretamente, possivelmente isso resultará em modificações em cascata em todo código.

Depois dessa explicação básica para quem ainda não conhecia a Law of Demeter, vamos aplicar algumas soluções:

Segunda tentativa:

#models
class Post < ActiveRecord::Base
  has_many :comments
end

class Comment < ActiveRecord::Base
  belongs_to :post
  def post_title
    post ? post.title : nil #preciso verificar se é nulo, caso contrário terei problemas
  end
  def post_name
    post ? post.name : nil #preciso verificar se é nulo, caso contrário terei problemas
  end
  def post_something_else
    post ? post.something_else : nil #preciso verificar se é nulo, caso contrário terei problemas
  end
end

#view - erb|haml
@comment.post_title
@comment.post_name
@comment.post_something_else

Essa mudança resolve o problema. Acontece que isso acaba sendo um pattern para resolver o problema, portanto, precisamos encontrar uma forma de não ficar repetindo esse código.

Quem já leu o livro The Pragmatic Programmer, tem bem na memória o capítulo que apresenta o conceito DRY – D’ont Repeat Yourself. Quem programa em Ruby e principalmente já usou o framework Rails sabe bem que DRY é um dos chavões que estão imbutidos na propaganda. Vamos então tentar fazer mais algumas modificações pra tentar alcançar esse objetivo:

Terceira tentativa:

#models
class Post < ActiveRecord::Base
  has_many :comments
end

require 'forwardable'
class Comment < ActiveRecord::Base
  extend Forwardable
  belongs_to :post
  def_delegator :post, :name, :post_name
  def_delegator :post, :title, :post_title
  def_delegator :post, :something_else, :post_something_else
end

#view - erb|haml
@comment.post_title
@comment.post_name
@comment.post_something_else

O módulo Forwardable já vem com o Ruby. Portanto, a solução mais obvia foi usar esse módulo para melhorar o exemplo anterior. Apesar de escrever menos código, essa alternativa tem o inconveniente de não verificar se o objeto post é nil, causando assim NoMethodError em alguns casos. Sendo assim, a alternativa anterior ainda parece ser mais adequada. Porém, a duplicação de código ainda me incomodava bastante, portanto, resolvi montar uma solução única que deu origem a gem demeter.

A solução definitiva:

#no shell
> sudo gem update --system
> sudo gem sources -a http://gemcutter.org
> sudo gem install demeter

#models
class Post < ActiveRecord::Base
  has_many :comments
end

class Comment < ActiveRecord::Base
  extend Demeter     #extends demeter module
  demeter :post      #demeter post object
  belongs_to :post
end

#view
@comment.post_title
@comment.post_name
@comment.post_something_else

Basicamente o problema foi resolvido com 2 linhas de código:

  extend Demeter
  demeter :post

A vantagens são visíveis porque (1) você escreve bem menos, (2) já existe a verificação de objetos nulos e (3) caso você queira sobrescrever o comportamento padrão, basta criar um método que responda a mesma mensagem que a gem demeter responde. Dessa forma, o método criado pelo programador semrpe terá prioridade.

O código fonte do projeto está em http://github.com/emerleite/demeter com todas as instruções para utilização tanto em Ruby quanto em Ruby on Rails. O código fonte tem todos os testes automatizados que cobrem diversos cenários. O resultado desses testes podem ser vistos em http://runcoderun.com/emerleite/demeter. A página da gem fica em http://gemcutter.org/gems/demeter

Aguardo o feedback de vocês

Uma discussão que sempre vem a tona no forum do GUJ e em conversas entre colegas de trabalho, é sobre o uso do pattern TO/DTO (Antigo VO, que hoje em dia significa outra coisa). Eis o trecho do livro Core J2EE Patterns:

Transfer Object

Problem
You want to transfer multiple data elements over a tier.

Forces

• You want clients to access components in other tiers to retrieve and update data.
• You want to reduce remote requests across the network.
• You want to avoid network performance degradation coused by chattier applications that have high network traffic.

Solution
Use a Transfer Object to carry multiple data elements across a tier.

O Pattern Transfer Object, foi criado para solucionar os problemas dos Entity Beans (EJB 2.x), quando retornados para outro TIER, geralmente a apresentação, pois geralmente ficam em JVMs separadas. Quando você tenta retornar um Entity Bean, o que é retornado na verdade é um Stub para acesso ao mesmo. Quando são invocados os Getters deste, é aberto uma conexão de rede para cada invocação. Isso é extremamente custoso, gerando um overhead extremamente desnecessário.

Bem, mas nosso papo é tradução certo?

INI-UPDATE: Consegui o livro em português com um colega e estou adicionado a tradução em português também.

Vejamos a tradução para o português:

Transfer Object

Problema
Você deseja transferir diversos elementos de dados sobre uma camada.

Forças

• Você deseja que os clientes acessem componentes em outras camadas para recuperar e atualizar os dados.
• Você deseja reduzir as solicitações remotas ao longo da rede.
• Você deseja evitar a degradação do desempenho da rede causada pelas aplicações muito ruidosas que têm alto tráfego de rede.

Solução
Use um Transfer Object para enviar vários elementos de dados por uma camada.

O leitor atento perceberia que o segundo e terceiro item da seção Forças fala de tráfego de rede e degradação do desempenho da mesma.

FIM-UPDATE

Acontece que, o termo TIER, foi traduzido erradamente no livro em português para camada. O mais correto seria camada física ou nó. Em Java isso pode ser considerado simplesmente “em uma outra JVM”. Essa tradução gera confusão a todo momento. Se você conversar com 10 desenvolvedores, vai perceber que a maioria acredita que TO/DTO pode/deve ser usado entre LAYERS (i.e. camadas lógicas, usadas apenas para organização do software). Eis um grave problema de tradução, pois uma grande parte não sabe a diferença entre LAYER e TIER, e o uso do Pattern dessa forma se mostrou uma solução sem sentido, conforme diversas discussões no próprio GUJ.

Outro grave problema recorrente é a tradução dos livros de Patterns. Pegue por exemplo o PEAA traduzido e veja o Pattern Active Record. O nome do Pattern foi traduzido para Registro Ativo. Parece piada, considerando que um dos maiores valores de um Pattern é a criação de um vocabulário comum.

Em fim, existem diversos outros exemplos ruins, e só quem perde com isso é o leitor.

Mas nem tudo está perdido. Existem sim traduções bem aceitáveis, porém em quantidade extremamente reduzida e demoram a sair. Você está disposto a esperar? Não acha melhor comprar o livro em inglês mesmo?

Mas se eu não domino o inglês?

Sinto informar, mas você vai ficar refém de boas traduções, isso quando tiver tradução. Sem contar os podcasts, como por exemplo os videos disponibilizados no InfoQ. Na verdade, muita coisa não tem tradução e nem vai ter, isso é fato.

Esse cenário serve pra reforçar a idéia de que o inglês na área de TI é fundamental para o profissional se manter atualizado, visto que existem livros que não são traduzidos, e os que são, ou a tradução é horrível, ou demora muito para ser traduzido após o lançamento da versão original.

Mesmo que o cenário mude, ainda assim tem muita coisa que você estará perdendo. Quem sabe um emprego no exterior?