DEV Community: Nicolas de Souza

Materiais de estudo

Estamos chegando ao fim do nosso artigo e queria deixar alguns materiais que usei para estudar esse padrão de software:

Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos

Design Pattern - Adapter

Nicolas de Souza — Mon, 02 Sep 2024 12:00:00 +0000

Sabe quando seu sistema legado precisa de um feature nova mas a biblioteca que você usa não tem suporte para isso e a biblioteca que você achou para implementar não faz o que a biblioteca antiga faz e de alguma forma você precisa fazer as duas trabalharem juntas no seu sistema ?! É aí que podemos contar com o Design Patter Adapter!

Design Patter - Adapter é um padrão estrutural que permite objetos com interfaces incompatíveis trabalhem juntos!

Estrutura básica

Target ( Alvo ) - é (geralmente) a nova interface que precisamos adicionar ao nosso projeto
Adapter ( Adaptador ) - irá realizar ajustes necessários, convertendo a interface da classe a ser adaptada para que a interface target possa ser utilizada
Adaptee ( Classe adaptada ) - nossa classe legada, a classe que faz todo esse esforço ser necessário
Client - Usa a interface Target para interagir com os objetos do sistema

Situação problema

Vamos esmiuçar essa estrutura com um exemplo. Imagina que você faz parte da equipe do Spotify e a empresa decidiu que agora irão trabalhar com vídeos. O júnior da equipe logo fica ansioso imaginando que será necessário refazer todo o código, procurar uma nova biblioteca que suporte tanto áudios mp3 e os vídeos mp4. Ele chega a sugerir isso na reunião mas todo mundo fica preocupado com a ideia de mexer no que já está funcionando, mas e se houvesse uma forma de fazer uma biblioteca de vídeos funcionar junto com a biblioteca de áudio que a equipe já está acostumada a usar?!

É nesse momento que vamos propor nosso mais novo amigo como a solução dos problems!

Mão na massa!

Vamos iniciar criando nossa interface target, ela deverá ter a declaração de um método Play que recebe o nome do arquivo a ser executado.

Interface Alvo (Target)

public interface IMidiaPlayer
{
    void Play(string file);
}

Nossa classe antiga .mp3

Observe que ela só sabe executar .mp3

public class Mp3Player
{
    public void PlayMp3( string file)
    {
        Console.WriteLine($"Reproduzindo MP3: {file}");
    }
}

Nossa nova classe .mp4

Esta classe já implementa nossa interface mas ainda falta a estrela dessa operação

public class Mp4Player : IMidiaPlayer
{
    public void Play(string file)
    {
        Console.WriteLine($"Reproduzindo MP4: {file}");
    }
}

A estrela do dia: Mp3PlayerAdapter

Note como ela será responsável por tornar viável a integração entre as nossas classes mp3 e mp4

public class Mp3PlayerAdapter : IMidiaPlayer
{
    private readonly Mp3Player mp3Player;
    private readonly Mp4Player mp4Player;
    
    public Mp3PlayerAdapter(Mp3Player mp3Player_, Mp4Player mp4Player_)
    {
        mp3Player = mp3Player_;
        mp4Player = mp4Player_;
    }

    public void Play(string file)
    {
        if(file.EndsWith(".mp3"))
            mp3Player.PlayMp3(file);
        if(file.EndsWith(".mp4"))
            mp4Player.Play(file);
    }

}

Media Client

public class MediaClient
{
    private readonly IMidiaPlayer mediaPlayer;
    
    public MediaClient(IMidiaPlayer mediaPlayer_)
    {
        mediaPlayer = mediaPlayer_;
    }

    public void Play(string file)
    {
        mediaPlayer.Play(file);
    }
}

Main

namespace AdapterPlayer
{
    class Program
    {
        static void Main(string[] args)
        {
            var serviceProvider = new ServiceCollection()
                .AddScoped<Mp4Player>()
                .AddScoped<Mp3Player>() 
                .AddScoped<IMidiaPlayer, Mp3PlayerAdapter>() 
                .AddScoped<MediaClient>()
                .BuildServiceProvider();

            var mediaClient = serviceProvider.GetRequiredService<MediaClient>();  

            mediaClient.Play("musica.mp3");
            mediaClient.Play("video.mp4");
            mediaClient.Play("documento.pdf");
        }
    }
}

Resultado em tela

Olha que legal, o arquivo .pdf foi ignorado já que não possui uma classe que seja capaz de executá-lo.

Reproduzindo MP3: musica.mp3

Reproduzindo MP4: video.mp4

Algumas considerações sobre esse padrão

Esse padrão é um coringa muito interessante para se ter em mente, ele tem como vantagens a flexibilidade, o desacoplamento, a reutilização de código, facilita a integração de sistemas legados e ainda melhora a legibilidade do código! Mas como nem tudo são flores, é necessário certos cuidados, esse padrão pode aumentar a complexidade do seu sistema, limitar a capacidade de debugar o código... Como tudo na vida, use com moderação!

Repositório GIT

Materiais de Estudo

Estamos chegando ao fim do nosso artigo e queria deixar alguns materiais que usei para estudar esse padrão de software:

Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos

Padrão Adapter - DevMedia

Design Pattern - Singleton

Nicolas de Souza — Mon, 03 Jun 2024 12:30:00 +0000

O objetivo deste padrão é bem simples, garantir que apenas uma instância de uma determinada classe seja criada.

Simples não?! Após padrões um tanto quanto confusos e complexos, parece até pegadinha mas é fato, realmente é simples. Mas quando isso pode ser aplicado?! Um exemplo comum são as situações de conexões com banco, normalmente não queremos ter N fontes de verdades sobre os dados, o que poderia ocasionar situações de conflito entre essas instâncias.

Não vou me extender neste padrão, ele realmente é simples, deixarei algumas recomendações no final caso queira saber mais!

Ótimo, você já entendeu que o objetivo é criar apenas uma instância, mas como podemos fazer isso?! Algumas linguagens como C# permitem que "marquemos" determinados serviços como singleton quando realizamos a injeção de dependências, então talvez você já tenha visto algo como isso:


.AddSingleton<Interface, Class>()

Mas aqui quero falar um pouco mais sobre a ótica de criarmos uma classe que só possa ter uma instância e não sobre um serviço em si. Pensemos no seguinte, você está construindo um jogo de futebol, neste jogo teremos vários objetos que teremos um ou mais, como jogadores de linha, goleiros, bandeirinhas, mas teremos apenas uma objeto bola, apenas um objeto juíz...

Primeiro vamos criar nossa classe de interesse

public class Ball
{
    private static Ball instance;
    public string ImagePath { get; set; }
    public string Weight { get; set; }
    public double ElasticCoefficient { get; set; }

    private Ball() { }

    public static Ball GetInstance()
    {
        instance ??= new Ball(); // só é instanciado se instace é nula
        return instance;
    }
}

Agora vamos verificar se tudo ocorreu bem

using SingletonFootball;

var b1 = Ball.GetInstance();
var b2 = Ball.GetInstance();

if (b1 == b2)
    Console.WriteLine("A mesma instância foi atribuída aos dois objetos");
else
    Console.WriteLine("Instância diferentes foram atribuídas");

No console veremos:

A mesma instância foi atribuída aos dois objetos

Ótimo, funcionou!!! Mas aqui mora uma pegadinha, se por algum motivo estivermos trabalhando com Threads, teremos a possibilidade de várias rotinas acessarem simultaneamente obtendo várias instância, para corrigir isso precisamos realizar pequenas modificações em nosso código.

Para isso vamos implementar a classe Referee utilizando uma instrução chamada lock. A ideia é que a primeira instância a chave, irá bloquear que outras possíveis instâncias sejam iniciadas.

public class Referee
{
    private static Referee instance;
    public string Name { get; set; }

    private static readonly object _lock = new object();

    private Referee(){ }

