Design Patterns

Há um tempo atrás eu criei um artigo sobre o que é e como utilizar o decorator pattern. Ele fazia parte de uma série de posts sobre design patterns que iniciei.

Dando continuidade a esta série, hoje vou mostrar um exemplo mais real do uso dele e que talvez explique melhor a sua utilidade. O post antigo mantém-se, porém este vai ilustrar um pouco melhor.

Bom, para relemebrar: o decorator pattern tem como intenção mudar ou adicionar comportamentos de um determinado objeto sem precisar modificar sua classe.

O exemplo utilizado aqui foi retirado "do mundo real" e adaptado para o post. Acontece que um usuário poderia marcar a ordem e quais compressões um determinado arquivo deveria sofrer. Entre as possibilidades, estavam o Gzip e o Bzip.

Existem maneiras e maneiras de se resolver este problema. A escolhida foi utilizando o Decorator para retornar o conteúdo do arquivo comprimido e seu nome final, já com as extensões .gz e .bz2 definidas.

O meu artigo Como usar mod_rewrite de verdade fez um bom sucesso. Então, decidi fazer este artigo, que mostra como a utilização do mod_rewrite pode impactar na arquitetura de uma aplicação web, use esta aplicação um Framework ou não. Será feito uma análise de implementação de URL's amigáveis para sites de pequeno e médio porte e também como ele é utilizado em frameworks MVC.

Há um tempo, fiz um post falando sobre o porquê usar URL amigável. Muitos sites têm adotado isto, principalmente os que utilizam algum framework como Zend Framework, CakePHP, Symfony, CodeIgniter, na maioria das vezes por imposição do próprio Framework. Mas isto não é uma exclusividade do PHP, Django (Python), Ruby on Rails (Ruby) entre outros também a utilizam.

Olá! Faz um tempo que não mexo com perl. Encontrei perdido um arquivo com esse exemplo que fiz em 2008, segundo a data de última modificação. Então, decidi dar continuidade aos posts de design patterns. Esse padrão é bem interessante, poderia ser traduzido para Fachada.

Eu gosto dessa tradução, porque traduz bem direitinho o que ele representa, é uma fachada para "esconder" chamadas de vários métodos de objetos diferentes atrás de um mesmo método. Pense assim:

Toda vez que eu aperto o botão de uma máquina de café e pedir um mocacchino, acontece a mesma coisa:

• Moe-se o café
• Pega-se um copo
• Esquenta-se a água
• Passa-se o café
• Coloca-se o café passado no copo
• Coloca-se o chocolate
• Coloca-se o leite
• Apita pra dizer que está pronto

Se olharmos isso com a visão de um pojetista, vemos que temos várias responsabilidades e que não podemos deixar tudo numa mesma classe, como por exemplo:

• Responsável por moer o café
• Responsável por colocar algo no copo
• Responsável por pegar 1 copo novo
• Responsabilidade de saber quanto de cada ingrediente por no copo
• Responsabilidade de apitar e escrever nos leds

Enfim, para que o código seja organizado, precisamos distribuir as responsabilidades de acordo com as necessidades e obrigações de cada classe. Porém, cada vez que o botão for pressionado, seria muito cruel ter que chamar várias classes e executar esses métodos que selecionam o copo, moem o grão, etc.

Para esses casos foi pensando o Facade Pattern, ou seja, a Fachada. Todo aquele algoritmo descrito na primeira lista acima, é encapsulado dentro de uma classe específica para a máquina de café, dentro do método pressionaBotao, por exemplo. Chamando o método, ele se encarrega de interagir com os objetos de seleção do copo, do cálculo da quantidade de ingredientes, etc.

Olá! Dando continuidade ao post anterior, sobre Decorator Pattern. Mostrarei neste post aqui um exemplo de como e porquê usar o Adapter Pattern. Qualquer dúvida, comente!

Rá! Acá estou eu para explicar um pouco mais sobre o Decorator pattern, um deles que eu acho pouco usado, mas pode salvar vidas. Tem poder na mão. Alguns podem já ter noção do que seja, mas outros devem estar se perguntando: 'WTF??'. Este post é mais ilustrativo e didático, mas há um outro onde eu dou um exemplo real do uso do decorator pattern. Então vamos lá: