DEV Community: Marcus Xavier

Como as linguagens de programação são criadas?

Marcus Xavier — Sun, 04 Aug 2024 19:30:24 +0000

Introdução

Nós usamos linguagens de programação diariamente, e as vezes pode parecer que o computador está fazendo uma mágica: você escreve um arquivo de texto e o computador magicamente executa as operações que esse arquivo descreve.

Quando eu era criança, existia um desenho animado chamado "De onde vem?". A cada episódio algo era explicado, como por exemplo, "De onde vem o vidro?". Era uma explicação simples e de fácil entendimento, porém bem satisfatória.

Com isso em mente, a ideia desse artigo, é explicar um pouco sobre de onde vêm as linguagens de programação. Nesse post, eu pretendo explicar um pouco sobre como uma linguagem pode ser implementada, e por fim, trazer alguns materiais de estudo bem interessantes para quem deseja se aprofundar e quem sabe programar a sua própria linguagem.

Para que uma linguagem tome vida, é preciso implementá-la

Antes de mais nada, precisamos separar muito bem dois conceitos: a ideia abstrata da linguagem, e a sua implementação concreta (um interpretador ou compilador).

Uma linguagem nada mais é do que uma forma de se comunicar, é uma sequência de letras organizadas de forma a passar uma mensagem.

O problema é: computadores não entendem palavras, nem mesmo sequências esquisitas de letras (o comando LDS, por exemplo). Tudo o que o computador entende, são instruções pra sua CPU. Então é necessário ter algum software capaz de pegar as operações descritas na nossa linguagem (o print('hello world'), por exemplo), e transformar isso em instruções para o computador interpretar, de alguma forma.

Ou seja, precisamos de uma implementação concreta para que nossa linguagem possa ser executada. Nesse artigo, sempre que eu falar "linguagem", eu estou me referindo à essa implementação concreta e prática que traz utilidade para o amontoado de texto colorido que escrevemos.

E esses programas capazes de executar linguagens têm nome: interpretadores e compiladores.

O que são interpretadores e compiladores? E qual a diferença entre eles?

O que é um compilador?

De forma muito resumida, um compilador é um programa que transforma o seu código fonte, em outro tipo de representação, que geralmente é uma forma mais eficiente para o computador executar. O software que pega seu código C, e transforma em binário executável, é um compilador. Mas o software que pega o código typescript (main.ts), e transforma em javascript (main.js) para ser executado no navegador, também é um compilador.

Ou seja, um compilador não é necessariamente um programa que lê código numa linguagem X e cospe código binário. Esse programa basicamente tem a responsabilidade de transformar seu código em algo alguma representação que possa ser executada de alguma forma, mas essa representação pode ter várias formas.

O que é um interpretador?

Por outro lado, um interpretador é um programa que lê o seu código fonte, e de alguma forma, executa as instruções que ele contém. Só isso, então quando você passa código javascript para o Nodejs, ele está agindo como um interpretador: lendo código fonte, e interpretando-o. E algumas interpretadores usam compiladores para os auxiliarem no processo de interpretador uma linguagem.

A linguagem PHP por exemplo, tem uma espécie de máquina virtual chamada Zend, que recebe uma representação compilada do seu código fonte, e executa as instruções dessa representação.

Pera, então linguagens interpretadas também podem ser compiladas?

Sim, isso é algo um pouco confuso no início, mas a ideia principal é que interpretadores e compiladores não são opostos. Um compilador tem um papel muito claro, e esse papel é diferente de um interpretador.

Muitas linguagens interpretadas usam a técnica de ter uma espécie de máquina virtual, extremamente otimizada, que recebe uma coisa que chamamos de bytecode e executa isso. Então, a máquina virtual de linguagens como PHP e Python, não são capazes de entender seu código e por isso precisamos da ajuda de compiladores, para gerar bytecode a partir do seu código (imagine como um assembly para uma máquina virtual).

No fim das contas, quando falamos que uma linguagem é "interpretada", simplesmente queremos dizer que você precisa sempre passar o seu código fonte para um programa (o node ou python, por exemplo), e esse programa já vai rodar o seu código.

E quando uma linguagem é "compilada", primeiro você precisa passar seu código fonte para um programa (o gcc ou tsc, por exemplo), que irá gerar um novo arquivo, e daí sim poderemos executar esse arquivo de alguma forma.

Ok, entendi de onde vêm as linguagens, mas como eu posso criar uma implementação?

Eu diria que o caminho mais prático pra quem está começando é criar um interpretador, que utiliza a técnica de tree walk para interpretar o código. Esse estilo de implementação é quebrada em 3 componentes principais: scanner, parser e o interpretador tree walk.

O seu código passará por esses 3 componentes nessa ordem mesmo, onde a cada etapa, o interpretador transforma o seu código em estruturas cada vez mais fáceis de serem interpretadas pelo computador.

Esse fluxograma simples mostra o caminho do código fonte da sua linguagem até a fase da interpretação.

Vou explicar (com códigos de exemplo) cada uma dessas etapas.

Scanner

Nessa fase o seu código fonte é lido como uma string (sequência de caracteres) e quebrado em vários tokens. Esse token é uma unidade da sua linguagem de programação, como por exemplo as palavras reservadas while e if, ou então os literais como "isso é uma string" ou 10.

Então, isso:

Vira isso:

Essa imagem é só pra exemplificar a quebra do código fonte em tokens, geralmente o "token" é um objeto/estrutura contendo algumas informações importantes como:

O seu tipo (ser é um for, um número, operador ++ e etc.).
O seu lexema (a string que achamos na hora de escanear esse token).
Em qual linha ele foi encontrado (ajuda bastante na hora de aportar erros de sintaxe).

Um exemplo de token seria:

class Token {
    public function __construct(
        public readonly TokenType $tipo,
        public readonly mixed $valor, // Válido somente para valores literais como "strings" e números (10.5) explícitos no código fonte
        public readonly string $lexema,
        public readonly int $linha
    ){}
}

Parser

Nessa fase já possuímos os tokens, mas esse monte de tokens ainda não possui significado algum, não possui semântica. Então o parser vai transformar esse amontoado de tokens em algo mais palpável: uma árvore, representando as operações. Chamamos essa árvore de "Parse Tree".

Uma parse tree é uma estrutura de capaz de representar fielmente a estrutura do seu programa, respeitando as regras de precedência (por exemplo, no código const x = 5 * 5, precisamos executar o código 5 * 5 antes de executar o código de atribuição const x = ... que irá receber o valor do resultado)

Por exemplo, imagine a expressão 10 + 5 * 2. Ela pode ser representada assim na parse tree:

Na parse tree, cada item (chamamos de nó da arvore) tende a representar uma operação feita no código. Onde cada nó por sua vez pode conter várias ramificações e se tornar uma árvore, com outros nós representando operações mais aninhadas na expressão.

Também é bom lembrar que a imagem acima é um exemplo, e um nó de uma parse tree pode ser um objeto/estrutura com várias informações úteis, como por exemplo, assim pode ser um nó que guarda operações binárias (uma operação com dois operandos, como soma ou multiplicação):

class BinaryExpr extends Expr
{
    public function __construct(
        public readonly Expr $esquerda,
        public readonly Token $operador,
        public readonly Expr $direita
    ){}
}

Nesse nó eu salvo a ramificação de expressões à esquerda e direita, que podem ser uma variável (x + 4), uma chamada de função (pegaNoBanco(x) + 4) ou um literal (10 + 4). E também guardo o token que possui informações do operador dessa expressão (+, *, etc.).

Interpretação Tree Walk

As duas primeiras fases são praticamente iguais pra QUALQUER implementação de uma linguagem, mas a partir dessa fase, cada linguagem vai escolher suas técnicas para dar vida à parse tree. Existe uma infinidade de técnicas, e nessa artigo vamos abordar uma das mais diretas: A Tree Walk.

Como o nome sugere, a ideia é percorrer a árvore de expressões e ir computando os nós mais profundos primeiro e indo subindo até a raiz da árvore.

Na implementação do Phortugol, eu usei pattern matching pra ter uma função que conseguia interpretar cada tipo de nó da árvore e me retornar um resultado

    public function evaluate(Expr $expr): mixed {
        return match(true) {
            $expr instanceof BinaryExpr => $this->handleBinary($expr),
            $expr instanceof UnaryExpr => $this->handleUnary($expr),
            $expr instanceof LiteralExpr => $this->handleLiteral($expr),
            $expr instanceof LambdaExpr => $this->handleLambdaExpr($expr),
            ...
        };
    }

Então sempre que eu chamar a função evaluate passando uma ramificação da árvore, ele vai saber exatamente qual função chamar pra interpretar o nó atual, e no fim das contas essa função continuará sendo chamada até o resultado de todas as operações chegar à raiz da arvore e obtermos o resultado final da expressão.

Por exemplo, a parse tree anterior seria interpretada da seguinte forma:

Um fato curioso, é que as primeiras versões de Ruby e PHP usavam essa técnica de tree walk. Então é totalmente possível construir uma linguagem funcional usando um tree walk interpreter.

conclusão

Ufa finalmente chegamos ao fim. Eu expliquei a ponta do iceberg, tem várias técnicas que eu não cobri, e não falamos sobre coisas como compilação e nem otimização de código (essa parte é bem mindblowing). Mas eu espero que já seja possível ter um modelo mental mais acurado sobre o que acontece quando digitamos o código e mandamos o computador rodar.

Caso você tenha se interessado pelo assunto, tenho algumas recomendações:

O livro crafting interpreters. É absurdamente bom, eu gostaria que mais áreas da computação tivessem um livro com a mesma qualidade, pragmatismo e simplicidade sem perder profundidade.
Essa playlist sobre parsers top down, os dois primeiros vídeos são a melhor explicação sobre o "Recursive Descent Parser" que eu já vi. Recomendo usar como material de apoio

Iniciando no Elasticsearch: Conceitos básicos

Marcus Xavier — Thu, 18 Apr 2024 14:11:12 +0000

Introdução

Segundo o site oficial do Elasticsearch, ele é uma engine RESTFul distribuída de busca. Esse monte de palavras basicamente querem dizer que ele é um banco de dados que funciona de forma distribuída por natureza (pode usar várias máquinas em paralelo de forma super fácil) e que expõe uma API RESTFul para que o usuário interaja com o banco, seja escrevendo ou buscando dados, entre outras coisas.

O Elasticsearch é uma ferramenta incrível quando o assunto é trabalhar com uma quantidade massiva de dados e fazer buscas em textos longos (diga adeus aos select like %texto% lentos). Ele é a base do sistema de buscas de milhares de empresas, e muito provavelmente você tem contato diariamente com algum software que usa Elasticsearch por baixo dos panos.

Antes de mais nada, um pouco de história

Sempre que estou estudando uma tecnologia nova, gosto de entender porque essa ferramenta foi criada e em qual contexto ela nasceu. O Elasticsearch foi criado em 2010, mas podemos dizer que sua história começa em 2004 quando Shay Banon iniciou um projeto chamado Compass, com o intuito de ser usado no sistema de buscas em um app de receitas para sua esposa. O projeto nasceu de forma despretensiosa e só foi se tornar open source tempos depois.

Um fato curioso: nesse mesmo ano (2004) nascia o projeto que atualmente é um dos principais concorrentes do elastic, o Apache Solr.

Todos esses projetos nasceram mais ou menos com o mesmo objetivo em mente: realizar buscas de texto de forma muito eficiente usando por baixo dos panos o Apache Lucene, projeto criado em 1999 usando Java. O Apache Lucene é a base de quase todos os softwares de busca atualmente, sendo por exemplo usado pelo twitter para buscar milhões de tweets diariamente.

Mas voltando ao assunto, o Shay Banon criou o Compass em 2004, e quando estava criando a versão 3.0 do projeto em 2010, reescreveu várias partes do projeto para que ele fosse distribuído por natureza e altamente escalável. E daí nasce o Elasticsearch.

O Elasticsearch foi criado então, para ser uma forma fácil de usar todo o poder do Apache Lucene, enquanto fornece uma forma extremamente simples de escalar seu projeto horizontalmente, usando e abusando de computação distribuída.

Termos comuns do Elasticsearch

Ao iniciar os estudos sobre Elasticsearch é normal se deparar com vários termos novos, e achar a ferramenta complicada por causa disso. A ideia aqui é explicar os principais termos deste banco de dados, e mostrar quando esse termo tem algum paralelo no mundo dos bancos relacionais.

Documento

É basicamente como uma row/linha no banco de dados relacional. A diferença está no fato de documentos serem salvos como objetos JSON.
Quando você fizer buscas na API de _search do elastic, vai encontrar documentos com essa estrutura.

Os dados salvos pelo usuário estão dentro de _source, os outros campos são metadados adicionados pelo banco de dados.

{
    "_index": "produtos",
    "_type": "_doc",
    "_id": "1234",
    "_score": 2.0,
    "_source": {
        "nome": "Notebook",
        "descricao": "bla bla bla", // Essa descrição pode ser facilmente buscável no elastic, e eu eu sei que JSON não aceita comentário
        "preco": "4000"
    }
}

Índice

É basicamente uma coleção de documentos do mesmo tipo. Ou seja, é como uma tabela de um banco de dados relacional.

Node

Um node é uma instância do Elasticsearch que salva dados. Para salvar terabytes de dados no elastic, você pode ter vários nodes, cada um guardando um pedaço dos dados.
Assim você pode escalar em várias máquinas diferentes, mesmo que cada uma tenha só alguns gigabytes de armazenamento, cada uma rodando os nodes que pode.
Teoricamente falando, é como se cada node fosse um arquivo.

Cluster

Se nodes são arquivos, clusters são pastas. Eles basicamente agrupam os nodes e te permitem buscar em todos esses nodes em busca dos dados que você quer.
Geralmente um cluster serve a um propósito. Então é possível ter um cluster para ter a busca de produtos no seu e-commerce, e outro cluster guardando os seus logs, por exemplo.

Outros termos do Elastic

Field é como se fosse uma coluna da tabela do banco relacional. No Json do documento, "nome" é um field e "preco" é outro.
Mapping é como o schema de um banco de dados relacional. Por exemplo, é o mapping que guarda o tipo de cada Field
Shard é um pedaço do seu índice. O elastic por padrão quebra seu índice em vários pedaços e distribui entre os nodes do cluster, daí vem a computação distribuída que mencionei anteriormente.

Arquitetura "básica" da API Restful do elastic

Enquanto outros bancos de dados usam conexão TCP para se comunicar com o cliente, e exigem um driver específico para cada linguagem, o Elastic usa simplesmente uma API RESTful HTTP. Isso significa que qualquer linguagem com uma lib de requisições HTTP consegue se comunicar facilmente com o elastic (embora existam clients específicos para facilitar esse trabalho também).

As estruturas básicas de um endpoint do elastic são as seguintes:

{url_cluster}/<seu_indice>/<_operação>
// ou
{url_cluster}/<_ação_no_cluster_inteiro>/<_operação>

Geralmente, as operações começam com underscore (_), tipo _search, _update, _delete, _bulk, etc. E na maioria dos casos, se você colocar a url do cluster e em seguida um nome sem underscore, como no primeiro exemplo, ele vai inferir que é um índice seu.

Como a API é RESTful, cada operação tem um verbo HTTP associado.
Para buscar dados, seja buscar documentos ou dados sobre o cluster, você usa o verbo GET, para criar um novo documento você usa o verbo POST e assim por diante.

Alguns exemplos de requisições para essa API são:

# Buscar dados de saúde do cluster
curl -X GET "localhost:9200/_cluster/health"

# Atualizar o mapping de um índice
curl -X PUT "localhost:9200/meu_indice/_mapping" -H 'Content-Type: application/json' -d'
{
  "properties": {
    "nome_produto": {
      "type": "text"
    }
  }
}

Como o Elastic consegue buscar texto de forma tão rápida?

Como dito anteriormente, o elastic é baseado no Apache Lucene, e o Lucene usa uma técnica chamada inverted index para buscar texto de forma eficiente. Um índice invertido é basicamente uma lista de palavras que apontam para os documentos que contém essa palavra. Por exemplo, se você tem o documento de id 1 com o texto "O rato roeu a roupa do rei de Roma", e o outro de id 2 com "O gato comeu a roupa do rato", o índice invertido seria algo como:

{
    "rato": [1, 2],
    "roeu": [1],
    "roupa": [1, 2],
    "rei": [1],
    "roma": [1],
    "gato": [2],
    "comeu": [2]
}

E quando você busca por "roupa", o elastic vai buscar no índice invertido a palavra "roupa" e vai te retornar os documentos 1 e 2.

Então, buscando a frase "O rato comeu queijo", ele vai perceber que o documento 2 tem duas palavras da busca ("rato", "comeu"), e vai te retornar o documento 2 com um score maior que o documento 1, pois o documento 1 só tem uma palavra da busca ("rato").

Por isso o nome é índice invertido, pois ele inverte a lógica de busca. Em vez de buscar palavras em documentos, ele busca documentos em palavras. Isso é simples, mas extremamente eficaz.

Claro, existem outras otimizações, como usar um Vector Space Model para calcular similiridade entre documentos e o texto buscado, mas a ideia básica é essa.

Conclusão

Bom, esse foi um resumo básico do que é o Elasticsearch, porque ele foi criado e como ele consegue buscar texto de forma tão eficiente, além de ser um overview de como funciona a API RESTful.
Nos próximos artigos aprenderemos a fazer queries e usaremos o docker para subir um cluster do elastic e uma instância do Kibana, uma ferramenta muito útil para visualizar e interagir com clusters do elastic. Até lá!

Entendendo A Função Reduce - Parte 2

Marcus Xavier — Tue, 29 Nov 2022 14:48:10 +0000

Eu dei uma relida no artigo sobre reduce que tinha publicado anteriormente, e percebi algumas coisas que eu gostaria de adicionar, vamos lá. Se você não leu o artigo anterior, eu recomendo ler.

Tipos de retorno no reduce

O reduce recebe uma lista do tipo X (onde X pode ser um objeto, um número, qualquer coisa) e geralmente te retorna um único valor do tipo X, vamos dizer que isso é do tipo [X] -> X.

Mas isso não é obrigatório. É bem possível que o reduce te retorne um outro tipo (nesse caso seria [X] -> Y), ou seja, pode receber uma lista de inteiros e retornar uma string ou um objeto, por exemplo.

Vou exemplificar com código logo abaixo. Aqui eu tenho duas funções. Na primeira eu recebo uma lista de números, e retorno um único numero (que é a soma de todos os valores dessa lista). Isso seria [X] -> X.

Mas na segunda função, eu recebo uma lista de strings e retorno uma lista de objetos, isso seria [X] -> Y.

//Tipo [X] -> X
[1,2,3,4].reduce((acc, value) => acc + value)
//retorna 10

//Tipo [X] -> Y
//Aqui eu recebo uma lista de pessoas,
//e quero criar uma lista de objetos
//Onde cada pessoa está com o score zerado
['nome', 'aleatorio'].reduce((acc, value) => acc.concat({name: value, score: 0}), [])
//retorna [ { name: 'nome', score: 0 }, { name: 'aleatorio', score: 0 } ]

No Javascript, geralmente, se você chama seu reduce sem passar um valor inicial, ele será do tipo [X] -> X. Já se você quiser fazer algo do tipo [X] -> Y, geralmente, terá que passar um valor inicial, que é o segundo parametro da função reduce, logo após a sua função anônima. No exemplo acima eu coloquei um array vazio.

Debuggando o reduce

Bom, a ideia aqui é criar um reduce, e ir passo a passo pra ver o que ele está fazendo. Primeiro vou reimplementar a função somador e ver como os valores vão mudando a cada passo, como aconteceria num debugger mesmo. Depois explicarei um exemplo um pouco mais complexo (e útil).

const values = [1,2,3,4,5]
values.reduce((acc, value) => acc + value)

//isso aqui, na verdade é
[1,2,3,4,5].reduce((acc, value) => acc + value)

Agora vamos lá. Se você não passar um valor inicial (como eu não passei), o JS irá pegar o primeiro item do array pra ir pro acc, e vai começar a rodar a partir do segundo, ou seja, vai colocar o segundo item no value. Então dando um passo e nosso estado seria isso aqui

//              1     2        1   +  2 = 3
[3,4,5].reduce((acc, value) => acc + value)

O resultado dessa soma irá sobrescrever o valor de acc, que passará a ser 3. Vamos dar mais um passo. Atualmente o nosso acc é um 3, e o nosso value irá pegar o valor do próximo item do array. Que por coincidência é um 3 também

