DEV Community: Armando Tadeu

Introdução a Arquitetura Baseada em Eventos

Armando Tadeu — Thu, 02 Mar 2023 00:18:49 +0000

Nos tempos atuais, em que vivemos em contato constante e até "frenético" com sistemas digitais online e interconectados, é muito comum que em apenas um dia, por pessoa, sejam realizadas diversas ações através de aplicativos de celular, computadores pessoais, caixas eletrônicos, meios de pagamentos, etc.

Cada ação realizada em um sistema computacional online pode desencadear uma série de efeitos colaterais, por exemplo, a compra de um produto em um e-commerce, vai necessitar comunicar um setor para gerar nota fiscal, vai precisar avisar o setor de estoque para separar o pedido, a situação do pedido precisa ser informada para o cliente, o pedido precisa ser enviado para a transportadora, etc. E cada ação dessa, pode desencadear outras ações como efeitos colaterais.

Vamos utilizar esse contexto de ação para definir o que é evento. Evento é uma situação desencadeada por essas ações, o evento é uma situação que já ocorreu (está no passado) e deixa (na maioria das vezes) efeitos colaterais.

Nesse mundo em que o tempo é precioso, a resposta para as ações (que causam os eventos) devem ser rápidas, para que as pessoas não fiquem paradas esperando um retorno que talvez irá passar por diversos setores diferentes e possa demorar.

A demanda por respostas rápidas e eficientes traz a necessidade de uma estrutura capaz de lidar com um grande fluxo de eventos transitando na internet e que precisam ser captados e processados quase que instantaneamente.

A arquitetura baseada em eventos é uma forma de planejar e estruturar os sistemas para que lidem com eventos de forma rápida, eficiente e desacoplada.

Tipos de evento

Existem alguns tipos de eventos que são muito importantes e podem nortear a arquitetura, influenciando na escolha das ferramentas adequadas para trabalhar com o tipo específico.

Event Notification

Esse tipo de evento é muito comum em sistemas que lidam com grande quantidade de microserviços que se comunicam freneticamente, pois, o event notification é uma mensagem bem enxuta que contêm apenas o essencial para comunicação fluir, por exemplo, uma série de microserviços de grande sistema de entrega de comida só precisam saber da mudança de status do pedido para tomar algumas ações, então o event notification pode ser simplesmente um json {"pedido": 123, "status": "saiu para entrega"}

Event Carried State Transfer

Esse tipo de evento é utilizado quando é necessário enviar mensagens muito grandes, em que estejam carregadas de dados, a mensagem é mais completa, por exemplo, {"acao": "cadastro_cliente", "cliente": {...}, "origem": {...}, "produtos_de_interesse": []}, esses eventos são comumente utilizados para desencadear ações para alimentar sistemas analíticos em que seja necessário grande quantidade de informações.

Event Sourcing

Esse tipo de evento é normalmente utilizado para que seja capturado e armazenado em banco de dados, gerando histórico dos eventos, deixando-os disponíveis para serem consumidos posteriormente para diversas situações, por exemplo, armazenar histórico para auditoria, armazenar histórico para backup de eventos, armazenar eventos para que posteriormente outras aplicações possam vir a consumir e realizar outras ações baseadas neles, etc.

Event Collaboration

Esse é um conceito de uma abordagem utilizando a arquitetura de eventos em que uma série de sistemas que dependem de informações um do outro estão gerando eventos de todas as ações (mudança de estado) que acontecem no contexto deles, fazendo com que nenhum dos sistemas tenha que ficar solicitando informação de outro, pois, ele recebe a informação a cada evento que acontece, pois, está configurado para ouvir e consumir todos os eventos necessários para que tome suas ações de forma mais autônoma. Esse conceito visa construir um fluxo de trabalho distribuido em que os sistemas evoluam de forma independente

Referência: Confluent Event Collaboration

Conclusão

Esse texto visa compartilhar estudos e entendimentos introdutórios sobre um assunto muito quente no mercado de tecnologia, e trazer tópicos para despertar interesse em aprofundamento.

A arquitetura baseada em eventos está sendo muito utilizada nas empresas que utilizam sistemas distribuídos e microserviços, alguns tópicos e ferramentas interessantes que fazem parte desse contexto: Kafka, RabbitMQ, Sistemas de Mensageria, CQRS.

Fundamentos da Engenharia de Dados

Armando Tadeu — Wed, 24 Aug 2022 03:06:00 +0000

Uma pessoa que deseja ingressar na carreira de engenharia de dados certamente irá se deparar com inúmeras fontes de conteúdo que podem deixar o caminho um pouco confuso por alguns motivos como:

Pesquisas sobre o assunto endereçam muito a materiais sobre ferramentas como Spark, Airflow, Python, SQL, etc.;
As áreas e carreiras relacionadas a dados vem crescendo muito por conta do big data e as definições muitas vezes não ficam muito claras (mistura-se muita coisa de engenharia, análise, ciência de dados, machine learning, etc.);
As pessoas que atuam na área podem viver contextos diferentes, pois as empresas podem ter visões diferentes sobre as funções de um engenheiro de dados;

Então, um ponto focal unânime sobre como ingressar bem nessa carreira é conhecer e ficar bom nos assuntos fundamentais, aqueles que trazem a base para qualquer segmento dentro da carreira de engenharia de dados.

Nesse texto, gostaria de compartilhar um pouco de minhas anotações sobre os fundamentos da engenharia de dados, de forma que possa ajudar quem esteja começando, a entender alguns assuntos, conceitos e terminologias ou apenas ajude a formar um índice sobre os assuntos fundamentais.

Espero que tenham uma ótima leitura!

Um pouco sobre OLTP

Esse conceito é importante porque representa uma forma antiga muito conhecida dentro da área de TI de gerenciamento de dados que ficou consolidada durante muitos anos, é utilizada nos dias atuais e serve como fonte de dados para diversas tarefas que um engenheiro de dados realiza.

OLTP é o conceito que define o uso de banco de dados relacional para realização de processamento de leitura, escrita e atualização de dados em grande escala de forma transacional (garantia de que um processamento sendo realizado por um usuário X não interfira em outro processamento realizado por usuário Y), online e atômico (garante que um conjunto de transações interligadas sejam concluídas com sucesso ou nenhuma delas é efetivada).

É difícil imaginar um sistema computacional comercial que não utilize um OLTP, pois, a grande maioria tem em sua arquitetura um banco de dados relacional para gerenciar o processamento de suas informações.

Um OLTP engloba algumas características que são importantes para um sistema como:

Ter um banco de dados relacional unificado organizado em tabelas que possuem atributos e podem se relacionar entre si;
Definir algumas regras de negócio nas tabelas, afim de ter um controle e organização das informações no banco de dados;
Disponibilizar características essenciais de processamento (leitura, escrita e atualização) de forma segura e organizada;
Possuí integração com diversos ecossistemas já consolidados no universo da TI, diversas ferramentas já maduras para o trabalho, além de muita literatura e conteúdo;

Entendendo que o OLTP possuí muitos dados relacionados ao negócio de uma empresa e que hoje a utilização de dados está cada vez mais rápida e volumosa, aparecem algumas desvantagens nesse sistema porque OLTP não foi desenhado para atender uma frenética carga de operações ao mesmo tempo e nem é otimizado para realizar análises.

E nos dias atuais existe a necessidade de que os dados estejam otimizados para análises e estejam preparados para serem consumidos e utilizados de diversas formas estratégicas, onde, muitas operações de leitura são realizadas e muitas pessoas interessadas em alavancar os negócios, criar oportunidades e entender as informações obtidas através dos dados querem trabalhar.

E então surge a necessidade de uma outra estratégia que engloba leitura constante e análise de dados para qual o OLTP não está preparado.

Nesse cenário, existe um importante tipo de profissional que lida com a resolução dessa necessidade, já sabe que profissional é esse ?

Uma pequena lupa no conceito de ACID

Todos os bancos relacionais são projetados para implementar o conceito denominado ACID (Atomicidade, Consistência, Isolamento e Durabilidade).

Atomicidade: Garantia de que toda operação dentro de uma transação seja efetivada por completo, se algum processo ali dentro da transação falhar, nada é efetivado, em resumo é tudo ou nada, por exemplo, em um sistema de vendas, se toda vez que uma venda é efetivada, preciso inserir os dados da venda e dar baixa no estoque, se alguma dessas operações que fazem parte da mesma transação falhar, nenhuma operação deve funcionar.
Consistência: Garantia de que uma transação seja realizada de acordo com o estado em que os dados se encontram no banco, por exemplo, uma operação de baixa no estoque que retirará 1 produto do estoque de 50, tem que ser garantida e o estoque deve diminuir para 49.
Isolamento: Garantia de que 2 usuários do banco de dados não realizem transações (que possam interferir na atomicidade e consistência) ao mesmo tempo que geralmente são inserção e atualização, é criado um bloqueio para isolar uma transação e só libera o banco para novas transações assim que a outra terminar.
Durabilidade: Garantia de que toda operação realizada no banco de dados que foi efetivada seja permanente, ou seja, o banco de dados é um local de armazenamento, é preciso garantia de que os dados estarão lá.

O conceito de ACID rege a implementação dos bancos de dados relacionais, a garantia desses 4 tópicos é o que norteia toda a estrutura de um sistema OLTP.

Em decorrência desses tópicos, existe também um conceito interessante dos bancos de dados relacionais que é o multi-versionamento.

Quando um usuário solicita uma operação de leitura, ou seja, realiza uma consulta no banco de dados, ele espera que o retorno sejam os dados mais atualizados possíveis, e se ele faz uma consulta no momento em que está ocorrendo uma transação de inserção, deve-se esperar toda a transação ocorrer para retornar a consulta ?

Nesse caso existe o conceito de multi-versionamento, onde criasse uma réplica do estado mais atual do banco antes do inicio da transação de inserção e a consulta recebe o retorno com maior performance sem esperar o término da transação que estava ocorrendo ao mesmo tempo da consulta.

Exemplos de banco de dados relacionais: MySQL, PostgreSQL, SQL Server, OracleDB, etc.

Uma solução para deficiência do OLTP: OLAP

Vimos que o OLTP é um sistema desenhado para lidar bem com e garantir o conceito de ACID e que ele não foi desenhado para prática de análise de dados.

Nos dias atuais, análise de dados é um tema extremamente quente e poderoso, pois, é através das análises que podemos trazer utilidade para os dados que são chamados hoje de "o novo petróleo".

Como os sistemas OLTP possuem diversas tabelas que se relacionam entre si e é um modelo que persiste os registros em forma de linhas (cada linha é um registro e possuí diversas colunas), na medida em que as consulta de análises vão ficando mais complexas buscando colunas especificas de registros que possuem N relacionamentos, a performance vai ficando mais baixa, as consulta são lentas e fica cada vez mais difícil de trazer os insights necessários.

Então surgiu o conceito de OLAP, que são sistemas desenhados para o trabalho analítico.

OLTP = Operacional, ACID.
OLAP = Analítico, colunar.

Os sistemas OLAP possuem a estrutura de armazenamento colunar

E como OLAP não é operacional, de onde vem os dados já que as interações de registros ficam em sistemas OLTP ?

Os dados vem justamente do OLTP (podem vir de outros lugares também) através de um sistema de pipeline que faz diversas consultas no OLTP e abastece o sistema OLAP de acordo com a necessidade dos analistas de dados.

Esse trabalho de trazer os dados para o OLAP é uma das responsabilidades do Engenheiro de Dados.

Conhecendo o conceito de ETL

Vimos que existe um processo que conecta os sistemas OLTP com os sistemas OLAP.

Esse processo é chamado de ETL, significa extrair, transformar e carregar (extract, transform, load).

O engenheiro de dados projeta esse processo de forma que faça as consultas necessárias para extrair os dados do OLTP e então existe um trabalho de transformar os dados para deixar de acordo com as necessidades das áreas de análises e então carregar os dados para os sistemas OLAP.

Esse processo é realizado de tempos em tempos (ex: 6h em 6h), para não sobrecarregar os sistemas OLTP.

A ideia é utilizar alguma ferramenta que possibilite realizar um trabalho agendado de tempos em tempos e outras ferramentas que auxiliam nos trabalhos de extração, transformação e carregamento.

Diferenças entre Engenharia de dados e Ciência de Dados

Apesar de fazer parte de um mesmo contexto (Dados e Big Data), entendo que são duas funções diferentes e complementares.

O Engenheiro de Dados trabalha para construir uma base sólida de recursos para que o Cientista de Dados possa atuar.

Sendo o engenheiro responsável por trabalhos de coleta, armazenamento, exploração e transformação de dados e o cientista encarregado de análises, identificação/rotulagem, treinamento de modelos, utilizar inteligência artificial para lidar com dados, etc.

Data Warehouse

Data Warehouse é o conceito que representa o nosso armazém de dados que é um conjunto grande de dados destinado à análises.

O Data Warehouse é um representante do sistema OLAP.

Estando na ponta de saída dos processos de ETL, o data warehouse recebe os dados que foram extraídos dos sistemas OLTP, transformados, modelados em estratégias específicas (ex: star schema ou snowflake schema) para otimizar as características de análises.

Como Data Warehouse é um conceito, é possível definir banco de dados tradicionais como um, aplicando-se características que representem um OLAP, porém, existem muitas tecnologias especificas e otimizadas para isso como Amazon Redshift, Snowflake, Oracle ADW, Google Big Query, etc.

Data Lake

Com o grande volume e variedade de dados sendo gerados o tempo todo, as organizações estão lidando com dados originados de seus próprios sistemas e/ou sistemas externos.

Existe alguns tipos de dados como:

Dados estruturados: Dados que tem um modelo definido e consistente, são dados que vem de sistemas de banco de dados relacional;
Dados semiestruturados: Possuem uma estrutura livre, como XML ou JSON;
Dados não-estruturados: São arquivos, imagens, áudios, que são dados que não possuem uma estrutura definida, não tem colunas, registros, etc.;

*Quando as organizações lidam com inúmeros fontes e tipos de dados, surge a necessidade de manter um estoque destinado apenas a armazenamento em que não seja necessário preocupação com algum tipo de processamento no primeiro momento.

Dessa forma, na medida em que for necessário, os analistas, engenheiros, cientistas vão poder recuperar esses dados e dar um devido processamento.

Surge a ideia de utilizar um disco de armazenamento que recebe arquivos (dumps de banco de dados, imagens, json, csv, txt, xml, etc.) e vão acumulando esses dados como um estoque.

Esse disco, onde estão armazenados arquivos que representam diversos dados vindos de diversas fontes recebe o nome de data lake.

Exemplos famosos de sistemas utilizados para data lake (amazon s3, google cloud storage, blob storage).

Governança de Dados

Uma organização que mantêm estruturas de big data certamente precisará de uma forma de manter o suporte necessário para que os donos dos dados (quem produz o dado) consiga utilizar os dados de acordo com a proposta do negócio.

A infraestrutura de TI é responsável por todo o sistema de frameworks e suporte para que os usuários e aplicações possam gerar e utilizar os dados, porém, a infra estrutura de TI não é dona dos dados.

Algumas diretrizes de governança de dados comumente aplicadas: catalogação de dados, definir e manter a qualidade dos dados, implementar politicas de privacidade e segurança, etc.

Computação Distribuída

A computação distribuída é um conceito relevante porque atualmente com o grande volume e variedade de dados transitando fica dificil lidar com o processamento desses dados em servidores com escala vertical porque todo o trabalho fica concentrado em uma única máquina.

A ideia de dividir para conquistar é muito interessante para esse contexto, distribuindo o volume em diversos servidores é possível trabalhar com o processamento de dados paralelamente.

A maioria dos serviços modernos (em cloud principalmente) utiliza os conceitos de computação distribuída.

Existem alguns conceitos que as tecnologias de computação distribuída conseguem implementar como processamento paralelo que favorece o processamento de um grande volume de dados, redundância de armazenamento para garantir consistência e/ou alta disponibilidade.

Referências

A maior parte desse texto foi baseado nos estudos do treinamento de Fundamentos da Engenharia de Dados disponível na comunidade The Plumbers

E um pouco do livro Fundamentals of Data Engineer

Introdução à Machine Learning

Armando Tadeu — Sat, 30 Jul 2022 00:02:00 +0000

O que é Machine Learning ?

Machine learning é a prática de aprender com dados, mas no caso, quem aprende são as máquinas.

É possível que um computador faça uma análise de uma imagem qualquer e seja capaz de indicar se aquela imagem é a de um animal ou de um ser humano, ou ainda, se é a pessoa X ou Y ?

