No caso das validações esse design pattern não seria o Composite? Já que temos uma lista de validações e estamos aplicando cada uma delas
No caso das validações esse design pattern não seria o Composite? Já que temos uma lista de validações e estamos aplicando cada uma delas
Olá Matheus!
Você está certo ao pensar que o padrão de projeto Composite poderia ser uma solução para gerenciar uma coleção de validações. No entanto, no contexto específico que você mencionou, estamos utilizando o padrão Strategy.
Vamos entender a diferença:
Composite: É usado quando você quer tratar objetos individuais e composições de objetos de maneira uniforme. Por exemplo, se você tivesse uma estrutura de árvore onde cada nó poderia ser um objeto simples ou um grupo de objetos, o Composite seria ideal.
Strategy: É usado para definir uma família de algoritmos, encapsular cada um deles e torná-los intercambiáveis. No seu caso, cada validador é uma estratégia diferente de validação que pode ser aplicada de forma independente.
No exemplo da aula, estamos utilizando o padrão Strategy porque queremos aplicar várias estratégias de validação (implementadas como classes separadas) de uma maneira flexível e extensível. Cada validador implementa a interface ValidadorAgendamentoDeConsulta, e a classe AgendadeConsultas usa uma lista dessas estratégias para aplicar todas as validações necessárias.
Dessa forma, ao adicionar ou remover validadores, você não precisa alterar a classe AgendadeConsultas, mantendo o código flexível e seguindo os princípios do SOLID.
Espero ter ajudado e bons estudos!