//            3    3         3   +  3 = 6
[4,5].reduce((acc, value) => acc + value)
//Agora vamos rodar até a lista esvaziar

//          6    4         6   + 4 = 10
[5].reduce((acc, value) => acc + value)

//          10   5        10  + 5 = 15
[].reduce((acc, value) => acc + value)

Certo, agora o nosso acc vale 15, e a nossa lista está vazia, o que acontece agora? Bom, quando a lista está vazia, o reduce simplesmente pega o que está no acc e retorna para o usuário. É por isso que o exemplo abaixo retorna o valor 1, e não o valor 500.

//Eu vou passar 1 como valor inicial para a minha função.
//ou seja, o acc começará valendo 1
//Mas como a minha lista está vazia, o código return 500 nem rodará,
//o reduce vai retornar 1 logo
[].reduce((acc, value) => {return 500}, 1)
//retorna 1

Resolvendo um problema possivelmente real

Bom, agora vem o "debugging" mais complexo que citei anteriormente. Imaginemos que você recebe uma lista de objetos que representam a pontuação dos usuários, e você quer definir qual usuário ganhou. Existem várias formas de resolver esse problema, e uma delas é o reduce.

const scores = [
{ name: 'Huguinho', score: 20},
{ name: 'Zezinho', score: 25},
{ name: 'Luizinho', score: 15}]

Agora que nós temos a lista de pontuações, é só rodar no nosso reduce

scores.reduce((previousValue, actualValue) => {
    if (actualValue.score > previousValue.score) return actualValue
    else return previousValue
})

Como eu não quero "acumular" um valor nesse caso, eu preferi chamar o meu primeiro parâmetro como "previousValue" (valorAnterior) e o segundo como "actualValue" (valoarAtual).

A ideia aqui é basicamente olhar se o meu actualValue tem um score maior que o previousValue, se ele tiver, eu retorno o actualValue, sobrescrevendo o que tem no previousValue.

Agora, caso o score do meu previousValue seja maior ou igual ao do meu actualValue eu retorno o previousValue, ou seja, eu basicamente estou deixando o mesmo valor que tinha no previousValue. Não estou tratando o caso de empate aqui.

Coloquei esse else pra deixar claro que retorna um ou outro, nesse caso ele é opcional.

//Vamos dar o primeiro passo então
//como não passei valor inicial o reduce faz o mesmo esquema de antes
//que é pegar o primeiro item e colocar no acumulador (valor anterior),
//e botar o segundo item no valor atual

const scores = [
{ name: 'Huguinho', score: 20},
{ name: 'Zezinho', score: 25},
{ name: 'Luizinho', score: 15}]

//                              {name: 'Huguinho'...} {name: 'Zezinho'...}
[{ name: 'Luizinho', score: 15}].reduce((previousValue, actualValue) => {
//                 25     >              20 é true
    if (actualValue.score > previousValue.score) return actualValue
    else return previousValue
    //retorno o meu actualValue (pontuação do zezinho)
})

Como o score do meu valor atual é maior do que o do valor anterior, eu retorno o meu valor atual, sobrescrevendo o previousValue com ele. Agora o nosso próximo passo está assim.

//   {name: 'Zezinho'...} {name: 'Luizinho'...}
[].reduce((previousValue, actualValue) => {
//                 15     >              25 é false
    if (actualValue.score > previousValue.score) return actualValue
    else return previousValue
    //retorno o previousValue (pontuação do zezinho)
})

E como o meu valor atual não tem um score maior do que o anterior, vamos retornar o valor anterior para ser salvo no nosso acumulador (ou previousValue nesse caso), basicamente deixando do mesmo jeito que estava.

O reduce irá rodar novamente e verá que a lista está vazia, aí ele simplesmente retornará o que tiver no meu acumulador. E nesse caso isso é a pontuação do zezinho. { name: 'Zezinho', score: 25}.

Se você quiser tirar a prova, abra o node ou o console do navegador e rode o código completo abaixo

const scores = [
{ name: 'huguinho', score: 20},
{ name: 'zezinho', score: 25},
{ name: 'luizinho', score: 15}]

scores.reduce((previousValue, actualValue) => {
    if (actualValue.score > previousValue.score) return actualValue
    else return previousValue
})

Conclusão

Bom, esse artigo serviu mais para explicar melhor como o reduce computa os valores da lista e reduz um [X] em outra coisa como um X ou um Y.

Ainda existem muitas coisas para serem abordadas, por exemplo: como map e filter são derivados do reduce, como é uma recursão por trás do reduce, como usar os outros dois parâmetros da função interna do reduce que nós ainda não usamos.

Mas por hoje ficamos por aqui. Eu posso abordar esses temas em artigos futuros.

Clean Code: Classes

Marcus Xavier — Mon, 28 Nov 2022 12:51:44 +0000

TL;DR

Classes deveriam ser pequenas, deveriam fazer somente uma coisa e deveriam ter somente um motivo para mudar

Classes deveriam ser pequenas

Existe um milhão de motivos para odiar classes grandes: o código fica com aspecto de bagunçado, existem literalmente dezenas de métodos que podem fuçar em todos os atributos da classe, o que aumenta a chance de algum erro passar despercebido, e também é uma porcaria se "mover" na classe, você pula pra um método privado da classe, e vai pra 1000 linhas abaixo de onde você estava.

Já as "classes pequenas", por outro lado, são mais simples de manter, pois elas não fazem muitas coisas então a preocupação de causar um efeito colateral ao mudando algo é menor. Em geral, quando você bate o olho no nome de um "Classe pequena" já é possível ter uma ideia do que ela faz (se o nome for bom, obviamente).

"Classes pequenas", também são mais fáceis de testar, pois elas costumam a ser menos acopladas com coisas externas, isso significa menos mocks no teste, o que é sempre bom 😀.

Mas o que raios é uma "Classe Pequena"?

Acho que isso foi o suficiente pra mostrar que classes gigantes são uma merda geralmente. E agora vem a próxima pergunta: como eu defino o que é uma classe pequena?
Muitas pessoas vão lembrar do capitulo sobre funções e pensar que também é possível definir se a classe é pequena ou não, se baseando na sua quantidade de linhas (seu tamanho), mas isso não poderia estar mais incorreto.

Usar a quantidade de linhas para classificar uma classe seria muito vago, e por isso o uncle bob nos recomenda pensar no bom e velho S do SOLID (Principio da Responsabilidade Única).

A ideia aqui é, ao invés de contar a quantidade de linhas para ver se a classe é pequena, nós iremos contar a quantidade de "responsabilidades" que a classe possui. Se tiver mais do que uma responsabilidade, geralmente é hora de dividir essa classe em classes menores.

Ok, e como eu sei se a minha classe tem mais de uma responsabilidade?

Bom, o uncle bob também apresenta algumas formas bem interessantes de verificar isso.

A primeira forma é, na hora de criar o nome da classe, tentar dar um nome descritivo para ela. Se você tentar e não conseguir criar um nome descritivo, e ao mesmo conciso, pode ser que a classe tenha mais de uma responsabilidade.

Outra forma de ver isso é tentar escrever uma pequena descrição de uma 25 palavras explicando por cima o que a classe faz. Se você usar palavras como "mas", "se", "e", "ou", também pode ser que a sua classe tenha mais de uma responsabilidade. Aqui vai um exemplo do livro:

"A SuperDashBoard provê acesso ao último componente utilizado e também nos permite acompanhas [metadados como] o número da versão e build."

E por fim você pode pensar "motivos para mudar", ao invés de "responsabilidades". Pense, "em quais situações, ou por quais motivos, eu teria de mudar o código dessa classe?". Se existir mais de um motivo para mudar, está bem claro que a sua classe tem mais de uma "responsabilidade" ou "razão para existir".

O que você prefere?

Eu já vi pessoas reclamando de que dividir seu sistema classes pequenas acaba gerando PRs maiores do que simplesmente fazer do modo "quick and dirty", tudo dentro de uma classe.

Outras pessoas também podem argumentar que ter uma sistema repleto de arquivos de classes é mais complexo de gerenciar. Mas o autor do livro argumenta que a complexidade do sistema não tende a mudar muito por causa disso, e deixa a seguinte reflexão.

"Você prefere as suas ferramentas organizadas em armários repletos de pequenas gavetas, cada uma contendo componentes bem definidos e bem nomeados? Ou prefere umas poucas gavetas onde você joga tudo lá?"

Clean Code: Testes

Marcus Xavier — Wed, 16 Nov 2022 13:52:21 +0000

Falar que testes são importantes pra mantenabilidade do código é chover no molhado, mas é sempre bom ter em mente que nem todo teste trás tanto benefício assim.

Testes que quebram o tempo todo, são difíceis de estender e complicados de entender, são mais prejudiciais do que benéficos para a sua codebase, e o autor explica o porquê nesse trecho.

"Ter testes 'sujos' é o equivalente ou até mesmo pior do que não ter testes. O problema é que testes precisam ser modificados enquanto o código de produção evolui e quanto mais os seus testes forem 'sujos', mas difícil será mudar eles."

O que faz um teste ser "limpo"? Legibilidade, Legibilidade, Legibilidade

Segundo o autor, a legibilidade talvez seja até mesmo mais importante no código dos testes do que o código de produção. Testes legíveis têm clareza, simplicidade e densidade de expressão. O dois primeiro pontos são meio óbvios, e o terceiro significa que os seus testes precisam expressar o máximo de informação usando o mínimo de linhas possíveis. O que nos leva pra segunda dica.

Pode ser boa ideia tentar minimizar a quantidade de assertions nos seus testes

E isso não quer dizer que você precise deixar de testar algum caso, simplesmente significa que é sempre bom tentar abstrair as suas assertions. Se você der um nome descritivo para a função que está abstraindo as suas assertions, isso pode até mesmo ajudar o leitor a entender a intenção do seu código.

Vou mostrar um exemplo abaixo de um código Go que eu fiz para testar quando o usuário fazia uma requisição http para pegar a definição de uma palavra.

É bom lembrar que em Go, nós fazemos "assertions" usando um if mesmo, e não chamando um assertEquals da vida. Então considere cada if como uma asserção no código.

