O Publisher vs Subscriber ou Pub-Sub é um padrão de projeto comportamental que permite que você defina um mecanismo de assinatura para notificar múltiplos objetos sobre quaisquer eventos que aconteçam com o objeto que eles estão observando.
Na imagem acima temos uma atividade sendo executada enquanto outras atividades observam sua apresentação e aguardam a vez delas de executarem também. Temos nesse cenário uma regra de negócio resolvivel pelo padrão Pub-Sub. Na imagem abaixo é demonstrado o problema inicial na forma de um diagrama de atividades adaptado para o padrão Pub-Sub, da forma que o sistema realmente deve funcionar. Tem-se a Atividade 1 sendo executada e uma ramificação com diversas atividades esperando a vez delas de executar ao mesmo tempo. Compare esse diagrama com os diagramas anteriores e observe quais comportamentos diferentes existem neles.
Imagem criada pelo autor no editor UML Dia
No mundo real é muito comum criarmos um problema em que tenhamos de ficar checando a cada 1 ou mais segundos se determinada atividade encerrou para podermos executar as atividades que dependem dela. Com o Pub-Sub pretende-se chegar a solução onde assim que a atividade termina de executar todas as atividades que dependem dela são notificadas e começam a executar. Por isso, a ramificação. No cenário anterior tinha-se as Atividade B aguardando a Atividade A, e Atividade C aguardando a Atividade B. Não é o que se deseja.
Nessa figura temos dois cenários: um em que um determinado cliente fica indo na loja diversas vezes para conferir se um determinado produto já está no estoque; e outro em que a loja dispara uma notificação para todos os clientes informando a eles que o produto já está no estoque.
Mas, para compreensão correta desse cenário temos de analisar esse problema do ponto de vista da análise de sistemas. Na primeira figura temos um cliente aguardando a resposta da atividade "o produto está no estoque". E podemos perceber que esse cliente faz a verificação dessa atividade diversas vezes. A cada vez que esse cliente faz essa requisição ele é ocupa recursos do sistema (loja) impedindo que o logista consiga atender outros clientes. Já no cenário 2 da mesma figura nós temos uma situação em que a atividade o produto está no estoque assume a responsabilidade de notificar automaticamente todos os clientes que estão esperando o fim da atividade. Vejamos como ficaria a modelagem das classes:
Esse diagrama de classes nós temos um caso de uso em que a classe a Anunciante (Publisher) faz a excreção dos objetos daclasse Inscritos (Subscriber). Poderíamos também chama-los de Sujeito (Subject) e Ouvinte (Listener), respectivamente. O Anunciante é a Atividade 1, que será executada e os Inscritos são as demais atividades que dependem dela. Então a gente inscreve várias atividades em outra atividade para que elas fiquem aguardando a notificação de que é a primeira atividade encerrou, para que elas possam executar utilizando os dados da primeira atividade.
N código abaixo é definir uma interface para o inscrito ou assinante. Nessa interface tem o método update que será o método acionado pelo método notify do publisher (ou anunciante).
Na classe seguinte demos a implementação de uma classe escrito a que planeta a interface update cujo argumento recebe o anunciante. Nesse método estará a ação para qual o escrito existe. Esta ação poderá ser um envio de e-mail, escrita no log, ou outra especificada na análise do sistema.
Em seguida temas a interface do anunciante com os seus métodos.
Comentários