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.
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
Confira outros conteúdos:
Teste de Acessibilidade de Software
Boas Práticas em TDD
Principais Anomalias Arquiteturais de...
Por Eduardo Em 2017Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.
Aceitar