func TestGetDefinition(t *testing.T) {
    t.Run("User retrieve word definition successfully", func(t *testing.T) {
        server := makeFakeServer(200, []byte(wordDefinition))
        got, _ := GetDefinition(server.URL)
        response := createResponse(
            "To shrink, cower, tense or recoil, as in fear, disgust or embarrassment.",
            "He cringed as the bird collided with the window.",
            "cringe",
        )

        if !reflect.DeepEqual(got, response) {
            t.Errorf("got %v want %v", got, response)
        }

        if got.Normalize().Word == "" {
            t.Errorf("normalized word from response %v shouldn't be empty", got)
        }

    })

    t.Run("word dont exists", func(t *testing.T) {
        server := makeFakeServer(404, []byte("I dont know"))
        _, err := GetDefinition(server.URL)
        if err != IO.NotFoundError {
            t.Errorf("got %q want %q", err, IO.NotFoundError)
        }
    })
}

Eu não considero esse código de teste como o ideal, por que ele não tem muita densidade de expressão, ou seja, ele não passa a sua ideia de forma enxuta e isso obriga o leitor a ler bem mais coisa do que ele deveria. Nós podemos refatorar o teste para ficar dessa forma.

func TestGetDefinition(t *testing.T) {
    t.Run("User retrieve word definition successfully", func(t *testing.T) {
        server := makeFakeServer(200, []byte(wordDefinition))
        got, _ := GetDefinition(server.URL)
        response := createResponse(
            "To shrink, cower, tense or recoil, as in fear, disgust or embarrassment.",
            "He cringed as the bird collided with the window.",
            "cringe",
        )

        checkSuccessResponse(t, got, response)
    })

    t.Run("word dont exists", func(t *testing.T) {
        server := makeFakeServer(404, []byte("I dont know"))
        _, err := GetDefinition(server.URL)

        checkFailResponse(t, err, IO.NotFoundError)
    })
}

//Meus testes acabaram, daqui pra baixo só temos funções auxiliares

func checkSuccessResponse(t testing.TB, got, want DictionaryApiResponse) {
    t.Helper()

    if !reflect.DeepEqual(got, want) {
        t.Errorf("got %v want %v", got, want)
    }

    if got.Normalize().Word == "" {
        t.Errorf("normalized word from response %v shouldn't be empty", got)
    }
}

func checkFailResponse(t testing.TB, got, want error) {
    t.Helper()

    if got != want {
        t.Errorf("got %q want %q", got, want)
    }
}

Nesse exemplo acima, eu "diminuí" a quantidade de assertions por teste simplesmente abstraindo a checagem das responses. Os testes ainda têm a mesma cobertura, mas o código dos testes ficou mais simples e enxuto. O número de linhas desse arquivo pode ter aumentado, mas a parte mais importante (o código que testa) está menor.

Claro, é sempre bom lembrar de ter bom senso, eu não acho uma boa ideia criar um milhão de funções auxiliares só para que seus testes tenham uma única assertion.

Cada teste deveria testar um único conceito

Nós não queremos um teste enorme que testa vários cenários, esses tipos de testes podem ser mais práticos de escrever, mas costumam ser bem chatas de manter, por que se esse teste quebrar, você pode precisar ter de debuggar o teste inteiro, o que irá te dar muito mais trabalho do que debuggar um código menor que testa somente um conceito.

Pegue como exemplo o código acima, se nós misturássemos todos os testes em um único teste, a própria Legibilidade desse teste ficaria comprometida, mesmo que os dois testes mostrados acima sejam bem simples.

TL;DR

Bons testes tem uma boa legibilidade. Testes ruins mais atrapalham do que ajudam, pois eles tendem a ser bem mais difíceis de modificar à medida que o sistema evolui.

Abstrair as assertions dos seus testes pode ser uma boa ideia, mas é importante ter bom senso. Não misture conceitos diferentes no mesmo teste, se você está testando o caso de sucesso em um teste, é melhor criar um novo teste para testar o caso de exceção do que testar tudo no mesmo teste.

Clean Code: Formatação

Marcus Xavier — Sat, 12 Nov 2022 16:33:55 +0000

Introdução

A primeira impressão que tive sobre o capítulo sobre formatação é que ele só teria obviedades, afinal, formatar código não tem muito segredo, mas eu vi algumas provocações interessantes que gostaria de compartilhar.

Por exemplo, se eu perguntasse que código funcionando é a coisa mais importante no trabalho de um Programador, a grande maioria das pessoas diria que sim. E o uncle bob no começo do capítulo lança uma provocação e diz que isso não é verdade.

Segundo o autor, comunicação eficiente (o que engloba uma formatação de código eficiente) é o principal trabalho de um desenvolvedor. E com "comunicação" eu entendo que ele também engloba código legível e fácil de manter. O Uncle bob expressa muito bem esse ideia nesse parágrafo abaixo.

"as funcionalidades que você cria hoje têm uma boa chance de serem alteradas na próxima release, mas a legibilidade do seu código vai ter um profundo efeito em todas as mudanças que estarão por vir. Estilo de código e Legibilidade setam precedentes que continuarão a afetar a mantenabilidade e extensibilidade do código muito depois do código original ser modificado a ponto de ser tornar irreconhecível. Seu estilo e disciplina sobrevivem, mesmo que seu código não".

Antes de mais nada, a melhor formatação tende a ser aquela que a equipe inteira segue

Uma das primeiras coisas que o autor menciona nesse capítulo é que você deveria escolher algumas regras simples em conjunto com a sua equipe e todos seguirem essas regras. Parece bobo, mas padronizar esse tipo de coisa deixa o código mais uniforme e constante.

E em pleno 2022 você não precisa nem se preocupar em formatar seu código, existem inúmeras ferramentas (como o prettier por exemplo) que formatam seu código com base em algumas regras pré definidas.

Por isso também, é sempre bom procurar seguir convenções das linguagens e frameworks. Se todo mundo usa snake_case em python, por que você usaria camelCase?

Cada "bloco" de código deveria funcionar da mesma forma que um parágrafo

Em um texto bem escrito, geralmente o ideal é que cada parágrafo represente uma ideia. Ou seja, ideias diferentes, ao longo do texto você vai desenvolvendo suas ideias, e vai separando elas em parágrafos, pois assim você terá um texto bem formatado naturalmente, ao invés de ter um bloco enorme de palavras que é péssimo de ler.

A mesma ideia se aplica à código. Eu sei que algumas pessoas não gostam de colocar espaços em branco no código, mas eu tenho uma opinião forte (e o autor corrobora com a minha opinião) de que "blocos" de código deveriam representar alguma "coisa", e "coisas" diferentes deveriam estar em blocos separados.

Por exemplo:

Versão com tudo junto

function ignoreUserThreads(data) {
  const threads = getThreads()
  threads.forEach((thread) => {
    if (data.needIgnoreThisUser(getAuthorName())) {
      thread.style = 'display: none;'
    }
    function getAuthorName() {
      return thread.getAttribute('data-author');
    }
  })
}
function muteBlacklist(data) {
  const threads = getThreads()
  threads.forEach(thread => {
    if (data.threadTitleIsBlacklisted(getTitle(thread))) {
      thread.style = 'display: none;'
    }
  })
}
function getThreads() {
  return document.querySelectorAll('.js-threadList>.structItem')
}
function getTitle(thread) {
  try {
      return thread.querySelector('.structItem-title').innerText
  } catch(e) {
      return ''
  }
}

Versão com código separado

function ignoreUserThreads(data) {
  const threads = getThreads()

  threads.forEach((thread) => {
    if (data.needIgnoreThisUser(getAuthorName())) {
      thread.style = 'display: none;'
    }

    function getAuthorName() {
      return thread.getAttribute('data-author');
    }
  })
}

function muteBlacklist(data) {
  const threads = getThreads()

  threads.forEach((thread) => {
    if (data.threadTitleIsBlacklisted(getTitle(thread))) {
      thread.style = 'display: none;'
    }
  })
}

function getThreads() {
  return document.querySelectorAll('.js-threadList>.structItem')
}

function getTitle(thread) {
  try {
      return thread.querySelector('.structItem-title').innerText
  } catch(e) {
      return ''
  }
}

O que você prefere? Eu particularmente prefiro a segunda opção

Seja gente fina com o leitor do código, tente colocar coisas relacionadas o mais perto possível

Uma das coisas que eu mais detesto é ter que ficar indo pra cima e pra baixo no código pra entender o que está acontecendo nele. E uma das formas de mitigar isso é deixando códigos que se relacionam, o mais próximo um do outro.

Eu particularmente gosto de ler código de cima pra baixo, como se fosse um texto mesmo, então se a função A chama a função B, eu sempre tento deixar a função A em algum lugar por cima da função B, e nunca o contrário. Por exemplo:

def a:
    b()

def b:
    #do something

Claro que nem sempre isso é possível por N questões, mas é sempre bom tentar fazer isso pra facilitar a vida do leitor 😁.

TL;DR

Geralmente é melhor seguir um estilo de código já definido do que inventar moda. Baixe um formatador de código automático (como o prettier ou phpcbf, por exemplo).

Separe os os seus blocos de código com espaços, a leitura desse artigo ficaria péssima se não tivesse espaços separando os blocos de texto, por que você acha que seria diferente com o seu código?

Clean Code: Fazendo bom uso das funções | Parte 2

Marcus Xavier — Sat, 12 Nov 2022 14:41:25 +0000

Esse artigo é a continuação do tema "funções", por favor leia a parte 1 primeiro.

Um nível de abstração por função

Para garantir que a nossa função faz somente uma coisa, nós precisamos ter certeza que os pedaços de código dentro da função estão no mesmo nível de abstração.

O que eu quero dizer com isso é que se uma parte da sua função está cuidando de coisas bem abstratas, não faz muito sentido misturar isso com detalhes de implementação logo abaixo. Vou mostrar um trecho de código para clarificar isso.

Esse método abaixo faz parte de uma classe que tem como responsabilidade buscar dados do usuário. Essa função em específico precisa pegar a primeira venda do usuário.


public getFirstOrder(userId: number)
{
    cachedOrder = client.get(
                   `orders.userId`, (err, reply) => {
                      if (err) throw err;
                      return reply
                  })

    if (!cachedOrder) {
        return cachedOrder;
    }

    return this.getFirstOrderInDB(userId);
}

No código acima eu tento pegar o pedido no cache, se não tiver no cache eu pego o valor do banco de dados. No começo eu fiz algo como um nível muito baixo de abstração que no caso foi chamar o client.get e logo no fim da função eu chamei a função getFirstOrderInDB que é algo muito mais abstraído.

Um código assim não fica muito bom, na minha opinião, porque estamos fazendo algo com pouca abstração num cenário onde poderia ter muito mais abstração.
Olhe agora o exemplo abaixo.

public getFirstOrder(userId: number)
{
    cachedOrder = this.getOrderFromCache(userId);

    if (!cachedOrder) {
        return cachedOrder;
    }

    return this.getFirstOrderInDB(userId);
}

Não mudou praticamente nada, só a busca no cache que foi abstraída. Essa simples mudança deixou o código mais limpo e simples.

Escreva código para ser lido de cima pra baixo

Eu gosto bastante dessa dica e tento sempre seguir ela. Me surpreende isso ser uma coisa tão pouco debatida. A ideia é você escrever o seu código com muita abstração no começo do arquivo, e a parte do código menos abstraída (ou seja, as funções que foram chamadas pelas funções no topo do arquivo) devem ficar mais abaixo no arquivo.

Por exemplo, no trecho de código anterior a função getFirstOrder é mais abstraída, logo deveria ficar mais acima. Já as funções getOrderFromCache egetFirstOrderInDB devem ficar no final do arquivo por que estão em um nível mais baixo de abstração (talvez essas duas últimas funções podem até mesmo ser métodos privados).

Use nomes descritivos

O seus nomes precisam descrever o que a função faz, por isso é bom ter funções pequenas e que fazem somente uma coisa. Bons nomes são tão importantes que esse foi assunto do primeiro artigo dessa série de posts, você pode conferir lá ótimas dicas para escolher bons nomes.

Cuidado ao passar booleanos como parâmetro da sua função

Nessa parte o autor diz que passar booleanos como parâmetro para a sua função pode ser um sinal de que a sua função faz mais de uma coisa, pois ela pode fazer uma coisa se o parâmetro for true e outra coisa caso seja false.

Claro, nem sempre é possível evitar isso, mas caso você tenha uma situação com a citada acima, pode ser interessante fazer uma função para caso determinado valor seja true e outra para caso seja false

Você deve evitar códigos como o abaixo

public class CompanyRepository
{
    public void CreateOrUpdate(Company company, bool create)
    {
        if (create) {
            ...
        }
        else {
            ...
        }
    }
}

E preferir fazer códigos como esse aqui

public class CompanyRepository
{
    public void Create(Company company) { ... }
    public void Update(Company company) { ... }
}

Error Handling é uma coisa

Lembra que no mundo ideal cada função faria somente uma coisa? então, error Handling é uma coisa. Segundo o autor, se a sua função tem um bloco de try catch ou algo do tipo, não deveria haver nada além disso. Ao invés de abrir o bloco try e colocar um monte de código nele, você deveria pegar todo o código dentro do try e colocá-lo em uma nova função.

Conclusão

Ufa, finalmente terminamos de cobrir o capítulo sobre funções. Esse capítulo nem é tão grande, mas como ele é cheio de pérolas interessantes sobre como escrever funções "melhores", eu não quis deixar ele muito resumido.

É sempre bom lembrar que nem mesmo o autor do livro escreve funções boas logo de cara (ele fala sobre isso no final do capítulo), a ideia é primeiramente fazer algo que funciona, depois se preocupar em fazer o seu código seguir as boas práticas citadas acima.

E pra finalizar esse artigo, deixo um insight do uncle bob que achei bem interessante.

"Programadores experientes veem os sistemas como histórias a serem contadas em vez de programas a serem escritos.[...]Mas jamais se esqueça de que seu objetivo verdadeiro é contar a história do sistema, e que as funções que você escrever precisam estar em perfeita sincronia e formar uma linguagem clara e precisa para lhe ajudar nessa narração"

Clean Code: Fazendo bom uso das funções | Parte 1

Marcus Xavier — Sun, 25 Sep 2022 15:25:54 +0000

Parafraseando o próprio uncle bob, funções são a primeira linha de organização de qualquer programa. Ou seja, na maioria das linguagens, uma função (ou método) é a "menor" forma de organizar seu código.

Você pode ter classes, interfaces e tudo mais, mas dentro disso tudo estarão funções mantendo sua codebase organizada. Ou bagunçada, depende de como você as usa. Eu diria que essa é uma das partes mais importantes dessa série de artigos justamente por isso.

Pequenas!

Aqui o autor diz que funções deveriam ser pequenas, e eu concordo totalmente com isso. Raramente existe um motivo plausível para que as suas funções tenham mais do que vinte e cinco linhas. Nessa seção do livro, o uncle bob é mais extremista e diz que uma função pequena tem por volta de quatro linhas.

Você pode pensar que ele enlouqueceu, mas em algumas linguagens como haskell é até comum ver uma codebase inteira composta em sua maioria por minúsculas funções de quatro ou cinco linhas.

O código fica muito mais organizado e bonito dessa forma, na minha opinião. O problema é que muitas vezes acabamos o código de forma apressada e damos muitas responsabilidades pra mesma função. Não tem problema fazer isso, contanto que limpe o seu código depois.

Praticamente todo editor hoje em dia fornece a opção de selecionar um bloco de código e extrair uma função (ou seja, pegar esse bloco e automaticamente jogar numa nova função). Trate de configurar essa opção no seu editor pra ontem, é muito útil pra refatorar o código.

Nada de Hadouken, por favor

O autor sugere que as suas funções tenham somente um ou dois níveis de identação no máximo, ou seja, você deveria ao máximo evitar aninhados. Sério, se tem um if aninhado no seu código, ele muito provavelmente poderia ser abstraído em uma nova função.

Outra dica polêmica do uncle bob, da qual eu gosto bastante, é que deveria ter somente uma linha de código em blocos como if, else, while, etc. Eu acho essa dica um pouco extrema em algumas situações, mas se estiver um monte de coisa acontecendo dentro do seu if, isso provavelmente deveria ser abstraído dentro de um novo método (lembra que as suas funções deveriam ser pequenas? 🙃).

Faça somente uma coisa, e faça direito

Fazer uma função que faz mais de uma coisa fere tantas "boas práticas" que é até difícil de listar todas, mas os principais problemas de ter uma função "multitarefa" são:

Fere o princípio de responsabilidade única do SOLID
Como a função faz várias coisas, fica muito mais difícil dar um nome descritivo pra ela
Muito provavelmente não será uma função pequena

Essa dica de criar funções que fazem somente uma coisa já é algo extremamente antiga, desenvolvedores muito inteligentes já aplicavam isso nos anos 70. No desenvolvimento do Unix o programadores fizeram ferramentas que faziam somente uma coisa, mas faziam direito.

Por exemplo, o comando history serve para mostrar o seu histórico de comandos rodados no terminal. O comando grep pode ser usado para filtrar texto.
E pronto, caso eu queira ver todos os comandos do git que eu rodei no terminal, basta rodar o comando history combinado com o grep pra filtrar o resultado e me mostrar somente os comandos que contenham a palavra git.

Mas nós temos um problema, escrever funções que fazem somente uma coisa (e fazem isso direito), não costuma ser uma tarefa trivial. Pode ser complicado dizer se a sua função é multitarefa ou não.

O exemplo abaixo é uma função de um CLI meu que salva palavras em inglês que o usuário não conhece (para poder adicioná-las no anki depois), e dá ao usuário a opção de printar a definição dessa palavras desconhecida no terminal.

func(cmd *cobra.Command, args []string) {
    definition, _ := cmd.Flags().GetBool("definition")
    sentence := getSentenceFromArgs(args)

    if definition {
        url := "https://api.dictionaryapi.dev/api/v2/entries/en/" + sentence
        response, err := dictionary.GetDefinition(url)
        if err == IO.NotFoundError {
            IO.PrintRed(os.Stdout, "word not found on dictionary api\n\n")
        }
        if err == nil {
            PrettyPrintDefinition(response.Normalize())
        }
    }

    saveSentence(sentence)
}

Esse função é multitarefa? Parece ser, não é? E se nós abstrairmos o código dentro desse if?

func(cmd *cobra.Command, args []string) {
    definition, _ := cmd.Flags().GetBool("definition")
    sentence := getSentenceFromArgs(args)

    if definition {
        printDefinition(sentence)
    }

    saveSentence(sentence)
}

func printDefinition(sentence string) {
    url := "https://api.dictionaryapi.dev/api/v2/entries/en/" + sentence
    response, err := dictionary.GetDefinition(url)
    if err == IO.NotFoundError {
        IO.PrintRed(os.Stdout, "word not found on dictionary api\n\n")
    }
    if err == nil {
        PrettyPrintDefinition(response.Normalize())
    }
}

Será que agora a função faz somente uma coisa? Bom, vamos listar o que a nossa função está fazendo.

Pegando os dados que o usuário passa, e ver se o usuário passou a flag definition no comando, para ver no terminal a definição da palavra que ele está adicionando
verificar se o usuário quer ver a definição da palavra, caso ele queira, printar isso na tela.
salvar a sentença que o usuário está adicionando para estudar no anki mais tarde.

Bom, como podemos ver, o nosso código ainda está "fazendo" três, será que nós conseguimos abstrair esse código ainda mais pra que ele faça somente uma coisa? Vamos ver

func(cmd *cobra.Command, args []string) {
    // finalmente a minha função faz SOMENTE uma coisa
    saveSentenceAndPrintDefinition(cmd, args)
}

// Mas espera, agora eu gerei uma função com assinatura igual à anterior
func saveSentenceAndPrintDefinition(cmd *cobra.Command, args []string) {
    // Esse código está exatamente igual antes, agora somente mudou de lugar
    definition, _ := cmd.Flags().GetBool("definition")
    sentence := getSentenceFromArgs(args)

    if definition {
        printDefinition(sentence)
    }

    saveSentence(sentence)
}

func printDefinition(sentence string) {
    url := "https://api.dictionaryapi.dev/api/v2/entries/en/" + sentence
    response, err := dictionary.GetDefinition(url)
    if err == IO.NotFoundError {
        IO.PrintRed(os.Stdout, "word not found on dictionary api\n\n")
    }
    if err == nil {
        PrettyPrintDefinition(response.Normalize())
    }
}

Viram? Existe um ponto onde não vale mais a pena ficar extraindo métodos da sua função principal para que ela fique "menos multitarefa". Depois de certo ponto você está simplesmente jogando o código para outro canto, sem melhorar em nada a sua legibilidade e mantenabilidade.

Ou seja, uma boa forma de saber se seu código chegou no "ponto certo" e está seguindo a regra do "Faça somente uma coisa" é ver se mais uma extração de função irá melhorar seu código ou se irá simplesmente pegar o seu código atual e jogá-lo em outro canto, como aconteceu no nosso último exemplo.