    public static Referee GetInstance(string value)
    {
        if (instance == null)
        {
            lock (_lock)
            {
                if (instance == null)
                {
                    instance = new Referee();
                    instance.Name = value;
                }
            }
        }
        return instance;
    }
}

Agora vamos testar o que implementamos

Thread process1 = new Thread(() => {
    TestSingleton("George");
});

Thread process2 = new Thread(() => {
    TestSingleton("Hamilton");
});

process1.Start();
process2.Start();

process1.Join();
process2.Join();

void TestSingleton(string value)
{
    Referee Referee = Referee.GetInstance(value);
    Console.WriteLine(Referee.Name);
}

Na saída teremos então:

George
George

Desse modo garantiremos que apenas uma instância será criada, mesmo quando utilizarmos threads para execução de tarefas.

Repositório GIT

Materiais de Estudo

Estamos chegando ao fim do nosso artigo e queria deixar alguns materiais que usei para estudar esse padrão de software:

Higor Diego - Padrão - Singleton

Balta - AddTransit, AddScopped, AddSingleton

Um pouco sobre a instrução lock

Design Patterns - Prototype

Nicolas de Souza — Fri, 31 May 2024 17:27:08 +0000

Uma das primeiras coisas que aprendemos na programação, seja qual for a linguagem, é como copiar valor de uma variável para outra. Uma atividade extremamente comum mas que rende situações interessantes no nosso dia a dia.

Definição

É um padrão criacional que permite a criação de novos objetos copiando um objeto já existente, isso pode ser útil quando a criação de um objeto é custosa ao sistema, seja por sua complexidade inerente ou pelo alto consumo de recursos envolvidos.

Exemplo conceitual

Quando estudei pela primeira vez este padrão de design, confesso que tive dificuldade para entender sua aplicação. Num primeiro momento me pareceu um tanto quanto desnecessário, criar toda uma estrutura para realizar uma simples cópia. Mas foi aí que pensei em um possível uso na minha rotina.

Imagine que você possua uma entidade Perfil cujo uma de suas propriedades seja a classe Configuração, e a cada vez que você for criar um novo Perfil, precisamos ir na tabela de configurações e obter as configurações mais recentes... Agora imagine, toda vez que precisar criar um novo objeto, será feito uma consulta em banco!! Se esses dados são os mesmos de outros objetos que já estamos manipulando, por quê não usá-los?! É aí que o prototype brilha, padronizando o processo de cópia desses objetos.

Shallow Copy e Deep Copy

Há, pelo menos inicialmente, duas situações para pensarmos sobre as cópias de objetos, as cópias parciais (shallow copy) e as cópias profundas (Deep Copy). A diferença está na forma como os valores são passados de um objeto ao outro.

Quando estudei programação pela primeira vez, a linguagem C era dominante na instituição (até hoje é ela) e o conceito de passagem de valor e referência fazia parte das primeiras aulas, já que é extremamente comum nesta linguagem, como sei que não é o caso de todos, vou explicar um pouco sobre.

Passagem de Valor vs Referência

Passagem de valor é literalmente passar um valor, passamos o conteúdo de uma variável para outra, como no exemplo que segue, onde passamos o valor que está em a para b. Com isso temos duas alocações na memória, dois endereços de memória diferentes.

int a = 10;
int b = a;

Parece óbvio que se queremos copiar algo, queremos copiar o seu valor, mas na programação certos tipos são sempre passados como referência, é o caso dos vetores em C.

int a[4] = [0,1,2,3];
int b[4] = a;

Neste caso é feito uma passagem por referência, isso significa que passamos para b apenas o endereço de memória de a. Isso significa que toda e qualquer modificação neste vector será refletida tanto em a quanto em b.

Mas o que isso tem a ver com as cópias?!

Em diversas linguagens, Java e C#, por exemplo, os objetos são passados como referência e isso entrega comportamentos peculiares. Ao realizarmos a cópia de um objeto que possui outros objetos, estes objetos internos serão copiados como referência para o seu destino, portanto compartilharam o mesmo estado em memória, tendo seus valores sempre iguais entre suas cópias, portanto uma cópia parcial (Shallow Copy).

