Forem: Juliane Pires

Design Patterns - 1 - Strategy (C#)

Juliane Pires — Thu, 13 Oct 2022 23:28:36 +0000

Padrões de projeto, ou design patterns, são bem importantes para escrever códigos limpos, manuteníveis, legíveis e bem estruturados de acordo com cada situação, ou seja, para trazer soluções elegantes para problemas recorrentes.

Para iniciar o estudo desses padrões, temos o padrão Strategy, um padrão comportamental que traz uma estratégia para lidar com a repetição e reaproveitamento de algoritmos em comum a diversas classes. Para isto, utilizamos interfaces que possuem uma definição desses métodos comuns e um conjunto de classes que implementam essa interface, concentrando toda a manipulação desse método no objeto e não tendo que criar código repetido em cada classe criada.

Para que fique mais claro, temos como exemplo uma calculadora de impostos, onde os métodos de cada imposto tem uma mesma estrutura, mudando apenas a taxa de acordo com o imposto escolhido. Para evitar que crie-se uma estrutura gigantesca com várias condicionais ou métodos, separamos os impostos em classes e criamos uma interface com a definição do método de cálculo do imposto recebendo o orçamento como parâmetro. As classes então implementariam a interface, sendo possível criar um único método na CalculadoraDeImpostos, lidando com o valor de acordo com a variância do método com o imposto definido.

Temos então a definição das classes de Impostos:

ICMS

using System;
namespace DesignPatterns.Impostos
{
    public class ICMS : Imposto
    {
        public double Calcula(Orcamento orcamento)
        {
            return orcamento.Valor * 0.1;
        }
    }
}

ISS

using System;
namespace DesignPatterns.Impostos
{
    public class ISS : Imposto
    {
        public double Calcula(Orcamento orcamento)
        {
            return orcamento.Valor * 0.6;
        }
    }
}

Concentradas em um diretório de impostos para manter a organização e facilitar a leitura/manipulação.

A interface Imposto traz então a definição do método Calcula, comum entre os diversos impostos:

Imposto

using System;
namespace DesignPatterns
{
    public interface Imposto
    {
        double Calcula(Orcamento orcamento);
    }
}

Na classe da calculadora de impostos, temos o método que recebe o orçamento e o tipo de imposto e chama o método Calcula informando o orçamento como parâmetro.

CalculadorDeImpostos

using System;
using DesignPatterns.Impostos;

namespace DesignPatterns
{
    public class CalculadoraDeImpostos
    {
        public void RealizaCalculo(Orcamento orcamento, Imposto imposto)
        {
            double valor = imposto.Calcula(orcamento);
            Console.WriteLine(valor);
        }
    }
}

Na classe orçamento, que recebe o valor, temos:

Orçamento

using System;
namespace DesignPatterns
{
    public class Orcamento
   {
        public double Valor { get; private set; }

        public Orcamento(double valor)
        {
            this.Valor = valor;
        }
    }
}

E então na classe Program, instanciamos um orçamento e um imposto e calculamos e realizamos o calculo informando essas propriedades:

Program

// See https://aka.ms/new-console-template for more information
using DesignPatterns;
using DesignPatterns.Impostos;

Orcamento orcamento = new Orcamento(500.00);

Imposto imposto = new ICMS();

CalculadorDeImpostos calculador = new CalculadorDeImpostos();

calculador.RealizaCalculo(orcamento, imposto);

A resposta no terminal será: 50.00.

Então, o padrão comportamental Strategy permite que uma família de algoritmos similares se conversem, mas sejam separados em classes, tornando o código desacoplado e bem distribuído.

Clean Code e a assimetria entre objetos e estruturas de dados

Juliane Pires — Sat, 01 Oct 2022 14:24:10 +0000

Talvez nós desenvolvedores tenhamos ouvido ou até reproduzido bastante a afirmação de que tudo na programação é objeto. O capítulo 6 do livro Clean Code, escrito pelo Robert C. Martin (também conhecido como Uncle Bob, ou tio Bob), explica porque nem sempre precisamos de objetos, às vezes precisamos somente de simples estruturas de dados e qual a diferença entre os dois conceitos.

Introdução

O capítulo começa questionando o porquê dos desenvolvedores exporem variáveis privadas como se fossem públicas através de métodos acessores (gets and sets), mesmo quando se quer preservar essas variáveis para que não gere dependência.

Abstração de Dados

A abstração de dados é super importante para que ocultemos os detalhes de nossos dados. Para isso, não utilizamos meramente métodos de escrita e leitura dos dados, isso faria com que ficassem expostos, nem tão somente trata-se de manipulação de métodos e funções. É necessário um entendimento da melhor maneira de manipular a essência dos dados que um objeto contenha, de maneira em que a implementação deste permaneça oculta.

Antissimetria data/objeto

Objetos ocultam seus dados através de abstrações e expõem métodos que manipulam esses dados.
Estruturas de dados expõem seus dados, mas suas funções não são significativas.

Ou seja, basicamente, as definições de objeto e estrutura de dados são quase que complementares.

Em resumo:

Em estruturas de dados, temos facilidade de adição de novas funções sem precisar alterar as estruturas de dados existentes, enquanto no código orientado a objeto, a facilidade está em adicionar novas classes sem alterar os métodos existentes.
Em estruturas de dados, temos dificuldade em adicionar novas estruturas de dados, pois demandaria a alteração de todas as funções. Enquanto que na programação orientada a objeto, a dificuldade está em adicionar novos métodos, pois demandaria a alteração das classes existentes.

O que é difícil em orientação a objeto é fácil para estruturas de dados e vice-versa. Assim, podemos tratar cada caso de acordo com o que for cabível e adequado.

Em casos em que desejamos adicionar novos tipos de dados sem alterar a função, o ideal seria utilizar a orientação a objeto, enquanto em casos em que desejamos adicionar novas funções mantendo os dados preservados, então estruturas de dados são mais adequadas.

Isso acaba respondendo o que foi questionado no início e desmistificando a afirmação de que em programação tudo é um objeto. Muitas vezes temos e desejamos estruturas de dados simples com funções operando sobre elas.

Lei de Demeter

A lei de Demeter é uma heurística (heurística: método que utiliza a pesquisa e prática para descobrir novos conceitos e provar fatos em busca de resposta para questões complexas) que afirma que um módulo não deve enxergar o interior dos objetos que ele manipula. Objetos abstraem os dados e expõem as operações sobre eles, ou seja, devem ocultar sua estrutura externa e não expô-la através de métodos acessores.

Mais precisamente, se temos uma função f em uma classe C, este só deve chamar métodos de:

C
Um objeto criado por f
Um objeto passado por parâmetro para f
Um objeto dentro de uma variável de instância C

Train Wrecks

Quando temos um código com métodos acoplados, como por exemplo:

const cep = ctx.getPessoa().getEndereco().getCep()

Chamamos de Train Wreck, pois a estrutura se comporta como um conjunto de vagões acoplados, se assemelhando a um trem. Esse tipo de código é considerado descuidado e inapropriado. O ideal seria escrevermos dessa maneira:

const pessoa = ctx.getPessoa();

const endereco = pessoa.getEndereco();

const cep = endereco.getCep();

A função getCep() possui acesso a muita informação em níveis aos quais não deveria ter acesso, certamente tem conhecimento de que o objeto ctx possui pessoas, que por sua vez possuem objetos do tipo endereco e, por consequência, possuem objetos do tipo cep.

Se isso é uma violação da lei de Demeter, dependerá se ctx, pessoa, endereco e cep são simples estruturas de dados ou objetos. Caso sejam objetos, não deveriam estar expondo sua estrutura interna, esta deveria estar oculta. Portanto, a informação sobre o seu interior viola a heurística. Por outro lado, caso sejam estruturas de dados simples, sua implementação interna é naturalmente exposta, não violando essa lei.

Esse questionamento acaba sendo menos confuso quando estruturas de dados simplesmente tem variáveis públicas e nenhuma função, enquanto objetos tem apenas variáveis privadas e funções públicas. Porém existem frameworks e padrões (como, por exemplo, o padrão beans) que demandam métodos acessores e de alteração, mesmo em estruturas de dados simples.

Híbridos

Estruturas híbridas são compostas por parte objeto e parte estruturas de dados. Essa configuração é ruim pois acaba expondo variáveis internas, fazendo com que funções externas tenham acesso a essas variáveis como numa estrutura de dados, assim como funções significativas e exposição de métodos acessores. O que dificulta tanto a adição de novas funções como a criação de novas estruturas de dados. São estruturas confusas, que não possuem coerência e devem ser evitadas.

Estruturas Ocultas

Devemos evitar que estruturas internas sejam expostas dentro de um objeto, ou que este não acabe se sobrecarregando de métodos para tratar informações. Para isso, utilizamos estruturas ocultas, métodos que lidem com a manipulação dessa estrutura sem expô-la ou comprometer a sua abstração.

Objetos de Transferência de Dados

Os DTO’s, ou objetos de transferência de dados, são basicamente classes que possuem variáveis públicas e nenhuma função. São estruturas úteis, especialmente para se comunicar com banco de dados ou analisar sintaticamente mensagens provenientes de sockets. São úteis para converter dados brutos vindos do banco de dados em objetos no código do aplicativo.

Active Record

Active Records são formas especiais de DTOs. São estruturas de dados com variáveis públicas, mas tipicamente possuem métodos de navegação como find e save. Os Active Records são traduções diretas das tabelas de bancos ou outras fontes de dados.

A solução para evitar que essas estruturas sejam tratadas como objetos, criando um híbrido entre uma estrutura de dados e um objeto, é tratar o Record Active como uma estrutura de dados e criar objetos separados que contenham as regras de negócio e ocultem seus dados internos.

Conclusão

Objetos expõem ações e ocultam seus dados, facilitando a adição de novos tipos de objetos sem modificar os métodos existentes e dificulta a inclusão de novas atividades em objetos existentes.
Estruturas de dados expõem dados e não possuem ações significativas, facilitando a adição de novos métodos sem afetar os dados existentes e dificultando a adição de novas estruturas em funções existentes.

Em um sistema, é desejável que haja flexibilidade para adicionar novos tipos de dados, para isso prefere-se o uso de objetos. Em outras ocasiões, queremos flexibilidade para adicionar novas ações, sendo preferível optar pela estrutura de dados e procedimentos. Portanto, cabe a nós desenvolvedores entendermos e decidirmos pela melhor estrutura aplicável no momento.

Event Bubbling

Juliane Pires — Tue, 28 Jun 2022 18:41:06 +0000

Referência

Você já reparou no comportamento de uma garrafa ou copo de refrigerante? Percebeu como as bolhas se deslocam do fundo até o topo do copo?

O event bubbling no javascript funciona de maneira similar, quando alguma ação ou interação com o HTML é feita por um componente filho, o evento que é causado por efeito colateral é propagado como uma "bolha" até o elemento pai, que lida com o mesmo.

Prática

Podemos observar os seguintes elementos:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <title>Page Title</title>
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <link rel="stylesheet" type="text/css" media="screen" href="main.css" />
    <script src="main.js"></script>
  </head>
  <body>
    <div onclick="alert('elemento pai')">
      FORM
      <div onclick="alert('elemento filho')">
        DIV
        <div onclick="alert('elemento neto')">P</div >
      </div>
    </div>
  </body>
</html>

Ao clicarmos no elemento neto temos o efeito bubbling e o evento será propagado e acionado nos demais elementos ancestrais, ou seja, ocorrerão três alertas:

alerta 1 “elemento neto”

alerta 2 “elemento filho”

alerta 3 “elemento pai”

Como essa propagação só ocorre entre os ancestrais, esse movimento nos três elementos só funciona partindo do elemento neto. Caso o clique seja aplicado no elemento filho, a propagação trará o seguinte resultado:

alerta 1 “elemento filho”

alerta 2 “elemento pai”

Podemos verificar o comportamento:

Interromper Propagação

Para que a propagação seja interrompida, devemos utilizar o stopPropagation. Assim, quem lidará com o evento será o próprio elemento e não chegará aos elementos ancestrais.

Podemos observar então esse comportamento:

Ao clicarmos no elemento filho, a propagação não irá ocorrer para o elemento pai porque foi interrompida, o mesmo não ocorrerá para o elemento neto pois a propagação só funciona para elementos ascendentes.

Também podemos observar que, após o clique no elemento neto, o evento se propaga para o elemento filho e para nele, interrompendo a propagação.

É isto!

Para mais informações, aqui fica o artigo de inspiração eventBubbling Javascript