Conclusão

Eu pretendia fazer somente um artigo para abordar o bom uso da função, mas as funções são tão importante para a programação, que existem inúmeras boas práticas e dicas para se fazer um excelente código com elas. Colocar tudo em um único artigo deixaria ele enorme.

Por isso pretendo fazer mais um ou dois artigos abordando mais dicas para escrever boas funções, como por exemplo, evitar efeitos colaterais e evitar receber um milhão de parâmetros.

Entendendo A Função Reduce - Parte 1

Marcus Xavier — Sun, 18 Sep 2022 20:24:16 +0000

Introdução

Faz um tempo que eu não escrevo nenhum blogpost. Nesse período eu andei estudando haskell e achei uma função que bem interessante chamada fold, mas essa função é mais conhecida como reduce. O que faz essa função ser bem interessante é o fato de que ela contém bastante informação em pouquíssimas linhas de código.

Implementando um simples problema

Só pra mostrar um pouco do que o reduce é capaz de fazer, vamos imaginar um problema hipotético: Você recebe uma lista de compras que um cliente fez, e precisa somar todos os valores dessa lista.

Aviso

Muitas linguagens fornecem funções pra somar os valores de uma lista, mas vamos implementar a nossa própria função só por questões didáticas.

Primeiro eu vou implementar essa função no bom e velho PHP escrevendo sem usar reduce, só com um foreach mesmo.

Depois vou implementar usando Javascript e reduce, e por fim vou mostrar como seria essa função em haskell

Versão no PHP

// Crio uma lista simples só pra poder testar depois
$array = [1,2,3,4,5,6,7,8,9,10];

//Aqui vou fazer um foreach simples e somar os valores do meu array
function sumArrayValues($array) {
    $value = 0;
    foreach($array as $item) {
        $value += $item;
    }
return $value;
}
sumArrayValues($lista);
//Output: 55

Versão JS com reduce

//Crio a lista
let lista = [1,2,3,4,5,6,7,8,9,10]

//Sim, a função só tem uma linha
let somador = (acumulador, valor) => acumulador + valor
lista.reduce(somador, 0)
// Output: 55

Versão em haskell

lista = [1..10] -- Cria uma lista de 1 até 10
foldl (\x acumulador -> x + acumulador ) 0 lista
-- Output: 55
-- Ou então nós poderíamos ter feito isso aqui que daria o mesmo resultado
foldl (+) 0 lista

Como você pode ver, o reduce torna seu código muito menos verboso, e na minha opinião, esse jeito minimalista e declarativo é bem elegante, mas creio que seja justamente por isso que a função fold (mais conhecida como reduce) seja tão incompreendida.

Tendo isso em vista, vamos então entender com calma o que a função reduce está fazendo por baixo dos panos.
Pra entender como o reduce funciona, nós vamos implementar a nossa própria versão dele, da forma mais explicita possível.

Implementando nosso próprio reduce

Vou usar javascript, mas funcionaria com praticamente qualquer linguagem.
Aqui está a definição original do array.reduce

array.reduce(function(total, currentValue, currentIndex, arr), initialValue)

Mas como os parâmetros currentIndex e arr são opcionais, vou fazer uma definição mais simples para explicar de forma mais didática.

Obs: O parâmetro initialValue também é opcional, mas eu considero ele importante demais para omitirmos na nossa implementação

array.reduce(function(acumulador, currentValue), initialValue)

//mas vamos criar uma função que recebe o array como ultimo parâmetro
meuReduce(function(acumulador, valorAtual), valorInicial, lista)

Agora vamos implementar logo a nossa versão simplificada do reduce

function meuReduce(funcaoAnonima, acumulador, lista) {
    // No reduce eu basicamente vou percorrer a minha lista e ir salvando no meu acumulador
    // o resultado da minha função anônima
    // Eu usei um for, mas poderia ser feito usando recursão também.
    for(let i = 0; i < lista.length; i++) {
        //Aqui o meu acumulador vai receber o resultado da computação da minha função anônima
        // Veja que eu estou usando "=" e não "+=".
        // Por isso estou passando o meu acumulador pra minha função
        // A ideia é como se ele estivesse sendo incrementado
        acumulador = funcaoAnonima(acumulador, lista[i])
    }
    //Por fim eu simplesmente retorno o meu acumulador
    return acumulador
}

E se eu chamar a minha nova função, tudo deve funcionar

//Se você quiser, pode copiar o codigo acima e esse aqui e colar no console do navegador pra ver o resultado também
const somador = (acumulador, valor) => acumulador + valor

const multiplicador = (acumulador, valor) => acumulador * valor

const dobra_array = function(acumulador, valor) {
    acumulador.push(valor * 2) //Aqui o meu valor inicial precisa ser um array vazio
    return acumulador
}

let lista = [1,2,3,4,5,6,7,8,9,10]
meuReduce(somador, 0, lista)
// Output: 55

meuReduce(multiplicador, 1, lista) //o valor inicial precisa ser 1, pois se for 0 vai zerar a multiplição
// Output: 3628800

meuReduce(dobra_array, [], lista)
// Output: [2, 4, 6, 8, 10, 12, 14, 16, 18, 20]

//Se você fizer lista.reduce(dobra_array, []) o resultado será o mesmo

Sim, eu diria que uma das principais funções do reduce é pegar uma lista de itens e retornar um único item. Como nas duas primeiras funções onde nós pegávamos umas lista de inteiros e REDUZÍAMOS a lista a somente um inteiro.

Mas também é possível que nosso reduce receba uma lista e retorne outra lista. Basta que o valor inicial seja um array vazio, para que o acumulador consiga usar a função push para colocar itens dentro de si.

Recapitulando

Bom, esse artigo já está ficando grande demais, então vamos somente recapitular o que aprendemos antes de finalizar:

O reduce (mais conhecido como fold em algumas linguagens) é uma função que pode fazer muitas coisas com poucas linhas de código
A função reduce é bastante usada para pegar uma lista de valores e reduzir essa lista a somente um item.
O reduce recebe uma função anônima que será aplicada ao acumulador e a cada item da sua lista, recebe um valor inicial para o acumulador, e recebe a própria lista
A função anônima deve receber como parâmetro, no mínimo o seu acumulador e o item atual da sua lista (lembre-se que a função vai ser chamada dentro de um loop que vai varrer toda a sua lista). Além desses dois itens obrigatórios algumas linguagens te permitem colocar mais parâmetros na sua função anônima, mas esses são opcionais.

E é isso pessoal. Foi bom escrever um pouco sobre essa função que é bem confusa de se entender quando vemos ela pela primeira vez.

Clean Code: Escolhendo bons nomes

Marcus Xavier — Sun, 18 Sep 2022 01:17:49 +0000

Introdução

Clean code é provavelmente um dos livros mais famosos do desenvolvimento de software, provavelmente todo desenvolvedor já ouviu o nome desse livro.

A ideia dessa série de artigos é servir como um pequeno resumo pessoal sobre o que vi no livro. Eu achei vários insights interessantes enquanto lia e anotei eles para que eu pudesse revisar, mas senti que anotações soltas com zero contexto não são muito boas pra revisar.

Por isso pretendo não só compartilhar esses insights, mas também divagar sobre cada uma das dicas apresentadas e colocar um pouco de código pra contextualizar o que está sendo dito.

É sempre bom deixar claro que o livro Clean Code não é nenhum magnum opus da computação e nem tem pretensão de ser. O próprio autor do livro deixa bem claro que não se deve levar a ferro e fogo 100% do que é dito no livro. Então não vamos desapontar o uncle bob, ok 😉?

Use nomes que revelam a intenção do código

Segundo o autor do livro, excelentes nomes são capazes de responder perguntas como essas aqui abaixo.

Por que a classe "X" existe?
Qual é a finalidade da função "Y"?
O teste "A" testa o que exatamente?
Eu consigo imaginar com um pouco de precisão a aparência do componente "Z" só com base no nome dele?

E eu concordo bastante com essa visão. Excelentes nomes te dão um certo contexto geral do que está acontecendo no código e isso pode poupar bastante tempo de leitura.

O problema é que criar excelentes nomes é uma tarefa bem difícil, raramente me vem à mente o nome perfeito quando estou codificando, principalmente se eu não tiver uma visão clara do que o código deve fazer.

Felizmente, hoje em dia quase todo editor te dá a possibilidade de renomear coisas no código de forma extremamente simples e rápida. Então, se você ainda não usa isso no seu editor, trate de configurar essa funcionalidade pra ontem. E se você tiver uma boa cobertura de testes, mudar o nome de algo é mais seguro ainda.

Pra mostrar outro exemplo real disso, vou pegar um trecho de código em Go de um projeto pessoal meu.
Eu troquei os nomes das funções e parâmetros que estou usando num trecho de código. Você consegue entender com facilidade o que está se passando no código abaixo?

func sentence(item string, files ...string) {
    for _,file := range files {
        if testItem(item, file) {
            color.Red("sentence '%s' already exists on file %s\n", item, file)
            os.Exit(3)
        }
    }
}

func testItem(item, file string) bool {
    buffer := read(file)
    return compare(item, buffer)
}

Agora, vamos para o código original. Leia novamente o trecho de código.


func CheckIfSentenceExists(sentence string, filePathList ...string) {
    for _,filePath := range filePathList {
        if hasSentence(sentence, filePath) {
            color.Red("sentence '%s' already exists on file %s\n", sentence, filePath)
            os.Exit(3)
        }
    }
}

func hasSentence(sentence, filePath string) bool {
    var buffer string = ReadFile(filePath)
    return verifyIsSentenceExists(sentence, buffer)
}

Os nomes mais descritivos ajudam mesmo a entender o funcionamento do código com o mínimo de contexto possível, não é?

Confesso que não acho esse trecho de código o mais legível que eu já escrevi, mas com uma boa nomenclatura de métodos (e claro, testes) eu consigo entender facilmente o que o código deveria fazer, mesmo depois de um tempo sem tocar no projeto.

Enfim, sempre que possível veja se seus nomes estão respondendo perguntas como as mencionadas mais acima.

Use e abuse de enums, constantes e afins

