DEV Community: Crystian Lefundes

Guia de S.O.L.I.D. com Java

Crystian Lefundes — Mon, 29 Apr 2024 21:03:52 +0000

SOLID é importante para qualquer linguagem de programação que adote o paradigma de orientação a objetos, eles facilitam o processo de desenvolvimento, como por exemplo na manutenção e escalabilidade do código, visando boas práticas e melhorando a vida útil de nós programadores. Este post é focado para quem não sabe sobre o significado de SOLID e também para quem sabe mas procura um exemplo na linguagem Java, não irei focar no paradigma de orientação a objetos pois não é foco, porém, se você não conhece, é importante que visite este link para que compreenda melhor este post.

O que é SOLID?

SOLID é um acrônimo idealizado por Micheal Feathers que unificou os princípios da orientação a objetos apresentados inicialmente por Robert C Martin, mais conhecido como "Uncle Bob" em seu artigo chamado "The principles of OoD" de 1995, a sigla significa:

Mais abaixo irei explicar com detalhes o que cada letra dessas significa tanto na teoria quanto na prática com Java, explorando exemplos também com imagens.

S – Single Responsability Principle (Princípio da Responsabilidade Única)

Este princípio diz que cada método, função ou classe, deve ter uma responsabilidade única, ou seja, deve ter um único objetivo.

Como a imagem acima demonstra, neste princípio, cada um tem uma única função, sendo uma má prática alguma classe ou método fazer mais de uma coisa ao mesmo tempo, vamos ver o exemplo em código, imaginando um cenário de um método que gera senhas, verifica e salva no banco de dados:

public String geraVerificaESalvaSenha() {
  // Implementação do código...
}

Problemática

Apesar de ter um nome que diz exatamente o que o método faz, como uma boa prática de código limpo, o método faz muitas coisas ao mesmo tempo, se alguma dessas etapas estiverem com bug, fica mais difícil de identificar, é importante que separe tudo para que não se tenha dupla ou mais funções.

Solução

Separar cada etapa do método acima em diferentes métodos.

public String gerarSenha() {
  // Implementação do código...
}

public void verificarSenha(String senha) {
  // Implementação do código...
}

public void salvarSenha(String senha) {
  // Implementação do código...
}

Com isso, é mais fácil de identificar um possível erro que venha a acontecer, podendo até mais facilmente no futuro separar estes métodos para diferentes classes.

Uma forma de identificar se um método está fazendo mais de uma função é se atentar ao seu nome, como no exemplo acima, para classes, é importante prestar atenção se seus métodos implementados condizem com sua abstração, como por exemplo:

public class Copo {

  public void notificarEstado() {
     // Implementação do código... 
  }

  public void limpar() {
    // Implementação do código...
  }

  public void encher() {
    // Implementação do código...
  }

  public void esvaziar() {
    // Implementação do código...
  }

}

Problemática

Podemos ver no exemplo acima que temos métodos que não precisam estar implementados nesta classe, como por exemplo, notificarEstado para saber se um copo está vazio ou cheio ou o método limpar que serve para limpar o copo, estes métodos não fazem sentido na abstração de um Copo, pois abragem muito mais coisas.

Solução

Delegar os métodos que não fazem parte de uma abstração para uma outra que faça mais sentido, como podemos ver abaixo:

public class Notificação {
  public void notificar() {
     // Implementação do código... 
  }
}

public class LavaLoucas {
  public void limpar() {
     // Implementação do código... 
  }
}

public class Copo {
  public void encher() {
    // Implementação do código...
  }

  public void esvaziar() {
    // Implementação do código...
  }
}

Por mais que as classes sejam bem pequenas inicialmente, é mais fácil para expandir e podermos implementar outras classes que possam utilizar da notificação e de serem limpos também, assim a classe Copo fica responsável somente por aquilo que faz sentido para sua abstração.

O – Open-Closed Principle (Princípio Aberto-Fechado)

Este princípio diz que suas classes e métodos/funções devem estar abertos para extensões e fechados para modificações, ou seja, se você quer realizar adições as suas classes/métodos, não é recomendável que se mexa em seu comportamento, isso evita que gere possíveis bugs a cada código novo adicionado.

A imagem acima representa o nosso exemplo que veremos logo abaixo.

public class CLT {
  public int salario() {
    // Implementação do código...
  }
}

public class Estagio {
  public int bolsaAuxilio() {
    // Implementação do código...
  }
}

public class FolhaDePagamento {
  private int saldo;  

  public int calcular(Object funcionario) {
    if (funcionario instanceof CLT) {
      this.saldo = ((CLT) funcionario).salario();;
    } else if (funcionario instanceof Estagio) {
      this.saldo = ((Estagio) funcionario).bolsaAuxilio();
    }
  }
}

