oop

Há tempos eu venho lendo sobre XP (eXtreme Programming), Scrum e Feature Driven Development (FDD). São metodologias ágeis de desenvolvimento de software. O engraçado é que praticamente, ao meu ver, fazem a mesma coisa, porém de forma diferente. E todas elas frizam a importância dos testes unitários e, mais especificadamente, testes unitários antes do desenvolvimento, o chamado TDD (Test Driven Development). Como nunca havia trabalhado desta forma, ainda não tinha uma opinião sobre isso. Apenas comentários e depoimentos de que usa. Somado a isso, veio aquele senso de desafio, de inovação e curiosidade.

Faz alguns meses, e decidimos, eu e o Emanuel Zabka, implantar o TDD no desenvolvimento na empresa em que trabalhamos. Academicamente é falado muito em refactoring e mudanças de requisitos, mas na prática, eu nunca havia notado a quantidade de modificações que um mesmo código/classe/arquivo é modificado num curto período de tempo e a longo prazo.

Os testes me ajudaram a enxergar, não só as dependências do sistema, como também, acoplamentos desnecessários; a qualidade dos códigos; do design do projeto; e, consequentemente, diminuiu muito os bugs mais corriqueiros, como validação de campos. Mesmo tendo várias coisas boas, há coisas ruins, como aumento do tempo de desenvolvimento - o que, apesar de nunca ter medido, diminui o retrabalho e tempo utilizado no futuro em correções de bugs -, aumento da complexidade da arquitetura - a fim de manter uma maior coesão com baixo acoplamento, entre outros menos relevantes.

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.

Quantas vezes você faz um arquivo que é exatamente igual à um outro arquivo por dia? Quantas vezes você abre um arquivo só para copiar um trecho de código que é utilizado em vários arquivos? Quantas vezes você se vê fazendo a mesma coisa que fez em outro lugar?

E aquela palavra que você sempre escreve errada? Aquela função que você sempre esquece o nome?

Conheça algumas dicas para aumentar a produtividade e diminuir o trabalho dessas coisas rotineiras.

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á: