Sou da área técnica, e com frequência me vejo numa situação que não me agrada muito: Ao descobrir(e gostar de) uma tecnologia/método/ferramenta nova, tento aplicar seja lá no que estiver fazendo. Por um lado isso é ótimo, mas por outro, essa vontade pode fazer com que eu utilize a ferramenta errada para solucionar o meu problema.

Achei legal, quero usar!

Um exemplo disso, é o Redis. O fato de trabalhar com uma estrutura de chave/valor, funcionar em memória, entre outros, sempre me deixou instigado. Li bastante, fiz alguns pet projects para testar, brinquei bastante, mas nunca cheguei a utilizar tudo que a ferramenta me proporciona. Por que? Porque até o momento, nenhum dos problemas que enfrentei precisou da sua utilização(embora utilize sidekiq, minha ideia era utilizar o redis para persistência principal de uma app).

A curiosidade instiga a vontade

Já trabalhei com desenvolvedores que sofriam desse mesmo problema, e vou confessar, estão entre os melhores desenvolvedores que conheço, pois curiosidade e interesse são qualidades muito importantes. A vontade de usar vem acompanhada com essas qualidades. Um caso que me chamou a atenção, foi quando um colega me pediu ajuda para utilizar um “padrão de projeto”, sem sequer conhecer o problema que precisava resolver.

Design Patterns

Os Design Patterns são soluções que podem ser aplicadas à problemas enfrentados diariamente no desenvolvimento de software. As primeiras convenções surgiram em 1994, com a publicação do famoso livro do “GOF”(Gang of four).

A confusão

Então chega um ponto em que conhecemos o problema que precisa ser resolvido: Uma tela/view/camada de apresentação muito complexa. Seja durante a criação ou manutenção, com possibilidade de uma bela refatoração, o código html se perde com a linguagem do back-end, e tudo fica confuso.

Como já temos uma ideia de quais são os patterns que existem, com o estalar de um dedo vem a ideia: “Vou usar um decorator!”.

Imagino que seja pelo nome, ou pela imaginação, onde “decorar” está ligado com visualização. Mas este engano pode causar uma certa confusão, pois o padrão Decorator serve para acrescentar funcionalidades e comportamento a entidades, enquanto o padrão Presenter, este sim, serve para interligar sua camada de modelo/negócio/etc com seus componentes de visualização.

Esse pequeno engano também é respondido no stackoverflow.