Sim, isso é possível com a utilização de algoritmos de machine learning, onde são inseridos muitos dados de imagens de animais e seres humanos para que o computador aprenda o que é uma coisa ou outra criando um modelo que tem como função a capacidade de distinguir novas imagens.

Nos tempos atuais esse assunto está bem aquecido, porque estamos vivendo uma época onde os dados são produzidos em larga escala, as pessoas estão cada vez mais conectadas no mundo digital e produzindo dados a todo momento, esse cenário é o que chamam de Big Data.

Com uma grande quantidade de dados, começa a busca de como tirar valor deles, de como extrair conhecimento e utilizá-lo para evoluir, inovar, criar.

A técnica de machine learning esta totalmente relacionada a esse cenário de big data, porque essa grande quantidade de dados pode ser utilizada para ensinar as máquinas a simular a forma como humanos tomam decisões em determinadas situações e com isso, automatizar tarefas com essas decisões, auxiliar os seres humanos em análises para trazer mais conforto, habilitar o foco em outras tarefas que máquinas não precisem ou não possam fazer como por exemplo o relacionamento, a busca de mais conhecimento, a busca da verdade, as tomadas de decisões reais baseadas em conhecimento humano e de suas práticas e relações.

Falando um pouco mais da técnica de machine learning... Existem algumas categorias (que abrangem outras) utilizadas de acordo com determinado contexto. As categorias são:

Aprendizado supervisionado;
Aprendizado não supervisionado;
Aprendizado por reforço;

Aprendizado supervisionado

Vou imaginar uma situação hipotética e simples. Se eu tivesse uma loja de vídeo games e trabalhasse com a venda de 2 consoles concorrentes...

Tenho alguns clientes cadastrados em uma base de dados que compraram um dos consoles, esses clientes tem suas características como, idade, endereço, jogo preferido, etc. E de fato o vídeo game que comprou e se ele está satisfeito ou não com a sua escolha.

Eu gostaria de atender um novo cliente e reconhecer qual vídeo game (ou quais) ele provavelmente vai ficar satisfeito, eu cadastro os dados dele na minha base e por experiência, por já ter efetuado o cadastro de diversos outros clientes e aprendido alguns padrões das suas características relacionados a sua satisfação ou não com o vídeo game X ou Y, eu posso classificar esse novo cliente como satisfeito ou não com determinado vídeo game.

Com essas classificações eu posso entender melhor o meu público e fazer previsões com futuros possíveis clientes para fazer campanhas publicitárias direcionadas, com estoques do vídeo game X ou Y preparados para atende-los.

Um computador pode fazer essa tarefa, eu posso utilizar uma base de dados que possui características de determinado objeto ou situação com um objetivo explícito e aplicar em um algoritmo supervisionado, os dados e o objetivo vão ensinar a máquina a generalizar e ser capaz de receber a entrada de um novo registro, determinar o objetivo, fazer uma predição e classificar o novo registro.

Imaginando uma base de dados com registros de um modelo de carro, com características como marca, cor, comprimento, largura, altura, portas, motor, etc. E com o objetivo, a informação se ele é do modelo X ou não.

Posso inserir essa base em um algoritmo supervisionado e treiná-lo para que ao informar um novo registro de um modelo de carro, o algoritmo retorne se ele é do modelo X ou não.

Assim funciona o aprendizado supervisionado, o algoritmo precisa de dados em que seja informado características e o objetivo para assim, classificar novas entradas.

Esse tipo de aprendizado é bastante utilizado em reconhecimento de imagens, diagnósticos, previsões de mercado, etc.

Aprendizado não supervisionado

Se eu quisesse pegar uma base de dados contendo registros com diversas características e criar grupos de registros que sejam semelhantes, eu poderia analisar uma base de dados de animais e criar grupos de animais aquáticos, terrestres, híbridos, aéreos , etc. Poderia utilizar um algoritmo de aprendizado não supervisionado.

No aprendizado não supervisionado, eu não tenho a definição do que é o registro, somente suas características, e ao inserir os dados de uma base no algoritmo, vou ter uma saída de agrupamentos baseado nas características semelhantes, gerando um modelo treinado que irá informar qual grupo um novo registro pertence analisando suas características.

Esse tipo de aprendizado é bastante utilizado em sistemas de recomendação, segmentação de clientes, etc.

Por exemplo, em um site de e-commerce eu poderia identificar a compra ou o interesse do cliente e verificar o grupo em que o produto está inserido e assim recomendar outros produtos do mesmo grupo.

Aprendizado por reforço

Aqui existe um determinado agente como por exemplo, em um jogo de vídeo game geralmente existe alguns NPCs (personagem não jogável, controlado por computador), imagino esse NPC realizando algumas tarefas dentro do ambiente do jogo, como andar até um ponto específico, "lançar uma bola de fogo", etc. Na medida que o NPC vai realizando ações existe um sistema que vai atribuindo ou diminuindo pontos desse agente, para que ele aprenda que determinada ação é ruim (tira pontos) e outra é boa (ganha pontos).

Com bastante treinamento e uma boa quantidade de pontos acumulados, o agente pode tomar decisões por conta própria em um cenário.

Algumas aplicações: Decisões em real-time, IA para vídeo games, etc.

Coleta e preparo de dados

A utilização de machine learning depende de dados, mas eles não estão sempre prontos para serem utilizados, é preciso uma coleta e preparação, tem que existir o trabalho de análise em diversas bases para identificar possíveis situações de utilização e assim preparar os dados para se encaixarem nos algoritmos e para isso, é necessário entender qual algoritmo será utilizado. Essa tarefa de preparação não é simples e rápida, demanda muito conhecimento e trabalho, e é atribuição de cientistas de dados, estes são os grandes agentes da prática de machine learning, por isso, uma alta demanda no cenário atual.

Existem muitos desafios nessa tarefa, entre eles, a identificação de dados com potencial de gerar algum valor importante, no big data, muitos dados armazenados e espelhados podem não ter relevância para determinadas soluções.

Atuar com machine learning faz parte da profissão de um cientista de dados e essa prática faz parte do "guarda-chuva" de assuntos que a inteligência artificial cobre.

Existe muita coisa a ser explorada nesse segmento, muitas tendências, muitas perguntas e eu acredito que ainda irão surgir grandes inovações baseadas em machine learning e/ou auxiliadas por ela.

4 pilares da Orientação a Objetos em Python

Armando Tadeu — Fri, 05 Nov 2021 23:01:22 +0000

A linguagem Python é considerada uma linguagem multiparadigma, ou seja, possibilita que o desenvolvedor programe utilizando diferentes tipos de programação como procedural, funcional, imperativa e orientação a objetos.

A programação orientada a objetos é um dos paradigmas mais utilizados atualmente, porque através dela é possível organizar a arquitetura do programa trazendo uma perspectiva mais perto do mundo real, considerando as coisas (abstratas ou concretas) do mundo real como objetos no sistema, que interagem entre si e dão vida ao fluxo do programa.

E para garantir uma programação orientada a objetos eficiente, existem alguns pilares desse paradigma que podemos utilizar em programas escritos com Python.

1º Pilar: Abstração

Na programação orientada a objetos, a construção dos objetos é baseada em uma Classe que representa as características daquele objeto.

Abstração é o princípio de criar uma classe que contenha atributos e métodos que são comuns a outras classes e que podem servir como base para serem herdados.

Você abstrai características comuns a N classes e fornece uma classe abstrata que pode ser herdada e servir de base para as demais.

Nesse conceito, podemos mencionar também a questão de fornecer uma classe abstrata como um contrato para que quando herdada garanta que as classes filhas irão implementar os métodos necessários, dessa forma, proteger o nosso código dando a certeza da existência e implementação do método.

Para ilustrar a abstração, imagine um sistema bancário, onde uma Conta bancária possa ser de diversos tipos, como, Conta poupança, Conta Corrente, Conta PJ, etc.

Cada tipo de conta, ainda é uma Conta, e as características comuns a todos os tipos de contas podem ser Abstraídas em uma classe abstrata. Por exemplo:

from abc import ABCMeta, abstractmethod

class Conta(metaclass=ABCMeta):
    _numero = "00000"
    _titular = "root"
    saldo = 0

    @abstractmethod
    def __init__(self, numero: str, titular: str, saldo: float):
        self._numero = numero
        self._titular = titular
        self.saldo = saldo

    @abstractmethod
    def sacar(self, value: float):
        pass

    @abstractmethod
    def depositar(self, value: float):
        pass

    @abstractmethod
    def exibir_saldo(self):
        pass

