#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

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Essas situações são muito frequentes, principalmente a primeira, com códigos fedorentos. Por isso, eu adoto uma postura: Sempre assino meus códigos.

O que seria assinar o código? Bem, assinar o código é aquela simples documentação que vem logo acima do arquivo, como por exemplo em Java, usando o famoso javadoc:

package xpto;
import x;
/**
* @author Emerson Macedo
*/
public class Abc {
// ...
}

Assinar o código pode parecer meio arrogante mas o objetivo não é esse. O propósito de assinar o código e se expor. Quando você assina alguma coisa, explicitamente está colocando a sua autoria naquilo, ficando sujeito tanto a críticas, quanto a elogios.

Quando algum pintor faz um quadro, ele sempre vem assinado em alguma parte. Dificilmente o autor dessa obra de arte vai terminar esse quadro antes que ele tenha certeza que está com ótima qualidade (pelo menos na visão dele).

E no que isso implica? Isso implica que você (1) vai pensar 2 vezes antes de colocar aquela habitual gambiarra no seu código, (2) vai pensar bem antes de concluir alguma coisa sem devidos testes automatizados e (3) vai ser muito mais responsável com o código que você está desenvolvendo.

Conclusão

Como qualquer desenvolvedor, já desenvolvi códigos ruins em diversos projetos pelos quais passei. Aquele que nunca desenvolveu código fedorento que atire a primeira pedra. Hoje em dia, não desprezo a qualidade daquilo que desenvolvo. Acredito muito que quando assinamos nossos códigos e nos damos conta que outro desenvolvedor/programador irá utiliza-lo futuramente, isso gera um maior cuidado com a qualidade.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Muitas vezes parei pra explicar pra vários colegas de trabalho sobre a importância do assunto, fiz pair-programmming pra ensinar como se faz, em fim, investi muito tempo pra ajudar diversas pessoas com isso. Por incrível que pareça, tem muiiiiiita gente que ainda não entendeu muito bem. Portanto, resolvi classificar a relação entre o desenvolvedor e os testes automatizados em 5 níveis.

São eles:

1. Ignorante: Esse é o nível no qual o desenvolvedor não sabe direito o que são testes automatizados ou sequer ouviu falar sobre o assunto (acredite, ainda tem gente assim em pleno 2009).
2. Indiferente: Nesse nível, o desenvolvedor já sabe o que é, mas acha que essa prática/tecnica não serve pra nada. Apenas toma tempo e atrasa a entrega do produto que está sendo desenvolvido. A sensação dele é que sem os testes a entrega seria mais rápida (e a quantidade de bugs tb vão aparecer mais rápido).
3. Prequiçoso: Nesse nível eu encontro muita gente. É nesse nível onde a ficha caiu mas o camarada não toma coragem pra aprender a fazer os testes automatizados. Ainda existe o medo de perder muito tempo com essa prática e a preguiça impera, impedindo o progresso.
4. Decidido: Esse pra mim é o nível mais importante. É nessa hora que o desenvolvedor se dá conta que não dá mais pra desenvolver software sem testes automatizados. É nessa hora que o cara pensa: “como eu pude desenvolver sem testes até hoje?”. É nesse momento que inicia-se o aprendizado.
5. Profissional: Nesse nível, o desenvolvedor já não se sente mais confortável desenvolvendo sem testes automatizados. Desenvolver sem testes o incomoda profundamente. Nesse momento o mesmo está maduro quanto a importância dos testes e a aplicação na prática. O mesmo começa a se tornar um evangelista para os demais desenvolvedores e sempre que pode, fala sobre o assunto. Nesse momento o desenvolvedor pode realmente dizer que é um profissional, pois hoje em dia não se admite mais desenvolver sem ter testes automatizados que garantam qualidade daquilo que se desenvolve.

Em qual nível você está?

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Tenho percebido de maneira geral que a maioria desses fornecedores não conhece muito do que nos tem apresentado. Uma simples pergunta sobre Message Broker e ninguém, absolutamente nenhum dos fornecedores soube responder direito. Na verdade, alguns deles confundiram com o produto Message Broker da IBM e outros com ESB.

Teve uma outra empresa, que não posso mencionar o nome por motivos óbvios, que conseguiu vender um projeto SOA aqui dentro, que não era nada mais que instalar um ESB, um servidor de processos e fazer um sisteminha de referência e só !!!! O Pior de tudo é que ganharam uma grana preta com isso.

O fato é que está muito difícil opinar sobre qual fornecedor a empresa deve confiar o “projeto” SOA, e o cenário atual, com a pressão vinda de cima pra baixo para implantar alguma coisa de SOA, só porque está na moda e sem as vezes nem entender o que é, faz como que muitos fornecedores consigam essa maravilhosa TETA pra mamar nas grandes corporações.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.