Muitas vezes nos vemos na situação em que precisamos usar um valor hardcoded no nosso código, tipo, o nosso valor não vai mudar e só vamos usá-lo em algum lugar, logo bate a vontade de simplesmente colocar o valor que você quer e pronto.
Quando surgir uma situação parecida, coloque esse valor dentro de uma constante ou variável, ou então se você estiver mexendo com números crus que representam algo além de um simples número, use um Enum ou algo parecido que é fornecido na sua linguagem.


function IgnoreVideos()
{
   let videos = Array.from(document.querySelectorAll("selector"));

   videos
   .filter(function (video) {
        return parseInt(video.querySelectoAll("selector").innerText.replace(".", "")) < 1000;
    })
    .forEach(function(video) {
        video.style.display = "none"
    });
}

Duas coisas podem ser feitas para melhorar muito a clareza do código. Nós poderíamos jogar aquele valor do parseInt numa variável que indica o que é o valor sendo guardado, e podemos usar um const para guardar aquele número 1000 hardcoded.


function IgnoreVideos()
{
   let videos = Array.from(document.querySelectorAll("selector"));

   videos
   .filter(function (video) {
        const MINIMUM_VIEWS = 1000;
        let numberOfViews = parseInt(video.querySelectoAll("selector").innerText.replace(".", ""));

        return numberOfViews < MINIMUM_VIEWS;
    })
    .forEach(function(video) {
        video.style.display = "none"
    });
}

Essa mudança não foi nada de extraordinário e sendo sincero eu nem achei que o nome da constante seja bom, mas o simples fato de adicionar nome a coisas que antes eram só um monte de código já trouxe muito mais clareza pra esse trecho de código.

Outra melhoria seria jogar esse código que pega o número de views em uma função, pois além de tirar esse innerText.replace feio da nossa frente, também tornaria o código reaproveitável e nós poderíamos escolher um bom nome pra essa função, deixando ainda mais claro o que o nosso código faz.

Procure nomear variáveis com nomes que indicam o que está sendo mensurado e a sua unidade

Imagine que eu preciso criar uma variável para guardar o número de dias que a minha entrega demorou pra chegar dos correios. Eu poderia usar uma variável chamada days, é um nome OK, mas podemos achar um nome melhor ainda.
Para descobrir qual nome usar, vamos responder as duas perguntas abaixo.

O que essa variável está guardando?

R: O número de dias decorridos desde que eu fiz o meu pedido.
Qual é a "unidade" dessa variável, ou seja, que tipo de valor eu estou guardando e qual é a sua ordem de grandeza?

R: Aqui quando eu digo "tipo" não estou me referindo se o valor é uma string ou um int, mas sim qual a ordem de grandeza do meu valor salvo, ou seja, esse tempo decorrido está sendo mensurado em dias, segundos ou milissegundos? Informar isso é importante para evitar confusões futuras (usar um valor em milissegundos achando que eram dias, por exemplo). Enfim, eu quero guardar o tempo decorrido em dias, então a unidade da minha variável é um dia.

Pronto, com essas duas informações fica mais simples decidir um nome para nossa variável: Por que ao invés de usar o nome days, nós não usamos o nome elapsedTimeInDays? É um nome que descreve o que nós guardamos (elapsedTime (Tempo decorrido)) e salva a unidade desse tempo que são dias.

Caso eu precisasse fazer uma variável para guardar quanto tempo eu consegui ficar sem respirar, uma boa opção de nome seria elapsedTimeInSeconds.

Se possível, use nomes que são "buscáveis"

Não sei quanto a você, mas eu busco nomes no meu código o tempo inteiro, seja porque eu tenho uma rota e quero descobrir qual Controller é usado por ela, ou então pra achar onde uma função é usada.

O problema é que quando o nome é genérico demais, fica péssimo de fazer buscas assim no código porque você vai receber vários resultados inúteis para sua busca, simplesmente porque existem várias coisas no código com um nome parecido com o nome buscado.

Uma boa forma de resolver isso é evitar ao máximo usar nomes genéricos no código. Um exemplo de nome genérico seria a variável days do trecho acima.

Evite também usar variáveis de uma só letra porque buscar por essa variável depois será como procurar agulha no palheiro. A única situação onde que acho plausível usar uma variável com esse tipo de nome é dentro de um for.

Conclusão

Bom, esse artigo já está ficando um pouco grande então vamos parar por aqui. O tema de nomes é algo extremamente importante para o desenvolvimento de software, não é atoa que esse tema é abordado logo no segundo capitulo do livro, e por isso eu acho importante que praticar dar bons nomes às coisas no seu código, e ter sempre à mão alguma ferramenta para refatorar código e trocar o nome de algo sem muita dor de cabeça (testes pra garantir que nada foi quebrado são sempre bem vindos).

No próximo artigo eu pretendo abordar o assunto de funções. Em minha humilde opinião a função é a unidade de código mais importante em um software. Fazendo o bom uso das funções seu código tende a ser organizado e fácil de manter, não importando qual paradigma você está usando.

Guia fundamental da programação orientada a objetos - Final

Marcus Xavier — Sat, 16 Apr 2022 18:57:54 +0000

Agora que nós já vimos os pilares da POO e a sua importância, está na hora de abordar mais alguns aspectos importantes de orientação a objetos neste último artigo. Vamos falar um pouco sobre classes abstratas, interfaces e classes finais (conhecida como classe selada em algumas linguagens).

O que são classes abstratas?

Elas são classes que não podem ser instanciadas. Ou seja, você não pode criar objetos a partir de uma classe abstrata. Aí você pode pensar: “Mas pra que serve uma classe que não pode virar objeto?”. Bom, você ainda pode fazer herança com uma classe abstrata, e é aí que vem a grande utilidade delas. Imaginemos que eu queira implementar algumas classes de Pagamento. Uma pra pagamento via cartão de crédito, outra para pagamento com boleto, e por fim uma para pagamento via pix.

Muitas coisas nessas três formas de pagamento são bem parecidas, não? Sempre existe uma pessoa que paga, um horário em que o pagamento e também o seu valor. Essas informações podem, e devem ser abstraídas, não faz o menor sentido ficar repetindo coisas atoa.

E é aí que nós podemos criar uma classe PagamentoBase que não vai ser capaz de realizar um pagamento, mas terá a responsabilidade de guardar essas partes comuns a todos os tipos de pagamento.

E não faz o menor sentido criar uma instância de PagamentoBase, já que ele não é uma classe responsável por fazer o pagamento em si, mas para abstrair ao máximo coisas para as outras classes usarem. Então nesse caso, nós podemos marcar essa classe como sendo abstrata, então será impossível de criar um objeto a partir de PagamentoBase.

Claro, classes abstratas também podem ter outras responsabilidades dependendo de como você as implementa, mas na minha visão, a principal função delas é abstrair coisas para que outras classes “normais” consigam usar e se beneficiar, aumentando a reusabilidade do código.

Além disso, lembre-se que também é possível sobrescrever os métodos da nossa classe abstrata, então, por exemplo, eu posso sobrescrever o método de notificar o usuário quando o pagamento é feito com sucesso.

Abaixo implemento o exemplo citado nos parágrafos anteriores.

<?php

abstract class PagamentoBase
{
    protected float $valor;
    protected DateTime $dataPagamento;
    //etc...

    public function notificarUsuarioSobrePagamento(): void
    {
        //imagine uma implementação
    }
    //Temos mais metodos abaixo que estão invisiveis...
}


class PagamentoViaCartao extends PagamentoBase
{
    private int $numeroCartao;
    //etc...

    //imagine que tem alguns métodos aqui
}

class PagamentoViaBoleto extends PagamentoBase
{
    //Imagine que eu implementei alguns metodos aqui também
}

class PagamentoViaPix extends PagamentoBase
{
    public function notificarUsuarioSobrePagamento(): void
    {
        //A implementação é diferente pois como o pix é instantaneo
        //eu preciso enviar essa notificação o mais rápido possivel.
    }

    //temos mais metodos e atributos nessa classe...
}

O que são interfaces?

A primeira coisa que você precisa ter em mente é que interface NÃO são classes, logo é impossível instanciar objetos a partir da interface. Mas você pode pensar, “se eu não consigo criar objetos a partir de interfaces, como que eu vou usar elas no meu código?”, e eu vou te responder que interfaces são usadas como se fossem ”contratos”.

Quando você assina um contrato, você é obrigado pela lei a cumprir o que está escrito no contrato. Ou seja, o contrato é uma forma de garantir que tu cumpra o que prometeu cumprir. Interfaces funcionam de forma parecida.

Digamos que eu tenha uma classe Carro, e uma classe Moto, e você concorda comigo que todo veículo precisa andar para ser útil, não é mesmo? Então, nessa situação, se essas classes não tiverem um método andar(), elas serão inúteis pra mim, pois um veículo que não anda é inútil.

E é justamente nesse cenário que as interfaces aparecem pra salvar o dia, eu posso criar uma interface chamada “ContratoVeiculo” e lá colocar o método andar(). Logo após isso eu faço a minha classe implementar essa interface. Isso vai fazer com que essa classe seja obrigada a implementar os métodos definidos na interface.

A interface não tem a obrigação de dizer como um método deve funcionar (e nem pode fazer isso), por isso em interfaces nós não implementamos o método, apenas escrevemos a assinatura do método, ou seja, escrevemos o seu nome, quais parâmetros ele recebe, e qual o tipo do retorno desse método.

É obrigação da classe que implementa esse interface dizer como vai ser toda a lógica do meu método, mas esse método precisa respeitar a assinatura da interface, então ele precisa receber os mesmos tipos de parâmetros e retornar o tipo de valor definido na interface.

A vantagem em ter essa abordagem (interfaces serem proibidas de ditar o funcionamento dos métodos) é que eu vou poder usar a mesma interface para classes diferentes, que terão lógicas de funcionamento diferentes. Como você já deve saber, carros e motos andam de formas diferentes, mas como a minha interface ContratoVeiculo é “agnóstica”, eu consigo usar ela tanto na classe Carro quanto na classe Moto.

Abaixo eu mostro um trecho de código PHP que implementa essas classes e interface citados acima.

<?php
interface ContratoVeiculo
{
   public function andar(): void;
   //Aqui eu digo que quero uma função chamada andar
   //que não recebe nenhum parametro e retorna void
   //Ou seja, não retorna nada
}

class Carro implements ContratoVeiculo
{
   //Imagine que temos varios atributos
   //e varios metodos aqui
   public function andar(): void
   {
       print("O carro está andando\n");
   }
}

class Moto implements ContratoVeiculo
{
   //Imagine que temos varios atributos
   //e varios metodos aqui
   public function andar(): void
   {
       print("Andando como uma moto\n");
   }
}

