anderson leite

A idéia de componentes sendo construídos a partir de “sub componentes” é algo bem comum em um software. Construir objetos a partir de “sub objetos” é o que sugere o padrão Composite, ou seja, objetos simples se integrando para resultar em um mais complexo e interessante para o sistema.

Vamos pegar um exemplo:

Contruir um Copo de suco é uma composição de uma série de tarefas.
Uma dos pontos positivos aqui é que qualquer objeto do sistema que precisar do CopoDeSuco não precisa se preocupar com a complexidade da criação desse objeto.

Show me the code!

O GoF chama essa situação de “the sum acts like one of the parts”. Primeiro precisamos de uma interface comum aos objetos. Essa interface é chamada de component.

Cada tarefa “indivisível” do processo é chamada de leaf. Cada um desses objetos deve implementar a interface acima.

O Composite, enfim, é o componente no nível mais alto da hierarquia.

Nossa tarefa tem apenas um initialize e uma método “duracao”. Obviamente poderia ter muitas outras características.

Vamos a criação das tarefas:

AdicionarIngredientes e Mistura são dois leafs, ou seja, duas tarefas que não dividimos nesse modelo. Vamos criar um component a partir desses objetos.

O objeto Suco é o resultado dessa composição. Ao criarmos esse componente, precisamos de um array de sub tarefas. Criaremos os métodos que adicionam e removem essas sub tarefas.

Para evitar duplicação de código, vamos extrair um component e criaremos a classe Composite.

Aplicando a mesma lógica agora temos a classe Suco da seguinte forma:

E aplicamos a mesma idéia a classe CopoDeSuco. Essa classe é uma composição entre um component e um leaf.

Nossa classe composite poderia ter herdado diretamente de Array para receber os métodos que precisamos, porém essa seria uma implementação estranha. Um composite não é um tipo “especializado” de array, e estariamos utilizando a herança apenas por preguiça fazendo isso.

Integração é um dos maiores desafios na construção de um sistema, cada
alteração causada por determinada parte do código pode causar mudanças
no sistema com um todo. Em uma planilha, ao alterar uma célula, vários
outros objetos podem mudar, como uma atualização de uma conta ou
recriar um gráfico. Manter esse tipo de integração não é simples, e alguns
padrões são voltados para diminuir esse tipo de acoplamento.

O Rails já implementa uma forma de atacar esse problema no próprio
Active Record, fazendo callbacks na classe ActiveRecord::Observer.

O código abaixo tenta demostrar uma implementação e solução desse problema.
Temos uma classe Funcionário e queremos manter avisados
todos os objetos do sistema que se interessem em modificações nele.

Agora vamos criar a classe Pagamento. Essa classe imprime um log a cada
vez que o salário do funcionário for alterado. Para isso, vamos laterar o
initialize da classe Funcionario para receber também um obejeto do tipo
Pagamento. Cada vez que o salário for alterado, agora chamanos o método
update do pagamento.

Mas e quando mais uma classe precisar ser informada das alterações no Funcionário ?
O código acima deixa as classe muito acompladas. Uma forma de diminnuir essa dependência pode ser criar uma lista de “observadores” ao criar o funcionário. Dessa forma poderiamos ingormar todos os objetos da lista quando uma alteração no funcionário for feita. Apenas precisamos aqui estabelecer uma interface, ou seja, todos os objetos que estão observando o funcionário terão o método update para serem notificados.

Agora podemos facilmente adicionar um novo observador, veja:

Nossa implementação agora está boa, mas e quando precisarmos observar um outro objeto do sistema ? Precisariamos então copiar a mesma idéia nesse outro objeto.

Um objeto que está sendo observado é chamado de Subject. Podemos resolver isso criando uma classe Subject que contém os métodos que adicionamos no Funcionario.

E usar herança nos objetos considerados Subject:

HERANÇA DE NOVO ! ? ! ?

Vamos dar preferência a composição ao invés da herança visando diminuir o acoplamento entre nossas classes. Para isso vamos alterar a classe Subject para um Módulo.
Utilizando o módulo Subject como mixin melhoramos a implementação:

Essa é exatamente a idéia da classe Observer encontrada na documentação do Ruby:

