Conhecendo os padrões de projeto Observer e Singleton
Este artigo aborda o assunto design patterns. Mais especificamente serão discutidos os padrões Observer e Singleton, soluções bastante conhecidas pela comunidade de desenvolvimento de software.
Design pattern é um termo bastante discutido, mas pouco entendido. Elucidando, ele representa uma solução reutilizável em termos de codificação para algum, ou alguns tipos de problemas, que já foi testada e possui comprovada eficácia. Neste artigo serão discutidos dois design patterns: o Observer e o Singleton. Apesar de conhecidos, é importante entender com clareza suas implementações e que tipo de problemas eles resolvem, já que é comum desenvolvedores discutirem soluções usando esses constructos sem entendê-los corretamente, ou pior, confundindo-os com outros.
Note que, como design patterns são soluções comprovadas para certos tipos de problemas, entendê-los é essencial para se tornar um bom programador. Isso porque suas implementações muitas vezes não são óbvias e, conhecendo-as de antemão, economiza-se muito tempo em desenvolvimento, pois não há necessidade de testar saídas não comprovadas para problemas conhecidos.
Para este artigo a linguagem de programação Java foi escolhida para exemplificar os design patterns citados, porém, como os exemplos aqui apresentados são simples, portá-los para outras linguagens é bastante trivial. A simplicidade dos algoritmos mostra outra característica interessante nos design patterns: o código necessário para implementá-los é pequeno e pouco complicado, o que facilita prover uma solução simples para problemas diversos. Mais ainda, isso mostra que o entendimento de design patterns vai além do código: é preciso entender a quais problemas eles se aplicam e como resolvem tais questões.
Design pattern Observer
Um cenário que aparece constantemente no mundo do desenvolvimento de software é o de como modelar problemas do tipo publisher-subscriber, ou seja, uma situação onde existem vários objetos (subscribers) que necessitam receber informações quando um evento oriundo de um único objeto (publisher), o qual sofreu uma mudança de estado, ocorre.
Veja um exemplo concreto: imagine um clube de livros (publisher) que envia, a cada lançamento, exemplares a seus assinantes (subscribers). Uma possível solução que se pode imaginar é uma classe representado o clube de livros (BookClub) e várias representando seus assinantes (John, Maria, Newton, etc). Nesse modelo, a cada publicação, ou seja, mudança de estado na classe BookClub, seus signatários são avisados, implicando que as classes John, Maria e Newton sejam informadas do lançamento do novo livro.
O exemplo utilizado na Figura 1 é meramente didático para ilustrar a importância dos conceitos discutidos. A opção de definir cada indivíduo como uma classe do modelo não deve ser considerada em uma aplicação real.