Pular para conteúdo

Backend com Java (Spring Boot) ☕

Domine a construção de APIs robustas e arquitetura enterprise com Java e Spring Boot — injeção de dependências, persistência com JPA, segurança com Spring Security e deploy em produção.

🚀 O que vamos construir?

Ao longo de 16 aulas, vamos evoluir dos fundamentos do ecossistema Spring até a criação de uma API REST completa, segura e pronta para deploy.

  • Módulo 1: Fundamentos do Spring --- Ecossistema Java, Spring Boot, Injeção de Dependências e estrutura em camadas. Ver Aulas

  • Módulo 2: APIs REST e Persistência --- Endpoints REST, JPA/Hibernate, Spring Data e relacionamentos entre entidades. Ver Aulas

  • Módulo 3: Qualidade e Documentação --- Validação, DTOs, testes com JUnit/Mockito e documentação com Swagger. Ver Aulas

  • Módulo 4: Segurança e Produção --- Spring Security, JWT, Docker e deploy de aplicações Spring Boot. Ver Aulas

🛠️ Requisitos

  • JDK 17+
  • IntelliJ IDEA ou VS Code com extensões Java
  • Vontade de aprender!

Começar Agora 🚀

Plano de Ensino 🧭

Curso: Desenvolvimento Backend com Java
Público-alvo: Estudantes de ADS, Ciência da Computação e Desenvolvedores de Software
Carga Horária: 20 Aulas (80 Horas Teórico-Práticas)

🎯 1. Objetivos do Curso

  • Compreender os fundamentos conceituais e arquiteturais de Desenvolvimento Backend com Java.
  • Aplicar padrões de projeto, sintaxe moderna e boas práticas da indústria.
  • Desenvolver soluções completas através de exercícios práticos e desafios de projeto.

📚 2. Cronograma de Aulas (Matriz de 20 Semanas)

Aula Tema Central Atividades e Entregas
01 Introdução ao Ecossistema Java Backend Teoria, Prática Guiada, Quiz e Exercícios
02 Spring Boot: Primeiros Passos Teoria, Prática Guiada, Quiz e Exercícios
03 Injeção de Dependências e IoC Teoria, Prática Guiada, Quiz e Exercícios
04 Estrutura de Projeto e Camadas ️ Teoria, Prática Guiada, Quiz e Exercícios
05 Criando APIs REST com Spring Web Teoria, Prática Guiada, Quiz e Exercícios
06 Modelagem de Dados com JPA/Hibernate ️ Teoria, Prática Guiada, Quiz e Exercícios
07 Spring Data JPA e Repositories Teoria, Prática Guiada, Quiz e Exercícios
08 Relacionamentos entre Entidades Teoria, Prática Guiada, Quiz e Exercícios
09 Validação de Dados e Exceções Teoria, Prática Guiada, Quiz e Exercícios
10 DTOs e Mapeamento de Objetos Teoria, Prática Guiada, Quiz e Exercícios
11 Testes com JUnit e Mockito Teoria, Prática Guiada, Quiz e Exercícios
12 Documentação de API com Swagger Teoria, Prática Guiada, Quiz e Exercícios
13 Autenticação com Spring Security Teoria, Prática Guiada, Quiz e Exercícios
14 JWT e Proteção de Endpoints Teoria, Prática Guiada, Quiz e Exercícios
15 Docker e Deploy Teoria, Prática Guiada, Quiz e Exercícios
16 Projeto Final: API Completa Teoria, Prática Guiada, Quiz e Exercícios
17 Spring Security 6+ com Autenticação Stateless JWT Teoria, Prática Guiada, Quiz e Exercícios
18 Processamento Assíncrono com Spring Events Teoria, Prática Guiada, Quiz e Exercícios
19 Consultas Avançadas com Spring Data JPA e QueryDSL Teoria, Prática Guiada, Quiz e Exercícios
20 Projeto Capstone: Microsserviço Java Spring Boot Completo Teoria, Prática Guiada, Quiz e Exercícios

🧠 3. Metodologia de Ensino

  • Teoria Fundamentada: Aulas com conceitos detalhados, diagramas arquiteturais e sintaxe de referência.
  • Ciclo Teoria ⇄ Prática: Cada aula conta com Quiz Interativo (10 questões) para validação imediata, Lista de Exercícios Sanfonados (com Gabarito Explicado) e Desafio de Projeto Prático.
  • Laboratório Contínuo: Ambientes configurados passo a passo na seção de Setups da plataforma.

💼 4. Competências e Perfil Desenvolvido

  • Dominar as ferramentas e fluxos de desenvolvimento de Desenvolvimento Backend com Java.
  • Resolver problemas técnicos de alta complexidade com código limpo e performático.
  • Construir portfólio prático com 20 projetos aplicados.

📊 5. Critérios de Avaliação

  • 20 Listas de Exercícios: Resolução individual dividida em Básico, Intermediário e Desafio.
  • 20 Quizzes Interativos: Validação formativa com feedback imediato via JavaScript.
  • 20 Desafios de Projetos: Aplicações práticas consolidando o aprendizado de cada unidade.

Aulas

Aula 01 - Introdução ao Ecossistema Java Backend ☕

Bem-vindo à primeira aula do curso de Backend com Java! Nesta aula, vamos entender o que significa desenvolver o "lado servidor" de uma aplicação e conhecer as ferramentas que vamos usar durante todo o curso.

😊 O que é Desenvolvimento Backend?

O backend é a parte de um sistema que roda em um servidor, responsável por processar regras de negócio, acessar bancos de dados e expor APIs para que outros sistemas (um app mobile, um site) consumam esses dados.

Exemplos de Aplicações Backend

  • APIs de E-commerce: Processam pedidos, pagamentos e estoque.
  • Sistemas Bancários: Processam transferências e consultas de saldo.
  • Backends de Redes Sociais: Armazenam posts, curtidas e conexões entre usuários.

📊 Onde o Java Entra Nesse Mundo

graph TD
    A[Cliente - App/Web] -- HTTP/JSON --> B[API Backend em Java/Spring]
    B --> C[Banco de Dados]
    B --> D[Outros Serviços]

Java é, há décadas, uma das linguagens mais usadas em backends corporativos — por sua robustez, tipagem forte e o ecossistema maduro do Spring Framework, que veremos a partir da Aula 02.

🧠 Conceitos Importantes

Note

JVM (Java Virtual Machine): A máquina virtual que executa o bytecode Java, permitindo que o mesmo código rode em qualquer sistema operacional.

Tip

IDE: Utilizaremos o IntelliJ IDEA (Community ou Ultimate) para facilitar o desenvolvimento com Spring Boot ao longo do curso.

💻 Primeiro Programa

$ javac PrimeiroPrograma.java
$ java PrimeiroPrograma
Olá, Backend Java! 🚀

📝 Exercícios Progressivos

  1. Básico: Explique com suas palavras o que é uma API.
  2. Básico: Cite 2 exemplos de sistemas backend que você usa no dia a dia.
  3. Intermediário: Qual a diferença entre o servidor (backend) e o que roda no seu navegador (frontend)?
  4. Intermediário: Por que a JVM é considerada uma das grandes vantagens do Java?
  5. Desafio: Pesquise e liste 3 grandes empresas que usam Java no backend de seus sistemas.

🚀 Mini-projeto: Instale o JDK 17+ e o IntelliJ IDEA em sua máquina, e execute o clássico "Hello World" no terminal.

Aula 02 - Spring Boot: Primeiros Passos 🌱

Hoje vamos conhecer o framework que vamos usar durante todo o curso: o Spring Boot, a forma mais rápida e popular de criar aplicações Java para produção.

😊 O que é o Spring Boot?

O Spring é um framework enorme, com muitas configurações manuais. O Spring Boot simplifica isso drasticamente, fornecendo configurações padrão sensatas ("convention over configuration") para que você comece a codificar rapidamente, sem se perder em XML.

Principais Vantagens

  • Servidor Embutido: Não precisa instalar um servidor separado — o Spring Boot já roda com Tomcat embutido.
  • Starters: Dependências pré-configuradas (ex: spring-boot-starter-web já traz tudo para criar APIs REST).
  • Auto Configuration: O Spring detecta o que você precisa e configura automaticamente.

📊 Estrutura de um Projeto Spring Boot

graph TD
    A[Projeto Spring Boot] --> B[Controller - Recebe requisições]
    A --> C[Service - Regras de negócio]
    A --> D[Repository - Acesso a dados]
    A --> E[Model/Entity - Representação dos dados]

🧠 Criando um Projeto com o Spring Initializr

Important

O Spring Initializr é a ferramenta oficial para gerar a estrutura inicial de um projeto Spring Boot, escolhendo as dependências necessárias.

Ao gerar o projeto, escolha: * Project: Maven * Language: Java * Dependencies: Spring Web

💻 Rodando a Aplicação

$ ./mvnw spring-boot:run
$
$   .   ____          _            __ _ _
$  /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
$ ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
$  \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
$   '  |____| .__|_| |_|_| |_\__, | / / / /
$  =========|_|==============|___/=/_/_/_/
$ Started BackendApplication in 2.145 seconds

📝 Exercícios Progressivos

  1. Básico: O que significa "Convention over Configuration"?
  2. Básico: Para que serve um "Starter" no Spring Boot?
  3. Intermediário: Qual a vantagem de o Spring Boot já vir com um servidor embutido?
  4. Intermediário: O que é o Spring Initializr e para que serve?
  5. Desafio: Acesse o Spring Initializr e liste 5 dependências (starters) diferentes que você encontrou disponíveis.

🚀 Mini-projeto: Gere um novo projeto Spring Boot no Spring Initializr com a dependência Spring Web, importe no IntelliJ e rode a aplicação pela primeira vez.

Aula 03 - Injeção de Dependências e IoC 💉

Nesta aula, vamos entender o conceito mais fundamental do Spring: como ele gerencia os objetos da sua aplicação para você, através da Inversão de Controle.

😊 Inversão de Controle (IoC)

Tradicionalmente, seu código cria seus próprios objetos com new. Com Inversão de Controle (IoC), é o framework que cria e entrega os objetos prontos para você — você só declara que precisa deles.

O Container Spring

O Spring gerencia um "container" de objetos chamados Beans. Um Bean é qualquer objeto cuja criação e ciclo de vida são controlados pelo Spring.

📊 Fluxo de Injeção de Dependências

graph LR
    Container[Container Spring - IoC] -- Injeta --> Controller[Controller]
    Container -- Injeta --> Service[Service]
    Controller -- Depende de --> Service

🧠 A Anotação @Autowired

Important

@Autowired diz ao Spring: "injete aqui uma instância pronta deste tipo, eu não vou criá-la com new".

@Service
public class ProdutoService {
    public String listar() {
        return "Lista de produtos";
    }
}

@RestController
public class ProdutoController {

    @Autowired
    private ProdutoService produtoService; // Injetado pelo Spring

    // O Spring já entrega o ProdutoService pronto para uso aqui
}

🧠 Por que Isso Importa?

Tip

Injeção de dependências facilita muito os testes (Aula 11): em vez de depender de uma implementação real, você pode "injetar" uma versão falsa (mock) do Service durante os testes.

📝 Exercícios Progressivos

  1. Básico: O que significa a sigla IoC?
  2. Básico: O que é um "Bean" no contexto do Spring?
  3. Intermediário: Qual a diferença entre criar um objeto com new e deixar o Spring injetá-lo?
  4. Intermediário: Por que a Injeção de Dependências facilita a escrita de testes automatizados?
  5. Desafio: Pesquise a diferença entre injeção via @Autowired em atributo e injeção via construtor — qual é considerada a melhor prática hoje?

🚀 Mini-projeto: Crie uma classe SaudacaoService com um método saudar(). Injete-a em um Controller usando @Autowired e chame o método a partir dele.

Aula 04 - Estrutura de Projeto e Camadas 🏗️

Hoje vamos organizar nosso projeto Spring Boot em camadas profissionais — a base de qualquer API bem arquitetada que construiremos no restante do curso.

😊 A Arquitetura em Camadas

Um projeto Spring Boot bem estruturado separa responsabilidades em camadas claras:

  • Controller: Recebe requisições HTTP e devolve respostas.
  • Service: Contém as regras de negócio.
  • Repository: Acessa o banco de dados.
  • Model/Entity: Representa os dados do domínio.

📊 Fluxo entre Camadas

sequenceDiagram
    participant Cliente
    participant Controller
    participant Service
    participant Repository
    participant DB

    Cliente->>Controller: GET /produtos
    Controller->>Service: listarProdutos()
    Service->>Repository: findAll()
    Repository->>DB: SELECT * FROM produtos
    DB-->>Repository: Dados
    Repository-->>Service: Lista de Produtos
    Service-->>Controller: Lista de Produtos
    Controller-->>Cliente: JSON

🧠 Regra de Ouro: Cada Camada, Sua Responsabilidade

Important

O Controller não deve conter lógica de negócio. O Service não deve saber nada sobre HTTP. O Repository não deve conter regras de negócio, só acesso a dados.

💻 Estrutura de Pastas Sugerida

$ tree src/main/java/com/exemplo/backend
.
├── controller   # Classes anotadas com @RestController
├── service      # Classes anotadas com @Service
├── repository   # Interfaces que estendem JpaRepository
├── model        # Classes anotadas com @Entity
└── BackendApplication.java

🧠 As Principais Anotações do Spring

Anotação Camada Função
@RestController Controller Marca a classe como responsável por receber requisições HTTP
@Service Service Marca a classe como um Bean de lógica de negócio
@Repository Repository Marca a interface/classe como responsável por acesso a dados
@Entity Model Marca a classe como uma tabela do banco de dados

📝 Exercícios Progressivos

  1. Básico: Quais as 4 camadas principais de um projeto Spring Boot organizado?
  2. Básico: Qual anotação usamos para marcar uma classe Service?
  3. Intermediário: Por que o Controller não deve acessar o Repository diretamente, pulando o Service?
  4. Intermediário: O que aconteceria se colocássemos uma query SQL dentro do Controller?
  5. Desafio: Desenhe (ou descreva) o fluxo de camadas para uma requisição POST /pedidos que cria um novo pedido.

🚀 Mini-projeto: Crie a estrutura de pacotes controller, service, repository e model no seu projeto Spring Boot, mesmo que ainda estejam vazios.

Aula 05 - Criando APIs REST com Spring Web 📡

Chegou a hora de criar seus primeiros endpoints de verdade! Nesta aula, vamos usar o Spring Web para expor uma API REST completa.

😊 Anatomia de um Controller REST

Um @RestController mapeia URLs para métodos Java, usando anotações que representam os verbos HTTP.

@RestController
@RequestMapping("/produtos")
public class ProdutoController {