Qual devo usar?!

O ganho do uso de cópias parciais é a eficiência do seu código, que usará menos recursos do que se realizasse uma cópia profunda, instanciando um novo objeto interno e copiando os valores presentes.

Mas qual o melhor a ser usado? Dependerá do seu projeto e necessidades, o padrão Prototype, conferirá a você a padronização desses processos, para que sempre que for necessário copiar um objeto, não seja necessário abrir a classe e verificar se há mais objetos internos, se esses objetos internos não possuem outros objetos internos...

Aplicando o Prototype

A primeira coisa que iremos precisar é uma interface do tipo Prototype, que terá os métodos ShallowCopy e DeepCopy.

public interface IPrototype<T>
{
    T ShallowCopy();
    T DeepCopy();    
}

Agora poderemos implementar a nossa classe abstrata que herdará de IPrototype, aqui já poderíamos implementar a interface se assim quiséssemos mas no caso prefiro usar uma classe intermediária.

Criarei também a classe Weapon para ser nossa classe interna, ela eu já opto por implementar diretamente e portanto não marco suas propriedades como abstract.

public abstract class Enemy : IPrototype<Enemy>
{
    public string Name;
    public string Description;    
    public Weapon Weapon;
    public abstract Enemy ShallowCopy();
    public abstract Enemy DeepCopy();
}

public class Weapon : IPrototype<Weapon>
{
    public string Type;
    public int Damage;

    public Weapon(string type, int damage)
    {
        this.Type = type;
        this.Damage = damage;
    }

    public Weapon ShallowCopy()
    {
        return (Weapon)this.MemberwiseClone();
    }

    public Weapon DeepCopy()
    {
        return new Weapon(Type, Damage);
    }
}

Note que os métodos herdados de IPrototype são marcados como abstract para que na próxima herança seja codificado.

Agora podemos finalmente implementar nossa classe produto, a classe Troll.

public class Troll : Enemy
{
    public override Enemy ShallowCopy()
    {
        return (Enemy)this.MemberwiseClone();
    } 

    public override Enemy DeepCopy()
    {
        Enemy enemy = ShallowCopy();
        enemy.Weapon = new Weapon(Weapon.Type, Weapon.Damage);

        return enemy;
    }
    
    public override string ToString()
    {
        var Str = new StringBuilder();

        Str.AppendLine($"Name: {this.Name}");
        Str.AppendLine($"Description: {this.Description}");
        Str.AppendLine($"Weapon: {Weapon.Type} ({Weapon.Damage})");
        
        return Str.ToString();
    }
}

Podemos ver que a classe Troll implementa nossos dois tipos de cópia e já na sua implementação entendemos que por mais que seus valores sejam parecidos, haverá um comportamento diferente entre os dois.

Executando nossas classes

Enemy Boss = new Troll
{
    Name = "Boss",
    Description = "Tordoaldo is an evil troll, with a sharp intelligence and hidden strength, who lives in a forest cave adorned with treasures from his adventures.",
    Weapon = new Weapon("Sword", 500)
};

Enemy Boss_ShallowCopy = Boss.ShallowCopy();
Enemy Boss_DeepCopy = Boss.DeepCopy();

System.Console.WriteLine("First Run \n");
ConsoleInfo();

Boss.Name = "BossWithNewName";
Boss.Weapon.Type = "Other Sword";  

System.Console.WriteLine("Second Run \n");
ConsoleInfo();

void ConsoleInfo()
{
    Console.WriteLine("Boss");
    Console.WriteLine(Boss.ToString());
    Console.WriteLine("Boss Shallow Copy");
    Console.WriteLine(Boss_ShallowCopy.ToString());
    Console.WriteLine("Boss Deep Copy");
    Console.WriteLine(Boss_DeepCopy.ToString());
}

Passo a Passo

Step 1