Dessa forma eu crio uma abstração do conceito de Conta e disponibilizo uma classe para ser herdada por outras classes que são do tipo Conta.

Obs: Uma classe abstrata não deve ser utilizada diretamente, deve ser vista e utilizada como uma base para outras classes como ContaCorrente, ContaPoupanca, etc.

2º Pilar: Encapsulamento

O princípio de encapsulamento consiste em "esconder" a parte funcional dos objetos de forma que quem estiver utilizando não tenha que conhecer mais do que o necessário para utiliza-lo.

Por exemplo, ao dirigir um carro, se quisermos que o carro pare de andar, não é preciso, conhecer toda a mecânica do funcionamento por dentro do veículo para que possamos frear. Basta pisar no freio, o freio é o encapsulamento do comportamento de frear de um carro.

Na orientação a objetos, estruturamos as classes de forma a encapsular toda regra de negócio e parte funcional relacionada a classe dentro de métodos e atributos, de forma que quem utilize, apenas diga oque quer fazer.

Por exemplo:

class Biblioteca:

    def __init__(self, livros_disponiveis) -> None:
        self.livros_disponiveis = livros_disponiveis

    def exibir_livros(self):
        for livro in self.livros_disponiveis:
            print(livro)

    def emprestar_livro(self, livro):
        print(f'Você escolheu o livro: {livro}')
        if livro in self.livros_disponiveis:
            self.livros_disponiveis.remove(livro)
        else:
            print('Desculpe o livro não está disponível!')

    def devolver_livro(self, livro):
        self.livros_disponiveis.append(livro)
        print(f'Obrigado pro devolver o livro: {livro}')

Na classe biblioteca, temos os métodos que fornecem as regras de negócio para que o programa que for utilizar não precise conhecer oque está acontecendo ali dentro e sim possa simplesmente dizer:

// biblioteca me mostre os livros:
biblioteca.exibir_livros()

3º Pilar: Herança

A herança consiste em determinar que uma classe existe por si mesma, porém, ela é uma outra classe em sua essência... Por exemplo, uma ContaCorrente existe mas ela é uma Conta.

Quando a herança é utilizada, a classe que herda, automaticamente, possui os atributos e métodos definidos na classe da qual herdou.

Por exemplo, imagine que o sistema bancário tenha uma uma regra geral para deposito e exibição de saldo para todos os tipos de conta somente o saque muda de conta para conta. Nesse caso, podemos criar uma classe Conta com as características comuns das outras Contas, e as outras contas, irão herdar essas características:

class Conta():
    _numero = "00000"
    _titular = "root"
    saldo = 0

    def __init__(self, numero: str, titular: str, saldo: float):
        self._numero = numero
        self._titular = titular
        self.saldo = saldo

    def depositar(self, value: float):
        # Regra para fazer o depósito...

    def exibir_saldo(self):
        # Exiba o saldo...

# Para aplicar a herança em Python, basta referênciar a classe que se quer herdar entre parenteses:
class ContaPoupaca(Conta):

    def __init__(self, numero: str, titular: str, saldo: float):
        super().__init__(numero, titular, saldo)

    def sacar(self, value: float):
        if value <= self._saldo:
            self._saldo -= value
            return True

        return False

    def titular(self):
        return self._titular

    def numero(self):
        return self._numero

A classe ContaPoupaca herda tudo de Conta, ou seja, possui os métodos depositar e exibir_saldo e os atributos _numero, _titular e saldo e ainda pode implementar outros métodos e definir outros atributos que sejam só dela.

4º Pilar: Polimorfismo

O conceito do polimorfismo é permitir que comportamentos comuns a N tipos de classes possam ser definidos de forma especifica para cada classe.

Imagine que um sistema bancário, define que uma ContaCorrente e uma ContaPoupaca devem ter saldo, titular, numero da conta, um método para sacar, depositar e exibir o saldo, mas, cada classe tem suas próprias regras de negócio, por exemplo, na ContaCorrente, o saque vai ter algum tipo de desconto dependendo de onde for sacado e a ContaPoupanca o deposito vai ser salvo em outro tipo de saldo interno, etc.

A questão é, possuem comportamentos diferentes mas devem possuir os comportamentos porque ambas são Contas.

Por exemplo, eu posso criar uma classe abstrata chamada Conta e a partir dela definir quais são os atributos e comportamentos necessários para quem for herdar dela mas as regras de negócio cada classe implementa a sua maneira, com o caso aqui em que ContaPoupanca herda de Conta (classe abstrata) e implementa suas próprias regras de negócio (gerando o comportamento polimórfico das Contas):

from abc import ABCMeta, abstractmethod

class Conta(metaclass=ABCMeta):
    _numero = "00000"
    _titular = "root"
    _saldo = 0

    @abstractmethod
    def __init__(self, numero: str, titular: str, saldo: float):
        self._numero = numero
        self._titular = titular
        self._saldo = saldo

    @abstractmethod
    def sacar(self, value: float):
        pass

    @abstractmethod
    def depositar(self, value: float):
        pass

    @abstractmethod
    def exibir_saldo(self):
        pass


class ContaPoupanca(Conta):

    def __init__(self, numero: str, titular: str, saldo: float):
        super().__init__(numero, titular, saldo)

    def sacar(self, value: float):
        if value <= self._saldo:
            self._saldo -= value
            return True

        return False

    def depositar(self, value: float):
        if value > 0:
            self._saldo += value
            return True

        return False

    def exibir_saldo(self):
        return self._saldo

    def titular(self):
        return self._titular

    def numero(self):
        return self._numero


class BankingSystem:
    __contas = []

    def __gerar_numero_conta(self):
        numero = len(self.__contas) + 1
        return f"{numero:05}"

    def __checar_valor_positivo(self, value):
        if value <= 0:
            return False

        return True

    def criar_conta_poupanca(self, deposito_inicial: float, nome_titular: str):
        if self.__checar_valor_positivo(deposito_inicial) == False:
            print("Deposito Inicial deve ser maior que Zero!")
            return

        conta = Savingsconta(self.__gerar_numero_conta(), nome_titular, deposito_inicial)
        self.__contas.append(conta)
        print("Conta criada com sucesso!")
        print("Titular: ", conta.titular())
        print("Número da conta: ", conta.numero())
        print("Saldo: ", conta.exibir_saldo())

    def total_of_contas(self):
        print("contas: ", str(len(self.__contas)))

    def acessar_conta(self, nome_titular: str, conta_numero: str):
        contas = [acc for acc in self.__contas 
                    if acc.titular() == nome_titular and acc.numero() == conta_numero]
        if len(contas) == 0:
            print("Conta não existe!")
            return

        conta = contas[0]
        print("Digite 1 para sacar")
        print("Digite 2 para depositar")
        print("Digite 3 para exibir saldo")
        escolha_usuario = (int(input()))
        if escolha_usuario == 1:
            print("sacar")
            print("Digite o valor a sacar")
            value = float(input())
            if conta.sacar(value):
                print("Saque realizado com sucesso!")
            else:
                print("Problema ao sacar, verifique o saldo!")
        elif escolha_usuario == 2:
            print("DEPOSITAR")
            print("Digite o valor do depósito")
            value = float(input())
            if conta.depositar(value):
                print("Deposito realizado com sucesso!")
            else:
                print("Problema ao depositar, valor não permitido!")
        elif escolha_usuario == 3:
            print(conta.exibir_saldo())
        else:
            print("Escolha inválida!")

banking_system = BankingSystem()
while True:
    print("Digite 1 para criar uma conta poupança")
    print("Digite 2 para acessar a conta")
    print("Digite 3 para exibir o total de contas")
    print("Digite 0 para sair")
    escolha_usuario = (int(input()))
    if escolha_usuario == 1:
        print("CREATE")
        print("Digite o nome do titular da conta")
        nome_titular = input()
        print("Digite o deposito inicial")
        initial_deposit = float(input())
        banking_system.criar_conta_poupanca(initial_deposit, nome_titular)
    elif escolha_usuario == 2:
        print("ACCESS")
        print("Digite o name do titular da conta")
        nome_titular = input()
        print("Digite o conta numero")
        conta_numero = input()
        banking_system.access_conta(nome_titular, conta_numero)
    elif escolha_usuario == 3:
        banking_system.total_of_contas()
    elif escolha_usuario == 0:
        quit()
    else:
        print("Escolha inválida!")

Uma API REST com Spring

Armando Tadeu — Tue, 16 Feb 2021 23:00:24 +0000

Esse artigo foi elaborado em uma etapa de desafio do processo seletivo para o programa Orange Talents da Zup.

A tarefa aqui é descrever em formato de artigo, estilo blog post, sobre um projeto em Spring.

O passo a passo foi implementado e o código está aqui: lottery-orange-talents

Contexto

Descrever o passo a passo utilizado para a criação de uma API REST que fornece um sistema de loteria.

A API deverá gerar números aleatórios para a aposta do solicitante, cada número deve estar associado a um e-mail para identificar a pessoa que está concorrendo.

Essencialmente são 2 endpoints, um receberá o e-mail da pessoa e retornará um objeto de resposta com os números sorteados para a aposta e o outro endpoint deverá listar em ordem de criação todas as apostas de um soliciante (passando seu e-mail como parâmetro).

A implementação deverá ser descrita utilizando Java com o ecossistema Spring + Hibernate.

Implementação

Modelagem

Para começar a implementação de uma API REST, após os requisitos, é importante documentar a modelagem do sistema para nortear o desenvolvimento, descrevendo as classes, relacionamentos, etc.

Nesse contexto, irei utilizar modelagem de dados UML mesclando modelagem conceitual com modelagem lógica.

Conceitual = descreve as entidades do sistema independente de paradigma e tecnologia;
Lógica = descreve as entidades, relacionamentos e determina um paradigma como POO, relacional, etc.;

Gerando a aplicação Spring Boot

Para iniciar o projeto, irei utilizar o Spring initializr com as seguintes configurações:

Maven como gerenciador de dependências;
Versão 2.4.2 do Spring;
Java 11;

E adicionarei a dependência Spring Web para utilizar os recursos de uma aplicação web MVC, assim poderei ter acesso a anotações que me auxiliam a criar Controllers, Services, etc. e a aplicação ja poderá rodar em um servidor Apache Tomcat.

O pom.xml inicial ficará assim:

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>2.4.2</version>
  <relativePath/> <!-- lookup parent from repository -->
</parent>
<groupId>com.armandotdelcol</groupId>
<artifactId>lottery-api</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>lottery-api</name>
<description>Desafio Orange Talents</description>
<properties>
  <java.version>11</java.version>
</properties>
<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>
</dependencies>

<build>
  <plugins>
    <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
    </plugin>
  </plugins>
</build>

Padrão Camadas

Para essa aplicação irei utilizar um padrão de camadas, onde implementarei Entidades que representam as tabelas do banco de dados, Repositories que representam a camada de acesso aos dados, services que representam a camada que conversa com os controllers transferindo DTOs.

Criando as entidades

Criarei as entidades no pacote entities, começando pela entidade LotteryTicket.

As entidades serão utilizadas como modelos para a criação das tabelas no banco de dados, por isso, irei precisar adicionar uma forma do projeto Spring fazer o mapeamento das Classes entidades com o BD e preciso especificar qual o Banco de dados é para ele utilizar.

Para fazer o mapeamento utilizarei o Hibernate que é um ORM muito utilizado pela comunidade Java e que implementa as especificações da JPA (Java Persistence Api) que define os padrões a serem seguidos para urtilizar ORM em Java

No ecossistema Spring é muito simples utilizar o Hibernate, basta adicionar uma dependência e o Maven ira fazer o download de todas os Jars necessários para utiliza-lo, eis a dependência:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

Essa dependência inclui a JPA API, Implementação JPA com Hibernate como default, JDBC e outras bibliotecas necessárias.

Como banco de dados irei utilizar o H2 que é um banco de dados carregado em memória em tempo de execução, é bem leve e bom para ser utilizado em fase de desenvolvimento antes de conectar a um banco de dados "profissional".

Para utilizar o H2, eis a depedência a ser adicionada no pom.xml:

<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <scope>runtime</scope>
</dependency>

LotteryTicket

@Entity
@Table(name = "tb_lottery_tickets")
public class LotteryTicket implements Serializable {

    private static final long serialVersionUID = 1L;

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

    @Column(nullable = false)
    private Integer bet1;

    @Column(nullable = false)
    private Integer bet2;

    @Column(nullable = false)
    private Integer bet3;

    @Column(nullable = false)
    private Integer bet4;

    @Column(columnDefinition = "TIMESTAMP WITHOUT TIME ZONE")
    private Instant createdAt;

    public LotteryTicket() {
    }

    public LotteryTicket(Long id, Integer bet1, Integer bet2, Integer bet3, Integer bet4) {
        this.id = id;
        this.bet1 = bet1;
        this.bet2 = bet2;
        this.bet3 = bet3;
        this.bet4 = bet4;
    }

    // OMITIDO AQUI OS GETTERS AND SETTERS DE id, bet1, bet2, bet3 e bet4.

    public Instant getCreatedAt() {
        return createdAt;
    }

    @PrePersist
    public void prePersist() {
        createdAt = Instant.now();
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        LotteryTicket that = (LotteryTicket) o;
        return Objects.equals(id, that.id);
    }

    @Override
    public int hashCode() {
        return Objects.hash(id);
    }
}

Utilizei anotação @Entity da JPA para indicar que a classe é uma entidade, @Table para customizar o nome da tabela a ser criada, @id e @GeneratedValue para definir a chave primaria autoincrementavél, @Column para utilizar o nullable=false e não aceitar valores nulos...

Para o campo createdAt utilizei um Instant e defini sem timezone para ficar neutro de timezone e para setar a data de crição utilizei um método prePersist que com auxilio da anotação PrePersist da JPA irá salvar um Instant no momento da criação do registro.

Bettor

@Entity
@Table(name = "tb_bettors")
public class Bettor implements Serializable {

    private static final long serialVersionUID = 1L;

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

    @Column(nullable = false)
    private String email;

    public Bettor() {
    }

    public Bettor(Long id, String email) {
        this.id = id;
        this.email = email;
    }

    // OMITINDO GETTERS AND SETTERS E HASHCODE E EQUALS
}

Associações

Adionarei em LotteryTicket a referência para Bettor com a anotação @ManyToOne e @JoinColumn para definir a coluna de associação:

@ManyToOne
@JoinColumn(name = "bettor_id", nullable = false)
private Bettor bettor;

Adicionando os devidos Getters and Setters e colocando para instanciar via construtor também junto aos demais atributos.

Já em Bettor adicionei a anotação @OneToMany com a opção mappedBy referenciando o campo na tabela de tickets:

@OneToMany(mappedBy="bettor")
private Set<LotteryTicket> lotteryTickets;

Nesse caso como é um Set, não adicionei no construtor e nem coloquei um método Setter, apenas o Getter é o ideal para manipular o lotteryTickets...

Verificando a Interação com o BD H2

Nessa próxima etapa irei habilitar a criação automática das tabelas e fazer alguns testes salvando alguns registros nas tabelas...

Primeiro irei criar um perfil de tests em src/main/resources chamado application-test.properties com o seguinte conteúdo para habilitar a conexão com o H2:

spring.datasource.url=jdbc:h2:mem:testdb
spring.datasource.username=sa
spring.datasource.password=

spring.h2.console.enabled=true
spring.h2.console.path=/h2-console

e no arquivo application.properties:

spring.profiles.active=test

spring.jpa.open-in-view=false

Ativando o perfil de test e definindo que as transações com o BD serão feitas fechadas dentro das camadas service-repository não deixando as transações abertas na camada de view que no caso será o nosso controller.

Depois irei criar as interfaces da camada Repository utilizando a anotação da JPA para ter acesso a todos os métodos de interação com o banco dados já implementados e prontos para usar:

@Repository
public interface LotteryTicketRepository extends JpaRepository<LotteryTicket, Long> {
}

// E

@Repository
public interface BettorRepository extends JpaRepository<Bettor, Long> {
}

Para testar a interação com o banco de dados, irei criar um arquivo TestDBMain na raiz do pacote com o seguinte código:

