Olá, pessoal! Hoje vou começar mais uma série de artigos, dessa vez será sobre Design Pattern. Claro que não abordarei todos os padrões (até porque não tenho uma real experiência em todos eles – na minha opinião, fazer um projeto como prova de conceito é uma coisa; usar para resolver problemas de cliente é outra), mas aqueles que considerei importantes e que são muito comuns no dia-dia.

Como diz o título da série, não há uma receita de bolo quando falamos em padrões, depende muito do contexto. E não se preocupe se você não sabe todos os Design Patterns de cabeça; até porque a ideia não é decorar, e sim saber usar. Ter um bom livro de Design Patterns na sua mesa sempre é bom.

Para esta série, não vou seguir um padrão em cada artigo, pois tudo depende do Pattern que vou abordar. Alguns nem precisam de código para entender, outros são tão abstratos que é preciso desenhar… Enfim, vou buscar diferentes formas de explicar cada Design Pattern da série, para que, ao término dela, você saiba a teoria e tenha uma ideia prática de onde como usá-lo.

Design Pattern

Antes de mais nada, é preciso conhecer cada tipo de padrão. Eles podem ser de criação, de estrutura e de comportamento. Por exemplo: se preciso adotar um padrão para criação de objetos, terei que olhar para os padrões existentes em “padrões de criação”. Por que lá? Veremos daqui a pouco…

Então, não adianta querer decorar os padrões. Na verdade, eles não foram feitos para serem decorados, mas sim para saber quando aplicá-los de acordo com o contexto. Repito: Design Pattern não é receita de bolo, que se você seguir do passo 1 até o 10 vai ter a solução. Aliás, a solução do seu “problema” é com você. Design Pattern não é uma biblioteca com resoluções de problemas.

Conhecendo os padrões

A seguir, fiz a definição da maneira mais simples e objetiva possível.

Note: Quando você tiver com algum problema de design, pense em que tipo de problema que você tem antes de adotar alguma padrão.

• Padrões de criação:

Ajudam a encapsular  a criação de objetos de um TIPO. Ou seja, é quando temos várias “respostas” com base no tipo do objeto passado. São eles: factory method, abstract method, builder, prototype, singleton, multiton e object pool.

Exemplo: Se o objeto é do tipo pessoa jurídica, eu vou fazer isso: “Olá xxx,  CNPJ:111”. Mas, se for pessoa física, é assim: “olá xxx, CPF:0000”.

• Padrões estruturais:

Estão relacionados às interações entre os objetos no sistema. Ou seja, como os meus objetos vão se relacionar com os outros. Buscam evitar o alto acomplamento entre objetos. São eles: adapter, bridge, composite, decorator, facade, front controller, flyweight e proxy.

Então, quando você precisar definir como serão as interações entre objetos, não se esqueça de dar uma olhada nos padrões estruturais e ver qual deles pode atender à sua necessidade.

• Padrões comportamentais:

Estão relacionados ao fato de saber quais intenções que um objeto pode fazer e como ele se relaciona com os outros objetos. São eles: command, iterator, mediator, observer, state, strategy, template method e visitor.

Como estudar?

Há dois livros bem famosos sobre o assunto. Um deles é do Erich Gamma, o Padrões de Projeto, e o outro é da série “Use a Cabeça: Design Pattern”. E qual comprar? Eu comendo os dois. A ordem de leitura, na minha opinião, seria primeiro o da série Use a Cabeça, caso você seja iniciante no assunto. O livro é bem didático.

O do Erich eu diria é quando já temos uma certa dose sobre Design Pattern e queremos entender com mais detalhe. Há trechos no livro em que o autor não é muito claro, e que para conseguir entender o que ele quer dizer é preciso já ter uma certa base de Design Pattern, do contrário, a informação é passada de forma perdida. O livro do Erich é uma espécie de referência que deve ficar na sua mesa para consultar. Até porque você não vai decorar tudo.

Vou ficando por aqui e espero que tenham gostado deste primeiro artigo. No próximo, já vamos brincar com um dos padrões de criação!