DEV Community: Determinado 96

Um resumo sobre o padrão de projeto Adapter

Determinado 96 — Tue, 07 Apr 2026 17:46:13 +0000

Analogia

Imagine que você tem um carregador de celular 🇧🇷 (tomada brasileira), mas viajou para os Estados Unidos 🇺🇸 e lá a tomada é diferente.

O carregador funciona
A energia funciona
Mas… eles não encaixam!

O que você faz?

Você usa um adaptador de tomada. Esse adaptador não muda o carregador nem a tomada — ele só faz os dois conseguirem se conectar (faz uma tradução).

O Adapter faz duas coisas que não são compatíveis conseguirem trabalhar juntas.

Exemplo simples

pagar(valor) // sistema espera algo assim (tomada us)

fazerPagamento(valor) // você tem algo assim (tomara 🇧🇷)

// o adapter faz as duas coisas que não são compatíveis conseguirem trabalhar
class AdapterPagamento {
  constructor(servico) {
    this.servico = servico;
  }

  pagar(valor) {
    this.servico.fazerPagamento(valor);
  }
}

O Adapter pode ser bidirecional?

Na maioria dos casos, você só precisa de uma direção:

Sistema → Adapter → Código existente

Porque existe um lado dominante (o sistema que define o padrão).

Quando vira bidirecional?

Quando você tem dois sistemas que precisam conversar entre si, e cada um fala um idioma” diferente.

Sistema A usa: pagar(valor)
Sistema B usa: fazerPagamento(valor)
A → B precisa de um Adapter
B → A precisa de outro Adapter

Exemplo completo

https://github.com/determinado96/Design-patterns/blob/main/src/structural/adapter/index.ts

Um resumo sobre coesão e SRP

Determinado 96 — Mon, 06 Apr 2026 17:23:09 +0000

O que é uma classe coesa?

Uma classe coesa é aquela que tem apenas uma responsabilidade.
Classes coesas são menores, mais organizadas, fáceis de manter e reutilizar.

Exemplo de classe com baixa coesão

class CalculadoraDeSalario {
  calcula(funcionario) {
    if (funcionario.cargo === "DESENVOLVEDOR") {
      return this.dezOuVintePorcento(funcionario);
    }

    if (funcionario.cargo === "DBA" || funcionario.cargo === "TESTER") {
      return this.quinzeOuVinteCincoPorcento(funcionario);
    }

    throw new Error("Funcionário inválido");
  }

  dezOuVintePorcento(funcionario) {
    if (funcionario.salarioBase > 3000) {
      return funcionario.salarioBase * 0.8;
    }
    return funcionario.salarioBase * 0.9;
  }

  quinzeOuVinteCincoPorcento(funcionario) {
    if (funcionario.salarioBase > 2000) {
      return funcionario.salarioBase * 0.75;
    }
    return funcionario.salarioBase * 0.85;
  }
}

Problemas dessa classe

A classe precisa saber todos os cargos.
Muitos ifs → sempre que surgir um novo cargo, a classe precisa ser alterada.
As regras de cálculo não podem ser reutilizadas facilmente.
A classe tem mais de uma responsabilidade (decidir o cargo + calcular o salário).

Ou seja, baixa coesão e alto acoplamento.

O ideal seria cada regra de cálculo estar em uma classe separada. Isso aumenta a coesão e facilita reutilização e manutenção.

Por que essa classe é difícil de reutilizar?

Imagine que você queira reutilizar apenas a regra dezOuVintePorcento() em outro lugar do sistema.

Você não consegue usar só o método, porque ele está dentro da classe CalculadoraDeSalario.

Então você é obrigado a:

Instanciar a classe
Criar um objeto funcionário
Passar o funcionário
Só então usar o método

Ou seja, para reutilizar uma regra de cálculo, você precisa levar a classe inteira junto.

Isso é um sinal claro de baixa coesão, porque a classe está fazendo coisas demais.

Exemplo de classe refatorada com alta coesão

class Cargo {
  calculaSalario(salarioBase) {
    throw new Error("Método deve ser implementado pela subclasse");
  }
}

class Desenvolvedor extends Cargo {
  calculaSalario(salarioBase) {
    return salarioBase > 3000
      ? salarioBase * 0.8
      : salarioBase * 0.9;
  }
}

class Dba extends Cargo {
  calculaSalario(salarioBase) {
    return salarioBase > 2000
      ? salarioBase * 0.75
      : salarioBase * 0.85;
  }
}

class Tester extends Cargo {
  calculaSalario(salarioBase) {
    return salarioBase > 2000
      ? salarioBase * 0.75
      : salarioBase * 0.85;
  }
}

const RegrasPorCargo = {
  DESENVOLVEDOR: new Desenvolvedor(),
  DBA: new Dba(),
  TESTER: new Tester()
};

class CalculadoraDeSalarioRefatorada {
  calcula(funcionario) {
    const regra = RegrasPorCargo[funcionario.cargo];

    if (!regra) {
      throw new Error("Funcionário inválido");
    }

    return regra.calculaSalario(funcionario.salarioBase);
  }
}

const funcionario2 = {
  cargo: "DESENVOLVEDOR",
  salarioBase: 3500
};

const calculadora2 = new CalculadoraDeSalarioRefatorada();

console.log(calculadora2.calcula(funcionario2));

Primeiro passo para entender a refatoração

Antes da refatoração, a classe CalculadoraDeSalario mudava por dois motivos:

Quando surgia um novo cargo
Quando surgia uma nova regra de cálculo

Ou seja, a classe tinha mais de um motivo para mudar, o que quebra o SRP (Single Responsibility Principle).

Se observarmos os métodos de cálculo, mesmo sendo diferentes, todos têm o mesmo formato:

Recebem o salário
Aplicam uma regra
Retornam o salário calculado

Ou seja, todos seguem a mesma abstração.
Então a ideia da refatoração é criar uma classe para cada regra de cálculo, todas com o mesmo método calculaSalario().

O que ganhamos com isso?
Cada regra fica isolada
Uma mudança em uma regra não afeta as outras
As classes ficam menores
As classes ficam mais coesas
O sistema fica mais fácil de manter
Podemos adicionar novos cargos sem alterar código existente

Agora cada classe tem apenas um motivo para mudar: a sua própria regra de cálculo.

Por que não separar em pequenos métodos?

Se separamos um método grande em pequenos métodos não teremos reuso isolado.

Referência

Este exemplo e a ideia de refatoração foram inspirados no livro: Orientação a Objetos e SOLID para Ninjas - Projetando classes flexíveis - MAURÍCIO ANICHE

Um resumo sobre tipos de Parâmetros em REST

Determinado 96 — Mon, 06 Apr 2026 03:17:47 +0000

Tipos de parâmetros

Em APIs REST existem 3 tipos principais de parâmetros:

Tipo	Onde fica	Para que serve
Path Param	URL	Identificar recurso
Query Param	URL	Filtrar / paginar / ordenar
Body	Corpo da requisição	Enviar dados

Path Parameter (req.params)

Parâmetro que vai na URL e serve para identificar um recurso específico (usuário, linha na tabela com base num id).

Exemplo:

GET /chamados/6 PUT /chamados/6 DELETE /chamados/6

Pode ter mais que um?

Sim, um por segmento da URL.

GET /usuarios/10/chamados/6

Quando usar?

Situação	Exemplo
Buscar 1 registro	`/chamados/6`
Atualizar	`/chamados/6`
Deletar	`/chamados/6`
Recurso relacionado	`/usuarios/10/chamados/6`

Query Parameter (req.query)

Parâmetro que vai depois do ? na URL e serve para filtrar ou consultar dados.

Exemplo:

GET /chamados?status=aberto GET /chamados?prioridade=alta GET /chamados?page=2&limit=10 GET /chamados?status=aberto&prioridade=alta