public static void main(String[] args) {

    ApplicationContext applicationContext = new SpringApplicationBuilder(LotteryApiApplication.class)
            .web(WebApplicationType.SERVLET)
            .run(args);

    BettorRepository bettorRepository = applicationContext.getBean(BettorRepository.class);
    LotteryTicketRepository lotteryTicketRepository = applicationContext.getBean(LotteryTicketRepository.class);

    Bettor bettor1 = new Bettor();
    bettor1.setEmail("better1@gmail.com");
    bettorRepository.save(bettor1);

    Random betGenerator = new Random();
    LotteryTicket lotteryTicket1 = new LotteryTicket();
    lotteryTicket1.setBet1(betGenerator.nextInt(100));
    lotteryTicket1.setBet2(betGenerator.nextInt(100));
    lotteryTicket1.setBet3(betGenerator.nextInt(100));
    lotteryTicket1.setBet4(betGenerator.nextInt(100));
    lotteryTicket1.setBettor(bettor1);
    lotteryTicketRepository.save(lotteryTicket1);
}

Com a aplicação startada e acessando a url do H2 consigo verificar a criação dos registros e confirmar que a interação com o banco de dados está Ok. Agora vamos para implementação das outras camadas.

Dto

Irei criar uma classe para servir de molde de dados para transitar entre a camada de controller e a camada de service, pensei em criar um TicketLotteryDTO nesse formato:

public class LotteryTicketDTO implements Serializable {

    private static final long serialVersionUID = 1L;

    private Long id;
    private Integer bet1;
    private Integer bet2;
    private Integer bet3;
    private Integer bet4;
    private Bettor bettor;

    public LotteryTicketDTO() {
    }

    public LotteryTicketDTO(Long id, Integer bet1, Integer bet2, Integer bet3, Integer bet4, Bettor bettor) {
        this.id = id;
        this.bet1 = bet1;
        this.bet2 = bet2;
        this.bet3 = bet3;
        this.bet4 = bet4;
        this.bettor = bettor;
    }

    public LotteryTicketDTO(LotteryTicket entity) {
        this.id = entity.getId();
        this.bet1 = entity.getBet1();
        this.bet2 = entity.getBet2();
        this.bet3 = entity.getBet3();
        this.bet4 = entity.getBet4();
        this.bettor = entity.getBettor();
    }

    // OMITINDO OS GETTERS AND SETTERS
}

Services

Na camada services irei criar métodos publicos, um para inserir uma nova aposta no banco e outro para listar as apostas por email.

Precisarei usar os dois repositories já criados, por isso irei usar o recurso de injeção de dependências do Spring com a anotação @Autowired que já cuida de tudo pra mim e disponibiliza os repositories que preciso.

Tanto no método insert como no método findAllByEmail que irei criar vou precisar de uma busca no BD de Bettors por email, por isso precisarei fazer uma modificação no meu BettorRepository:

@Repository
public interface BettorRepository extends JpaRepository<Bettor, Long> {

  @Query("SELECT b FROM Bettor b WHERE b.email=:email")
  public Optional<Bettor> findByEmail(@Param("email") String email);

}

Esse novo método findByEmail não existe por default na implementação do JPA, por isso precisei criá-lo.

Minha classe LotteryTicketService ficou assim:

@Transactional
public LotteryTicketDTO insert(LotteryTicketDTO dto) {
    Random betGenerator = new Random();
    Bettor bettor = getOrCreateBettor(dto.getBettor().getEmail());
    LotteryTicket entity = new LotteryTicket();
    entity.setBet1(betGenerator.nextInt(100));
    entity.setBet2(betGenerator.nextInt(100));
    entity.setBet3(betGenerator.nextInt(100));
    entity.setBet4(betGenerator.nextInt(100));
    entity.setBettor(bettor);
    entity = lotteryTicketRepository.save(entity);
    return new LotteryTicketDTO(entity);
}

@Transactional
public List<LotteryTicketDTO> findAllByEmail(LotteryTicketDTO dto) {
    Optional<Bettor> obj = bettorRepository.findByEmail(dto.getBettor().getEmail());
    Set<LotteryTicket> lotteryTickets = obj.get().getLotteryTickets();
    List<LotteryTicketDTO> dtoList = lotteryTickets.stream().map(x -> new LotteryTicketDTO(x)).collect(Collectors.toList());
    return dtoList;
}

@Transactional
private Bettor getOrCreateBettor(String email) {
    Optional<Bettor> obj = bettorRepository.findByEmail(email);
    try {
        return obj.get();
    } catch (Exception e) {
        Bettor bettor = new Bettor();
        bettor.setEmail(email);
        return bettorRepository.save(bettor);
    }
  }

A anotação @Transactional indica para o Spring que aquele método faz uma interação com o BD em uma transação.

O método getOrCreateBettor garante que não crie um Bettor com email repetido para uma nova aposta e sim adicione apostas ao Bettor.

Controllers

A interação real entre servidor e cliente acontece aqui no controller:

@RestController
@RequestMapping(value = "/lottery_tickets")
public class LotteryTicketsController {

  @Autowired
  private LotteryTicketService lotteryTicketService;

  @GetMapping
  public ResponseEntity<List<LotteryTicketDTO>> findAllByEmail(@RequestBody LotteryTicketDTO dto) {
      List<LotteryTicketDTO> dtoList = lotteryTicketService.findAllByEmail(dto);
      return ResponseEntity.ok(dtoList);
  }

  @PostMapping
  public ResponseEntity<LotteryTicketDTO> insert(@RequestBody LotteryTicketDTO dto) {
      dto = lotteryTicketService.insert(dto);
      return ResponseEntity.ok().body(dto);
  }

}

A anotação @RestController garante que minha classe seja um controlador REST e @ResquestMapping permite que eu customize a rota de acesso pela URI.

Injeto o LotteryTicketService e crio dois métodos um POST para fazer a inserção de uma nova aposta e um GET para listar as apostas por email.

Ao retornar um LotteryTicketDTO ou uma lista deles, tenho um problema de recursão pois ao trazer o Bettor dentro do Json de LotteryTicketDTO, irá ficar tentanto acessar as apostas dentro do Bettor e Bettor dentro da aposta, etc. Para resolver isso adicionei a anotação @JsonIgnore no atributo lotteryTickets da entidade Bettor:

@JsonIgnore
@OneToMany(mappedBy="bettor")
@OrderBy("createdAt DESC")
private Set<LotteryTicket> lotteryTickets;

Por fim os testes finais, com a aplicação startada e um software de requisições RESTs como Insmnia posso fazer um POST:

http://localhost:8080/lottery_tickets:
JSON BODY:

{
    "bettor": {
        "email": "bettor1@gmail.com"
    }
}

Resposta:

{
  "id": 5,
  "bet1": 44,
  "bet2": 86,
  "bet3": 68,
  "bet4": 72,
  "bettor": {
    "id": 1,
    "email": "bettor1@gmail.com"
  }
}

E um GET:

http://localhost:8080/lottery_tickets:
JSON BODY

{
    "bettor": {
        "email": "bettor1@gmail.com"
    }
}

Resposta:

[
  {
    "id": 5,
    "bet1": 44,
    "bet2": 86,
    "bet3": 68,
    "bet4": 72,
    "bettor": {
      "id": 1,
      "email": "bettor1@gmail.com"
    }
  },
  {
    "id": 4,
    "bet1": 13,
    "bet2": 62,
    "bet3": 78,
    "bet4": 1,
    "bettor": {
      "id": 1,
      "email": "bettor1@gmail.com"
    }
  }
]

E assim fica a implementação de um sistema de Loteria (bem simplório) para explorar os recursos e funcionalidades de Java com Spring + Hibernate.

Extra

Tratamento de exceções

No método findAllByEmail do Service vai disparar um erro com status 500 caso o email informado não possua nenhum cadastro como Bettor. Para tratar isso criei uma exception no pacote services.exceptions:

public class ResourceNotFoundException extends RuntimeException{
  public ResourceNotFoundException(String message) {
      super(message);
  }
}

Modifiquei o método para capturar o erro e lançar essa exceção:

@Transactional
public List<LotteryTicketDTO> findAllByEmail(LotteryTicketDTO dto) {
    Optional<Bettor> obj = bettorRepository.findByEmail(dto.getBettor().getEmail());
    Set<LotteryTicket> lotteryTickets = obj.orElseThrow(() -> new ResourceNotFoundException("Entity not found.")).getLotteryTickets();
    List<LotteryTicketDTO> dtoList = lotteryTickets.stream().map(x -> new LotteryTicketDTO(x)).collect(Collectors.toList());
    return dtoList;
}

E criei um StandardError para moldar a mensagem de retorno de erro la em controllers.exceptions:

public class StandardError implements Serializable {

    private static final long serialVersionUID = 1L;

    private Instant timestamp;
    private Integer status;
    private String error;
    private String message;
    private String path;

    public StandardError() {
    }

    // OMITINDO GETTERS AND SETTERS

}

E uma classe de Handler para disparar uma resposta de erro amigavel quand o ResourceNotFoundException ocorrer:

@ControllerAdvice
public class ResourceExceptionHandler {
  @ExceptionHandler(ResourceNotFoundException.class)
  public ResponseEntity<StandardError> entityNotFound(ResourceNotFoundException exception, HttpServletRequest request) {
      HttpStatus status = HttpStatus.NOT_FOUND;
      StandardError error = new StandardError();
      error.setTimestamp(Instant.now());
      error.setStatus(status.value());
      error.setError("Resource Not Found");
      error.setMessage(exception.getMessage());
      error.setPath(request.getRequestURI());

      return ResponseEntity.status(status).body(error);
  }
}

A anotação @ControllerAdvice coloca essa classe de erro sob comando do Spring e ele irá disparar automaticamente assim que ResourceNotFoundException ocorrer.

Verificando Sequência de números repetidos na aposta

Criei um método em LotteryTicketService para gerar os números da aposta, mas antes de atribuir a entidade LotteryTicket eu verifico se o Bettor não possuí uma aposta com a mesma sequencia de números através de um loop for dentro das lotteryTickets do Bettor:

@Transactional
private void generateBets(Bettor bettor, LotteryTicket entity) {
    Boolean allRight = false;
    Random betGenerator = new Random();
    Integer attempedBet1 = betGenerator.nextInt(100);
    Integer attempedBet2 = betGenerator.nextInt(100);
    Integer attempedBet3 = betGenerator.nextInt(100);
    Integer attempedBet4 = betGenerator.nextInt(100);
    Optional<Bettor> obj = bettorRepository.findByEmail(bettor.getEmail());
    Set<LotteryTicket> lotteryTickets = obj.get().getLotteryTickets();
    try {
        for (LotteryTicket lotteryTicket : lotteryTickets) {
            List<Integer> bets = new ArrayList<>();
            bets.add(lotteryTicket.getBet1());
            bets.add(lotteryTicket.getBet2());
            bets.add(lotteryTicket.getBet3());
            bets.add(lotteryTicket.getBet4());
            if (!bets.contains(attempedBet1) &&
                    !bets.contains(attempedBet2) &&
                    !bets.contains(attempedBet3) &&
                    !bets.contains(attempedBet4)) {
                allRight = true;
            }
        }
        if (!allRight) {
            generateBets(bettor, entity);
        } else {
            entity.setBet1(betGenerator.nextInt(100));
            entity.setBet2(betGenerator.nextInt(100));
            entity.setBet3(betGenerator.nextInt(100));
            entity.setBet4(betGenerator.nextInt(100));
        }
    } catch (Exception e) {
        entity.setBet1(betGenerator.nextInt(100));
        entity.setBet2(betGenerator.nextInt(100));
        entity.setBet3(betGenerator.nextInt(100));
        entity.setBet4(betGenerator.nextInt(100));
    }
}

Injeção de Dependências com Spring

Armando Tadeu — Fri, 29 Jan 2021 18:11:35 +0000

Uma das principais preocupações dos desenvolvedores com relação ao código de um projeto, é a questão da manutenção. Queremos deixar nosso projeto preparado para receber manutenção, modificações, inclusões de novas funcionalidades e que tudo seja feito com o mínimo de retrabalho possível. Por isso sentimos a necessidade de conhecer e trabalhar sempre com padrões de projeto, técnicas, frameworks que nos ajudem a deixar o código com o menor nível de acoplamento possível.

A injeção de dependência é um padrão de projeto que ajuda muito a deixar o código desacoplado, melhora a legibilidade e interpretação, melhora a distribuição de responsabilidades entre as classes e facilita a manutenção do código.

Definição objetiva

Uma descrição bem objetiva sobre o que significa injeção de dependência é: Uma forma de aplicar inversão de controle em uma classe que utiliza funcionalidades de outras classes, tirando a responsabilidade dela de instanciar ou buscar objetos dessas outras classes das quais ela depende.

Então o objetivo é não instanciar objetos que realizam funções que podem futuramente serem alteradas dentro de uma classe e sim deixar a responsabilidade dessa instanciação para quem chama a classe.

Um exemplo com Java

Imagine que temos uma classe de serviço chamada ValorVendaService e essa classe tem um método calculaValor que recebe um Produto faz um cálculo que é igual para todos os produtos baseado nas características e custo de produção e retorna o valor final do preço do produto para venda com adição de impostos de acordo com cálculo especifico chamado só para exemplificar de CalculoImpostoModelo1. Veja uma forma bem simplória da classe:

public class ValorVendaService {
  private CalculoImpostoModelo1 calculoImpostoModelo1 = new CalculoImpostoModelo1();

  public void calculaValor(Produto produto) {
    Double valorFinal = 0.0;
    // CÁLCULOS PARA DETERMINAR O PREÇO DO PRODUTO - valorFinal

    valorFinal + this.calculoImpostoModelo1.calcula(produto)
  }
}

Nesse exemplo eu coloquei uma dependência da classe CalculoImpostoModelo1 diretamente dentro da classe de ValorVendaService colocando nela a responsabilidade de instanciar e utilizar essa classe de dependência. Isso é um problema e ja vimos que a ideia é tirar a responsabilidade das classes de instanciar seus objetos de dependência.

Para resolver essa questão, poderíamos passar uma instância da classe CalculoImpostoModelo1 diretamente no construtor de ValorVendaService. Mas ainda sim estaríamos presos ao cálculo de impostos somente podendo usar o Modelo1 e se mais tarde precisarmos trocar para um cálculo Modelo2, Modelo3, etc. ?

Por isso, o ideal nesse caso seria criar uma interface CalculoImposto que tem um método calcula para ser implementado e ai usar a interface como referência para ValorVendaService:

public interface CalculoImposto {
  void calcula(Produto produto);
}

public class ValorVendaService {
  private CalculoImposto calculoImposto;

  public valorVendaService(CalculoImposto calculoImposto) {
    this.calculoImposto = calculoImposto;
  }

  public void calculaValor(Produto produto) {
    Double valorFinal = 0.0;
    // CÁLCULOS PARA DETERMINAR O PREÇO DO PRODUTO - valorFinal

    valorFinal + this.calculoImposto.calcula(produto);
  }
}

Essa é uma forma de aplicar a injeção de dependências com Java, de forma manual.

Como o Spring Lida com Injeção de Dependências

O Spring lida com injeção de dependências utilizando um Spring IoC Container conhecido como Spring Context. Esse container é o responsável por gerenciar todas as dependências do projeto de forma automática.

Os objetos gerenciados pelo container do Spring são chamados de Beans. Uma aplicação rodando pode ter vários beans ativos e gerenciados pelo Spring, pois, esses beans são os mesmos objetos que nós utilizamos no projeto normalmente, a única diferença é que a classe deles recebe uma anotação especial que determina que os objetos dessa classe devem ser gerenciados pelo Ioc container.

Essa anotação é a @Component, porém, existem outras anotações que fazem outras coisas mas também são um @Component em sua essência como por exemplo, @Controller, @Service, etc.

Então toda classe que nós colocarmos a anotação @Component já é instanciada automaticamente pelo Spring e se torna um Bean dentro do Contexto do Ioc Container.

Essa classe a seguir já está preparada para ser instanciada e se tornar um Bean gerenciável pelo container do Spring e poderá utilizar injeção de dependências:

@Component
public class ValorVendaService {
  private CalculoImposto calculoImposto;

  public ValorVendaService(CalculoImposto calculoImposto) {
    this.calculoImposto = calculoImposto;
  }

  public void calculaValor(Produto produto) {
    Double valorFinal = 0.0;
    // CÁLCULOS PARA DETERMINAR O PREÇO DO PRODUTO - valorFinal

    valorFinal + this.calculoImposto.calcula(produto);
  }
}

A ideia principal é injetar Beans em outros Beans, ou seja, eu só posso injetar um objeto em outro objeto se as classes deles forem gerenciáveis pelo Spring, precisam ser um @Component.

Então no caso do nosso exemplo (bem simplório, apenas ilustrativo) ficaria assim:

@Component
public class CalculoImpostoModelo1 implements CalculoImposto {
  public void calcula(Produto produto) {
    // Faz o calculo....
  }
}

@Component
public class ValorVendaService {
  private CalculoImposto calculoImposto;

  public ValorVendaService(CalculoImposto calculoImposto) {
    this.calculoImposto = calculoImposto;
  }

  public void calculaValor(Produto produto) {
    Double valorFinal = 0.0;
    // CÁLCULOS PARA DETERMINAR O PREÇO DO PRODUTO - valorFinal

    valorFinal + this.calculoImposto.calcula(produto);
  }
}

As duas classe são um @Component, então ao iniciar o projeto o Spring já instância e gerencia os Beans dessas classes e nesse caso a injeção de dependência ja está pronta, pois, só temos uma implementação de CalculoImposto e o Spring consegue entender isso. Porém, existem diversas formas de configurar as injeções de dependências, pois, quando tivermos mais implementações de CalculoImposto iremos precisar dizer qual implementação vamos utilizar.

Configuração de Beans

Por padrão o Spring faz a instanciação das dependências sem passar nenhum parâmetro para o construtor da classe ou sem fazer nenhum tipo de configuração, mas se em algum cenário isso for necessário é possível criar uma classe Java com a anotação @Configuration e definir métodos com o nome dos Beans a serem injetados e nesses métodos podemos fazer a configuração como de forma mais personalizada, por exemplo:

@Configuration
public class ExemploConfig {

  @Bean
  public CalculoImpostoModelo1 calculoImpostoModelo1() {
    CalculoImpostoModelo1 calculoImposto = new CalculoImpostoModelo1();
    calculoImposto.desativaTaxaExtra();

    return calculoImposto;
  }

}

Definindo essa classe, toda vez que o Spring instanciar o CalculoImpostoModelo1, irá chamar o método desativaTaxaExtra e ali poderiamos fazer passagem de parâmetros no construtor caso fosse necessário.

Pontos de Injeção

O Spring utiliza como ponto de injeção, o construtor da classe como já vimos:

@Component
public class ValorVendaService {
  private CalculoImposto calculoImposto;

  // O construtor aqui é o ponto de injeção
  public ValorVendaService(CalculoImposto calculoImposto) {
    this.calculoImposto = calculoImposto;
  }

  public void calculaValor(Produto produto) {
    Double valorFinal = 0.0;
    // CÁLCULOS PARA DETERMINAR O PREÇO DO PRODUTO - valorFinal

    valorFinal + this.calculoImposto.calcula(produto);
  }
}

Mas o que acontece se o construtor da classe tiver uma sobrecarga ? Nesse caso, precisamos indicar pro Spring qual é o ponto de injeção que ele deve utilizar e fazemos isso com a anotação @Autowired, assim:

@Component
public class ValorVendaService {
  private CalculoImposto calculoImposto;

  // Esse é o ponto de injeção
  @Autowired
  public ValorVendaService(CalculoImposto calculoImposto) {
    this.calculoImposto = calculoImposto;
  }

  public ValorVendaService(String algumaCoisa) {
    // Um construtor com sobrecarga...
  }

  public void calculaValor(Produto produto) {
    Double valorFinal = 0.0;
    // CÁLCULOS PARA DETERMINAR O PREÇO DO PRODUTO - valorFinal

    valorFinal + this.calculoImposto.calcula(produto);
  }
}

Mas o construtor não é o único ponto de injeção, é possível definirmos a anotação @Autowired em um setter ou no próprio atributo...

Exemplo no setter:

@Component
public class ValorVendaService {
  private CalculoImposto calculoImposto;

  public void calculaValor(Produto produto) {
    Double valorFinal = 0.0;
    // CÁLCULOS PARA DETERMINAR O PREÇO DO PRODUTO - valorFinal

    valorFinal + this.calculoImposto.calcula(produto);
  }

  //Agora o ponto de injeção é aqui
  @Autowired
  public void setCalculoImposto(CalculoImposto calculoImposto) {
    this.calculoImposto = calculoImposto;
  }
}

Exemplo no próprio atributo:

@Component
public class ValorVendaService {

  //Agora o ponto de injeção é aqui
  @Autowired
  private CalculoImposto calculoImposto;

  public void calculaValor(Produto produto) {
    Double valorFinal = 0.0;
    // CÁLCULOS PARA DETERMINAR O PREÇO DO PRODUTO - valorFinal

    valorFinal + this.calculoImposto.calcula(produto);
  }

}

Desambiguação dos Beans

Considerando o exemplo em que temos a classe CalculoImpostoModelo1, se precisarmos utilizar agora um CalculoImpostoModelo2 tendo um cenário mais ou menos assim:

@Component
public class CalculoImpostoModelo1 implements CalculoImposto {
  public void calcula(Produto produto) {
    // Faz o calculo....
  }
}

@Component
public class CalculoImpostoModelo2 implements CalculoImposto {
  public void calcula(Produto produto) {
    // Faz o calculo....
  }
}

@Component
public class ValorVendaService {

  //Agora o ponto de injeção é aqui
  @Autowired
  private CalculoImposto calculoImposto;

  public void calculaValor(Produto produto) {
    Double valorFinal = 0.0;
    // CÁLCULOS PARA DETERMINAR O PREÇO DO PRODUTO - valorFinal

    valorFinal + this.calculoImposto.calcula(produto);
  }

}

Nesse caso o Spring não saberá qual das implementações de CalculoImposto deverá utilizar no ValorVendaService, por isso, precisamos informar.

Uma forma de fazer isso é com a anotação @primary, colocando essa anotação em uma das classes de implementação, iremos indicar que é ela que deverá ser carregada como dependência da classe que utiliza a interface CalculoImposto.

@Component
public class CalculoImpostoModelo1 implements CalculoImposto {
  public void calcula(Produto produto) {
    // Faz o calculo....
  }
}

@Primary
@Component
public class CalculoImpostoModelo2 implements CalculoImposto {
  public void calcula(Produto produto) {
    // Faz o calculo....
  }
}

@Component
public class ValorVendaService {

  ////Ponto de injeção e usando CalculoImpostoModelo2
  @Autowired
  private CalculoImposto calculoImposto;

  public void calculaValor(Produto produto) {
    Double valorFinal = 0.0;
    // CÁLCULOS PARA DETERMINAR O PREÇO DO PRODUTO - valorFinal

    valorFinal + this.calculoImposto.calcula(produto);
  }

}

Nesse caso, a CalculoImpostoModelo2 é quem será injetada em ValorVendaService.

Outra forma de fazer essa indicação é utilizando a anotação @Qualifier, com o Qualifier temos que definir um nome que identifica o Bean e indicar qual queremos usar no ponto de injeção.

@Qualifier('modelo1')
@Component
public class CalculoImpostoModelo1 implements CalculoImposto {
  public void calcula(Produto produto) {
    // Faz o calculo....
  }
}

@Qualifier('modelo2')
@Component
public class CalculoImpostoModelo2 implements CalculoImposto {
  public void calcula(Produto produto) {
    // Faz o calculo....
  }
}

@Component
public class ValorVendaService {

  //Ponto de injeção e usando CalculoImpostoModelo2
  @Qualifier('modelo2')
  @Autowired
  private CalculoImposto calculoImposto;

  public void calculaValor(Produto produto) {
    Double valorFinal = 0.0;
    // CÁLCULOS PARA DETERMINAR O PREÇO DO PRODUTO - valorFinal

    valorFinal + this.calculoImposto.calcula(produto);
  }

}

Esses foram alguns exemplos de como utilizar os recursos de injeção de dependência no Spring para ajudar no entendimento de como funciona (que é a ideia principal do artigo), então, para finalizar, de forma bem objetiva... O Spring utiliza um Container especial para instanciar todos os objetos gerenciáveis por ele, além de suas classes internas, nós podemos indicar nossas classes para entrarem nesse contexto gerenciável, para isso, utilizamos as anotações que definem nossa classe como um componente do Spring (@Component, @Service, @Controller...), assim toda classe gerenciável é instanciada e se torna em Bean dentro do contexto de inversão de controle do Spring, todos esses objetos podem ser injetados uns nos outros facilmente conforme as técnicas nos exemplos do artigo =).

Esse artigo foi elaborado para participar do desafio do curso Especialista Spring REST da AlgaWorks. Todo o conteúdo que consegui elaborar aqui é resultado de estudos das aulas do curso.