Voltar
Por que eu devo ler este artigo:Este artigo aborda o assunto design patterns, mais especificamente os padrões Observer e Singleton, soluções bastante conhecidas pela comunidade de desenvolvimento de software. Eles resolvem problemas utilizando algoritmos elegantes que focam no uso de interfaces, reaproveitamento de código e uso adequado da tag synchronized. O Observer resolve o problema de publisher-subscriber de maneira elegante através do uso de interfaces e de uma solução simples para o aumento do número de subscribers. Já o Singleton resolve, com poucas linhas de código, o problema de entidades que precisam fornecer apenas uma instância para toda a aplicação.

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.

Modelo de classes contendo a primeira ideia de implementação do modelo publisher-subscriber
Figura 1. Modelo de classes contendo a primeira ideia de implementação do modelo publisher-subscriber

A Figura 1 exemplifica o modelo de classes descrito. Nessa solução, a cada vez que o método notifySubscribers da classe BookClub é chamado, todos os seus assinantes são notificados recebendo as publicações desejadas. Portanto, a solução atende aos requisitos necessários e modela adequadamente o problema apresentado. Apesar de isso ser verdade, a manutenção dessa solução pode ser problemática, devido às seguintes razões:

  • Imagine que o clube de livros (BookClub) passe a fazer bastante sucesso e, ao invés de três leitores, passe a ter cem. Perceba que a cada novo as ...
    Quer ler esse conteúdo completo? Tenha acesso completo