Portanto podemos incluir o próprio Observer do Ruby:

Melhorando o Observer usando blocos.

O método add_observer do Ruby não aceita blocos, mas podemos melhorar e solucionar isso aceitando blocos no módulo Subject que tinhamos criado anteriormente, chegando a uma implementação bem interessante de Observer:

Mais…
Entrevista com os autores do famoso livro do Gof, 15 anos depois de lançado:

Se você tem alguma sugestão para melhorar o código acima comente ou crie um fork no github.

É interessante conhecer como outros programadores pensaram para solucionar casos que costumam se repetir durante o desenvolvimento de software. Alguns casos recorrentes foram catalogados em 1994 pela GoF, no livro sobre Design Patterns. Vamos ver como aplicar alguns casos em Ruby.

Considere um sistema complexo onde em uma determinada parte do código existe a necessidade de uma variação. As vezes esse núcleo pode fazer uma coisa enquanto outra vez é necessário fazer outra. Para exemplificar melhor, vamos usar uma classe “Relatorio”. Nosso relatório mostrará um conteúdo inicialmente em HTML.

Vamos deixar de lado a questão do html na classe agora, apenas para efeito de análise do código.

Nesse momento nossa classe gera apenas o relatório em um formato, mas voltando ao problemas que estamos resolvendo, temos a necessidade de criar o mesmo relatório porém em um formato diferente, por exemplo pdf ou texto puro mesmo.
O que fazer agora que é necessário um relatório em formato diferente ?
Bem…(rs)..uma abordagem poderia ser:

Bonito nao ?
Para solucionar esse problema de forma orientada a objetos poderiamos criar uma classe abstrata que define o comportamento de um relatório, ou seja, que define que um relatório de ter um head, um body, um footer, etc. Mas como criar uma classe abstrata em Ruby ? Embora não exista a palavra chave reservada “abstract” o conceito permanece presente na linguagem. Vejamos:

A classe Relatorio agora possui os métodos que definem um relatório. Obviamente esses métodos podem ser invocados. A solução para isso normalmente é lançar uma exception nesses métodos não implementados.
Agora que temos nossa classe abstrata, podemos criar subclasses de Relatorio que contém a implementação de cada um dos tipos, por exemplo para HTML:

E a implementação para Texto:

Agora para usar nossos relatórios podemos fazer:

Esse é o Template Method, um dos patterns que deram origem ao famos livro de Design Patterns do GoF.
Mas…um dos princípios mais discutidos em engenharia de software nãe era …”Prefira composição ao invés de Herança” ?

HERANÇA!?!?!?!

Compor e delegar são formas muito mais recomendadas de construir o design de uma aplicação. O que podemos fazer para melhorar nossa solução seguindo essas idéias ?
Primeiramente vamos parar de usar a classe relatório como uma superclasse, vamos refatorar o código e criar uma superclasse chamada “Formatter”. Essa classe servirá para pensarmos em composição. Nossas implementações de relatórios agora ficam assim:

Agora podemos começar a pensar em composição. De volta a classe Relatorio, agora o “initalize” receberá um Formatter. Fica mais fácil imprimir um relatório agora, veja:

Agora para usar nossos relatórios podemos fazer:

Executar um núcleo diferente agora depende de como nosso objeto foi composto. O acoplamento agora é bem menor. Essa é a idéia do Strategy, tiramos a herança e favorecemos a composição, onde todos os objetos suportam
suportam a mesma interface, mesmo que não exista a palavra chave reservada em ruby.

Mas da pra melhorar um pouco ainda, não ?
Repare no método “imprime_relatorio” da classe Relatorio. Esse método passa o titulo e o texto
para a implementação do relatório. Podemos melhorar isso passando uma referência do próprio objeto
Relatório com self!

E pra melhorar um pouco mais e utilizar uma das características importantes do Ruby, podemos passar o conteúdo
do relatório através de blocos, tirando de vez a herança!

Por mais que algumas palavras chaves da orientação a objetos não sejam explicitas no ruby, os conceitos estão muito presentes.
Se você tiver alguma sugestão para melhorar o código acima, por favor, comente ou crie um fork do gist do Diego Carrion no github.