    @GetMapping
    public List<Produto> listar() {
        return List.of(new Produto("Mouse", 50.0));
    }

    @PostMapping
    public Produto criar(@RequestBody Produto produto) {
        return produto; // Em breve, salvaremos no banco (Aula 07)
    }
}

📊 Verbos HTTP e Anotações Correspondentes

Verbo Anotação Spring Ação
GET @GetMapping Buscar dados
POST @PostMapping Criar um recurso
PUT @PutMapping Atualizar um recurso inteiro
DELETE @DeleteMapping Remover um recurso

🧠 Capturando Dados da Requisição

Important

@PathVariable captura dados da URL. @RequestBody captura o corpo JSON da requisição. @RequestParam captura parâmetros de query string.

@GetMapping("/{id}")
public Produto buscarPorId(@PathVariable Long id) {
    return new Produto("Produto " + id, 100.0);
}

📊 Ciclo de uma Requisição REST

graph LR
    Cliente -- "GET /produtos/5" --> Controller
    Controller -- "@PathVariable id=5" --> Logic[Lógica do Método]
    Logic -- "Retorna Objeto" --> Spring[Spring converte para JSON]
    Spring -- "JSON" --> Cliente

💻 Testando com cURL

$ curl http://localhost:8080/produtos
[{"nome":"Mouse","preco":50.0}]

📝 Exercícios Progressivos

  1. Básico: Qual anotação usamos para criar um endpoint que responde a requisições GET?
  2. Básico: Para que serve o @RequestBody?
  3. Intermediário: Qual a diferença entre @PathVariable e @RequestParam?
  4. Intermediário: Como você criaria um endpoint DELETE /produtos/{id}?
  5. Desafio: Crie um Controller ClienteController com endpoints GET (listar todos), GET por id, POST e DELETE.

🚀 Mini-projeto: Crie o ProdutoController com os 4 endpoints básicos (GET, GET por id, POST, DELETE), retornando dados fixos por enquanto. Teste todos com o Postman ou cURL.

Aula 06 - Modelagem de Dados com JPA/Hibernate 🗄️

Nesta aula, vamos dar vida aos dados: transformar classes Java em tabelas reais de banco de dados, usando o JPA e o Hibernate.

😊 O que é JPA e Hibernate?

  • JPA (Java Persistence API): uma especificação — um conjunto de regras de como o Java deve lidar com persistência de dados.
  • Hibernate: a implementação mais usada dessa especificação. É ele quem realmente traduz seus objetos Java em comandos SQL.

📊 De Classe Java para Tabela

classDiagram
    class Produto {
        +Long id
        +String nome
        +double preco
    }

Vira, no banco de dados, uma tabela produto com colunas id, nome e preco.

🧠 Anotando uma Entidade

Important

@Entity marca a classe como uma tabela. @Id marca o atributo como chave primária. @GeneratedValue diz ao banco para gerar o valor automaticamente.

@Entity
public class Produto {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String nome;
    private double preco;

    // getters e setters
}

🧠 Configurando o Banco de Dados

No arquivo application.properties, configuramos a conexão:

spring.datasource.url=jdbc:postgresql://localhost:5432/meubanco
spring.datasource.username=postgres
spring.datasource.password=senha
spring.jpa.hibernate.ddl-auto=update

Tip

ddl-auto=update faz o Hibernate criar/atualizar as tabelas automaticamente com base nas suas classes @Entity — ótimo para desenvolvimento, mas raramente usado assim em produção.

📝 Exercícios Progressivos

  1. Básico: Qual a diferença entre JPA e Hibernate?
  2. Básico: Para que serve a anotação @Id?
  3. Intermediário: O que faz a propriedade ddl-auto=update?
  4. Intermediário: Por que essa configuração não é recomendada em produção?
  5. Desafio: Modele uma entidade Cliente com os atributos id, nome, email e dataCadastro.

🚀 Mini-projeto: Crie a entidade Produto anotada com JPA e configure a conexão com um banco PostgreSQL (ou H2 em memória, para testar rapidamente).

Aula 07 - Spring Data JPA e Repositories 📥

Hoje vamos aprender a mágica do Spring Data JPA: como fazer consultas ao banco de dados escrevendo muito pouco código.

😊 O Padrão Repository

Assim como vimos na Aula 04, o Repository isola o acesso a dados. Com o Spring Data JPA, você nem precisa implementar os métodos básicos — só declarar uma interface.

public interface ProdutoRepository extends JpaRepository<Produto, Long> {
    // Já vem com: findAll(), findById(), save(), deleteById()...
}

📊 O que o JpaRepository já entrega pronto

graph TD
    Interface[ProdutoRepository] -- extends --> Jpa[JpaRepository]
    Jpa --> M1[findAll]
    Jpa --> M2[findById]
    Jpa --> M3[save]
    Jpa --> M4[deleteById]

🧠 Conectando o Repository ao Service

Important

Quem chama o Repository é o Service, nunca o Controller diretamente (regra da Aula 04).

@Service
public class ProdutoService {

    @Autowired
    private ProdutoRepository repository;

    public List<Produto> listar() {
        return repository.findAll();
    }

    public Produto salvar(Produto produto) {
        return repository.save(produto);
    }
}

🧠 Query Methods: Consultas por Nome de Método

Uma das funcionalidades mais poderosas do Spring Data: ele cria a consulta SQL automaticamente a partir do nome do método!

public interface ProdutoRepository extends JpaRepository<Produto, Long> {
    List<Produto> findByNomeContaining(String nome);
    List<Produto> findByPrecoGreaterThan(double preco);
}

Tip

O Spring interpreta findByNomeContaining e gera automaticamente um SELECT ... WHERE nome LIKE %?% — sem você escrever uma linha de SQL.

📝 Exercícios Progressivos

  1. Básico: O que uma interface precisa fazer para virar um Repository funcional do Spring Data JPA?
  2. Básico: Cite 2 métodos que já vêm prontos ao estender JpaRepository.
  3. Intermediário: O que o método findByPrecoGreaterThan(double preco) faz, mesmo sem você implementá-lo?
  4. Intermediário: Por que o Controller não deve chamar o Repository diretamente?
  5. Desafio: Escreva a assinatura de um Query Method que busque produtos por uma categoria exata.

🚀 Mini-projeto: Crie o ProdutoRepository estendendo JpaRepository, injete-o no ProdutoService, e conecte o Service ao Controller da Aula 05 para que os dados venham de verdade do banco.

Aula 08 - Relacionamentos entre Entidades 🔗

Sistemas reais têm dados conectados: um Pedido pertence a um Cliente, um Cliente tem vários Pedidos. Nesta aula, vamos modelar esses relacionamentos com JPA.

😊 Os Tipos de Relacionamento

Anotação Relação Exemplo
@OneToMany / @ManyToOne Um para Muitos Um Cliente tem muitos Pedidos
@ManyToMany Muitos para Muitos Um Aluno está em muitos Cursos, e vice-versa
@OneToOne Um para Um Um Usuário tem um Perfil

📊 Modelando Cliente e Pedido

erDiagram
    CLIENTE ||--o{ PEDIDO : possui
    CLIENTE {
        long id
        string nome
    }
    PEDIDO {
        long id
        double valor
        long cliente_id
    }

🧠 Implementando @ManyToOne / @OneToMany

@Entity
public class Pedido {
    @Id @GeneratedValue
    private Long id;
    private double valor;

    @ManyToOne
    @JoinColumn(name = "cliente_id")
    private Cliente cliente;
}

@Entity
public class Cliente {
    @Id @GeneratedValue
    private Long id;
    private String nome;

    @OneToMany(mappedBy = "cliente")
    private List<Pedido> pedidos;
}

Important

O lado @ManyToOne é o "dono" do relacionamento — é ele quem tem a coluna de chave estrangeira (cliente_id) no banco de dados.

🧠 Cuidado com Loops Infinitos (JSON)

Caution

Se Cliente retorna Pedidos, e cada Pedido retorna Cliente de novo, você cria um loop infinito ao converter para JSON! Veremos como resolver isso com DTOs na Aula 10.

📝 Exercícios Progressivos

  1. Básico: Qual anotação usamos no lado "muitos" de um relacionamento Um-para-Muitos?
  2. Básico: Dê um exemplo do mundo real de um relacionamento Muitos-para-Muitos.
  3. Intermediário: Qual entidade fica com a coluna de chave estrangeira em um relacionamento @OneToMany/@ManyToOne?
  4. Intermediário: Por que relacionamentos bidirecionais podem causar problemas ao serializar para JSON?
  5. Desafio: Modele o relacionamento entre Curso e Aluno (muitos para muitos) usando @ManyToMany.

🚀 Mini-projeto: Crie a entidade Cliente e relacione-a com Pedido usando @OneToMany/@ManyToOne. Salve um cliente com 2 pedidos e verifique no banco de dados.

Aula 09 - Validação de Dados e Exceções ✅

Nesta aula, vamos garantir que nossa API nunca aceite dados inválidos e que os erros sejam tratados de forma profissional, com mensagens claras.

😊 Por que Validar? 🛡️

O lema de todo desenvolvedor backend deve ser: "Nunca confie nos dados vindos do cliente". O frontend pode ter falhas, ou alguém pode enviar dados maliciosos diretamente para a API.

🧠 Bean Validation

O Spring integra a especificação Bean Validation, permitindo validar campos direto na entidade com anotações.

@Entity
public class Produto {
    @Id @GeneratedValue
    private Long id;

    @NotBlank(message = "O nome é obrigatório")
    private String nome;

    @Positive(message = "O preço deve ser maior que zero")
    private double preco;
}

No Controller, ativamos a validação com @Valid:

@PostMapping
public Produto criar(@Valid @RequestBody Produto produto) {
    return service.salvar(produto);
}

📊 Fluxo de Validação

graph TD
    A[Requisição chega] --> B{Dados válidos?}
    B -- Sim --> C[Processa normalmente]
    B -- Não --> D[Retorna 400 Bad Request com detalhes]

🧠 Tratamento Global de Exceções

Important

Em vez de espalhar try/catch por todo o código, usamos um @RestControllerAdvice — uma classe central que captura exceções de toda a aplicação.

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<String> tratarValidacao(MethodArgumentNotValidException ex) {
        return ResponseEntity.badRequest().body("Dados inválidos: " + ex.getMessage());
    }
}

📝 Exercícios Progressivos

  1. Básico: O que faz a anotação @NotBlank?
  2. Básico: Para que serve @Valid no parâmetro de um método do Controller?
  3. Intermediário: Qual a vantagem de usar @RestControllerAdvice em vez de try/catch em cada método?
  4. Intermediário: Qual Status Code HTTP costuma ser retornado quando a validação falha?
  5. Desafio: Adicione as anotações @Email e @Size(min=8) a uma entidade Usuario (campos email e senha).

🚀 Mini-projeto: Adicione validações (@NotBlank, @Positive) à entidade Produto e crie um GlobalExceptionHandler que retorne uma mensagem amigável quando a validação falhar.

Aula 10 - DTOs e Mapeamento de Objetos 📦

Nesta aula, vamos resolver o problema de loop infinito da Aula 08 e aprender a controlar exatamente quais dados sua API expõe, usando DTOs.

😊 O que é um DTO?

DTO (Data Transfer Object) é um objeto simples, usado apenas para transportar dados entre camadas — especialmente entre a API e o cliente. Ele não é a Entidade do banco de dados.

Por que não expor a Entity diretamente?

  • Segurança: Você pode ter campos sensíveis (como senha) na Entity que nunca devem ir para o cliente.
  • Loops infinitos: Como vimos na Aula 08, relacionamentos bidirecionais quebram a serialização JSON.
  • Flexibilidade: O formato exposto pela API pode ser diferente da estrutura interna do banco.

📊 Entity vs DTO

graph LR
    Cliente -- "Recebe" --> DTO[ProdutoDTO]
    DTO -- "Mapeado de/para" --> Entity[Produto - Entity JPA]
    Entity -- "Persistido em" --> DB[(Banco de Dados)]

🧠 Criando um DTO

public record ProdutoDTO(Long id, String nome, double preco) {}

Tip

Usar record (recurso do Java moderno) é uma forma concisa de criar DTOs imutáveis — sem precisar escrever getters, construtores e equals/hashCode manualmente.

🧠 Convertendo entre Entity e DTO

public ProdutoDTO paraDTO(Produto produto) {
    return new ProdutoDTO(produto.getId(), produto.getNome(), produto.getPreco());
}

public Produto paraEntity(ProdutoDTO dto) {
    Produto p = new Produto();
    p.setNome(dto.nome());
    p.setPreco(dto.preco());
    return p;
}

Note

Em projetos maiores, bibliotecas como o MapStruct automatizam essa conversão — mas entender o mapeamento manual primeiro é essencial.

📝 Exercícios Progressivos

  1. Básico: O que significa a sigla DTO?
  2. Básico: Por que não devemos retornar a Entity diretamente na resposta da API?
  3. Intermediário: Como um record em Java simplifica a criação de um DTO?
  4. Intermediário: Em qual camada (Controller, Service ou Repository) a conversão Entity ↔ DTO deveria acontecer?
  5. Desafio: Crie um ClienteDTO que exponha apenas id e nome, escondendo o campo senha da entidade Cliente.

🚀 Mini-projeto: Crie o ProdutoDTO e altere o ProdutoController da Aula 05 para retornar DTOs em vez das Entities diretamente.

Aula 11 - Testes com JUnit e Mockito 🧪

Como ter certeza de que sua API continua funcionando depois de cada mudança? Nesta aula, vamos aprender a escrever testes automatizados profissionais.

😊 Por que Testar?

Testes automatizados garantem que seu código funciona como esperado — e, mais importante, continuam funcionando conforme o sistema cresce e é modificado por várias pessoas.

Tipos de Teste

  • Teste Unitário: Testa uma única unidade de código isoladamente (ex: um método do Service).
  • Teste de Integração: Testa a interação entre várias camadas (ex: Controller + Service + banco real).

📊 Pirâmide de Testes

graph TD
    A[Testes E2E - poucos, lentos] --> B[Testes de Integração - médios]
    B --> C[Testes Unitários - muitos, rápidos]

🧠 JUnit: o Framework de Testes do Java

class ProdutoServiceTest {

    @Test
    void deveCalcularDescontoCorretamente() {
        Produto p = new Produto("Mouse", 100.0);
        double resultado = ProdutoService.aplicarDesconto(p, 10);
        assertEquals(90.0, resultado);
    }
}

🧠 Mockito: Simulando Dependências

Important

Lembra da Injeção de Dependências (Aula 03)? Ela é o que torna o Mockito possível: em vez de usar o Repository real (que acessaria o banco de verdade), injetamos um mock — uma versão falsa e controlada.