Problemática

Neste exemplo acima, a medida que formos adicionando novos tipos de funcionários, novas verificações seriam necessárias e estaríamos mudando o comportamento do método.

Solução

Podemos observar que tanto o funcionário CLT quanto o estagiário, recebem uma remuneração, sendo assim, podemos simplificar os dois como uma interface que atenda os dois, deste jeito:

public interface Funcionario {
  int remuneracao();
}

public class CLT implements Funcionario {

  @Override
  public int remuneracao() {
    // Implementação do código...
  }
}

public class Estagio implements Funcionario {

  @Override
  public int remuneracao() {
    // Implementação do código...
  }
}

public class FolhaDePagamento {
  private int saldo;

  public int calcular(Funcionario funcionario) {
    this.saldo = funcionario.remuneracao();
  }
}

Com a criação desta simples interface, foi possível que simplificássemos nosso método calcular podendo assim receber qualquer tipo de funcionário, basta que implemente a interface Funcionário criando o método de remuneração, sendo assim, não precisa ser alterado caso queiramos adicionar mais tipos de funcionários.

L – Liskov Substitution Principle (Princípio da Substituição de Liskov)

A ideia deste princípio surge de uma cientista americana chamada Barbara Liskov que diz que as classes derivadas devem ser substituíveis pelas suas classes bases.

Esta ideia é a mesma da herança, a classe-filha deve ter/fazer tudo que a sua classe-mãe tem/faz, podendo ser substituída, não criando bugs por não ter implementado.

Para este princípio, trouxe um exemplo de um mediaplayer que tem como objetivo reproduzir qualquer tipo de mídia, um áudio, vídeo, etc.

public class MediaPlayer {
  public void reprodruzir() {
    System.out.println("Reproduzindo mídia...");
  }
}

public class Mp3Player {
  public void reprodruzir() {
    System.out.println("Reproduzindo som...");
  }
}

public class Mp4Player {
  public void reprodruzir() {
    System.out.println("Reproduzindo vídeo...");
  }
}

Veja que podemos alternar entre as classes dos players de mp3 e mp4 que irão fazer a mesma função que sua classe-mãe e podem ser substituídas pela sua classe base.

I – Interface Segregation Principle (Princípio da Segregação de Interface)

O princípio da segregação de interface diz que uma classe filha não pode ser forçada a implementar métodos dos quais ela não irá utilizar.

Podemos ver mais abaixo, um exemplo onde temos um robô e um humano que irão executar um trabalho, classe essa que foi definida para que ambos executem estas tarefas, já que são suas filhas.

public interface Trabalho {
  void comecarATrabalhar();

  void almocar();

  void carregarBateria();

  void terminarTrabalho();
}

public class Robo implements Trabalho {
  @Override
  public void comecarATrabalhar() {
    // Implementação do código...
  }

  @Override
  public void almocar() {
    return null;
  }

  @Override
  public void carregarBateria() {
    // Implementação do código...
  }

  @Override
  public void terminarTrabalho() {
    // Implementação do código...
  }
}

public class Humano extends Trabalho {
  @Override
  public void comecarATrabalhar() {
    // Implementação do código...
  }

  @Override
  public void almocar() {
    // Implementação do código...
  }

  @Override
  public void carregarBateria() {
    return null;
  }

  @Override
  public void terminarTrabalho() {
    // Implementação do código...
  }
}

Problemática

Existem coisas que não são feitas por humanos como carregar a bateria e nem um robô que iria almoçar, ou seja, não é recomendado que se tenha métodos que retornem nulo pois foram forçados a serem implementados.

Solução

Basta que determine os métodos que apenas serão usados por todos e deixem os mais especifícos para que sejam exclusivos de suas implementações, como podemos ver abaixo:

public class Trabalho {
   public void comecarATrabalhar() {
      // Implementação de código...
   }

   public void terminarTrabalho() {
      // Implementação de código...
   }
}

public class Robo extends Trabalho {
   public void carregarBateria() {
     // Implementação de código...
   }
}

public class Humano extends Trabalho {
    public void almocar() {
      // Implementação de código...
    }
}

D – Dependecy Inversion Principle (Princípio da Inversão de Dependência)

Este princípio se baseia na ideia de que abstrações não devem depender de detalhes e sim os detalhes que devem depender de abstrações.

Esta definição pode ser reescrita de outra forma, como, módulos de alto nível não devem de módulos de baixo de baixo nível, ambos devem depender de abstrações.

Caso não tenha ficado claro ainda, abaixo temos um exemplo.

Neste exemplo, temos um serviço que envia e-mails utilizando uma biblioteca chamada JavaMailSender.

public class EmailService {
  private final JavaMailSender mailSender;

  public EmailService(JavaMailSender mailSender) {
      this.mailSender = mailSender;
  }

  public void enviarEmail(String emailTo, String subject, String body) throws MailException {
      SimpleMailMessage message = new SimpleMailMessage();
      message.setTo(emailTo);
      message.setSubject(subject);
      message.setText(body);

      mailSender.send(message);
  }
}

Problemática

O problema desse código está na dependência na biblioteca JavaMailSender, imagine que a biblioteca seja descontinuada ou qualquer outro tipo de problema, precisáriamos reescrever toda a classe para trocar esta biblioteca, trocar para o Amazon SES, mailgun.

Solução

Basta adicionar uma interface que faz o JavaMailSender conversar com o serviço criando o método por ele necessário, agora se quisermos trocar para uma implementação utilizando Amazon SES ou mailgun, bastaria criar outra classe que implementasse esta interface chamada EmailSenderGateway.

public interface EmailSenderGateway {
    void enviarEmail(String emailTo, String subject, String body);
}

public class GmailSender implements EmailSenderGateway {

    private final JavaMailSender mailSender;

    public EmailService(JavaMailSender mailSender) {
        this.mailSender = mailSender;
    }

    @Override
    public void enviarEmail(String emailTo, String subject, String body) throws MailException {
        SimpleMailMessage message = new SimpleMailMessage();
        message.setTo(emailTo);
        message.setSubject(subject);
        message.setText(body);

        mailSender.send(message);
    }
}

public class EmailService {
    private final EmailSenderGateway emailSenderGateway;

    public EmailService(EmailSenderGateway emailSenderGateway) {
        this.emailSenderGateway = emailSenderGateway;
    }

    public void enviarEmail(String emailTo, String subject, String body) {
        this.emailSenderGateway.enviarEmail(emailTo, subject, body);
    }
}

Com isso, o serviço não depende de ninguém e nem conhece as implementações mais acima, apenas conhece a interface, assim como suas implementações, tornando o código mais flexível.

Saiba mais

Deixo aqui uns vídeos para caso você queira se aprofundar mais no assunto, recomendo que leia os livros do Robert C Martin, o "Uncle Bob", pois ele difundiu muito dessas ideias e é referência na nossa área.

Referências

Alura
Trybe
Ugonna Thelma

Entenda o básico de API

Crystian Lefundes — Wed, 03 Apr 2024 23:45:38 +0000

Se você ouve bastante sobre programadores falando sobre API's e fica perdido no assunto, este post é para você.

O que significa API?

Uma API é usada para definir um conjunto de regras, protocolos que devem ser seguidos, estabelecidos por um software para que usem suas funcionalidades, sem que haja a necessidade de saber como o software foi implementado, criando um meio de comunicação entre dois softwares para conectar soluções e serviços sem que você precise reinventar a roda.

Existem vários tipos de API, como SOAP, REST, RPC, WebSocket, GraphQL, porém, o foco deste post será na mais comumente usada, a API REST.

Tipos de API

API pública

Como o nome diz, qualquer pessoa pode usar, está aberta ao público, podendo conter algum tipo de custo envolvido com limites definidos ou não, alguma autorização.

API privada

São API's internas, usadas somente dentro de uma determinada empresa, conectando seus sistemas, dados, etc.

API de parceiros

Este tipo de API compartilha acesso para desenvolvedores externos autorizados, colaborando com as parcerias de negócios entre empresas e tendo mais controle sobre quem utiliza.

Segurança

Entendemos que as API's trocam informações, dados através de requisições e isso pode ser perigoso se não controlado, limitado, afinal, existem dados que somente pessoas autorizadas podem ter acesso, porém como isso é feito?

Token

Usado para autorização e fazer a identificação do usuário, verificação de direito de acesso ao realizar uma chamada a API.

Chave

Apesar de não ser tão segura quanto o token, a chave é usada para verificar e identificar qual aplicação esta realizando a chamada da API, garantindo que ela tenha os direitos de acesso necessário, monitorando o seu uso.

API REST

API REST, também conhecida como RESTful, é uma API que segue os princípios de design REST, uma sigla para Representational State Transfer, ou em português, Transferência de Estado Representacional, abaixo vemos seus 6 princípios de design:

Interface uniforme: As informações passadas da API para a origem da solicitação devem ser sempre iguais, padronizadas, não importando quem a chame, contendo todas as informações necessárias, além de hipertexto e hipermídia disponíveis caso necessário.
Desacoplamento cliente-servidor: O cliente e o servidor devem ser independentes um do outro, ou seja, nenhum dos dois interagem entre si, apenas utilizando métodos HTTP (Hypertext Transfer Protocol) para troca de dados solicitados.
Sem estado definido: O servidor não tem permissão para armazenar nenhum dado referente a chamada do cliente, tendo as solicitações separadas e desconectadas.
Armazenamento em cache: Realizar armazenamento de recursos, dados, em cache, otimizando o desempenho das chamadas entre cliente e servidor. É importante que os servidores contenham informações sobre as permissões de cache.
Arquitetura de sistemas em camadas: É uma arquitetura que faz com que o cliente nem o servidor saibam se estão se comunicando com a aplicação final ou intermediária, pois em uma chamada pode existir diversos intermediários para que a solicitação chegue ao servidor final e no cliente que realizou a chamada, como balanceamento de carga, segurança, etc.
Código sob demanda (opcional): Possibilita o envio de código executável, ou recurso estático do servidor para cliente, sendo assim, o código só é executado sob demanda do cliente.

Vamos ao que interessa, afinal, como funciona uma API REST? Bom, a resposta para essa pergunta é até que simples, veja a imagem abaixo:

Neste tipo de API, a comunicação é feita através de solicitações, requisições a API utilizando métodos do protocolo HTTP. Abaixo, descrevo os principais para criar, ler, atualizar e deletar, o famoso CRUD (Create, Read, Update and Delete):

GET: Utilizado para obter um recurso, um dado em especifico, utilizando uma identificação ou até mesmo uma lista deles quando solicitado.
POST: Este é utilizado para envio de informações, arquivos e cadastro de alguns dados para o servidor.
PUT: Atualiza, edita somente as informações ou arquivos que foram enviados ao servidor, utilizando uma identificação, tendo que claro, já terem sido criadas anteriormente, caso não especifique, poderá acabar atualizando tudo, precisa ser usado com cuidado.
DELETE: Este deleta os dados ou arquivos que estavam presentes no servidor, seja especifico utilizando uma identificação do que quer que seja deletado ou deletar tudo de uma vez, assim como o PUT, precisa ser utilizado com cuidado.

Importante ressaltar que existem outros métodos como HEAD, TRACE, CONNECT e OPTIONS, porém, irei focar somente nesses, caso queira saber mais sobre clique neste link para acessar o texto de autoria de Rene Junior.

Utilizado os métodos para se comunicar e definir o que você quer com o servidor, ele te retornará uma resposta ao que foi solicitado, seja positiva ou não, o mais comum será receber a resposta no formato JSON (Javascript Object Notation), pois é facilmente lido por nós humanos e por máquinas também.

Exemplos de API's

Ainda está perdido? Muito texto técnico? Então irei te dar dois exemplos, o primeiro será onde você usa API e não repara e o outro é como funciona uma API comparando com uma situação no mundo fora da internet, como por exemplo ir ao restaurante, vamos aos exemplos:

Exemplo de API na internet

Este exemplo é bem simples, sabe quando você está fazendo um login ou cadastro em algum site ou aplicativo?

Quando você faz o login ou se cadastra utilizando outros apps, redes sociais, você não sabe mas está utilizando uma API.

A integração de mapas utilizando a API do Google Maps em sites de imóveis, reserva de quarto de hotel, é muito grande também.

Exemplo de API em um restaurante

Depois que escutei sobre este exemplo, minha percepção de mundo mudou, atribuir situações como analogia a API me fez entender muito melhor e vou explicar para você:

Imagine que você está em um restaurante como cliente (client), você olha o cardápio e deseja fazer um pedido (request com método GET), chama o garçom (API), deixa claro o que você quer, ele vai até a cozinha (server) e trás o que foi pedido de volta para a sua mesa (response).

Eu tirei este exemplo de um vídeo muito bem feito pelo Mayk Brito, do canal da Rocketseat, recomendo que assista para se aprofundar no assunto:

Onde encontrar API’s

Existem muitas API’s espalhadas pela internet, vou deixar algumas aqui para você ter uma visão mais prática depois de todo esse assunto teórico.

Rapid API
Public APIs

Existem diversas, como do nosso próprio governo, correios, de redes sociais. Essa parte é com você, pesquise sobre public API’s no Google e se divirta, é ótimo para você que não sabe ainda que tipo de projetos quer fazer ou seguimento de indústria.

Depois de tanta teoria você deve estar querendo saber como por tudo isso em prática, eu trouxe dois exemplos para você, de minha autoria, um em Golang e outro em Java com Spring Boot, sinta-se livre para contribuir com os projetos caso sinta interesse, aqui estão:

Exemplo em Java
Exemplo em Golang

Referências

AWS
IBM
Red Hat