DEV Community: Giovanne Barbosa

Otimizando chamadas assincronas com Task.WhenAll

Giovanne Barbosa — Thu, 20 Apr 2023 02:27:54 +0000

Imagine que temos uma classe VeiculoService e dentro dela dois métodos (ObterCarros e ObterMotos). E esses métodos fazem uma busca em uma base de dados "recheada", o que faz cada um deles levar 5 segundos para retornar cada informação.

    public class VeiculoService
    {
        public async Task<string> ObterCarros(string marca)
        {
            await Task.Delay(5000);
            return $"Conclui busca de veiculos da marca {marca}";
        }

        public async Task<string> ObterMotos(string marca)
        {
            await Task.Delay(5000);
            return $"Conclui busca de Motos da marca {marca}";
        }
    }

Agora imagine que temos um programa que precise fazer a chamada desses dois métodos para retornar essas duas listas:

    class Program
    {
        static async Task Main(string[] args)
        {
            var veiculoService = new VeiculoService();

            var carros = await veiculoService.ObterCarros("xpto");
            var motos = await veiculoService.ObterMotos("xpto");

            Console.WriteLine(carros);
            Console.WriteLine(motos);
        }
    }

No código acima nós instanciamos a classe VeiculoService, chamamos o seu método ObterCarros, guardamos em uma variável e logo em seguida chamamos o método ObterMotos guardando também em outra variável. Por fim printamos na tela os dois resultados.

Ao executar o programa observamos que o tempo de processo foi em torno de 10 segundos. Isso porque estamos excutando os dois métodos em sequencia e os dois levam aproximadamente 5s para serem executados.

É possível diminuir consideravelmente esse tempo de processo com o método Task.WhenAll:

    class Program
    {
        static async Task Main(string[] args)
        {
            var veiculoService = new VeiculoService();

            var veiculos = veiculoService.ObterCarros("xpto");
            var marcas = veiculoService.ObterMotos("xpto");

            await Task.WhenAll(veiculos, marcas);

            Console.WriteLine(veiculos.Result);
            Console.WriteLine(marcas.Result);
        }
    }

Observando o console, podemos ver que o tempo de execução caiu pela metade:

Isso acontece pois o Task.WhenAll executa os métodos em paralelo. O que é muito útil para casos em que temos varias chamadas de métodos que não dependem do resultado um do outro, salvando um tempo que muitas vezes pode ser precioso para o seu programa.

SOLID - SRP

Giovanne Barbosa — Wed, 06 Apr 2022 00:44:46 +0000

Princípio da responsabilidade única

Uma classe deve ter apenas uma razão para mudar.

Cada classe deve ter uma única responsabilidade dentro do projeto.

Por exemplo:

Vamos supor que no nosso projeto exista a seguinte classe:

    public class PetShop
    {
        public decimal CalculaReceita(){}
        public void PagarFuncionarios(){ }
        public void AdicionarPet(Pet pet) { }
        public Pet BuscarPet(int id) { }
    }

Ela é responsável por uma série de tarefas, como calculo de finanças, pagamento de funcionários e cadastro de Pets... Muita coisa, né!?
Neste caso, nós teríamos cinco razões completamente diferentes para alterar uma classe, já quebrando o principio da responsabilidade única. Sem falar no alto acoplamento e na dificuldade de manutenção.

O ideal seria criar uma classe para cada responsabilidade diferente:

    public class Receita
    {
        public decimal CalcularReceita() { }
    }

    public class Pagamentos
    {
        public void PagarFuncionarios() { }
    }

    public class PetRepositorio
    {
        public void AdicionarPet(Pet pet) { }
        public Pet BuscarPet(int id) { }
    }

Muito mais fácil de entender e bonito de se ver, não é mesmo?

SOLID - DIP

Giovanne Barbosa — Sat, 02 Apr 2022 00:26:20 +0000

Princípio da inversão de dependência

Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações; Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.

Dependa de uma abstração e não de uma implementação.

Por exemplo:

Temos uma classe Petshop que recebe no seu construtor um PetRepositorioMySQL e possui o método CadastrarOuAtualizarPet() que verifica se o Pet informado já existe e o atualiza e caso contrário, cria um novo cadastro.

    public class Petshop
    {
        private readonly PetRepositorioMySQL _petRepositorioMySQL;
        public Petshop()
        {
            _petRepositorioMySQL = new PetRepositorioMySQL();
        }

        public void CadastrarOuAtualizarPet(string nome)
        {
            var pet = _petRepositorioMySQL.Get(nome);

            if (pet == null)
                _petRepositorioMySQL.Insert(pet);
            else
                _petRepositorioMySQL.Update(pet);
        }
    }

O problema é que se um dia nós resolvêssemos usar uma PetRepositorioSQLServer no lugar da PetRepositorioMySQL, mesmo as duas possuindo os mesmos metódos, precisaríamos mudar a nossa classe Petshop. Nossa classe não deveria ter que saber como se instancia este repositório ou como que ele se comporta internamente. Só precisamos saber o que ele recebe e o que retorna.
Devido a isso, estamos quebrando o princípio da inversão de dependência.

Solução:

Criamos a interface IRepositorioGenerico e fazemos com que nossa classe PetRepositorioMySQL implementa-a.

    public class PetRepositorioMySQL : IRepositorioGenerico
    {
        public Pet Get(string nome)
        {
            throw new NotImplementedException();
        }

        public void Insert(Pet pet)
        {
            throw new NotImplementedException();
        }

        public void Update(Pet pet)
        {
            throw new NotImplementedException();
        }
    }

Dentro da classe Petshop, nós injetamos nossa classe PetRepositorioMySQL representada pela sua interface IRepositorioGenerico.

    public class Petshop
    {
        private readonly IRepositorioGenerico _repositorio;
        public Petshop(IRepositorioGenerico repositorio)
        {
            _repositorio = repositorio;
        }

        public void CadastrarOuAtualizarPet(string nome)
        {
            var pet = _repositorio.Get(nome);

            if (pet == null)
                _repositorio.Insert(pet);
            else
                _repositorio.Update(pet);
        }
    }

Assim a Petshop não é obrigada a instanciar o repositório, pois quem consumir esta classe deve passar as instâncias já criadas no construtor dela. E se caso um dia quisermos mudar o repositório, não precisaremos alterar a classe PetShop, desde que o novo repositório implemente a mesma interface. Desta forma, invertemos o controle.

SOLID - OCP

Giovanne Barbosa — Sun, 27 Mar 2022 00:59:55 +0000

Princípio do aberto/fechado

Entidades de software devem ser abertas para extensão, mas fechadas para modificação.

Se você precisa adicionar uma nova funcionalidade, então é melhor estender do que modificar.

Por exemplo:

Temos uma classe Veiculo que recebe no seu construtor um tipo de veículo e dentro dela o método Ligar() que tem uma sequência de condicionais que verifica o tipo do veículo e realiza a operação adaptada a ele. Sendo assim, toda vez que for adicionado um novo veiculo, nós precisaríamos adicionar uma nova condição ao nosso método. Logo, nossa classe/método está aberta para modificação e estamos quebrando o princípio do aberto/fechado.

    public class Veiculo
    {
        private readonly TipoVeiculoEnum _tipoVeiculo;

        public Veiculo(TipoVeiculoEnum tipoVeiculo)
        {
            _tipoVeiculo = tipoVeiculo;
        }

        public string Nome { get; set; }

        public void Ligar()                             
        {
            if (_tipoVeiculo == TipoVeiculoEnum.Carro)
            {
                Console.WriteLine("Carro pronto para ser dirigido");
            }
            if (_tipoVeiculo == TipoVeiculoEnum.Moto)
            {
                Console.WriteLine("Moto pronta para ser pilotada");
            }
        }
    }

Para um exemplo de um método que utilize a Veiculo, criei uma classe LavaRapido com um método Lavar() que recebe um tipo de Veiculo

    public class LavaRapido
    {
        public void Lavar(Veiculo veiculo)
        {
            Console.WriteLine($"Lavando o veiculo {veiculo.Nome}");
        }
    }

var moto = new Veiculo(TipoVeiculoEnum.Moto);
moto.Ligar();

var lavaRapido = new LavaRapido();
lavaRapido.Lavar(moto);

Solução:

Podemos criar a classe abstrata Veiculo com seu método abstrato Ligar() e para cada novo veiculo que formos adicionando ao nosso projeto, criamos uma classe para ele, herdamos a classe Veiculo e sobrescrevemos o método Ligar() de acordo com as necessidades do veículo.

    public abstract class Veiculo
    {
        public string Nome { get; set; }
        public abstract void Ligar();
    }

    public class Moto : Veiculo
    {
        public override void Ligar()
        {
            Console.WriteLine("Moto pronta para ser pilotada");
        }
    }

    public class Carro : Veiculo
    {
        public override void Ligar()
        {
            Console.WriteLine("Carro pronto para ser dirigido");
        }
    }

O método Lavar() da classe LavaRapido não deixa de funcionar, pois tanto a classe Moto quanto a classe Carro são subtipos de Veiculo.

var moto = new Moto();
var carro = new Carro();
moto.Ligar();
carro.Ligar();

var lavaRapido = new LavaRapido();
lavaRapido.Lavar(moto);
lavaRapido.Lavar(carro);

SOLID - LSP

Giovanne Barbosa — Fri, 25 Mar 2022 23:30:44 +0000

Princípio da substituição de Liskov

Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para objetos y de tipo S onde S é um subtipo de T.

Se a nossa classe não pode se comportar como a classe que ela está herdando, então temos um problema de abstração.

Por exemplo:

Temos uma classe Veículo, com um método voar() e temos uma classe Helicóptero que herda essa classe Veículo.

    public class Veiculo
    {
        public string Nome { get; set; }
        public virtual void Voar()
        {
            Console.WriteLine($"O veículo {Nome} está voando");
        }
    }

    public class Helicoptero : Veiculo
    {

    }

Tudo certo, afinal um helicóptero é um subtipo de veículo e o helicóptero pode voar. Mas e se tivermos uma classe Moto herdando a classe Veículo, desta forma?

    public class Moto: Veiculo
    {

    }

...

Veiculo moto = new Moto();
moto.Voar() //>>>>>>>>>> WTF!?

Uma moto é um veículo, porém não pode voar. Logo, estamos quebrando o princípio da substituição de Liskov.

Solução:

Tiramos o método voar() da classe Veículo e criamos uma classe VeículoAéreo com o método voar() e então fazemos com que nossa classe Helicóptero herde a classe VeículoAéreo.

    public class Veiculo
    {
        public string Nome { get; set; }
    }

    public class VeiculoAereo : Veiculo
    {
        public virtual void Voar()
        {
            Console.WriteLine($"O veículo {Nome} está voando");
        }
    }

    public class Helicoptero : VeiculoAereo
    {

    }

    public class Moto: Veiculo
    {

    }

Desta forma nem a moto e nem o helicóptero deixam de ser um veiculo, porem não é mais possível voar com a moto (nunca foi).

Criei uma classe LavaRapido com um método Lavar() que recebe um tipo de Veiculo

    public class LavaRapido
    {
        public void Lavar(Veiculo veiculo)
        {
            Console.WriteLine($"Lavando o veiculo {veiculo.Nome}");
        }
    }

E assim consigo lavar meus dois veículos, mesmo que o helicóptero seja um veículo aéreo, pois a classe VeiculoAereo ainda é um subtipo de Veiculo.

var lavaRapido = new LavaRapido();

Veiculo moto = new Moto();
VeiculoAereo helicoptero = new Helicoptero();

lavaRapido.Lavar(moto);
lavaRapido.Lavar(helicoptero);

SOLID - ISP

Giovanne Barbosa — Fri, 25 Mar 2022 01:36:34 +0000

Princípio da segregação de interfaces

Nenhum cliente deve ser forçado a depender de métodos que não utiliza.

Onde podemos dizer que clientes são nossas classes e essas não devem depender de métodos que nunca vão utilizar.

Por exemplo:

Suponhamos que temos uma interface IBanhoPet com os métodos LimparPatas(), LimparAsas() e Secar() e criamos uma classe BanhoPardal e outra BanhoGato que implementam essa interface.

public interface IBanhoPet
{
    void LimparAsas();
    void LimparPatas();
    void Secar();
}

A classe BanhoPardal utiliza todos os métodos que a interface nos diz para implementar. Já a classe BanhoGato não precisa utilizar o método LimparAsas(), afinal, gatos não possuem asas. Porém também não podemos deixar de implementá-lo, pois uma interface é como um contrato que nos obriga a utilizar todos os seus métodos. Logo, estamos ferindo o princípio da segregação de interfaces.

Solução:

Criamos uma interface IBanhoGato que possui os métodos LimparPatas() e Secar() e outra IBanhoAve que possui os mesmos métodos da IBanhoGato com a adição do método LimparAsas() e as nossas classes implementam as suas respectivas interfaces.

public interface IBanhoGato
{
    void LimparPatas();
    void Secar();
}

public interface IBanhoAve
{
    void LimparAsas();
    void LimparPatas();
    void Secar();
}

Fácil, né!?

Métodos Virtuais

Giovanne Barbosa — Wed, 23 Mar 2022 01:13:34 +0000

O método virtual é um método que tem a opção de ser sobrescrito em uma classe que herda o mesmo de outra classe.

Por exemplo:

Temos a classe Animal com o método virtual Som

public class Animal
{
  public virtual void Som() 
  {
    Console.WriteLine("...");
  }
}

Ao criarmos uma classe Gato que herda a classe Animal, podemos sobrescrever o método Som() e mudá-la de acordo com a necessidade da classe Gato:

public class Gato : Animal
{
  public override void Som()
  {
    Console.WriteLine("miau!");
  }
}

Classe selada

Giovanne Barbosa — Wed, 23 Mar 2022 01:12:10 +0000

Sealed class são usadas quando não queremos que nossa classe seja derivada.

Por exemplo:

Eu criei a classe Gato e não quero que alguma outra classe seja filha dela, então eu uso o modificador de acesso sealed.

sealed class Gato 
{
  public virtual void Som()
  {
    Console.WriteLine("miau!");
  }
}

Ao tentar fazer como o exemplo abaixo e tentar compilar o código, uma exceção será lançada dizendo que não é possível derivar do tipo sealed.

class Gatinho : Gato 
{
  public override void Som()
  {
    Console.WriteLine("miauzinho!");
  }
}

Usando transaction no knex

Giovanne Barbosa — Tue, 22 Mar 2022 02:20:16 +0000

Transação é uma forma segura de garantir que se algo der errado no meio do processo de alteração do banco de dados, essas alterações não serão salvas. Por exemplo, quando estamos fazendo alterações que mexem em duas tabelas. Se a alteração da segunda tabela der errado, a da primeira também não será salva.

Para usar transaction no knex, é muito simples:

Primeiro, crie uma variável e inicie a transação:

const trx = await knex.transaction();

Depois faça as tratativas do seu banco de dados normalmente, com uma diferença: Ao invés de usar 'knex' para fazer suas alterações, use a variável de transação criada:

await trx('tabela').insert(dados)

E ao final de tudo é só commitar:

trx.commit()

Criando tipos de entrada no GraphQL

Giovanne Barbosa — Tue, 22 Mar 2022 02:00:33 +0000

É possível criar tipos pré-definidos de entradas para usar em suas querys ou mutations no GraphQL

Geralmente, quando criamos uma query ou mutation que precisa receber parâmetros de entrada, nós escrevemos cada uma das variáveis e os tipos que esperamos receber:

type User {
    id: Int!
    username: String!
}

type Query {
    searchUser(username: String!): User!
}

O problema é que se nossa entrada for composta de vários parâmetros, fica extremamente maçante e estéticamente feio ter que escrever tudo isso. Porém, é possível criar um tipo de entrada que já é composto por todos os atributos necessários para a query. Podemos também reutilizá-las, diminuindo ainda mais a quantidade de coisas repetidas que o dev teria que escrever:

input SearchUserInput {
    username: String!
}

type Query {
    searchUser(data: SearchUserInput!): User!
}

E então, quando eu fosse executar a query, ficaria assim:

Query {
    searchUser(data: {username: "test12345"}){
        id
        username
    }
}