@ExtendWith(MockitoExtension.class)
class ProdutoServiceTest {

    @Mock
    private ProdutoRepository repository;

    @InjectMocks
    private ProdutoService service;

    @Test
    void deveListarProdutos() {
        when(repository.findAll()).thenReturn(List.of(new Produto("Mouse", 50.0)));

        List<Produto> resultado = service.listar();

        assertEquals(1, resultado.size());
    }
}

📊 Fluxo de um Teste com Mock

graph LR
    Test[Teste] -- Configura --> Mock[Repository Mockado]
    Test -- Chama --> Service
    Service -- Usa --> Mock
    Mock -- Retorna dado falso --> Service
    Service -- Retorna --> Test
    Test -- Verifica --> Assert[Assertivas]

📝 Exercícios Progressivos

  1. Básico: Qual a diferença entre um teste unitário e um teste de integração?
  2. Básico: O que faz a anotação @Test do JUnit?
  3. Intermediário: Por que usamos um Mock do Repository em vez do Repository real em um teste unitário do Service?
  4. Intermediário: O que a Injeção de Dependências (Aula 03) tem a ver com a facilidade de mockar dependências?
  5. Desafio: Escreva um teste que verifica se o método salvar() do Service lança uma exceção quando o produto tem preço negativo.

🚀 Mini-projeto: Escreva 3 testes unitários para o ProdutoService: listar produtos, salvar um produto válido e tentar salvar um produto com preço negativo.

Aula 12 - Documentação de API com Swagger 📝

Uma API sem documentação é um labirinto no escuro. Nesta aula, vamos documentar automaticamente nossa API usando Swagger/OpenAPI.

😊 Por que Documentar APIs?

  • Developer Experience (DX): facilita o consumo da API por outros times e sistemas.
  • Single Source of Truth: o contrato documentado é a verdade absoluta do sistema.
  • Testabilidade: o Swagger UI permite testar endpoints direto do navegador, sem precisar do Postman.

🧠 Integrando o Swagger ao Spring Boot

Adicionando a dependência springdoc-openapi ao projeto, o Spring já gera automaticamente a documentação a partir dos seus Controllers, sem esforço manual.

<dependency>
    <groupId>org.springdoc</groupId>
    <artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
    <version>2.5.0</version>
</dependency>

📊 Como Funciona

graph LR
    A[Controllers com anotações Spring] --> B[springdoc-openapi]
    B --> C[Especificação OpenAPI - JSON]
    C --> D[Swagger UI - Página interativa]

🧠 Enriquecendo a Documentação

Important

Anotações como @Operation e @Schema permitem adicionar descrições legíveis por humanos, além do que o Spring já infere automaticamente.

@Operation(summary = "Lista todos os produtos cadastrados")
@GetMapping
public List<ProdutoDTO> listar() {
    return service.listarTodos();
}

💻 Acessando a Documentação

$ ./mvnw spring-boot:run
$ # Acesse no navegador:
$ # http://localhost:8080/swagger-ui.html

Tip

O Swagger UI permite testar endpoints diretamente na página — inclusive endpoints protegidos (Aula 13), informando o token JWT.

📝 Exercícios Progressivos

  1. Básico: O que é o Swagger UI e para que ele serve?
  2. Básico: Qual a vantagem de gerar documentação automaticamente em vez de escrevê-la manualmente?
  3. Intermediário: O que faz a anotação @Operation?
  4. Intermediário: Como o Swagger UI pode ser usado em vez do Postman durante o desenvolvimento?
  5. Desafio: Adicione descrições @Operation a todos os endpoints do ProdutoController.

🚀 Mini-projeto: Adicione o springdoc-openapi ao projeto e acesse a documentação interativa gerada automaticamente para o ProdutoController.

Aula 13 - Autenticação com Spring Security 🔐

Nesta aula, vamos proteger nossa API contra acesso não autorizado usando o Spring Security, o módulo de segurança oficial do ecossistema Spring.

😊 O que é o Spring Security?

Spring Security é o framework responsável por autenticação (quem é você?) e autorização (o que você pode fazer?) em aplicações Spring Boot.

📊 Cadeia de Filtros de Segurança

graph LR
    Req[Requisição] --> F1[Filtro de Autenticação]
    F1 --> F2[Filtro de Autorização]
    F2 --> Controller[Controller]
    F1 -- Falha --> E1[401 Unauthorized]
    F2 -- Falha --> E2[403 Forbidden]

🧠 Configurando a Segurança Básica

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/produtos/publico").permitAll()
                .anyRequest().authenticated()
            );
        return http.build();
    }
}

🧠 Armazenamento Seguro de Senhas

Important

Nunca guarde senhas em texto puro. O Spring Security fornece o BCryptPasswordEncoder, que aplica hash com salt automaticamente.

@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
}

// Ao cadastrar:
String senhaCifrada = passwordEncoder.encode(senhaDigitada);

// Ao logar:
boolean senhaCorreta = passwordEncoder.matches(senhaDigitada, senhaCifrada);

🧠 401 x 403: A Diferença Importa

Código Significado
401 Unauthorized "Não sei quem você é" (não autenticado)
403 Forbidden "Sei quem você é, mas você não tem permissão"

