O Observer Design Pattern é como um podcast

Se você ouvir podcasts, já estará familiarizado com o padrão Observador. Na verdade, você é um "observador".

Aqui está a definição para o padrão Observador:

O Padrão do Observador define uma dependência de um para muitos entre objetos, de modo que, quando um objeto muda de estado, todos os seus dependentes são notificados e atualizados automaticamente.

Vejamos a definição relacionada aos podcasts.

Encontrei um podcast interessante chamado developer tea.

Depois de clicar no botão ASSINAR, agora estou na lista de inscritos.

Quando o chá do desenvolvedor lançar um novo episódio, o aplicativo notificará a mim e a outros assinantes. Ele baixa o novo episódio para nós.

Essa é exatamente a definição do padrão Observer!

O Padrão do Observador define uma dependência de um para muitos entre objetos, de modo que, quando um objeto muda de estado, todos os seus dependentes são notificados e atualizados automaticamente.

Existe um relacionamento um-para-muitos entre o podcast para desenvolvedores e os assinantes.

Quando o chá do desenvolvedor muda de estado, como o lançamento de um novo episódio, todos os assinantes do chá do desenvolvedor são notificados e atualizados.

Vamos implementá-lo no Ruby.

Comece com uma versão simples.

A classe Podcast contém uma lista de episódios e possui um método para adicionar_episodo à lista.

Em seguida, podemos criar o podcast developer_tea e adicionar o episódio 1 a ele assim:

Quero receber uma notificação sempre que um novo episódio for lançado.

Podemos me atualizar depois de adicionar um novo episódio à lista:

E sempre que recebo uma atualização do developer_tea, posso ir em frente e baixar o episódio mais recente.

Gosto tanto de ouvir developer_tea que recomendo a minha amiga Amber. Agora, Amber quer se inscrever também.

Precisamos garantir que Amber também receba uma notificação sempre que um novo episódio for lançado:

Hmmm, esse código faz o que queremos.

Mas há um problema.

Cada vez que queremos adicionar um assinante, precisamos redefinir a classe.

Existe uma maneira de atualizar a lista de assinantes sem precisar redefinir a classe?

Podemos manter uma lista de assinantes!

A nova classe Podcast mantém uma lista de assinantes com a ajuda de dois novos métodos: um para adicionar assinantes e outro para remover assinantes. Quando um episódio é lançado, atualizamos cada assinante.

Infelizmente, Amber não gosta tanto do podcast quanto eu e decide cancelar a inscrição. Usamos o método remove_subscriber para removê-lo da lista de assinantes.

AyYay! Você acabou de aprender o padrão Observer!

Princípio de design por trás do padrão Observer.

O padrão Observer utiliza o princípio de design do Loose Coupling:

Busque designs fracamente acoplados entre objetos que interagem.

A classe Podcast não sabe muito sobre seus inscritos. Ele sabe apenas que cada assinante possui um método de atualização.

Esse acoplamento flexível minimiza a dependência entre o Podcast e seus assinantes. Também maximiza a flexibilidade. Contanto que tenha um método de atualização, um assinante pode ser qualquer coisa: um ser humano, um grupo de pessoas, um animal ou até um carro.

Takeaways:

  1. O Padrão do Observador define uma dependência de um para muitos entre objetos, de modo que, quando um objeto muda de estado, todos os seus dependentes são notificados e atualizados automaticamente.
  2. Princípio de design do Loose Coupling: procure por designs fracamente acoplados entre objetos que interagem.

Obrigado pela leitura. Existem outros exemplos reais do padrão Observer em que você pode pensar?

Eu publico semanalmente no sihui.io.

Inscreva-se para não perder o próximo artigo da série.

Da próxima vez vamos falar sobre…