Solucionado (ver solução)
Solucionado
(ver solução)
4
respostas

Dicas para melhores práticas em como lidar com um evento.

Olá, galera!

Eu gostaria de pedir dicas para aplicar uma funcionalidade em um projeto pessoal. Estou desenvolvendo um sistemas de controle de tickets para a empresa onde trabalho, e já está praticamente tudo funcionando. Agora vou implementar os envios de e-mails (quando um ticket for aberto, quando um atendente receber a responsabilidade pelo ticket, quando o mesmo for fechado, etc.), e gostaria de saber como implementar seguindo os princípios de SOLID.

Observer não cabe aqui, pois são várias ações em meu Ticket (fechar, addMensagem, reabrir, setAtendenteResponsavel, etc.). Pensei em Proxy. Criar um TicketProxy e nesses métodos adicionar a funcionalidade de e-mail. Porém se futuramente outras ações precisarem ser disparadas nesses eventos, precisaria mecher no Proxy, quebrando o S de SOLID.

Aqui está o código (branch dev-v2 é a versão em desenvolvimento com as features em questão): https://github.com/CViniciusSDias/controle-de-tickets/tree/dev-v2

Que linha devo seguir para não quebrar nenhum princípio SOLID?

PS.: Aceito dicas relacionados a quaisquer outras partes do código também, galera.

Desde já, grato!

4 respostas

Opa, não cheguei a olhar o código. O observer cabe se em função de uma ação no ticket, várias ações precisem ser disparadas. Por exemplo: abrir um novo ticket gera email, insert no banco de dados etc... Este é um ótimo caso.

Em relação ao Solid em si, eu focaria bastante em aumentar a coesão e diminuir o acoplamento. O resto vem de brinde.. Analise se suas classes estão com apenas uma responsabilidade e se cada alteração no sistema impacta em muitos lugares.

Não fique vidrado em usar vários patterns, deixe simples. Em geral, simplicidade é a coisa que os sistemas mais precisam.

Criei um TicketManager com os métodos abrir, fechar, interagir, reabrir, etc.

Nele, tenho mais de uma lista de observers. Em cada um dos métodos citados, chamo a respectiva lista.

É uma boa solução?

solução!

Olhando assim, parece uma boa. Essa classe talvez esteja com muitas responsabilidades, mas o resto ta com cara de estar desacoplado. Manda bala!

Eu até pensei em criar um TicketOpener, TicketCloser, TicketMessenger, etc. Mas não vi necessidade...