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
Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!
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!