E o que são classes seladas?

E por fim, vamos falar um pouco sobre as classes finais, ou classes seladas, o nome varia de acordo com a linguagem de programação que você estiver usando (em PHP e Java é classe final e no C# é classe selada).
Lembra que as classes abstratas não podem ser instanciadas, mas podiam ser herdadas? Com as classes finais acontece o oposto, elas podem ser instanciadas, mas não podem ser herdadas.

A razão para se usar uma classe desse tipo é que a herança também tem o seu ônus, e pode ser que em algum caso especifico você quer evitar que algum outro programador extenda a sua classe. Deixo abaixo a opinião de um usuário do stackoverflow sobre o assunto.

“É uma forma de dizer que esta classe não pode ser herdada, o que costuma ser uma boa ideia. Desenvolver classes preparadas para serem herdadas é muito mais difícil, a manutenção seguinte se torna um fardo. Acho até que o padrão deveria ser a classe não herdável.”

Abaixo deixo um exemplo de classe final no PHP.

<?php

abstract class CarroGenerico
{
   protected int $quilometragem;
   public function ligar(): void
   {
       //logica para ligar o carro
   }
}

final class ToyotaCorolla extends CarroGenerico
{
   //implementa coisas especificas de um Corolla
   //A ideia aqui, é que chegamos na nossa classe final
   //Não faz muito sentido extender um Corolla
   //pois ele já é o produto FINAL
}

Conclusão

Bom, com esse artigo nós cobrimos todas as partes que eu considero fundamentais para que você comece a usar a orientação a objetos. Existem muitas coisas que não foram cobertas nessa série e que estão relacionadas com POO, como por exemplo funções amigas e generics. Mas falar disso fugiria um pouco da finalidade dessa série, que é cobrir os fundamentos. Vejo vocês em próximos artigos! :)

Guia fundamental da programação orientada a objetos - Parte 2 | Os pilares

Marcus Xavier — Thu, 10 Feb 2022 19:05:56 +0000

É impossível falar de programação orientada a objetos sem citar seus famosos quatro pilares. Seguir esses pilares é muito importante para que você possa conseguir todos os maravilhosos benefícios da POO. No artigo de hoje eu vou falar exclusivamente sobre esses pilares, e sempre que pertinente vou exemplificar com código e imagens.
Seria ótimo que você deixasse seu feedback nos comentários.

Quais são os pilares da POO?

A POO possui alguns pilares que devem ser seguidos para que possamos começar a obter os benefícios oferecidos por esse paradigma da maneira mais correta possível.

Encapsulamento

Basicamente é o pilar que te permite deixar seu código mais isolado do resto, então quando você baixa uma lib no seu projeto e usa um objeto dessa lib com vários métodos úteis você não preciso fuçar na classe dela, já vem tudo encapsulado certinho pra você usar, só precisa chamar as funções desse objeto e deixar a mágica acontecer sem se preocupar se o seu código vai bugar o código da lib, porque se ela estiver encapsulada isso não vai acontecer.

Vou usar uma pilha como exemplo. Dentro da pilha tem vários elementos químicos, que poderiam danificar sua pele, por esse motivo nós colocamos eles dentro de uma cápsula, que tem dois terminais.
Então essa cápsula tem o único objetivo de te proteger da pilha, e ao mesmo tempo proteger a pilha de você, pois você poderia danificar a pilha caso ficasse tocando no catodo dela.
Essa cápsula da pilha só expõe o necessário dela (que são os terminais negativo e positivo) e esconde todo o resto. Encapsulamento na POO é exatamente isso.

Herança

É o pilar que te permite reutilizar o seu código, fazendo uma classe reaproveitar o código de outra classe, como um filho que herda os genes dos pais, então a classe que herda é a classe filha (child class), e a classe que serve como base na herança é a classe mãe (parent class).

Vamos imaginar que você está escrevendo um programa para realizar cobranças de um e-commerce. E nesse caso você vai aceitar pagamento por cartão de crédito, boleto e pix. É possível perceber que parte dos pagamentos vão ser iguais (todos tem um valor, informações do usuário, etc), e têm partes que são diferentes (boleto tem data de vencimento e pagamento por cartão não tem).

Então ao invés de escrever o código do zero pros três tipos de pagamento, ou escrever tudo junto, de forma bagunçada, nós podemos criar uma classe mais genérica, chamada pagamento, e classes para os pagamentos com cartão de crédito, boleto e pix, fazendo essas classes herdarem a genérica, reaproveitando código.

Abaixo vou deixar uma imagem como exemplo e um trecho de código.

public class Pagamento
{
   public int Id;
   public string NomeDoPagador;
   public bool FoiPago;
   //… mais várias propriedades aqui

}

public class PagamentoCartaoCredito : Pagamento
{
   //Eu ainda tenho as propriedades do Pagamento aqui
   // ou seja, posso acessar o Id, e o nome do pagador
   public int NumeroCartao;

   public void VerificarCartao()
   {
       //verificando o cartão
   }
}

public class PagamentoBoleto : Pagamento
{
   //Eu ainda tenho as propriedades do Pagamento aqui
   // ou seja, posso acessar o Id, e o nome do pagador

   public DateTime vencimento;

   public void VerificarSeVenceu()
   {
       //verificando se o boleto não venceu
   }

}

Abstração

O pilar da abstração vai deixar seu código o mais simples possível. Vamos imaginar que você precisa escrever o código de cadastro de alunos em uma escola, logo você irá precisar criar uma classe do tipo pessoa, mas uma pessoa tem milhares de características e pode realizar milhões de ações diferentes.

Então, pra evitar que a sua classe fique com 10000 linhas usamos o conceito de abstração, que é focar somente nas características e ações importantes no contexto do programa.

Para uma escola, a altura, peso ou cor da pele de um aluno não faz a menor diferença, mas é importante saber as notas desse aluno e o seu nome, então focaremos somente nas últimas características. A mesma ideia se aplica na hora de escolher quais ações representar usando os métodos.

public class Aluno
{
   //Aqui vou focar somente no essenssial
   //Um aluno é uma pessoa, logo tem centenas
   //de caracteristicas, mas vou focar em somente três
   public string Nome;
   public int Idade;
   public int[] Notas;
   //Isso acima é um vetor de notas
   //Ou seja, varias notas juntas na mesma estrutura

   public void Aprovar() { }

   public void Reprovar() { }
}

Polimorfismo

Polimorfismo quer dizer “muitas formas”, e é exatamente isso que você entendeu, os métodos das classes podem ter muitas formas. Eu vou explicar de forma mais detalhada logo logo, mas preciso falar primeiro que existe mais de um tipo de polimorfismo. Nesse artigo vou focar nos dois principais, a sobrescrita e sobrecarga.

>Sobrescrita

Como o próprio nome já diz, sobrescrita é uma forma de escrever por cima de algo que já existe, e no nosso contexto, é a habilidade de uma classe filha para modificar o comportamento de um método (função) da classe mãe. A vantagem disso é poder reutilizar toda parte útil da nossa classe mãe, mas ao mesmo tempo ter a capacidade de alterar as partes que nós desejamos alterar por qualquer motivo que seja.

Isso é literalmente o melhor dos dois mundos, pois economizamos código escrito e também temos total flexibilidade para deixar nossas classes filhas do jeito que queremos. Abaixo vou mostrar um trecho de código onde faz sentido esse tipo de polimorfismo.

Eu tenho uma classe Mamífero, e você vai concordar comigo que todos (ou quase todos) os mamíferos emitem som, não é mesmo? Então, por isso criamos um método Falar() nessa nossa classe. Mas, caso eu crie um Cachorro e um Gato a partir dessa classe Mamífero, eu vou precisar modificar esse método Falar(), pois como todos sabemos, cachorros e gatos “falam” de formas diferentes, um late e outro mia.

public class Mamifero
{

   public string Especie;
   public int Idade;


   public virtual void Falar()
   {
       Console.WriteLine("Fala genérica de um animal");
       // printa Fala genérica de um animal na tela
   }
}

public class Gato : Mamifero
{
   public override void Falar()
   {
       Console.WriteLine("Miau");
       // printa Miau na tela
   }
}

public class Cachorro : Mamifero
{
   public override void Falar()
   {
       Console.WriteLine("Au au");
       //printa au au na tela
   }
}

>Sobrecarga de métodos

Esse é um conceito que te permite criar variações de um mesmo método, ou seja, você pode ter vários métodos com nomes iguais dentro de uma mesma classe, realizando ações diferentes. Pode ter ficado confuso, mas eu vou mostrar agora uma situação onde a sobrecarga pode ser útil, é um exemplo bem bobo, mas vai tornar esse conceito mais claro pra você.

Imagina que vamos criar uma classe Calculadora, e ela tem um método de Somar(). O que esse método faz é basicamente pegar dois inteiros e retornar a soma deles

public class Calculadora{
   public int Somar(int a, int b)
   {
       return a + b;
   }
}

Mas se eu quiser somar 3 números, como eu faço? Caso eu modifique esse método acima, todos os meus trechos de código que usavam essa função vão quebrar, pois eles só estavam somando dois números, e a função passou a querer somar três números.

E é nesse momento que a sobrecarga vem salvar o dia. Eu tenho a opção de simplesmente criar outro método chamado Somar, que recebe três números, e o C# é inteligente o suficiente pra saber quando ele chama o método que recebe dois parâmetros, e quando chamar o método que recebe três.

public class Calculadora
{
   public int Somar(int a, int b)
   {
       return a + b;
   }

   // Novo método
   public int Somar(int a, int b, int c)
   {
       return a + b + c;
   }
}

Você vai ver isso bastante em métodos “nativos” do .NET Core (uma plataforma de desenvolvimento que usa o C#), a sobrecarga de métodos (mais conhecida como overload) é algo extremamente comum nessa plataforma.

Conclusão

No artigo de hoje nós vimos o coração da orientação a objetos: os seus famosos pilares. Entender bem esses conceitos é fundamental para aplicar bem a POO em problemas reais do dia a dia, por isso recomendo salvar esse texto para ler futuramente de novo depois que você tiver mais experiência programando nesse paradigma.

No próximo artigo veremos mais conceitos importantes da POO, como classes abstratas, interfaces, classes “seladas” e se sobrar tempo vou mostrar como os métodos GET e SET do C# podem ser escritos de forma elegante e enxuta.