Na implementação original da classe Controller, o método criaNovo recebe os dados para criação diretamente do corpo da requisição (req.body). No entanto, para a rota de matrícula (/pessoas/:estudanteId/matriculas), o estudante_id deveria ser extraído dos parâmetros da URL (req.params.estudanteId).
Implementação original na classe Controller:
async criaNovo(req, res) {
const dadosParaCriacao = req.body;
try {
const novoRegistroCriado = await this.entidadeService.criaRegistro(
dadosParaCriacao
);
return res.status(200).json(novoRegistroCriado);
} catch (erro) {
// erro
}
}
Problema
Essa implementação funciona para a maioria dos casos, mas, no contexto das matrículas, o estudante_id precisa ser extraído do req.params.estudanteId e incluído nos dados de criação do registro. O método da superclasse Controller não prevê esse cenário.
Solução: Aplicação de Polimorfismo
Para resolver essa limitação, sobrescrevemos o método criaNovo na MatriculaController, garantindo que o estudante_id seja corretamente atribuído.
Implementação na MatriculaController:
async criaNovo(req, res) {
const estudanteId = req.params.estudanteId;
const dadosParaCriacao = req.body;
try {
const estudanteEncontrado = await matriculaServices.pegaUmRegistroPorId(
estudanteId
);
if (!estudanteEncontrado) {
return res.status(404).json({ message: "Estudante informado inválido" });
}
const novoRegistroCriado = await this.entidadeService.criaRegistro({
...dadosParaCriacao,
estudante_id: estudanteId,
});
return res.status(200).json(novoRegistroCriado);
} catch (erro) {
// erro
}
}
Vantagens
- Mantém a estrutura base da superclasse Controller, evitando duplicação de código desnecessária.
- Garante que o estudante_id seja extraído corretamente dos parâmetros da rota.
- Mantém a coesão e reaproveitamento de código utilizando herança e polimorfismo.
Essa abordagem melhora a flexibilidade do código, permitindo a reutilização do método criaNovo para diferentes entidades sem comprometer a necessidade específica da rota de matrícula.
O que acham dessa solução?