Quando usar?

Situação	Exemplo
Filtro	`?status=aberto`
Paginação	`?page=2`
Limite	`?limit=10`
Ordenação	`?order=prioridade`
Busca	`?search=mouse`

Body Parameter (req.body)

Dados enviados no corpo da requisição (normalmente JSON).

Usado em:

Método	Uso
POST	Criar
PUT	Atualizar
PATCH	Atualizar parcial

Body Json

{ "titulo": "Mouse quebrado", "descricao": "Meu mouse parou de funcionar", "prioridade": "ALTA" }

Body também vem de FORMS

Quando você envia um form HTML, os dados também vão no body, não na query.

Um resumo sobre Fake Delay – Protegendo contra User Enumeration

Determinado 96 — Sun, 05 Apr 2026 23:12:39 +0000

O que é Fake Delay?

Fake delay é um atraso intencional adicionado em respostas do sistema para evitar que atacantes descubram informações sensíveis apenas pelo tempo de resposta.

Problema comum: sistemas podem responder mais rápido ou mais lento dependendo do dado solicitado, permitindo que alguém deduza informações privadas (como usuários existentes, senhas ou recursos).
Solução: introduzir um tempo de resposta uniforme, mesmo quando a ação falha, garantindo que nenhuma informação seja revelada pelo tempo.
Analogia: é como ficar sempre no mesmo ritmo de atendimento, independentemente de o pedido estar correto ou errado, para que ninguém consiga adivinhar o que acontece “por trás do balcão”.

Um resumo dos motivos para utilizar os commits antes das operações de E/S

Determinado 96 — Sun, 05 Apr 2026 22:31:08 +0000

O que são operações de E/S?

São todas as operações em que um computador envia ou recebe dados para algum lugar fora dele mesmo. Um exemplo comum em sistemas é o envio de e-mails, que envolve comunicação com servidores externos.

Por que fazer o commit antes do envio de e-mail?

Operações de E/S podem demorar ou falhar (ex.: timeout, problemas de rede). Desta forma, manter a E/S dentro de uma transação deixa o banco aberto por mais tempo, aumentando risco de:

Deadlocks.
Travamentos.
Inconsistência de dados (ex.: o e-mail é enviado, mas o commit falha).

Fazendo o commit antes da operação de E/S, garantimos que:

O banco de dados já está atualizado.
A operação de E/S não bloqueia nem compromete a transação.

Um resumo sobre JWT Token

Determinado 96 — Sun, 05 Apr 2026 22:20:27 +0000

O que é JWT Token?

JWT é um token usado para autenticação e autorização em aplicações web. Ele permite que o usuário faça login uma vez e depois apenas envie o token nas próximas requisições.

Analogia: É como se você se cadastrasse em um clube, pagasse a mensalidade e recebesse uma carteirinha; depois, basta mostrar a carteirinha para entrar sempre, sem precisar pagar ou se cadastrar novamente.

Estrutura do JWT

O JWT tem três partes: HEADER.PAYLOAD.SIGNATURE

Header: contém o tipo do token e o algoritmo.
Payload: contém os dados do usuário.
Signature: assinatura para garantir que o token não foi alterado.

Exemplo:

{
  "alg":"HS256",
  "typ":"JWT"
}
{
  "id":18,
  "tipo":"USUARIO",
  "iat":1775408838,
  "exp":1775412438
}

Como funciona o fluxo com JWT numa aplicação?

Usuário faz login.
Servidor gera o token com os dados do usuário.
Servidor envia o token para o cliente.
Cliente envia o token nas próximas requisições.
Middleware valida o token.
Middleware coloca os dados necessários em req.user.
A rota usa os dados necessários que estão em req.user.

Boas práticas com Token

Não colocar senha no token.
Não colocar dados sensíveis.
Sempre definir expiração (exp).
Usar HTTPS.
Usar Refresh Token.