Aqui realizamos as duas cópias e podemos ver que todas as propriedades são idênticas como deveria ser.

Step 2

Após isso atualizamos o nome do nosso "Boss" original, e trocamos o nome da sua arma e o que vemos na saída é interessante!

Como podemos ver nosso "Boss" aparece com seu nome novo, sem nenhum problema. Mas nosso "Boss Shallow Copy" também teve sua arma alterada! Isso se dá justamente pela propriedade que comentamos anteriormente, como realizamos uma cópia parcial, a classe interna Weapon compartilha o mesmo espaço na memória, assim, toda alteração realizada ali refletirá nos dois objetos, "Boss" e "Boss Shallow Copy"

Sobre seu uso

Quando usar?!

O livro sobre padrões do Erich Gamma, enumera três casos de uso para este modelo:

Quando classes que serão instanciadas são especificadas em tempo de execução, por carga dinâmica por exemplo.
Para evitar o acoplamento do nosso código, evitando a construção de uma hierarquia de classes factories paralela à hierarquia de classes do produto.
Quando as instâncias de uma classe puderem ter uma dentre poucas combinações diferentes de estados. Pode ser mais vantajoso instalar um número correspondente de protótipos e cloná-los, ao invés de instanciar a classe manualmente, cada vez com um estado apropriado.

Vantagens

Ainda utilizando o livro supracitado, temos alguns benefícios:

Acrescentar e remover produtos em tempo de execução. É um padrão mais flexível que outros padrões de criação, permitindo registrar novos produtos ao instanciar um novo prototype no cliente, deste modo o cliente pode instalar e remover protótipos em tempo de execução.
Especificar novos objetos pela variação de valores. Ao utilizarmos o padrão prototype podemos reduzir consideravelmente o número de classes envolvidas.
Especificar novos objetos pela variação da estrutura. Este design permite que criemos objetos com partes e subpartes, desde que o nosso objeto composto implemente um clone profundo.

Desvantagem

A principal desvantagem é que cada subclasse do Prototype deve implementar a operação Clone, o que pode ser difícil. Casos onde as classes possuem referências circulares, ou que não suportam a operação de cópia, são exemplos dessa dificuldade.

Repositório GIT

Materiais de Estudo

Estamos chegando ao fim do nosso artigo e queria deixar alguns materiais que usei para estudar esse padrão de software:

Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos

Design Patterns - Builder

Nicolas de Souza — Fri, 17 May 2024 18:29:41 +0000

Seguindo os estudos sobre Design Patterns, hoje vou escrever um pouco sobre o Builder!

Objetivo do padrão

Builder é um padrão criacional que nos auxilia na criação de objetos complexos, passo a passo, permitindo a produção de diferentes tipos e representações de um objeto usando um mesmo código de construção

Qual problema ele resolve?

Imagine um objeto complexo com inúmeros campos, com objetos agregados, e que sua inicialização necessite da realização de inúmeros passos e interações. Poderíamos deixar que o cliente que usará nossa classe, fique responsável por implementar os passos, mas estaríamos assumindo um risco muito grande de que os passos não sejam respeitados, criando objetos com comportamentos errôneos.

Mas, Nicolas, eu poderia criar um objeto intermediário e passar ele na construção. Sim, você poderia resolver esse problema de inúmeras formas, mas ficaria intuitivo para outros dev's no futuro? Talvez sim.

Não pense nos padrões como regras absolutas, padrões são acima de tudo sugestões de modelos já consolidados no mercado para elucidar problemas comuns. Cabe a cada desenvolvedor a responsabilidade de interpretar se é uma boa ideia ou não, o famoso: depende!

Vamos usar um exemplo?!

Nos materiais que usei para estudar, os exemplos geralmente giram em torno de casas, carros... Isso por que é bem intuitivo entender que um mesmo objeto carro pode ser criado de inúmeras formas, manual, automático, com 2 ou 3 portas... Tentei fugir um pouco do óbvio, pode dar errado, então me contem nos comentários 🤞

