Interface - Types ou Models

Oi, Estudante! Tudo bem?

No Angular, tanto interfaces quanto classes (models) podem ser usadas para definir a forma dos dados. A escolha entre um e outro depende do seu caso de uso.

// Interface
export interface Promocao {
  id: number;
  destino: string;
  imagem: string;
  preco: number;
}

// Classe (Model)
export class PromocaoModel {
  id: number;
  destino: string;
  imagem: string;
  preco: number;

  constructor(id: number, destino: string, imagem: string, preco: number) {
    this.id = id;
    this.destino = destino;
    this.imagem = imagem;
    this.preco = preco;
  }
}

Interfaces:

• Definem um contrato que os objetos devem seguir.
• Não são transpiladas para JavaScript, então não têm impacto no tamanho do bundle final.
• São ideais para definir a forma de dados que vêm de uma API, por exemplo.

Classes (Models):

• Podem conter propriedades e métodos.
• São transpiladas para JavaScript.
• Permitem criar instâncias de objetos e adicionar lógica a eles.

No contexto da aula, usar uma interface é mais adequado porque você está definindo a forma dos dados que vêm da API. Se você precisasse adicionar lógica a esses dados, como formatar um preço ou validar um campo, uma classe seria mais apropriada.

Espero ter ajudado. Conte com o apoio do Fórum na sua jornada. Fico à disposição.

Abraços e bons estudos!

Boa pergunta! Vou assumir aqui que você está se referindo ao momento em que criamos o arquivo types.ts dentro da pasta core/types para colocar a interface Promocao, certo?

Então, vamos lá: não é errado criar um model em vez de types. Na real, ambas as abordagens funcionam e você vai encontrar projetos usando uma ou outra (ou até as duas). A diferença está mais na convenção e na intenção de uso do que em algo técnico que o Angular exija.

Eu criei um arquivo types.ts porque tenho o hábito de centralizar nele as interfaces que representam "formas de dados" — aquelas estruturas que descrevem como um objeto se parece, tipo o retorno de uma API. É um costume que peguei trabalhando com TypeScript em geral, não só em Angular. Acho prático porque quando preciso de uma interface simples de dados, já sei onde procurar.

Mas isso não é uma regra do Angular. É um estilo pessoal.

Quando a gente fala de "model" em Angular, geralmente estamos nos referindo a uma das duas coisas:

1. Uma pasta models/ onde ficam interfaces ou classes que representam entidades do domínio (tipo Promocao, Usuario, Passagem).
2. Classes com lógica — por exemplo, uma classe Promocao que além das propriedades tem métodos como aplicarDesconto() ou formatarPreco().

Se você está só descrevendo a forma de um dado (o que vem da API, por exemplo), uma interface resolve. Se você precisa de comportamento (métodos, validações, transformações), aí faz sentido usar uma classe dentro de models/.

O guia oficial do Angular (que é diferente do que existia na época que eu gravei esse curso) não "obriga" você a usar types/ ou models/. O que ele recomenda é:

1. Organizar por funcionalidade, não por tipo de arquivo. Ou seja, evitar pastas genéricas como components/, services/, models/ jogando tudo junto. A ideia é agrupar arquivos relacionados por feature.
2. Um conceito por arquivo. Se a interface é pequena e focada, pode até ficar junto com o componente ou serviço que a usa. Se for algo compartilhado por várias partes da aplicação (como Promocao), faz sentido isolar.
3. Nomes de arquivos descritivos. O guia sugere evitar nomes genéricos demais como helpers.ts, utils.ts ou... types.ts (ops!). A recomendação atual é que o nome do arquivo reflita o conteúdo. Então, tecnicamente, um arquivo promocao.ts ou promocao.model.ts seria mais alinhado com o guia.

Na prática, você vai encontrar projetos com:

• models/promocao.model.ts — interface ou classe, um arquivo por entidade
• types/types.ts — várias interfaces juntas (o que eu fiz)
• core/types/promocao.ts — um meio-termo, separando por arquivo mas dentro de uma pasta types

Nenhuma dessas abordagens está "errada". O importante é manter consistência no projeto. Se você começou usando models/, segue com models/. Se o time usa types/, segue com types/.

Por que eu fiz do jeito que fiz? Sinceramente? Hábito e praticidade pra aula. Num projeto real, eu provavelmente criaria um arquivo separado por interface (tipo promocao.ts) dentro de uma pasta models/ ou types/, dependendo do padrão do time. Mas pra um curso, onde o foco era mostrar o fluxo de criação do serviço e da comunicação com a API, achei mais direto criar um único arquivo e seguir em frente.

Fica aí o aprendizado: o que eu mostro em aula nem sempre é a única forma (ou a "forma perfeita") de fazer. É uma forma que funciona e que me ajuda a explicar o conceito sem complicar demais. Conforme você for pegando mais experiência, vai ajustando pro estilo que fizer mais sentido pra você e pro time.

Qualquer coisa, só mandar mais perguntas!