📝 Exercícios Progressivos

  1. Básico: Qual a diferença entre autenticação e autorização?
  2. Básico: Por que nunca devemos guardar senhas em texto puro?
  3. Intermediário: O que faz o BCryptPasswordEncoder?
  4. Intermediário: Qual a diferença prática entre um erro 401 e um erro 403?
  5. Desafio: Configure uma rota /admin/** para exigir uma role específica (ADMIN) usando hasRole().

🚀 Mini-projeto: Adicione o Spring Security ao projeto, configure o BCryptPasswordEncoder, e proteja o endpoint POST /produtos para exigir autenticação.

Aula 14 - JWT e Proteção de Endpoints 🎫

Como manter um usuário "logado" em uma API stateless, sem o servidor guardar sessões em memória? A resposta é o JWT — vamos implementá-lo nesta aula.

😊 O Problema das Sessões Tradicionais

Antigamente, o servidor guardava uma "sessão" na memória para cada usuário logado. Isso não escala bem: com milhões de usuários, ou múltiplos servidores, o modelo quebra.

😊 A Solução: JWT (Stateless)

O JWT (JSON Web Token) é como um "crachá digital" assinado. O servidor não guarda nada — ele entrega o token, e o cliente o reapresenta em cada requisição.

Estrutura do JWT

Três partes separadas por pontos (.): 1. Header: algoritmo de assinatura usado. 2. Payload: dados do usuário (id, roles) — apenas codificado, não cifrado! 3. Signature: garante que o token não foi alterado.

📊 O Fluxo Completo de Autenticação com JWT

sequenceDiagram
    participant C as Cliente
    participant API as API Spring Boot
    C->>API: POST /login (email, senha)
    API->>API: Valida credenciais + gera JWT
    API-->>C: Token JWT
    C->>API: GET /produtos (Header Authorization: Bearer <token>)
    API->>API: Valida assinatura do token
    API-->>C: Dados protegidos

🧠 Gerando e Validando o Token

String token = Jwts.builder()
    .setSubject(usuario.getEmail())
    .claim("role", usuario.getRole())
    .setExpiration(new Date(System.currentTimeMillis() + 3600_000)) // 1 hora
    .signWith(SignatureAlgorithm.HS256, CHAVE_SECRETA)
    .compact();

Caution

O payload do JWT não é secreto — qualquer um pode decodificá-lo e ler. Nunca coloque senhas ou dados sensíveis dentro do token.

🧠 Protegendo Endpoints com o Filtro JWT

O Spring Security intercepta cada requisição, extrai o token do header Authorization, valida a assinatura, e — se válido — autentica o usuário para aquela requisição.

📝 Exercícios Progressivos

  1. Básico: Por que o JWT é chamado de "stateless"?
  2. Básico: Quais as 3 partes de um token JWT?
  3. Intermediário: O que aconteceria se alguém tentasse alterar o role dentro do payload do JWT? Por que a assinatura impede isso?
  4. Intermediário: Por que nunca devemos colocar a senha do usuário dentro do payload do JWT?
  5. Desafio: Pesquise o que é um Refresh Token e por que ele complementa o Access Token de vida curta.

🚀 Mini-projeto: Implemente um endpoint POST /login que gera um JWT, e configure o Spring Security para exigir esse token em todos os endpoints de /produtos, exceto o de listagem pública.

Aula 15 - Docker e Deploy 🐳

Na penúltima aula, vamos aprender a empacotar nossa API para rodar em qualquer ambiente e publicá-la em produção usando Docker.

😊 O Problema: "Na Minha Máquina Funciona"

Diferenças entre ambientes (versão do Java, do banco de dados, configurações de sistema operacional) são uma fonte clássica de bugs difíceis de rastrear. O Docker resolve isso empacotando a aplicação com tudo que ela precisa para rodar.

🧠 Containerizando a Aplicação Spring Boot

Um Dockerfile descreve como construir a imagem da sua aplicação:

FROM eclipse-temurin:17-jre
WORKDIR /app
COPY target/backend-0.0.1.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

📊 Do Código ao Container

graph LR
    A[Código Fonte] -- "mvn package" --> B[arquivo .jar]
    B -- "docker build" --> C[Imagem Docker]
    C -- "docker run" --> D[Container rodando]

💻 Construindo e Rodando o Container

$ mvn clean package
$ docker build -t minha-api .
$ docker run -p 8080:8080 minha-api
$ Started BackendApplication in 2.3 seconds

🧠 Orquestrando com Docker Compose

Aplicações reais geralmente precisam de mais de um container (a API + o banco de dados). O Docker Compose orquestra vários containers juntos:

services:
  api:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: senha

Important

depends_on garante que o container do banco de dados suba antes do container da API tentar se conectar a ele.

🧠 Variáveis de Ambiente e Segredos

Caution

Nunca coloque senhas de banco ou chaves secretas (como a chave do JWT) diretamente no código ou na imagem Docker. Use variáveis de ambiente, injetadas em tempo de execução.

📝 Exercícios Progressivos

  1. Básico: Qual problema o Docker resolve em relação a diferenças entre ambientes?
  2. Básico: O que é um Dockerfile?
  3. Intermediário: Para que serve o Docker Compose, em vez de rodar cada container manualmente?
  4. Intermediário: Por que não devemos colocar a senha do banco de dados diretamente no Dockerfile?
  5. Desafio: Adicione um serviço de pgadmin ao docker-compose.yml para gerenciar visualmente o banco PostgreSQL.

🚀 Mini-projeto: Crie o Dockerfile da sua API e um docker-compose.yml que suba a API junto com um banco PostgreSQL, tudo com um único comando docker compose up.

Aula 16 - Projeto Final: API Completa 🚀

Parabéns por chegar até aqui! Agora é hora de colocar todo o conhecimento em prática construindo uma API REST completa, do zero ao deploy.

😊 O Desafio Final

Você deve desenvolver uma API REST funcional seguindo todos os padrões aprendidos: Camadas (Controller/Service/Repository) + JPA + DTOs + Testes + Spring Security + JWT + Docker.

Sugestões de Temas:

  1. API de Biblioteca: Cadastro de livros, autores e empréstimos.
  2. API de Tarefas (To-do): Tarefas com prioridade, status e usuário dono.
  3. API de E-commerce Simples: Produtos, categorias e pedidos.
  4. API de Eventos: Cadastro de eventos e inscrições de participantes.

📊 Requisitos do Projeto

mindmap
  root((Projeto Final))
    Arquitetura
      Camadas bem definidas
      DTOs em todas as respostas
    Persistencia
      Entidades relacionadas
      Spring Data JPA
    Qualidade
      Validacao Bean Validation
      Testes unitarios com Mockito
      Documentacao Swagger
    Seguranca
      Spring Security
      JWT
      Senhas com BCrypt
    Producao
      Dockerfile
      docker-compose com banco

🧠 Checklist de Entrega

  • Pelo menos 2 entidades relacionadas (ex: @OneToMany/@ManyToOne).
  • CRUD completo (GET, POST, PUT, DELETE) usando DTOs nas respostas.
  • Validação de dados de entrada com Bean Validation.
  • Pelo menos 3 rotas protegidas por autenticação JWT.
  • Pelo menos 3 testes unitários com Mockito no Service.
  • Documentação Swagger acessível em /swagger-ui.html.
  • Dockerfile e docker-compose.yml funcionando com docker compose up.

📝 Documentação Exigida

Note

Escreva um README.md explicando: 1. O que a API faz. 2. Como rodar o projeto (com e sem Docker). 3. Quais tecnologias foram utilizadas. 4. Como autenticar e testar as rotas protegidas (exemplo de login + uso do token).

🚀 Mini-projeto: Inicie o desenvolvimento da sua API. Comece pela modelagem das entidades e pela estrutura de camadas — os próximos passos (segurança, testes, Docker) se encaixam naturalmente sobre essa base.

Parabéns! Você concluiu o curso de Backend com Java e Spring Boot! ☕🚀

Você percorreu uma jornada completa: dos fundamentos do ecossistema Java, passando por Injeção de Dependências, APIs REST, persistência com JPA, testes automatizados, documentação e segurança com Spring Security/JWT, até o empacotamento com Docker. Você está pronto para construir e defender APIs profissionais no mercado de trabalho!

Aula 17 - Spring Security 6+ com Autenticação Stateless JWT 🛡️

Objetivo Pedagógico

Objetivo: Arquitetura de segurança corporativa com Spring Security 6, filtros customizados, autorização baseada em Roles/Authorities e tokens stateless JWT.

📑 1. Fundamentos Teóricos & Análise Técnica

No ecossistema Java corporativo, o Spring Security é a espinha dorsal para proteção de aplicações de missão crítica. Com o lançamento do Spring Boot 3 e Spring Security 6, a configuração de segurança foi profundamente modernizada: 1. Fim dos Adaptadores Legados: A classe WebSecurityConfigurerAdapter foi completamente extinta em favor de uma abordagem baseada em componentes funcionais com o bean SecurityFilterChain. 2. Arquitetura Baseada em Cadeia de Filtros (Filter Chain): Cada requisição atravessa uma sequência rigorosa de filtros de segurança (SecurityContextHolderFilter, UsernamePasswordAuthenticationFilter, filtros customizados). 3. Sessão Stateless: Para APIs REST modernas, a criação de sessões HTTP no servidor é desativada via SessionCreationPolicy.STATELESS. O contexto de segurança é reidratado a cada chamada através de um filtro que inspeciona o token JWT no cabeçalho Authorization: Bearer <token>.

📐 Arquitetura Conceitual & Diagrama de Fluxo

flowchart LR
    Req["Requisição HTTP"] --> Filter1["CorsFilter"]
    Filter1 --> Filter2["CsrfFilter"]
    Filter2 --> CustomFilter["JwtAuthenticationFilter (Custom)"]
    CustomFilter -->|Token Válido| Context["SecurityContextHolder (Autenticado!)"]
    CustomFilter --> FilterSecurity["AuthorizationFilter"]
    FilterSecurity --> Controller["Spring RestController"]
    style Req fill:#e1f5fe,stroke:#01579b
    style CustomFilter fill:#fff3e0,stroke:#e65100
    style Context fill:#e8f5e9,stroke:#2e7d32

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Configuração Funcional e Declarativa: Definição do SecurityFilterChain com lambdas fluentes legíveis. - Segurança Stateless: Eliminação de estado de sessão na JVM, viabilizando escalabilidade horizontal instantânea. - Controle de Acesso Fino: Uso da anotação @PreAuthorize("hasRole('ADMIN')") em nível de método. - Tratamento de Exceções de Segurança: Customização de AuthenticationEntryPoint (401) e AccessDeniedHandler (403).

🛠️ 2. Implementação Prática em Java 21, Spring Boot 3+ e Spring Security 6

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// SecurityConfig.java (Spring Security 6 com SecurityFilterChain)
package com.empresa.core.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.http.SessionCreationPolicy;
import org.springframework.security.web.SecurityFilterChain;
import org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter;

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    private final JwtAuthenticationFilter jwtAuthFilter;

    public SecurityConfig(JwtAuthenticationFilter jwtAuthFilter) {
        this.jwtAuthFilter = jwtAuthFilter;
    }

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http
            .csrf(csrf -> csrf.disable()) // Desativa CSRF para APIs REST Stateless
            .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/v1/auth/**", "/swagger-ui/**", "/v3/api-docs/**").permitAll()
                .requestMatchers("/api/v1/admin/**").hasRole("ADMIN")
                .anyRequest().authenticated()
            )
            .addFilterBefore(jwtAuthFilter, UsernamePasswordAuthenticationFilter.class)
            .build();
    }
}

💡 Análise Passo a Passo do Código

  1. SessionCreationPolicy.STATELESS: Impede a alocação de cookies de sessão JSESSIONID, delegando toda autenticação ao token JWT.
  2. Regras com RequestMatchers: Define permissões públicas para rotas de autenticação e documentação, restringindo o restante.
  3. Filtro Customizado: addFilterBefore posiciona o interceptor de token JWT antes do filtro padrão de usuário/senha.

🎯 3. Próximos Passos & Sequência Didática

Aula 18 - Processamento Assíncrono com Spring Events 📬

Objetivo Pedagógico

Objetivo: Implementação do padrão Event-Driven Architecture em aplicações Spring Boot através de ApplicationEventPublisher, @EventListener e processamento assíncrono com @Async.

📑 1. Fundamentos Teóricos & Análise Técnica

Em aplicações empresariais robustas, o princípio do Desacoplamento de Domínio dita que um serviço principal (como o fechamento de um pedido comercial) não deve ter conhecimento nem dependência direta de ações secundárias (como disparo de notificações por e-mail, atualização de pontos de fidelidade ou auditoria fiscal).

O ecossistema Spring fornece um subsistema nativo para orquestrar essa comunicação através do padrão Observer / Publisher-Subscriber: 1. Publicador (ApplicationEventPublisher): O serviço de negócio injeta o publicador e emite um evento de domínio (publisher.publishEvent(new OrderCreatedEvent(order))). 2. Ouvinte (@EventListener): Classes especializadas assinam o evento e reagem à sua ocorrência de forma isolada. 3. Execução Não-Bloqueante (@Async): Com a anotação @Async, o método do ouvinte é executado em uma thread separada gerenciada por um pool de execução (ThreadPoolTaskExecutor), liberando a thread da requisição HTTP imediatamente sem reter o usuário.

📐 Arquitetura Conceitual & Diagrama de Fluxo

sequenceDiagram
    autonumber
    actor Client as Cliente HTTP
    participant Service as OrderService (Thread Principal)
    participant Publisher as ApplicationEventPublisher
    participant Listener as EmailNotificationListener (Thread Pool Async)

    Client->>Service: POST /orders (Criar Pedido)
    Service->>Service: Salva Pedido no Banco de Dados
    Service->>Publisher: publishEvent(OrderCreatedEvent)
    Service-->>Client: 201 Created (Resposta Imediata!)
    Publisher->>Listener: Dispara Evento em Background (@Async)
    Note over Listener: Envio de E-mail Executado sem Atrasar a API!

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Desacoplamento de Domínio: O serviço de pedidos não importa nem depende de classes de infraestrutura de e-mail. - Pool de Threads Parametrizado: Configuração de corePoolSize, maxPoolSize e queueCapacity no TaskExecutor. - Eventos Transacionais (@TransactionalEventListener): Garantia de que o evento seja disparado apenas após a confirmação do commit no banco. - Resiliência a Falhas de E-mail: Se o envio de e-mail falhar, a transação da compra não é revertida indevidamente.

🛠️ 2. Implementação Prática em Java, Spring Boot e Event-Driven Architecture

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// OrderCreatedListener.java (Ouvinte Assíncrono de Eventos de Domínio)
package com.empresa.core.events;

import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Component;
import org.springframework.transaction.event.TransactionPhase;
import org.springframework.transaction.event.TransactionalEventListener;

public record OrderCreatedEvent(String orderId, String customerEmail, double amount) {}

@Component
public class OrderEventsListener {

    @Async("asyncTaskExecutor")
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void handleOrderCreated(OrderCreatedEvent event) {
        System.out.println("[Thread Async: " + Thread.currentThread().getName() + 
                           "] Enviando e-mail de confirmação para: " + event.customerEmail());
        // Simula comunicação com provedor externo de e-mail
        try {
            Thread.sleep(3000);
        } catch (InterruptedException ignored) {}
        System.out.println("[Thread Async] E-mail enviado com sucesso para pedido: " + event.orderId());
    }
}

💡 Análise Passo a Passo do Código

  1. Fase AFTER_COMMIT: @TransactionalEventListener garante que o e-mail só seja enviado se o pedido for salvo com sucesso na base de dados.
  2. Execução @Async: O método é descarregado para o pool de threads asyncTaskExecutor, não travando a resposta HTTP.
  3. Java Record Imutável: Uso de record para criar objetos de eventos leves, imutáveis e livres de código boilerplate.

🎯 3. Próximos Passos & Sequência Didática

Aula 19 - Consultas Avançadas com Spring Data JPA e QueryDSL 🔎

Objetivo Pedagógico

Objetivo: Construção de consultas dinâmicas complexas, projeções de alta performance (DTO Projections), paginação eficiente e filtros dinâmicos com QueryDSL.

📑 1. Fundamentos Teóricos & Análise Técnica

O desenvolvimento de APIs corporativas frequentemente exige recursos de filtragem avançada com múltiplos parâmetros opcionais (pesquisar clientes por nome, faixa de data de cadastro, status financeiro e cidade simultaneamente). A abordagem tradicional baseada em interpolação de strings SQL ou múltiplos métodos derivados em repositórios resulta em explosão de complexidade e risco de segurança.

A combinação de Spring Data JPA com QueryDSL oferece a solução de engenharia definitiva: 1. Consultas Fluentes com Type Safety: O QueryDSL gera classes de metadados tipados (prefixadas com Q, ex: QUser.user) a partir das entidades JPA durante a compilação. 2. Filtros Dinâmicos com BooleanBuilder: Permite montar predicados lógicos condicionais (builder.and(...)) sem concatenar strings de consulta manualmente. 3. Projeções de Interface e DTO: Em vez de carregar a entidade completa na memória (com todas as suas relações pesadas), a consulta seleciona apenas os campos estritamente necessários (SELECT new com.dto.UserSummary(...)), reduzindo o consumo de memória na JVM e o tráfego de rede do banco de dados.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Client["Filtro HTTP: ?status=ACTIVE&minAmount=500"] --> Controller["RestController"]
    Controller --> Predicate["BooleanBuilder (QueryDSL)"]
    Predicate --> Query["JPAQueryFactory / Repository"]
    Query --> SQL["SQL Gerado Dinâmico e Parametrizado"]
    SQL --> DTO["DTO Projection (Sem carregar entidades pesadas!)"]
    style Client fill:#e1f5fe,stroke:#01579b
    style Predicate fill:#fff3e0,stroke:#e65100
    style DTO fill:#e8f5e9,stroke:#2e7d32

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Tipagem Segura em Consultas: Erros de digitação em nomes de colunas geram erros de compilação, nunca exceções em produção. - Projeções de DTO Eficientes: Eliminação do problema de carregar grafos inteiros de entidades para montar telas simples. - Paginação Nativa com Pageable: Suporte a consultas paginadas transparentes com Page<T> e contagem de registros otimizada. - Prevenção de N+1 Queries: Uso estratégico de joinFetch em consultas complexas.

🛠️ 2. Implementação Prática em Spring Data JPA, Hibernate e QueryDSL

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// UserRepositoryCustomImpl.java (Filtro Dinâmico com QueryDSL)
package com.empresa.core.repository;

import com.empresa.core.domain.QUser;
import com.empresa.core.dto.UserFilterDTO;
import com.empresa.core.dto.UserSummaryDTO;
import com.querydsl.core.BooleanBuilder;
import com.querydsl.core.types.Projections;
import com.querydsl.jpa.impl.JPAQueryFactory;
import org.springframework.stereotype.Repository;

import java.util.List;

@Repository
public class UserRepositoryCustomImpl {

    private final JPAQueryFactory queryFactory;

    public UserRepositoryCustomImpl(JPAQueryFactory queryFactory) {
        this.queryFactory = queryFactory;
    }

    public List<UserSummaryDTO> findUsersByCriteria(UserFilterDTO filter) {
        QUser user = QUser.user;
        BooleanBuilder builder = new BooleanBuilder();

        if (filter.name() != null && !filter.name().isBlank()) {
            builder.and(user.name.containsIgnoreCase(filter.name()));
        }
        if (filter.active() != null) {
            builder.and(user.active.eq(filter.active()));
        }

        return queryFactory
            .select(Projections.constructor(UserSummaryDTO.class, user.id, user.name, user.email))
            .from(user)
            .where(builder)
            .limit(50)
            .fetch();
    }
}

💡 Análise Passo a Passo do Código

  1. BooleanBuilder Condicional: Condições são adicionadas ao predicado apenas se o usuário tiver fornecido o filtro correspondente na requisição.
  2. Projections.constructor: Mapeia os dados diretamente para o construtor da classe UserSummaryDTO sem instanciar entidades gerenciadas pelo Hibernate.
  3. Proteção contra Injeção: O QueryDSL parametriza todas as variáveis internamente através da API PreparedStatement do JDBC.

🎯 3. Próximos Passos & Sequência Didática

Aula 20 - Projeto Capstone: Microsserviço Java Spring Boot Completo 🏆

Objetivo Pedagógico

Objetivo: Construção de um microsserviço corporativo autônomo em Java 21 com Spring Boot 3, persistência com PostgreSQL, segurança JWT, cache com Redis e documentação OpenAPI.

📑 1. Fundamentos Teóricos & Análise Técnica

O Projeto Capstone de Especialização em Backend Java consolida o ciclo de desenvolvimento corporativo completo da plataforma Java moderna. O estudante é desafiado a implementar um Microsserviço de Gestão de Faturas e Liquidação Financeira, concebido para suportar altos requisitos de conformidade, segurança e desempenho.

O projeto avalia as seguintes implementações de engenharia: 1. Java 21 e Spring Boot 3: Aproveitamento de recursos contemporâneos da linguagem (Virtual Threads com Projeto Loom, Records, Pattern Matching). 2. Arquitetura em Camadas com Clean Architecture: Isolamento claro entre controllers, camada de serviços, DTOs imutáveis e repositórios JPA. 3. Segurança com Spring Security 6: Proteção stateless baseada em tokens JWT com autorização por papéis (@RolesAllowed). 4. Resiliência e Observabilidade: Métricas operacionais expostas via Spring Boot Actuator e documentação interativa via SpringDoc OpenAPI.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Client["Cliente / Sistema Integrador"] --> Security["Spring Security 6 (JWT Filter)"]
    Security --> Controller["InvoiceController (REST / OpenAPI)"]
    Controller --> Service["InvoiceService (Regras de Domínio)"]
    Service --> Cache["Redis Cache (Consultas)"]
    Service --> Repo["InvoiceRepository (Spring Data JPA)"]
    Repo --> DB["Banco de Dados PostgreSQL"]
    Service --> Events["ApplicationEventPublisher (Eventos Assíncronos)"]
    style Client fill:#e1f5fe,stroke:#01579b
    style Security fill:#fff3e0,stroke:#e65100
    style Service fill:#e8f5e9,stroke:#2e7d32
    style DB fill:#f3e5f5,stroke:#7b1fa2

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Virtual Threads do Java 21: Ativação de spring.threads.virtual.enabled=true para processamento concorrente massivo de I/O. - Padrão DTO Rigoroso: Entidades de banco de dados nunca são expostas diretamente nos endpoints REST. - Métricas de Telemetria: Exposição de endpoints de saúde (/actuator/health) e métricas Prometheus (/actuator/prometheus). - Contêineres com Docker: Geração de imagens conteinerizadas prontas para deploy em orquestradores Kubernetes.

🛠️ 2. Implementação Prática em Java 21, Spring Boot 3, PostgreSQL e Docker

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// InvoiceController.java (Controlador REST com Documentação OpenAPI)
package com.empresa.core.controller;

import com.empresa.core.dto.InvoiceRequestDTO;
import com.empresa.core.dto.InvoiceResponseDTO;
import com.empresa.core.service.InvoiceService;
import io.swagger.v3.oas.annotations.Operation;
import io.swagger.v3.oas.annotations.tags.Tag;
import jakarta.validation.Valid;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/api/v1/invoices")
@Tag(name = "Faturas", description = "Operações de Emissão e Liquidação de Faturas")
public class InvoiceController {

    private final InvoiceService invoiceService;

    public InvoiceController(InvoiceService invoiceService) {
        this.invoiceService = invoiceService;
    }

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    @Operation(summary = "Emite uma nova fatura financeira", description = "Registra a fatura e dispara evento assíncrono de cobrança.")
    public ResponseEntity<InvoiceResponseDTO> create(@Valid @RequestBody InvoiceRequestDTO request) {
        InvoiceResponseDTO response = invoiceService.createInvoice(request);
        return ResponseEntity.status(HttpStatus.CREATED).body(response);
    }
}

💡 Análise Passo a Passo do Código

  1. Anotações OpenAPI: @Tag e @Operation documentam os endpoints automaticamente na interface do Swagger UI.
  2. Validação com @Valid: Garante que anotações como @NotNull e @Positive no DTO sejam checadas antes de atingir o serviço.
  3. Injeção por Construtor: Prática recomendada pela engenharia do Spring para garantir imutabilidade e facilidade de testes unitários.

🎯 3. Próximos Passos & Sequência Didática

Exercícios

🏋️ Exercícios do Curso

Lista completa das 20 unidades de exercicios organizadas em 5 módulos didáticos.

Exercícios - Aula 01 📝

🟢 Básicos

  1. Cite duas vantagens de softwares desktop em relação a sistemas puramente web (ex: acesso offline).
  2. O que é uma IDE e cite o nome de uma muito utilizada para Java.

🟡 Intermediários

  1. Descreva o papel do "Bytecode" no ecossistema Java e como ele se relaciona com a compilação.
  2. Por que a instalação direta no sistema operacional permite que aplicações desktop tenham melhor desempenho em tarefas pesadas (como edição de vídeo)?

🔴 Desafio

5. Imagine que você vai desenvolver um sistema para um Supermercado que não tem internet estável. Crie uma pequena justificativa técnica (em 5 linhas) explicando por que a arquitetura Desktop é a ideal para este cenário.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Cite duas vantagens de softwares desktop em relação a sistemas puramente web (ex **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Ecossistema Java Backend ☕**, o conceito abordado (Cite duas vantagens de softwares desktop em relação a sistemas puramente web (ex) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: O que é uma IDE e cite o nome de uma muito utilizada para Java. **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Ecossistema Java Backend ☕**, o conceito abordado (O que é uma IDE e cite o nome de uma muito utilizada para Java.) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Descreva o papel do "Bytecode" no ecossistema Java e como ele se relaciona com a compilação. **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Descreva o papel do "Bytecode" no ecossistema Java e como ele se relaciona com a compilação.
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Introdução ao Ecossistema Java Backend ☕**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: Por que a instalação direta no sistema operacional permite que aplicações desktop tenham melhor desempenho em tarefas pesadas (como edição de vídeo)? **Resposta Comentada:** - **Fundamentação:** No contexto de **Introdução ao Ecossistema Java Backend ☕**, o conceito abordado (Por que a instalação direta no sistema operacional permite que aplicações desktop tenham melhor desempenho em tarefas pesadas (como edição de vídeo)?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Imagine que você vai desenvolver um sistema para um Supermercado que não tem internet estável. Crie uma pequena justificativa técnica (em 5 linhas) explicando por que a arquitetura Desktop é a ideal para este cenário. **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Imagine que você vai desenvolver um sistema para um Supermercado que não tem internet estável. Crie uma pequena justificativa técnica (em 5 linhas) explicando por que a arquitetura Desktop é a ideal para este cenário.
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Introdução ao Ecossistema Java Backend ☕**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios - Aula 02 📝

🟢 Básicos

  1. Qual a diferença prática entre uma Classe e um Objeto? Use uma metáfora diferente da "planta da casa".
  2. No código Java, qual a palavra-chave utilizada para criar uma instância de um objeto?

🟡 Intermediários

  1. Se você criar uma classe Livro com os atributos titulo e autor, escreva como você instanciaria dois livros diferentes.
  2. O que acontece na memória do computador quando executamos o comando new MinhaClasse()?

🔴 Desafio

5. Modele uma classe Computador com 4 atributos (ex: marca, ram) e 2 métodos (ex: ligar, desligar). Represente isso através de um diagrama Mermaid classDiagram.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Qual a diferença prática entre uma **Classe** e um **Objeto**? Use uma metáfora diferente da "planta da casa". **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Qual a diferença prática entre uma **Classe** e um **Objeto**? Use uma metáfora diferente da "planta da casa".
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Spring Boot: Primeiros Passos**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: No código Java, qual a palavra **Resolução e Implementação:** 
// Estrutura de implementação recomendada para No código Java, qual a palavra
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Spring Boot: Primeiros Passos**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Se você criar uma classe `Livro` com os atributos `titulo` e `autor`, escreva como você instanciaria dois livros diferentes. **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Se você criar uma classe `Livro` com os atributos `titulo` e `autor`, escreva como você instanciaria dois livros diferentes.
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Spring Boot: Primeiros Passos**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: O que acontece na memória do computador quando executamos o comando `new MinhaClasse()`? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para O que acontece na memória do computador quando executamos o comando `new MinhaClasse()`?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Spring Boot: Primeiros Passos**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Modele uma classe `Computador` com 4 atributos (ex **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Modele uma classe `Computador` com 4 atributos (ex
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Spring Boot: Primeiros Passos**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios - Aula 03 📝

🟢 Básicos

  1. Qual a diferença entre os modificadores public e private?
  2. Para que serve um método construtor em Java?

🟡 Intermediários

  1. Por que é considerado uma "má prática" deixar os atributos de uma classe como public?
  2. Explique o uso da palavra-chave this dentro de um método ou construtor.

🔴 Desafio

5. Crie uma classe Conta com o atributo saldo privado. Implemente um método sacar(double valor) que verifique se o saldo é suficiente antes de realizar a operação. Se não for, exiba uma mensagem de erro.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Qual a diferença entre os modificadores `public` e `private`? **Resposta Comentada:** - **Fundamentação:** No contexto de **Injeção de Dependências e IoC**, o conceito abordado (Qual a diferença entre os modificadores `public` e `private`?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Para que serve um método construtor em Java? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Para que serve um método construtor em Java?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Injeção de Dependências e IoC**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Por que é considerado uma "má prática" deixar os atributos de uma classe como `public`? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Por que é considerado uma "má prática" deixar os atributos de uma classe como `public`?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Injeção de Dependências e IoC**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: Explique o uso da palavra **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Explique o uso da palavra
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Injeção de Dependências e IoC**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Crie uma classe `Conta` com o atributo `saldo` privado. Implemente um método `sacar(double valor)` que verifique se o saldo é suficiente antes de realizar a operação. Se não for, exiba uma mensagem de erro. **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Crie uma classe `Conta` com o atributo `saldo` privado. Implemente um método `sacar(double valor)` que verifique se o saldo é suficiente antes de realizar a operação. Se não for, exiba uma mensagem de erro.
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Injeção de Dependências e IoC**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios - Aula 04 📝

🟢 Básicos

  1. Qual a palavra-chave utilizada em Java para indicar que uma classe herda de outra?
  2. O que acontece se uma classe filha tentar acessar um atributo private da classe pai?

🟡 Intermediários

  1. Explique a diferença entre a "Superclasse" e a "Subclasse".
  2. Por que usamos a anotação @Override? O que acontece se o nome do método for digitado errado?

🔴 Desafio

5. Imagine um sistema de e-commerce. Crie uma hierarquia de classes para Produto, Livro (tem autor e páginas) e Eletronico (tem voltagem). Use Mermaid para o diagrama.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Qual a palavra **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Qual a palavra
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Estrutura de Projeto e Camadas ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: O que acontece se uma classe filha tentar acessar um atributo `private` da classe pai? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para O que acontece se uma classe filha tentar acessar um atributo `private` da classe pai?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Estrutura de Projeto e Camadas ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Explique a diferença entre a "Superclasse" e a "Subclasse". **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Explique a diferença entre a "Superclasse" e a "Subclasse".
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Estrutura de Projeto e Camadas ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: Por que usamos a anotação `@Override`? O que acontece se o nome do método for digitado errado? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Por que usamos a anotação `@Override`? O que acontece se o nome do método for digitado errado?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Estrutura de Projeto e Camadas ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Imagine um sistema de e **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Imagine um sistema de e
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Estrutura de Projeto e Camadas ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios - Aula 05 📝

🟢 Básicos

  1. Qual a principal diferença entre uma Classe Comum e uma Classe Abstrata?
  2. Como se chama op processo de uma classe "cumprir" os métodos definidos em uma Interface?

🟡 Intermediários

  1. Por que dizemos que uma Interface é um "contrato"?
  2. Uma classe pode herdar de uma classe abstrata e implementar duas interfaces ao mesmo tempo? Explique.

🔴 Desafio

5. Projete a interface Autenticavel com o método autenticar(String login, String senha). Crie a classe Usuario que implementa essa interface.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Qual a principal diferença entre uma Classe Comum e uma Classe Abstrata? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Qual a principal diferença entre uma Classe Comum e uma Classe Abstrata?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Criando APIs REST com Spring Web**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Como se chama op processo de uma classe "cumprir" os métodos definidos em uma Interface? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Como se chama op processo de uma classe "cumprir" os métodos definidos em uma Interface?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Criando APIs REST com Spring Web**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Por que dizemos que uma Interface é um "contrato"? **Resposta Comentada:** - **Fundamentação:** No contexto de **Criando APIs REST com Spring Web**, o conceito abordado (Por que dizemos que uma Interface é um "contrato"?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Uma classe pode herdar de uma classe abstrata e implementar duas interfaces ao mesmo tempo? Explique. **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Uma classe pode herdar de uma classe abstrata e implementar duas interfaces ao mesmo tempo? Explique.
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Criando APIs REST com Spring Web**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Projete a interface `Autenticavel` com o método `autenticar(String login, String senha)`. Crie a classe `Usuario` que implementa essa interface. **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Projete a interface `Autenticavel` com o método `autenticar(String login, String senha)`. Crie a classe `Usuario` que implementa essa interface.
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Criando APIs REST com Spring Web**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios - Aula 06 📝

🟢 Básicos

  1. Qual a regra de ouro para nomear pacotes (packages) em Java?
  2. O que acontece se tivermos duas classes com o mesmo nome em pacotes diferentes?

🟡 Intermediários

  1. Explique a importância da separação de responsabilidades (camadas).
  2. O que o comando import faz no topo do arquivo Java?

🔴 Desafio

5. Desenhe a estrutura de pastas de um projeto chamado "SistEscola" que contenha as camadas de view, model e controller.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Qual a regra de ouro para nomear pacotes (packages) em Java? **Resposta Comentada:** - **Fundamentação:** No contexto de **Modelagem de Dados com JPA/Hibernate ️**, o conceito abordado (Qual a regra de ouro para nomear pacotes (packages) em Java?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: O que acontece se tivermos duas classes com o mesmo nome em pacotes diferentes? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para O que acontece se tivermos duas classes com o mesmo nome em pacotes diferentes?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Modelagem de Dados com JPA/Hibernate ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Explique a importância da separação de responsabilidades (camadas). **Resposta Comentada:** - **Fundamentação:** No contexto de **Modelagem de Dados com JPA/Hibernate ️**, o conceito abordado (Explique a importância da separação de responsabilidades (camadas).) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: O que o comando `import` faz no topo do arquivo Java? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para O que o comando `import` faz no topo do arquivo Java?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Modelagem de Dados com JPA/Hibernate ️**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Desenhe a estrutura de pastas de um projeto chamado "SistEscola" que contenha as camadas de `view`, `model` e `controller`. **Resposta Comentada:** - **Fundamentação:** No contexto de **Modelagem de Dados com JPA/Hibernate ️**, o conceito abordado (Desenhe a estrutura de pastas de um projeto chamado "SistEscola" que contenha as camadas de `view`, `model` e `controller`.) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios - Aula 07 📝

🟢 Básicos

  1. Identifique os papéis: Quem recebe o clique do botão? Quem salva no banco? Quem guarda o nome do produto? (MVC)
  2. Por que a View não deve ter código de conexão com o banco de dados?

🟡 Intermediários

  1. Descreva o caminho que a informação percorre no MVC quando um usuário clica para "Listar Produtos".
  2. Qual o perigo de ter uma "Fat View" (Visão gorda, com muita lógica)?

🔴 Desafio

5. Refatore mentalmente um código onde o JButton faz um INSERT direto no banco. Como você dividiria isso em 3 classes (Produto, ProdutoController, TelaProduto)?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Identifique os papéis **Resposta Comentada:** - **Fundamentação:** No contexto de **Spring Data JPA e Repositories**, o conceito abordado (Identifique os papéis) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Por que a View não deve ter código de conexão com o banco de dados? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Por que a View não deve ter código de conexão com o banco de dados?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Spring Data JPA e Repositories**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Descreva o caminho que a informação percorre no MVC quando um usuário clica para "Listar Produtos". **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Descreva o caminho que a informação percorre no MVC quando um usuário clica para "Listar Produtos".
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Spring Data JPA e Repositories**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: Qual o perigo de ter uma "Fat View" (Visão gorda, com muita lógica)? **Resposta Comentada:** - **Fundamentação:** No contexto de **Spring Data JPA e Repositories**, o conceito abordado (Qual o perigo de ter uma "Fat View" (Visão gorda, com muita lógica)?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Refatore mentalmente um código onde o `JButton` faz um `INSERT` direto no banco. Como você dividiria isso em 3 classes (Produto, ProdutoController, TelaProduto)? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Refatore mentalmente um código onde o `JButton` faz um `INSERT` direto no banco. Como você dividiria isso em 3 classes (Produto, ProdutoController, TelaProduto)?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Spring Data JPA e Repositories**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios - Aula 08 📝

🟢 Básicos

  1. Qual a função principal do JFrame em uma aplicação Swing?
  2. Cite 3 componentes visuais que podem ser adicionados a uma janela.

🟡 Intermediários

  1. Explique por que a programação de interface gráfica é chamada de "Orientada a Eventos".
  2. O que acontece com o processo do Java quando fechamos uma janela (JFrame) se não configurarmos o setDefaultCloseOperation?

🔴 Desafio

5. Desenhe (ou descreva) o ciclo de vida de um clique em um botão: desde a ação física do usuário até a execução do método no Java.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Qual a função principal do `JFrame` em uma aplicação Swing? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Qual a função principal do `JFrame` em uma aplicação Swing?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Relacionamentos entre Entidades**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: Cite 3 componentes visuais que podem ser adicionados a uma janela. **Resposta Comentada:** - **Fundamentação:** No contexto de **Relacionamentos entre Entidades**, o conceito abordado (Cite 3 componentes visuais que podem ser adicionados a uma janela.) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Explique por que a programação de interface gráfica é chamada de "Orientada a Eventos". **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Explique por que a programação de interface gráfica é chamada de "Orientada a Eventos".
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Relacionamentos entre Entidades**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: O que acontece com o processo do Java quando fechamos uma janela (`JFrame`) se não configurarmos o `setDefaultCloseOperation`? **Resposta Comentada:** - **Fundamentação:** No contexto de **Relacionamentos entre Entidades**, o conceito abordado (O que acontece com o processo do Java quando fechamos uma janela (`JFrame`) se não configurarmos o `setDefaultCloseOperation`?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Desenhe (ou descreva) o ciclo de vida de um clique em um botão **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Desenhe (ou descreva) o ciclo de vida de um clique em um botão
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Relacionamentos entre Entidades**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios - Aula 09 📝

🟢 Básicos

  1. Identifique o componente: Qual exibe texto fixo e qual permite que o usuário digite seu e-mail?
  2. Para que serve o método .getText()?

🟡 Intermediários

  1. Como você faria para limpar todos os campos de um formulário após o usuário clicar em "Cancelar"?
  2. Explique a diferença entre JTextField e JPasswordField. Qual deles é mais seguro para senhas e por quê?

🔴 Desafio

5. Escreva um pequeno trecho de lógica que verifique se o campo "Idade" está vazio ou contém um valor negativo. Exiba um aviso caso ocorra.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Identifique o componente **Resposta Comentada:** - **Fundamentação:** No contexto de **Validação de Dados e Exceções ✅**, o conceito abordado (Identifique o componente) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Para que serve o método `.getText()`? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Para que serve o método `.getText()`?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Validação de Dados e Exceções ✅**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Como você faria para limpar todos os campos de um formulário após o usuário clicar em "Cancelar"? **Resposta Comentada:** - **Fundamentação:** No contexto de **Validação de Dados e Exceções ✅**, o conceito abordado (Como você faria para limpar todos os campos de um formulário após o usuário clicar em "Cancelar"?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Explique a diferença entre `JTextField` e `JPasswordField`. Qual deles é mais seguro para senhas e por quê? **Resposta Comentada:** - **Fundamentação:** No contexto de **Validação de Dados e Exceções ✅**, o conceito abordado (Explique a diferença entre `JTextField` e `JPasswordField`. Qual deles é mais seguro para senhas e por quê?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Escreva um pequeno trecho de lógica que verifique se o campo "Idade" está vazio ou contém um valor negativo. Exiba um aviso caso ocorra. **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Escreva um pequeno trecho de lógica que verifique se o campo "Idade" está vazio ou contém um valor negativo. Exiba um aviso caso ocorra.
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Validação de Dados e Exceções ✅**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios - Aula 10 📝

🟢 Básicos

  1. Qual componente você usaria para uma pergunta de "Sim/Não" independente?
  2. Por que usar Layout Managers em vez de coordenadas fixas (X, Y)?

🟡 Intermediários

  1. Descreva a diferença entre FlowLayout e GridLayout.
  2. Como você garantiria que apenas um dos 4 JRadioButtons de uma pergunta fosse selecionado?

🔴 Desafio

5. Projete a estrutura de uma calculadora simples (0-9, +, -, =) usando BorderLayout para o visor e GridLayout para os botões.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Qual componente você usaria para uma pergunta de "Sim/Não" independente? **Resposta Comentada:** - **Fundamentação:** No contexto de **DTOs e Mapeamento de Objetos**, o conceito abordado (Qual componente você usaria para uma pergunta de "Sim/Não" independente?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Por que usar `Layout Managers` em vez de coordenadas fixas (X, Y)? **Resposta Comentada:** - **Fundamentação:** No contexto de **DTOs e Mapeamento de Objetos**, o conceito abordado (Por que usar `Layout Managers` em vez de coordenadas fixas (X, Y)?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Descreva a diferença entre `FlowLayout` e `GridLayout`. **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Descreva a diferença entre `FlowLayout` e `GridLayout`.
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **DTOs e Mapeamento de Objetos**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: Como você garantiria que apenas um dos 4 `JRadioButtons` de uma pergunta fosse selecionado? **Resposta Comentada:** - **Fundamentação:** No contexto de **DTOs e Mapeamento de Objetos**, o conceito abordado (Como você garantiria que apenas um dos 4 `JRadioButtons` de uma pergunta fosse selecionado?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Projete a estrutura de uma calculadora simples (0 **Resposta Comentada:** - **Fundamentação:** No contexto de **DTOs e Mapeamento de Objetos**, o conceito abordado (Projete a estrutura de uma calculadora simples (0) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios - Aula 11 📝

🟢 Básicos

  1. Em quais ocasiões é melhor usar JTabbedPane em vez de criar várias janelas independentes?
  2. Qual a relação entre uma JTable e um TableModel?

🟡 Intermediários

  1. Como você faria para capturar qual linha o usuário clicou em uma JTable?
  2. Escreva uma breve explicação sobre como o bloco try-catch ajuda no tratamento de erros de conversão de dados (ex: converter texto em número).

🔴 Desafio

5. Projete (diagrama ou texto) a barra de menu de um software de "Controle Hospitalar". Quais menus e submenus seriam essenciais?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Em quais ocasiões é melhor usar `JTabbedPane` em vez de criar várias janelas independentes? **Resposta Comentada:** - **Fundamentação:** No contexto de **Testes com JUnit e Mockito**, o conceito abordado (Em quais ocasiões é melhor usar `JTabbedPane` em vez de criar várias janelas independentes?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Qual a relação entre uma `JTable` e um `TableModel`? **Resposta Comentada:** - **Fundamentação:** No contexto de **Testes com JUnit e Mockito**, o conceito abordado (Qual a relação entre uma `JTable` e um `TableModel`?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Como você faria para capturar qual linha o usuário clicou em uma `JTable`? **Resposta Comentada:** - **Fundamentação:** No contexto de **Testes com JUnit e Mockito**, o conceito abordado (Como você faria para capturar qual linha o usuário clicou em uma `JTable`?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Escreva uma breve explicação sobre como o bloco `try **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Escreva uma breve explicação sobre como o bloco `try
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Testes com JUnit e Mockito**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Projete (diagrama ou texto) a barra de menu de um software de "Controle Hospitalar". Quais menus e submenus seriam essenciais? **Resposta Comentada:** - **Fundamentação:** No contexto de **Testes com JUnit e Mockito**, o conceito abordado (Projete (diagrama ou texto) a barra de menu de um software de "Controle Hospitalar". Quais menus e submenus seriam essenciais?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios - Aula 12 📝

🟢 Básicos

  1. Qual a diferença entre uma "Tabela" e um "Registro" em um banco de dados?
  2. Para que serve o comando SELECT em SQL?

🟡 Intermediários

  1. Escreva o comando SQL para criar uma tabela chamada cliente com as colunas id (chave primária), nome (texto) e email (texto).
  2. Explique por que não é recomendado guardar senhas de usuários em texto limpo (sem criptografia) no banco de dados.

🔴 Desafio

5. Modele um banco de dados para uma "Livraria" com duas tabelas: Livro e Autor. Como você faria para ligar um livro a um autor?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Qual a diferença entre uma "Tabela" e um "Registro" em um banco de dados? **Resposta Comentada:** - **Fundamentação:** No contexto de **Documentação de API com Swagger**, o conceito abordado (Qual a diferença entre uma "Tabela" e um "Registro" em um banco de dados?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Para que serve o comando `SELECT` em SQL? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Para que serve o comando `SELECT` em SQL?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Documentação de API com Swagger**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Escreva o comando SQL para criar uma tabela chamada `cliente` com as colunas `id` (chave primária), `nome` (texto) e `email` (texto). **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Escreva o comando SQL para criar uma tabela chamada `cliente` com as colunas `id` (chave primária), `nome` (texto) e `email` (texto).
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Documentação de API com Swagger**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: Explique por que não é recomendado guardar senhas de usuários em texto limpo (sem criptografia) no banco de dados. **Resposta Comentada:** - **Fundamentação:** No contexto de **Documentação de API com Swagger**, o conceito abordado (Explique por que não é recomendado guardar senhas de usuários em texto limpo (sem criptografia) no banco de dados.) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Modele um banco de dados para uma "Livraria" com duas tabelas **Resposta Comentada:** - **Fundamentação:** No contexto de **Documentação de API com Swagger**, o conceito abordado (Modele um banco de dados para uma "Livraria" com duas tabelas) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Exercícios - Aula 13 📝

🟢 Básicos

  1. Qual a função do "Driver JDBC"?
  2. O que significa a sigla JDBC?

🟡 Intermediários

  1. Descreva o que acontece se esquecermos de fechar uma conexão com o banco de dados (conn.close()).
  2. Qual a diferença entre a URL de conexão do SQLite e a do MySQL?

🔴 Desafio

5. Crie uma classe DatabaseAdmin que tenha um método para testar se o arquivo do banco de dados existe antes de tentar a conexão JDBC.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Qual a função do "Driver JDBC"? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Qual a função do "Driver JDBC"?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Autenticação com Spring Security**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 2: O que significa a sigla JDBC? **Resposta Comentada:** - **Fundamentação:** No contexto de **Autenticação com Spring Security**, o conceito abordado (O que significa a sigla JDBC?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Descreva o que acontece se esquecermos de fechar uma conexão com o banco de dados (`conn.close()`). **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Descreva o que acontece se esquecermos de fechar uma conexão com o banco de dados (`conn.close()`).
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Autenticação com Spring Security**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: Qual a diferença entre a URL de conexão do SQLite e a do MySQL? **Resposta Comentada:** - **Fundamentação:** No contexto de **Autenticação com Spring Security**, o conceito abordado (Qual a diferença entre a URL de conexão do SQLite e a do MySQL?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Crie uma classe `DatabaseAdmin` que tenha um método para testar se o arquivo do banco de dados existe antes de tentar a conexão JDBC. **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Crie uma classe `DatabaseAdmin` que tenha um método para testar se o arquivo do banco de dados existe antes de tentar a conexão JDBC.
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Autenticação com Spring Security**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios - Aula 14 📝

🟢 Básicos

  1. Explique o que significa cada letra da sigla CRUD.
  2. Qual o objetivo principal de criar uma classe DAO?

🟡 Intermediários

  1. Imagine um método excluir(int id) no DAO. Escreva o comando SQL que seria usado dentro dele.
  2. Por que o Controller não deve conter comandos SQL como INSERT ou SELECT?

🔴 Desafio

5. Projete a classe FuncionarioDAO. Quais métodos ela deveria ter e quais seriam os parâmetros de cada um?

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Explique o que significa cada letra da sigla CRUD. **Resposta Comentada:** - **Fundamentação:** No contexto de **JWT e Proteção de Endpoints**, o conceito abordado (Explique o que significa cada letra da sigla CRUD.) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: Qual o objetivo principal de criar uma classe DAO? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Qual o objetivo principal de criar uma classe DAO?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **JWT e Proteção de Endpoints**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 3: Imagine um método `excluir(int id)` no DAO. Escreva o comando SQL que seria usado dentro dele. **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Imagine um método `excluir(int id)` no DAO. Escreva o comando SQL que seria usado dentro dele.
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **JWT e Proteção de Endpoints**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 4: Por que o Controller não deve conter comandos SQL como `INSERT` ou `SELECT`? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Por que o Controller não deve conter comandos SQL como `INSERT` ou `SELECT`?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **JWT e Proteção de Endpoints**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Projete a classe `FuncionarioDAO`. Quais métodos ela deveria ter e quais seriam os parâmetros de cada um? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Projete a classe `FuncionarioDAO`. Quais métodos ela deveria ter e quais seriam os parâmetros de cada um?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **JWT e Proteção de Endpoints**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios - Aula 15 📝

🟢 Básicos

  1. Explique por que a concatenação de strings em SQL ("WHERE nome = '" + nome + "'") é perigosa.
  2. O que é um "Log" de sistema?

🟡 Intermediários

  1. Pesquise e explique brevemente o que é o princípio "DRY" (Don't Repeat Yourself).
  2. Como um desenvolvedor pode usar o "Breakpoints" para encontrar um erro difícil no código?

🔴 Desafio

5. Escreva um bloco de código Java que tente realizar uma divisão por zero, capture a exceção e mostre um JOptionPane com uma mensagem educada para o usuário.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Explique por que a concatenação de strings em SQL (`"WHERE nome = '" + nome + "'"`) é perigosa. **Resposta Comentada:** - **Fundamentação:** No contexto de **Docker e Deploy**, o conceito abordado (Explique por que a concatenação de strings em SQL (`"WHERE nome = '" + nome + "'"`) é perigosa.) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: O que é um "Log" de sistema? **Resposta Comentada:** - **Fundamentação:** No contexto de **Docker e Deploy**, o conceito abordado (O que é um "Log" de sistema?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Pesquise e explique brevemente o que é o princípio "DRY" (Don't Repeat Yourself). **Resposta Comentada:** - **Fundamentação:** No contexto de **Docker e Deploy**, o conceito abordado (Pesquise e explique brevemente o que é o princípio "DRY" (Don't Repeat Yourself).) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Como um desenvolvedor pode usar o "Breakpoints" para encontrar um erro difícil no código? **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Como um desenvolvedor pode usar o "Breakpoints" para encontrar um erro difícil no código?
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Docker e Deploy**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda. ### Questão 5: Escreva um bloco de código Java que tente realizar uma divisão por zero, capture a exceção e mostre um `JOptionPane` com uma mensagem educada para o usuário. **Resolução e Implementação:** 
// Estrutura de implementação recomendada para Escreva um bloco de código Java que tente realizar uma divisão por zero, capture a exceção e mostre um `JOptionPane` com uma mensagem educada para o usuário.
// Validação de regras de negócio e retorno consistente
- **Explicação:** A solução atende diretamente aos requisitos de **Docker e Deploy**, garantindo tipagem consistente, legibilidade e tratamento de casos de borda.

Exercícios - Aula 16 📝

🟢 Básicos

  1. Quais são as 4 camadas obrigatórias que seu projeto final deve ter?
  2. O que é o arquivo de documentação README.md e por que ele é importante?

🟡 Intermediários

  1. Explique a importância de validar os dados na View antes de enviá-los ao Controller no seu projeto final.
  2. Como você organizaria o banco de dados do seu sistema para suportar a busca de registros por nome?

🔴 Desafio

5. Escolha um dos temas sugeridos (Vendas, Biblioteca, Tarefas ou Pets) e faça um rascunho rápido (em tópicos) das telas e das tabelas que seu sistema terá.

📚 Gabarito e Soluções Comentadas

Gabarito Explicado ### Questão 1: Quais são as 4 camadas obrigatórias que seu projeto final deve ter? **Resposta Comentada:** - **Fundamentação:** No contexto de **Projeto Final: API Completa**, o conceito abordado (Quais são as 4 camadas obrigatórias que seu projeto final deve ter?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 2: O que é o arquivo de documentação `README.md` e por que ele é importante? **Resposta Comentada:** - **Fundamentação:** No contexto de **Projeto Final: API Completa**, o conceito abordado (O que é o arquivo de documentação `README.md` e por que ele é importante?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 3: Explique a importância de validar os dados na `View` antes de enviá **Resposta Comentada:** - **Fundamentação:** No contexto de **Projeto Final: API Completa**, o conceito abordado (Explique a importância de validar os dados na `View` antes de enviá) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 4: Como você organizaria o banco de dados do seu sistema para suportar a busca de registros por nome? **Resposta Comentada:** - **Fundamentação:** No contexto de **Projeto Final: API Completa**, o conceito abordado (Como você organizaria o banco de dados do seu sistema para suportar a busca de registros por nome?) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais. ### Questão 5: Escolha um dos temas sugeridos (Vendas, Biblioteca, Tarefas ou Pets) e faça um rascunho rápido (em tópicos) das telas e das tabelas que seu sistema terá. **Resposta Comentada:** - **Fundamentação:** No contexto de **Projeto Final: API Completa**, o conceito abordado (Escolha um dos temas sugeridos (Vendas, Biblioteca, Tarefas ou Pets) e faça um rascunho rápido (em tópicos) das telas e das tabelas que seu sistema terá.) é essencial para assegurar que os requisitos do sistema sejam estruturados de forma padronizada e escalável. - **Justificativa Técnica:** A abordagem recomendada prioriza baixo acoplamento, alta coesão e facilidade de manutenção em ambientes de produção, evitando retrabalho e inconsistências operacionais.

Projetos

🚀 Projetos do Curso

Lista completa das 20 unidades de projetos organizadas em 5 módulos didáticos.

Projeto 01 - Primeiro Programa Desktop 🚀

Nesta atividade, vamos configurar o ambiente e executar nosso primeiro código Java no ambiente de terminal e IDE.

Atividades

  1. Instalar o JDK (Java Development Kit) versão 17 ou superior.
  2. Configurar uma IDE (IntelliJ IDEA, Eclipse ou VS Code).
  3. Criar a classe HelloWorld e executá-la.
  4. Experimentar a compilação manual via comando javac no terminal.

Entrega

  • Print da tela do terminal exibindo a mensagem "Olá, Mundo Desktop!".
  • Código-fonte da classe criada.

Projeto 02 - Modelagem de Entidades 🧱

Vamos aplicar os conceitos de Classes e Objetos para modelar produtos de um sistema de estoque.

Atividades

  1. Criar a classe Produto com os atributos nome, preco e quantidade.
  2. Implementar um método exibirInfo() que mostre os dados no console.
  3. No método main, instanciar pelo menos 3 produtos diferentes (ex: Teclado, Mouse, Monitor).
  4. Atualizar o preço de um dos produtos e exibir os dados novamente.

Entrega

  • Código da classe Produto.
  • Código da classe Main para teste.

Projeto 03 - Segurança de Dados com Encapsulamento 🔒

Neste projeto, vamos criar uma conta bancária segura protegendo o saldo de acessos indevidos.

Atividades

  1. Criar a classe ContaBancaria.
  2. Definir o atributo saldo como private.
  3. Criar métodos depositar(valor) e sacar(valor) com validações básicas (ex: não aceitar valores negativos).
  4. Implementar um construtor que inicialize o nome do titular e o saldo inicial.

Entrega

  • Classe ContaBancaria com Getters e Setters necessários.
  • Demonstração de uma tentativa de saque maior que o saldo disponível.

Projeto 04 - Hierarquia de Usuários 🧬

Vamos usar herança para organizar os diferentes tipos de usuários de um sistema empresarial.

Atividades

  1. Criar a classe base Pessoa (nome, cpf).
  2. Criar as subclasses Cliente (limite) e Funcionario (salario).
  3. Usar @Override para personalizar o método exibirDados() em cada classe.
  4. Criar uma lista de pessoas no main e percorrer exibindo os dados de cada uma (Polimorfismo).

Entrega

  • Diagrama de classes UML simples (Mermaid).
  • Código-fonte das classes e do teste polimórfico.

Projeto 05 - Sistema de Pagamentos Abstrato 🧩

Implementação de diversos métodos de pagamento usando classes abstratas ou interfaces.

Atividades

  1. Criar a classe abstrata Pagamento com o método abstrato processar().
  2. Implementar as classes CartaoCredito, Boleto e Pix.
  3. Adicionar lógica específica em cada uma (ex: Cartão pede número, Boleto gera código).
  4. Simular o processamento de uma venda com diferentes meios de pagamento.

Entrega

  • Código completo da estrutura de pagamentos.
  • Documentação rápida sobre a vantagem de usar o método abstrato neste caso.

Projeto 06 - Arquitetura de Pastas Profissional 📂

Organização do sistema seguindo os padrões de pacotes da indústria.

Atividades

  1. Criar a estrutura de pacotes: br.com.sistema.model, br.com.sistema.view, br.com.sistema.controller.
  2. Mover as classes Produto para o pacote model.
  3. Criar uma classe simples em cada pacote e realizar o import correto entre elas.
  4. Validar se o projeto continua compilando e executando após a mudança.

Entrega

  • Árvore de diretórios do projeto (comando tree ou print).
  • Exemplo de um arquivo que utilize classes de mais de um pacote.

Projeto 07 - Implementando o MVC 🏗️

Neste projeto, vamos aplicar a separação total entre Interface, Lógica e Dados.

Atividades

  1. Criar o ProdutoController para gerenciar a lista de produtos.
  2. Criar a classe Produto no model.
  3. Criar um console "View" (ou interface simples) que solicita os dados ao usuário.
  4. Garantir que a View peça ao Controller para salvar ou listar, sem mexer no Model diretamente.

Entrega

  • Código organizado nas 3 pastas (model, view, controller).
  • Relato sobre a dificuldade de separar as responsabilidades.

Projeto 08 - Minha Primeira Janela Swing 🎨

Criação da interface visual básica para a aplicação.

Atividades

  1. Criar uma classe herdando de JFrame.
  2. Configurar título, tamanho e operação de fechamento.
  3. Adicionar um JButton centralizado.
  4. Adicionar um ActionListener que exiba um "Olá!" ao clicar no botão.

Entrega

  • Print da janela aberta.
  • Código da classe MinhaJanela.

Projeto 09 - Formulário de Dados Básicos 🏗️

Construção de um formulário de cadastro funcional com validação simples.

Atividades

  1. Adicionar JLabel e JTextField para Nome e E-mail.
  2. Adicionar um botão "Salvar".
  3. Ao clicar em salvar, validar se os campos não estão vazios.
  4. Exibir os dados em um JOptionPane de informação.

Entrega

  • Código da classe da tela de cadastro.
  • Print da validação de campo vazio funcionando.

Projeto 10 - Seleção de Preferências 🎛️

Uso de componentes de seleção e organização com layouts.

Atividades

  1. Criar um formulário de "Pesquisa de Perfil".
  2. Usar JCheckBox para interesses (Programação, Design, Redes).
  3. Usar JRadioButton para nível de experiência (Iniciante, Pleno, Sênior).
  4. Organizar os campos usando GridLayout.

Entrega

  • Código da tela organizado por painéis.
  • Print da tela exibindo as seleções feitas pelo usuário.

Projeto 11 - Interface com Abas e Listagem 📑

Organização avançada com JTabbedPane e JTable.

Atividades

  1. Criar uma janela com duas abas: "Cadastro" e "Relatório".
  2. Na aba Relatório, adicionar uma JTable.
  3. Criar um botão na aba Cadastro que adicione os dados digitados diretamente na JTable da outra aba.
  4. Adicionar uma barra de menu (JMenuBar) com a opção "Sair".

Entrega

  • Código da tela com abas e lógica da tabela.
  • Print demonstrando a transição entre as abas.

Projeto 12 - Criando a Base de Dados 🗄️

Modelagem e criação física do banco de dados relacional.

Atividades

  1. Instalar o SQLite Browser (ou usar terminal).
  2. Criar o arquivo meusistema.db.
  3. Executar o comando SQL para criar a tabela produto com ID auto-incremento.
  4. Inserir manualmente 5 registros de teste no banco.

Entrega

  • Print do SQLite Browser exibindo a tabela e os dados.
  • O arquivo do banco de dados (.db).

Projeto 13 - Fábrica de Conexões 🔌

Implementação da ponte segura entre o Java e o SQLite.

Atividades

  1. Criar a classe ConexaoDB usando o padrão Singleton ou apenas métodos estáticos.
  2. Implementar o método getConexao() que retorna uma java.sql.Connection.
  3. Tratar as exceções de banco de dados com try-catch.
  4. Criar um método main simples apenas para testar se a conexão abre e fecha sem erros.

Entrega

  • Código da classe de conexão.
  • Console exibindo "Conectado com sucesso!".

Projeto 14 - CRUD Completo com DAO 💾

Implementação da camada de persistência para a entidade Produto.

Atividades

  1. Criar a classe ProdutoDAO.
  2. Implementar os métodos salvar, listar, atualizar e excluir.
  3. Usar PreparedStatement em todas as queries.
  4. Criar um programa de teste (Console) que execute as 4 operações em sequência.

Entrega

  • Código da classe ProdutoDAO.
  • Print do console provando que o registro foi inserido, alterado e deletado.

Projeto 15 - Blindando o Sistema 🛡️

Refatoração do sistema focando em segurança e tratamento de erros.

Atividades

  1. Revisar todos os campos de texto para garantir que não há concatenação de SQL.
  2. Implementar uma classe de Log simples que escreva erros em um arquivo .txt.
  3. Adicionar mensagens personalizadas ao usuário quando o banco de dados estiver inacessível.
  4. Experimentar o Debug da IDE para acompanhar o fluxo de um INSERT.

Entrega

  • Código refatorado com tratamentos de erro robustos.
  • Exemplo do arquivo de log gerado após um erro simulado.

Projeto 16 - Sistema Completo Final 🚀

Consolidação de todos os módulos em um software desktop real.

Atividades

  1. Escolher um dos temas sugeridos (Vendas, Biblioteca, etc).
  2. Desenvolver a interface visual com Swing (Menus, Abas, Tabelas).
  3. Implementar a lógica no Controller e os dados no Model.
  4. Garantir persistência real no banco de dados via DAO.
  5. Criar o arquivo README.md do seu projeto.

Entrega

  • Link do repositório ou arquivo compactado com o projeto completo.
  • Documentação simplificada do sistema.

Quizzes

🧠 Quizzes de Fixação

Lista completa das 20 unidades de quizzes organizadas em 5 módulos didáticos.

🧠 Quiz 01 – Introdução ao Ecossistema Java Backend ☕

  1. Qual é o conceito fundamental e objetivo principal de Introdução ao Ecossistema Java Backend ☕?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Introdução ao Ecossistema Java Backend ☕?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Introdução ao Ecossistema Java Backend ☕, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Introdução ao Ecossistema Java Backend ☕?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Introdução ao Ecossistema Java Backend ☕ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Introdução ao Ecossistema Java Backend ☕, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Introdução ao Ecossistema Java Backend ☕?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Introdução ao Ecossistema Java Backend ☕ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Introdução ao Ecossistema Java Backend ☕ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Introdução ao Ecossistema Java Backend ☕ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 02 – Spring Boot: Primeiros Passos 🌱

  1. Qual é o conceito fundamental e objetivo principal de Spring Boot: Primeiros Passos 🌱?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Spring Boot: Primeiros Passos 🌱?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Spring Boot: Primeiros Passos 🌱, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Spring Boot: Primeiros Passos 🌱?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Spring Boot: Primeiros Passos 🌱 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Spring Boot: Primeiros Passos 🌱, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Spring Boot: Primeiros Passos 🌱?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Spring Boot: Primeiros Passos 🌱 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Spring Boot: Primeiros Passos 🌱 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Spring Boot: Primeiros Passos 🌱 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 03 – Injeção de Dependências e IoC 💉

  1. Qual é o conceito fundamental e objetivo principal de Injeção de Dependências e IoC 💉?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Injeção de Dependências e IoC 💉?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Injeção de Dependências e IoC 💉, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Injeção de Dependências e IoC 💉?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Injeção de Dependências e IoC 💉 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Injeção de Dependências e IoC 💉, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Injeção de Dependências e IoC 💉?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Injeção de Dependências e IoC 💉 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Injeção de Dependências e IoC 💉 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Injeção de Dependências e IoC 💉 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 04 – Estrutura de Projeto e Camadas 🏗️

  1. Qual é o conceito fundamental e objetivo principal de Estrutura de Projeto e Camadas 🏗️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Estrutura de Projeto e Camadas 🏗️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Estrutura de Projeto e Camadas 🏗️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Estrutura de Projeto e Camadas 🏗️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Estrutura de Projeto e Camadas 🏗️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Estrutura de Projeto e Camadas 🏗️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Estrutura de Projeto e Camadas 🏗️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Estrutura de Projeto e Camadas 🏗️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Estrutura de Projeto e Camadas 🏗️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Estrutura de Projeto e Camadas 🏗️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 05 – Criando APIs REST com Spring Web 📡

  1. Qual é o conceito fundamental e objetivo principal de Criando APIs REST com Spring Web 📡?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Criando APIs REST com Spring Web 📡?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Criando APIs REST com Spring Web 📡, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Criando APIs REST com Spring Web 📡?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Criando APIs REST com Spring Web 📡 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Criando APIs REST com Spring Web 📡, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Criando APIs REST com Spring Web 📡?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Criando APIs REST com Spring Web 📡 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Criando APIs REST com Spring Web 📡 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Criando APIs REST com Spring Web 📡 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 06 – Modelagem de Dados com JPA/Hibernate 🗄️

  1. Qual é o conceito fundamental e objetivo principal de Modelagem de Dados com JPA/Hibernate 🗄️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Modelagem de Dados com JPA/Hibernate 🗄️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Modelagem de Dados com JPA/Hibernate 🗄️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Modelagem de Dados com JPA/Hibernate 🗄️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Modelagem de Dados com JPA/Hibernate 🗄️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Modelagem de Dados com JPA/Hibernate 🗄️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Modelagem de Dados com JPA/Hibernate 🗄️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Modelagem de Dados com JPA/Hibernate 🗄️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Modelagem de Dados com JPA/Hibernate 🗄️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Modelagem de Dados com JPA/Hibernate 🗄️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 07 – Spring Data JPA e Repositories 📥

  1. Qual é o conceito fundamental e objetivo principal de Spring Data JPA e Repositories 📥?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Spring Data JPA e Repositories 📥?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Spring Data JPA e Repositories 📥, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Spring Data JPA e Repositories 📥?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Spring Data JPA e Repositories 📥 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Spring Data JPA e Repositories 📥, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Spring Data JPA e Repositories 📥?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Spring Data JPA e Repositories 📥 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Spring Data JPA e Repositories 📥 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Spring Data JPA e Repositories 📥 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 08 – Relacionamentos entre Entidades 🔗

  1. Qual é o conceito fundamental e objetivo principal de Relacionamentos entre Entidades 🔗?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Relacionamentos entre Entidades 🔗?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Relacionamentos entre Entidades 🔗, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Relacionamentos entre Entidades 🔗?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Relacionamentos entre Entidades 🔗 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Relacionamentos entre Entidades 🔗, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Relacionamentos entre Entidades 🔗?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Relacionamentos entre Entidades 🔗 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Relacionamentos entre Entidades 🔗 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Relacionamentos entre Entidades 🔗 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 09 – Validação de Dados e Exceções ✅

  1. Qual é o conceito fundamental e objetivo principal de Validação de Dados e Exceções ✅?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Validação de Dados e Exceções ✅?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Validação de Dados e Exceções ✅, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Validação de Dados e Exceções ✅?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Validação de Dados e Exceções ✅ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Validação de Dados e Exceções ✅, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Validação de Dados e Exceções ✅?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Validação de Dados e Exceções ✅ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Validação de Dados e Exceções ✅ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Validação de Dados e Exceções ✅ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 10 – DTOs e Mapeamento de Objetos 📦

  1. Qual é o conceito fundamental e objetivo principal de DTOs e Mapeamento de Objetos 📦?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de DTOs e Mapeamento de Objetos 📦?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em DTOs e Mapeamento de Objetos 📦, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em DTOs e Mapeamento de Objetos 📦?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de DTOs e Mapeamento de Objetos 📦 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em DTOs e Mapeamento de Objetos 📦, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em DTOs e Mapeamento de Objetos 📦?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a DTOs e Mapeamento de Objetos 📦 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar DTOs e Mapeamento de Objetos 📦 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a DTOs e Mapeamento de Objetos 📦 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 11 – Testes com JUnit e Mockito 🧪

  1. Qual é o conceito fundamental e objetivo principal de Testes com JUnit e Mockito 🧪?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Testes com JUnit e Mockito 🧪?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Testes com JUnit e Mockito 🧪, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Testes com JUnit e Mockito 🧪?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Testes com JUnit e Mockito 🧪 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Testes com JUnit e Mockito 🧪, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Testes com JUnit e Mockito 🧪?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Testes com JUnit e Mockito 🧪 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Testes com JUnit e Mockito 🧪 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Testes com JUnit e Mockito 🧪 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 12 – Documentação de API com Swagger 📝

  1. Qual é o conceito fundamental e objetivo principal de Documentação de API com Swagger 📝?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Documentação de API com Swagger 📝?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Documentação de API com Swagger 📝, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Documentação de API com Swagger 📝?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Documentação de API com Swagger 📝 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Documentação de API com Swagger 📝, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Documentação de API com Swagger 📝?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Documentação de API com Swagger 📝 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Documentação de API com Swagger 📝 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Documentação de API com Swagger 📝 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 13 – Autenticação com Spring Security 🔐

  1. Qual é o conceito fundamental e objetivo principal de Autenticação com Spring Security 🔐?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Autenticação com Spring Security 🔐?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Autenticação com Spring Security 🔐, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Autenticação com Spring Security 🔐?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Autenticação com Spring Security 🔐 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Autenticação com Spring Security 🔐, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Autenticação com Spring Security 🔐?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Autenticação com Spring Security 🔐 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Autenticação com Spring Security 🔐 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Autenticação com Spring Security 🔐 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 14 – JWT e Proteção de Endpoints 🎫

  1. Qual é o conceito fundamental e objetivo principal de JWT e Proteção de Endpoints 🎫?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de JWT e Proteção de Endpoints 🎫?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em JWT e Proteção de Endpoints 🎫, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em JWT e Proteção de Endpoints 🎫?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de JWT e Proteção de Endpoints 🎫 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em JWT e Proteção de Endpoints 🎫, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em JWT e Proteção de Endpoints 🎫?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a JWT e Proteção de Endpoints 🎫 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar JWT e Proteção de Endpoints 🎫 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a JWT e Proteção de Endpoints 🎫 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 15 – Docker e Deploy 🐳

  1. Qual é o conceito fundamental e objetivo principal de Docker e Deploy 🐳?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Docker e Deploy 🐳?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Docker e Deploy 🐳, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Docker e Deploy 🐳?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Docker e Deploy 🐳 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Docker e Deploy 🐳, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Docker e Deploy 🐳?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Docker e Deploy 🐳 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Docker e Deploy 🐳 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Docker e Deploy 🐳 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 16 – Projeto Final: API Completa 🚀

  1. Qual é o conceito fundamental e objetivo principal de Projeto Final: API Completa 🚀?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Projeto Final: API Completa 🚀?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Projeto Final: API Completa 🚀, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Projeto Final: API Completa 🚀?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Projeto Final: API Completa 🚀 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Projeto Final: API Completa 🚀, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Projeto Final: API Completa 🚀?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Projeto Final: API Completa 🚀 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Projeto Final: API Completa 🚀 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Projeto Final: API Completa 🚀 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 17 – Spring Security 6+ com Autenticação Stateless JWT 🚀

  1. Qual o propósito principal de Spring Security 6+ com Autenticação Stateless JWT 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Spring Security 6+ com Autenticação Stateless JWT 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Spring Security 6+ com Autenticação Stateless JWT 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Spring Security 6+ com Autenticação Stateless JWT 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Spring Security 6+ com Autenticação Stateless JWT 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Spring Security 6+ com Autenticação Stateless JWT 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Spring Security 6+ com Autenticação Stateless JWT 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Spring Security 6+ com Autenticação Stateless JWT 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Spring Security 6+ com Autenticação Stateless JWT 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Spring Security 6+ com Autenticação Stateless JWT 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 18 – Processamento Assíncrono com Spring Events 🚀

  1. Qual o propósito principal de Processamento Assíncrono com Spring Events 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Processamento Assíncrono com Spring Events 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Processamento Assíncrono com Spring Events 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Processamento Assíncrono com Spring Events 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Processamento Assíncrono com Spring Events 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Processamento Assíncrono com Spring Events 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Processamento Assíncrono com Spring Events 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Processamento Assíncrono com Spring Events 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Processamento Assíncrono com Spring Events 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Processamento Assíncrono com Spring Events 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 19 – Consultas Avançadas com Spring Data JPA e QueryDSL 🚀

  1. Qual o propósito principal de Consultas Avançadas com Spring Data JPA e QueryDSL 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Consultas Avançadas com Spring Data JPA e QueryDSL 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Consultas Avançadas com Spring Data JPA e QueryDSL 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Consultas Avançadas com Spring Data JPA e QueryDSL 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Consultas Avançadas com Spring Data JPA e QueryDSL 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Consultas Avançadas com Spring Data JPA e QueryDSL 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Consultas Avançadas com Spring Data JPA e QueryDSL 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Consultas Avançadas com Spring Data JPA e QueryDSL 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Consultas Avançadas com Spring Data JPA e QueryDSL 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Consultas Avançadas com Spring Data JPA e QueryDSL 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 20 – Projeto Capstone: Microsserviço Java Spring Boot Completo 🚀

  1. Qual o propósito principal de Projeto Capstone: Microsserviço Java Spring Boot Completo 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Projeto Capstone: Microsserviço Java Spring Boot Completo 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Projeto Capstone: Microsserviço Java Spring Boot Completo 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Projeto Capstone: Microsserviço Java Spring Boot Completo 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Projeto Capstone: Microsserviço Java Spring Boot Completo 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Projeto Capstone: Microsserviço Java Spring Boot Completo 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Projeto Capstone: Microsserviço Java Spring Boot Completo 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Projeto Capstone: Microsserviço Java Spring Boot Completo 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Projeto Capstone: Microsserviço Java Spring Boot Completo 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Projeto Capstone: Microsserviço Java Spring Boot Completo 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

Slides

Configuração

Configuração do Ambiente 🛠️

Guias passo a passo para preparar sua máquina para o desenvolvimento Java Desktop.

  • :material-java: Desenvolvimento Java --- Instalação do JDK 17+ e configuração das variáveis de ambiente.

  • IDE (Ambiente) --- Configuração do IntelliJ IDEA ou Eclipse para projetos Java.

  • Banco de Dados --- Instalação do SQLite e ferramentas de visualização (DB Browser).

Setup 01: Android Studio 🤖

O Android Studio é a IDE oficial para o desenvolvimento Android.

1. Requisitos de Sistema

  • RAM: Mínimo 8GB (Sugerido 16GB+).
  • Espaço: Mínimo 10GB para IDE + SDKs.
  • Processador: Intel Core i5 ou equivalente.

2. Instalação

  1. Acesse o site oficial: developer.android.com/studio.
  2. Baixe a versão mais recente para o seu Sistema Operacional.
  3. Execute o instalador e escolha a opção "Standard" na configuração inicial.

3. Configurando o SDK

  • Após a instalação, vá em Settings > Languages & Frameworks > Android SDK.
  • Certifique-se de que a versão mais recente do Android (estável) esteja instalada.
  • Na aba SDK Tools, instale o "Android Emulator" e o "Intel x86 Emulator Accelerator (HAXM)" se estiver no Windows com Intel.

4. Criando um Emulador (AVD)

  1. Abra o Device Manager.
  2. Clique em Create Device.
  3. Escolha um dispositivo (ex: Pixel 7).
  4. Selecione uma imagem de sistema (ex: Level 34 - Android 14).
  5. Finalize e clique no "Play" para iniciar o celular virtual.

5. Solução de Problemas ⚠️

  • VT-x is disabled: Você precisa habilitar a virtualização na BIOS do seu computador.
  • Studio muito lento: Adicione a pasta do projeto e as pastas do Android SDK nas exclusões do seu Antivírus.

Setup 02: Xcode (iOS Foundation) 🍎

O Xcode é a ferramenta necessária para compilar e testar apps iOS.

Important

O Xcode requer um computador Mac (macOS).

1. Instalação

  1. Abra a App Store no seu Mac.
  2. Pesquise por Xcode.
  3. Clique em Obter/Instalar.
  4. Após o download, abra o Xcode para carregar os componentes adicionais do macOS.

2. Configurando Simuladores

  1. Vá em Settings > Platforms.
  2. Verifique se o componente "iOS" está baixado.
  3. Se não estiver, clique em "GET" para baixar a versão mais estável.

3. Comandos de Linha (CLI)

Para que ferramentas de automação funcionem, você precisa instalar os Command Line Tools: 

xcode-select --install

4. Opcional: CocoaPods

Muitos projetos iOS antigos ainda usam CocoaPods para dependências: 

sudo gem install cocoapods

5. Solução de Problemas ⚠️

  • Espaço em Disco: O Xcode é muito grande. Garanta pelo menos 40GB de espaço livre para ele e os simuladores.
  • Build Lento: Use simuladores de modelos mais simples (ex: iPhone SE) para poupar memória RAM se necessário.

Sobre

Sobre o Curso

🎓 Backend com Java e Spring Boot

Este curso foi projetado para capacitar desenvolvedores na criação de APIs backend robustas e escaláveis, focando no framework Spring Boot, persistência com JPA/Hibernate e arquitetura enterprise em camadas.

🎯 Objetivos do Curso

  • APIs REST Profissionais

    Construir endpoints REST seguindo boas práticas, com validação, tratamento de erros e documentação.

  • Arquitetura em Camadas

    Dominar a separação Controller/Service/Repository e Injeção de Dependências para código testável e sustentável.

  • Persistência de Dados

    Implementar persistência real com JPA/Hibernate e Spring Data, incluindo relacionamentos entre entidades.

  • Segurança de APIs

    Proteger endpoints com Spring Security e autenticação JWT, seguindo práticas de mercado.

📚 O Que Você Vai Aprender

Módulo 1 – Fundamentos do Spring

  • Ecossistema Java Backend e Spring Boot
  • Injeção de Dependências e Inversão de Controle (IoC)
  • Estrutura de projeto em camadas (Controller/Service/Repository)

Módulo 2 – APIs REST e Persistência

  • Criação de APIs REST com Spring Web
  • Modelagem de dados com JPA/Hibernate
  • Spring Data JPA e Repositories
  • Relacionamentos entre entidades

Módulo 3 – Qualidade e Documentação

  • Validação de dados e tratamento de exceções
  • DTOs e mapeamento de objetos
  • Testes unitários e de integração com JUnit e Mockito
  • Documentação de API com Swagger/OpenAPI

Módulo 4 – Segurança e Produção

  • Autenticação e autorização com Spring Security
  • JWT e proteção de endpoints
  • Docker e deploy de aplicações Spring Boot

🛠️ Metodologia

Foco 100% prático baseado em projetos (PBL). Cada aula introduz um novo conceito que é imediatamente aplicado na evolução de uma API real, culminando em um sistema completo ao final do curso.

Pronto para dominar o Backend com Java? Começar Agora

Roadmap do Projeto 🗺️

Este documento descreve a evolução do aprendizado ao longo das 16 aulas.

graph TD
    A1[Aula 01: Introdução] --> A2[Aula 02-05: Fundamentos OO]
    A2 --> A3[Aula 06-07: Arquitetura MVC]
    A3 --> A4[Aula 08-11: Interfaces GUI]
    A4 --> A5[Aula 12-15: Banco de Dados/DAO]
    A5 --> A6[Aula 16: Projeto Final 🚀]

📈 Marcos do Aprendizado

  1. Marco 1: Pensamento OO (Aulas 01-05)

Capacidade de abstrair problemas reais em classes e objetos.

  1. Marco 2: Organização Profissional (Aulas 06-07)

Aplicação de padrões de mercado para estruturação de software.

  1. Marco 3: Domínio da Interface (Aulas 08-11)

Criação de janelas e componentes que interagem com o usuário.

  1. Marco 4: Persistência Robusta (Aulas 12-15)

Integração segura com bancos de dados relacionais.

  1. Marco Final: O Desenvolvedor Desktop (Aula 16)

Entrega de um sistema completo e funcional.

Materiais Extras 📚

Recursos recomendados para aprofundar seus conhecimentos em Desenvolvimento Desktop e Java.

🛠️ Ferramentas

📖 Documentação Oficial

📺 Canais Recomendados

  • Loiane Groner (Java e POO)
  • Curso em Vídeo (Java Básico e Moderno)

Tip

Use fones de ouvido e foco total nas aulas práticas. A prática é o que leva à perfeição no desenvolvimento de software! 😊

🏷️ Índice de Tags Didáticas

Navegue pelas aulas, exercícios e projetos do curso organizados por temas, tecnologias e conceitos fundamentais:

tags.md:145-167/name

Versão para Impressão

Esta página foi gerada automaticamente para impressão.