Vamos pensar em um jogo de RPG, onde os jogadores podem montar o seu personagem. Cada personagem será construído de uma forma, com atributos e comportamentos diferentes um dos outros. Além disso, algo comum em alguns RPG's é a possibilidade de combinarmos tipos, por exemplo, posso criar um Mago Bárbaro e ter inúmeras combinações...

[!warning]
Farei inúmeras limitações, o objetivo aqui é explicar o padrão builder e não criar um jogo!

Para começar, vamos criar nossa classe personagem, será ela que terá n construções possíveis.

public class Personagem
{
    public int HP;
    public string nome;
    public List<string> classe; //bárbaro, mago...
    public Dictionary<string, string> atributos;    

}

Agora que já vimos nossa classe personagem, vamos construir nossa interface responsável por produzir tipos específicos de personagens.

public interface IBuilder
{
    void BuildMago(string _nome);

    void BuildBarbaro(string _nome);

    void BuildLandino(string _nome);
}

Agora podemos implementar o nosso IBuilder.

public class Builder : IBuilder
{
    private Personagem _personagem = new Personagem();

    public void BuildMago() 
    {
        _personagem.classe.Add("Mago"); 
        atributos.Add("AtaqueMagico", "20");
        atributos.Add("DanoMagico", "5");

    }

    public void BuildBarbaro()
    {       
        _personagem.classe.Add("Barbaro");
        atributos.Add("AtaqueFisico", "20");
        atributos.Add("DanoFisico", "10");
    }

    public void BuildLandino()
    {
        _personagem.classe.Add("Landino");
        atributos.Add("AtaqueFurtivo", "20");
        atributos.Add("DanoFurtivo", "2");
    }

    public Personagem GetPersonagem(string _nome, int dado)
    {
        this._personagem.nome = _nome;

        this._personagem.HP = dado*150;

        Personagem result = this._personagem;

        this.Reset();

        return result;
    }

    public void Reset()
    {
        this._personagem = new Personagem();
    }
}

Nesse ponto já poderíamos usar o builder para criar os nossos personagens, mas podemos também usar uma classe "Diretor", que no nosso caso será a classe Mestre. É dela (classe Mestre) o trabalho de realizar os passos necessários para que combinemos nossos Build de cada personagem, agregando propriedade e comportamentos.

public class Mestre

{
    private IBuilder _builder;
    
    public Mestre(IBuilder builder)

    {

        _builder = builder;

    }

    public Personagem BuildMagoBarbaro(string _nome, int dado)
    {
        _builder.BuildMago();

        _builder.BuildBarbaro();

        return _builder.GetPersonagem(_nome, dado);
    }

    public Personagem BuildMagoLandino(string _nome, int dado)
    {
        _builder.BuildMago();

        _builder.BuildLandino();

        return _builder.GetPersonagem(_nome, dado);
    }
}

Vamos ver como usaríamos estas classes?!


Console.WriteLine("Utilizando o Mestre ");

Console.WriteLine(mestre.BuildMagoBarbaro("Nicolas", 15).ToString());

Console.WriteLine(mestre.BuildMagoLandino("Maria Eduarda", 7).ToString());



Console.WriteLine("Utilizando o Builder ");

builder.BuildLandino();

Console.WriteLine(builder.GetPersonagem("Judith", 10));

Note que no último exemplo estou usando diretamente o Builder para construir um objeto simples. A saída pode ser visto aqui:

Olhando a implementação, já entendemos que podemos padronizar o objeto principal com diversas funcionalidades. Neste exemplo foquei nas propriedades (por ser mais fácil de implementar) mas poderíamos ter funções sendo implementadas de jeitos diferentes para cada objeto. Nosso personagem Mago poderia atacar com uma bola de fogo, nosso bárbaro ao atacar usaria uma clava, mas todos continuarão sendo Personagens do nosso RPG.

Repositório GIT

Materiais de Estudo

Estamos chegando ao fim do nosso artigo e queria deixar alguns materiais que usei para estudar esse padrão de software: