2
respostas

Conteúdo do ScreenmatchApplication para a classe Principal

Olá! Já fiz até o final, passando o conteúdo do run para a classe Principal, ficando com apenas 2 linhas, conforme a aula.

Porém, mesmo assim, não entendi muito bem do por que disso, se o método 'run' é considerado o ponto de partida da aplicação, porque não deixar tudo como estava?

2 respostas

Oi Sérgio! Tudo certinho?

Fizemos isso porque é uma boa prática: a classe ScreenmatchApplication tem como responsabilidade principal inicializar a aplicação, rodando tudo que está "escondido" pelo Spring Boot. Porém, além disso, estamos adicionando mais coisas para o método run.

Agora, mais no início, parecem poucas coisas, então realmente não teria taaanta necessidade de criar uma outra classe para fazer isso. Mas sabemos que ainda iremos adicionar outras funcionalidades à aplicação. Imagina que pra cada uma delas, a gente vai criar um método. Se adicionarmos esses métodos na classe ScreenmatchApplication, ela vai ter várias responsabilidades além de inicializar o Spring Boot, além de ficar bem extensa.

Então é melhor criar logo outra classe para representar as nossas funcionalidades, que é a classe Principal, e apenas usar o método exibeMenu na classe ScreenmatchApplication, deixando tudo melhor dividido.

Essa parte de deixar a classe com uma única responsabilidade tem relação com um princípio do SOLID, o Princípio da Responsabilidade Única. Se quiser dar uma olhada, tem um artigo aqui da Alura sobre esse assunto: https://www.alura.com.br/artigos/solid

Espero ter ajudado, e qualquer dúvida, estou à disposição!

Bons estudos!

Olá, bom dia Iasmin!

Muito obrigado pelo retorno, agora ficou mais claro a motivação...

Bom saber que faz parte do princípio SOLID, vou estudar também, valeu!