DEV Community: Terminal Coffee

HTML é uma linguagem de programação - ou pelo menos está mais perto disso do que você imagina

Terminal Coffee — Tue, 01 Apr 2025 20:53:55 +0000

O HTML é alvo de muita chacota on-line, quem nunca riu do famoso "programador de HTML" ou, pelo menos, pensou que era óbvio que ele estava errado, que atire a primeira pedra.

Não é exatamente incomum nos depararmos com a afirmação de que "HTML é uma linguagem de programação" e ver diversos comentários dizendo o contrário (afinal é verdade), apesar disso, muitos desses comentários tem como intenção zombar como se a pessoa fosse estúpida por pensar daquela forma, como se essa fosse uma discussão rasa e banal.

O problema é que geralmente os argumentos demonstrando que ele não é uma linguagem de programação, não são bem os mais inteligentes do mundo também, o que gera uma situação do sujo falando do mal lavado, ou seja, a famosa hipocrisia.

Entretanto esse rabbit role pode ser bem mais profundo e interessante do que se imagina, existe de fato uma área cinza considerável quanto à o que seria uma linguagem de programação.

Por isso hoje vamos estudar como aquele seu amigo iniciante que "programa" em HTML talvez possa ter mais razão do que você imagina.

Caso 1: é uma linguagem de marcação

Para muitos, o fato de HTML ser uma sigla para hypertext markup language é o suficiente para desconsiderar ele como linguagem de programação, afinal ele não seria uma linguagem de programação, mas sim uma de marcação, porém não tem nada que impede uma linguagem de marcação de ser uma linguagem de programação também, alguns exemplos disso seriam:

XSLT (Extensible Stylesheet Language Transformation);
SGML (Standart Generalized Markup Language);
LaTeX.

XSLT por exemplo é uma linguagem Turing Complete (o que como vamos ver mais para frente também não é requisito, apesar de ser um bom indicativo), além de possuir construtos como condicionais, e estruturas de repetição, sendo possível até escrever algoritmos nele, como por exemplo a sequência de fibonacci:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="/">
        <result>
            <xsl:call-template name="fibonacci">
                <xsl:with-param name="n" select="10"/>
                <xsl:with-param name="a" select="0"/>
                <xsl:with-param name="b" select="1"/>
            </xsl:call-template>
        </result>
    </xsl:template>

    <xsl:template name="fibonacci">
        <xsl:param name="n"/>
        <xsl:param name="a"/>
        <xsl:param name="b"/>

        <!-- Output current Fibonacci number -->
        <fib>
            <xsl:value-of select="$a"/>
        </fib>

        <!-- Continue recursion if n > 1 -->
        <xsl:if test="$n > 1">
            <xsl:call-template name="fibonacci">
                <xsl:with-param name="n" select="$n - 1"/>
                <xsl:with-param name="a" select="$b"/>
                <xsl:with-param name="b" select="$a + $b"/>
            </xsl:call-template>
        </xsl:if>
    </xsl:template>
</xsl:stylesheet>

Caso 02: não está no nome

Continuando num outro argumento que vem acompanhado quando se faz o anterior é a ideia de que como o HTML tem markup language no nome, ele claramente é uma linguagem de marcação e como não tem programação escrito no nome, não poderia ser uma linguagem de programação, o que é um argumento no mínimo pedante.

Várias outras linguagens de programação bem populares também carregam nomes ambíguos como por exemplo JavaScript, que indica que ele seria uma linguagem script e não uma de programação de verdade, ou PHP (PHP Hypertext Processor) que inclusive possui o hypertext no nome, o que demonstra que o nome pode até ser um indicativo, mas ele não deveria ser um critério decisivo para decidir isso.

Outro grande exemplo seria o próprio XSLT que vimos anteriormente que mesmo sendo uma linguagem de marcação, com markup language no nome, ainda assim é uma linguagem de programação.

Caso 03: HTML é estrutura, CSS é estilização, e JS é interatividade

Uma variação do ponto anterior é que se argumenta que como o HTML tem uma responsabilidade muito clara de definir a estrutura semântica de uma página web, enquanto CSS serve para estiliza-lá, e o JS para adicionar interatividade.

Dessa forma, apenas o JS poderia ser considerado uma linguagem de programação afinal ele que adiciona o elemento do dinamismo e da interatividade nos documentos.

O problema disso é que tanto o HTML quanto CSS possuem capacidades de tornar coisas dinâmicas atualmente, mesmo que de forma limitada.

O HTML, por exemplo, possui a Popover API, os novos atributos command e commandfor (que possibilitam habilitar uma tag dialog sem JS, e muito mais), ou tags interativas como as summary e details.

Caso 04: Falta de controle de fluxo

Para muitos, uma linguagem só pode ser de programação se incluir coisas como variáveis, estruturas condicionais como if ou switch, e estruturas de repetição como for loops por exemplo.

Sendo um dos argumentos mais hipócritas de todos, visto que demonstra que elas entendem tanto do tema quanto o iniciante ao qual elas estão fazendo chacota.

Afinal você não precisa de variáveis, ifs ou loops para programar, programação funcional nos mostra que é possível programar de forma imutável (sem variáveis), podemos simplesmente usar recursão ao invés de loops, e ifs não precisam ser estruturas que controlam o fluxo do código, uma vez que booleans podem ser expressos como objetos ou funções, resultando em branching ou pelo type system ou simplesmente pela invocação de funções.

Considerar apenas essas estruturas mais comuns deixa de fora inumeras linguagens como as que compõe o paradigma lógico e funcional, e até mesmo algumas puramente orientadas a objeto como Smalltalk (não existem estruturas de controle de fluxo aqui, apenas objetos).

Caso 05: Não é Turing Complete

Este talvez seja o melhor ponto para se ressaltar se algo é uma linguagem de programação ou não, visto que é uma métrica bem confiável para maioria dos casos, afinal se passa pelo teste de Turing, possui uma sintaxe formal com semântica definida, e pode ser usado para escrever programas de computador, então é uma linguagem de programação.

O problema aqui é que só ser Turing Complete não garante que é uma linguagem de programação visto que existem coisas que são Turing Complete, mas não são linguagens de programação por exemplo o a redstone do jogo Minecraft.

Por outro lado, não ser Turing Complete também não desqualifica automaticamente uma linguagem, afinal existem alguns domínios que exigem que as linguagens proibam certas coisas como loops infinitos de acontecerem, por exemplo em linguagens usadas para projetar chips de computador (como os produzidos pela Intel ou AMD), como essas linguagens produzem especificações que refletem as limitações que o hardware vai ter na vida real, elas acabam tendo limitações que as impedem de ser consideradas Turing Complete.

Mas então o que caracterizaria uma linguagem de programação?

Isso é uma questão complexa, visto que mesmo critérios já estabelecidos como a completude de Turing não parecem ser suficiente para isso, mas se formos para uma linha abstrata demais, quase que filosófica, e dizer que seria qualquer coisa que possibilite a criação de instruções que façam um computador fazer alguma coisa, talvez até mesmo prompt numa IA possa ser considerado programação, o que também não é muito útil como critério.

O que fez mais sentido para mim até hoje seria a ideia de que precisa ser uma linguagem com sintaxe e semântica formais, um grau de expressividade suficiente para computação geral (Turing completa ou próximo disso) e que permite o raciocínio sobre seus programas.

Expressividade significa o grau de liberdade que uma linguagem oferece, por exemplo numa linguagem de tipagem estática, a liberdade é menor, pois o sistema de tipos te impede de usar um valor de um tipo quando outro é requerido.

O raciocínio se refere a capacidade de programas poderem ser análisados por humanos ou computadores baseado na sua sintaxe e semânticas formais, por exemplo poder olhar que x = 1 + 1, e dizer que x é 2 se baseando no modelo formal da matemática.

Essa definição se baseia na descrição de Peter Van Roy sobre o que seria programação:

First, a computation model, which is a formal system that defines a language and how sentences of the language (e.g., expressions and statements) are executed by an abstract machine.For this book, we are interested in computation models that are useful and intuitive for programmers.This will become clearer when we define the first one later in this chapter.

Second, a set of programming techniques and design principles used to write programs in the language of the computation model.We will sometimes call this a programming model.A programming model is always built on top of a computation model.

Third, a set of reasoning techniques to let you reason about programs, to increase confidence that they behave correctly, and to calculate their efficiency.

~ Peter Van Roy, Concepts, Techiniques, and Models of Computer Programming, p. 29

Já que ela nos dá os critérios necessários para entender os casos "fora da curva" que eu citei nas seções anteriores, ao mesmo tempo que oferece uma justificativa para o HTML chegar perto, mas não ser uma linguagem de programação.

No caso, ele possui sintaxe e semântica muito bem definidas, você consegue raciocinar sobre o resultado de um "programa" HTML, tem um certo grau de expressividade (inclusive ele ganhou mais expressividade nos últimos anos), mas ainda não chega a ser suficiente para ser algo próximo de uma máquina de Turing, ele ainda é uma linguagem cujo a expressividade é limitada à apenas declarar estruturas de dados e nada mais.

Dito isso, ele é compatível com várias das coisas que caracterizam uma linguagem de programação, e é por isso que num critério menos rigoroso, ele poderia sim ser considerado uma linguagem de programação, mesmo que técnicamente isso fosse errado, o que explica o motivo de muitos iniciantes, ou pessoas em geral falando de forma informal, se referirem a ele assim.

Explorando as áreas cinzas

Apesar disso tudo que nós abordamos, se a gente considerar a existência de web components, e fizermos algumas concessões, o HTML poderia sim ser considerado uma linguagem de programação dentro das regras que nós decidimos na seção anterior.

Tudo o que falta para o HTML é uma expressividade maior, de modo que ele possa realizar computações além de simplesmente declarar estruturas de dados.

Tanto que isso se verifica na prática pois template engines, ou frameworks JS que adicionam DSLs por cima do HTML (tipo o Vue ou Svelte) basicamente tornam possível a escrita de programas com ele.

O problema é que template engines não contam pois são uma nova linguagem implementada por cima do HTML, então ele em si continua não contando.

E no caso dos frameworks de JS, apesar deles melhorarem o HTML, essencialmente o código que você escreve é o em JS, a parte HTML continua sendo só puramente declarativa mesmo.

O interessante seria se o HTML em si ganhasse novas tags que permitissem expressar computações mesmo que de forma declarativa (semelhante ao XLST citado anteriormente), e é ai que entram os web components.

Eles são uma spec oficial da web cujo o propósito é justamente estender o HTML permitindo que você registre novos elementos válidos ao DOM da página. Sendo assim, poderíamos definir um conjunto de web components que simbolizam computações formais, virando HTML válido dentro da página que registrar eles.

O único problema dessa abordagem seria que web components dependem de JS para funcionar, então para esse ponto funcionar deveríamos fazer a concessão de considerar o JS apenas como o runtime do HTML, tal como o bytecode é para o Java.

Essa concessão faz sentido aqui e não para os frameworks de JS, pois os web components não adicionam nada na sintaxe formal do HTML, então essencialmente um novo web component seria uma nova tag do HTML, e o JS não é exposto em nenhum ponto aqui, ele age apenas como um detalhe de implementação, se a gente escrevesse um interpretador de HTML em python e que entendesse esses web components também, e projetasse uma saída num console, a parte de raciocínio do programa continuaria igual, ao passo que num interpretador de Vue por exemplo, seria necessário adicionar toda a semântica e raciocínio para um programa JS também.

Conclusão

No artigo de hoje vimos que a ideia de HTML ser uma linguagem de programação vai bem além de só uma piada, e que a definição de o que seria uma é um assunto bem mais profundo do que parece, por isso se você achou o conteúdo interessante, comenta aqui para gente o que você achou da nossa proposta de interpretação com web components, o HTML deveria ser considerado uma linguagem de programação nesse caso ou não?

Se preferimos composição, então por que os frameworks usam herança?

Terminal Coffee — Tue, 31 Dec 2024 23:48:49 +0000

Todos já ouvimos aquele famoso ditado do GoF (Gang of Four) sobre preferir composição ao invés de herança, entretanto, na prática, isso acaba mais virando um: herança é ruim, nunca use herança, sempre utilize exclusivamente composição para tudo.

Apesar disso, ela está mais presente em nossos códigos do que parece quando pensamos sobre o assunto, afinal, embora nós nunca a escolhemos para projetar os nossos códigos, e temos até certa aversão ao seu uso dependendo de quão fundo você foi neste tópico, ela se faz presente em diversos códigos essenciais para que a nossas aplicações existam, afinal diversos frameworks de utilizam dela para que eles funcionem, então não é incomum precisarmos herdar uma classe de um framework por exemplo.

Ao refletir neste tópico, isso me fez chegar a questão do nosso título: se preferimos composição, então por que os frameworks usam herança? Será que podemos estar subestimando a sua utilidade? Ou será que podemos ser criativos e projetar algo interessante através dela? Sendo isso que iremos investigar no artigo de hoje.

Disclaimer

Eu conheço os diversos problemas da herança tal como o alto acoplamento, problema do diamante, problema da classe base frágil, e etc, entretanto este não é um artigo para discutir os seus problemas num geral, e sim as suas utilidades, por isso se quiserem um artigo sobre isso também não deixem de pedir nos comentários o nosso take sobre "why inheritance is evil".

Também não é a intenção deste artigo dizermos que você sempre deve utilizar herança ao invés de composição, ou até que discordamos do ditado, na verdade, é por concordar demais com ele, que resolvi realizar esta investigação atrás de um cenário onde o "prefira" se aplica de fato ao invés de ser um "sempre", afinal se é "prefira" então significa que deve ter algum caso onde herança pode ser mais útil ou pelo menos equivalente.

Por que preferimos composição ao invés de herança?

Em resumo, é porque, geralmente, o trade-off é melhor quando usamos composição, utilizamos herança por dois motivos:

Reúso de código;
Programação incremental;

Reúso é bem auto-explicativo, se temos uma classe A com os métodos foo e bar, podemos usar ela de base para criar a classe B com os métodos foo, bar, e bazz, ex:

class A
{
    public function foo(): void
    {
        echo "Foo";
    }

    public function bar(): void
    {
        echo "Bar";
    }
}

class B extends A
{
    public function bazz(): void
    {
        echo "Bazz";
    }
}

Assim não precisamos ficar copiando e colando todo o código comum da nossa aplicação toda vez que tivermos uma classe parecida com outra, podemos simplesmente herdar da original.

Essa habilidade de reúsar o código é bem útil para aplicar uma abordagem que chamamos de programação incremental, onde ao invés de começar com uma classe gigante que faz tudo, nós começamos com uma pequena, e se precisarmos criar variações dela, nós podemos implementa-las como classes filhas dessa original, incrementando de pouco em pouco a cada nova iteração. Assim como fizemos com a classe A que tinha dois métodos, onde incrementamos ela com mais um método lá na classe B.

Herança também permite a gente modificar o código de um método da classe mãe na filha caso seja necessário, mas como sabemos que boa parte do tempo, se quisermos respeitar o LSP (Liskov Substitution Principle), não devemos fazer isso, ou perderemos a capacidade de trocar classes dentro de uma mesma hierarquia (que é uma das maiores vantagens de se colocar os adicionais em classes separadas ao invés de tudo na principal), então normalmente só temos uma situação onde se adiciona coisas a mãe na filha, e não modificamos nada que veio da mãe, assim a filha é só a mãe com coisas extras, ao invés de ser a mãe só que diferente em alguns pontos.

Dado que vamos respeitar o LSP, poderíamos ter uma hierarquia assim:

<?php

class Text implements Stringable
{
    public function __construct(private string $value) {}

    public function __toString(): string
    {
        return $this->value;
    }
}

class AllCapsText extends Text
{
    public function __toString(): string
    {
        return strtoupper(parent::__toString());
    }
}

class TrimmedText extends Text
{
    public function __toString(): string
    {
        return trim(parent::__toString());
    }
}

echo new Text('    Hello World') . PHP_EOL; //     Hello World
echo new AllCapsText('    Hello World') . PHP_EOL; //     HELLO WORLD
echo new TrimmedText('    Hello World') . PHP_EOL; // Hello World

Dessa forma, qualquer código que aceita Text vai aceitar suas filhas também, entretanto, observe esse código feito com composição:

<?php

class Text implements Stringable
{
    public function __construct(private string $value) {}

    public function __toString(): string
    {
        return $this->value;
    }
}

class AllCapsText implements Stringable
{
    public function __construct(private Stringable $text) {}

    public function __toString(): string
    {
        return strtoupper($this->text->__toString());
    }
}

class TrimmedText implements Stringable
{
    public function __construct(private Stringable $text) {}

    public function __toString(): string
    {
        return trim($this->text->__toString());
    }
}

$text = new Text('    Hello World');
$allCaps = new AllCapsText($text);
$trimmed = new TrimmedText($text);

echo $text . PHP_EOL; //     Hello World
echo $allCaps . PHP_EOL; //     HELLO WORLD
echo $trimmed . PHP_EOL; // Hello World

Obtivemos exatamente o mesmo resultado com praticamente o mesmo esforço, apesar disso, a abordagem com composição possui duas vantagens:

Tem menor acoplamento;
Você pode compor cada uma das classes;

Então, como cada classe é uma classe independente sem acoplamento direto com a original, podemos nos beneficiar do baixo acoplamento e evoluir cada uma de forma independente sem ter medo de quebrar ninguém de forma não planejada, além disso, apesar do efeito ser o mesmo para quando só queremos usar versões diferentes da classe base, a vantagem aqui é que se a gente quiser combinar as mutações, podemos só fazer isso:

echo new TrimmedText(
    new AllCapsText(
        new Text('   Hello World')
    )
); // HELLO WORLD

E usando herança, não temos como combinar as filhas, nós temos que criar uma nova filha que tem a capacidade de duas, por exemplo uma classe AllCapsTrimmedText, o que limita a flexibilidade da habilidade de se incrementar, mantendo o reúso de código, só que tendo que escrever bem mais código de boilerplate em troca.

Em resumo, podemos visualizar melhor os trade-offs de cada abordagem na seguinte tabela:

Aspecto	Peso	Herança	Composição
Acoplamento	Muito Importante (3)	Alto (1)	Baixo (3)
Flexibilidade	Muito Importante (3)	Médio (2)	Alto (3)
Reúso	Importante (2)	Alto (3)	Alto (3)
Extensibilidade	Importante (2)	Alto (3)	Médio (2)
Boilerplate	Pouco Importante (1)	Baixo (3)	Alto (1)
Média Ponderada		4.8	5.8

Acoplamento

Esse é um aspecto que é muito importante na prática (por isso seu peso é 3), pois tem um impacto enorme na capacidade de se dar manutenção e evoluir qualquer sistema.

A composição possui baixo acoplamento devido a poder evitar uma relação direta com outras classes através de interfaces, sendo assim, mudanças ficam encapsuladas num objeto, e não se propagam para os outros objetos que dependem dele tão facilmente.

A herança, pelo contrário, cria uma relação direta entre mãe e filha, sendo uma das relações com maior grau de acoplamento entre objetos. O que se reflete pelo próprio objetivo da herança que seria o reúso de código, ou seja, quando você utiliza herança é justamente quando você quer que mudanças na classe base se propagem nas filhas, então, por natureza, ela exige um cenário de alto acoplamento.

Flexibilidade

Esse também é outro aspecto que damos muita importancia na prática, afinal é o aspecto mais útil de quando digitamos código, pois mais útil do que não precisar copiar as mesmas linhas de código de um módulo para criar variações dele, é conseguir juntar vários módulos diferentes num módulo só, assim economizando as linhas de todos esses módulos ao mesmo tempo.

Até porque as variações de uma classe podem ir surgindo com o tempo, mas elas vão crescendo de forma linear, entretanto as combinações entre vários módulos podem ir crescendo exponencialmente a cada nova variação introduzida.

Nesse aspecto, a composição, similar a herança no último tópico, tem como objetivo principal ser o ato de combinar vários módulos em um (afinal você compõe eles), então por natureza esse é o aspecto mais forte dessa abordagem.

No caso da herança, enquanto ela oferece certo grau de flexibilidade ao permitir que nós adicionemos variações de uma mesma classe ao herdar ela, não conseguimos misturar essas variações umas com as outras, sendo um grau menos flexível que a composição.

Reúso

Esse é um aspecto importante, afinal seguir o DRY tem se provado como uma decisão sábia ao longo de toda a história do desenvolvimento de software, entretanto, ele não é um aspecto que deve ser buscado a custa de outros, inclusive reusar código em situações onde a coesão entre os módulos for baixa acaba sendo mais um problema do que uma solução, visto que pela falta de coesão entre eles, cada módulo vai acabar evoluindo de forma independente ao longo do tempo, sendo assim, depois de um periodo de tempo, a tendência é que eles já não vão compartilhar mais nada entre si, tornando o ato de criar uma abstração para compartilhar o código um empecilho em evoluir cada um deles de forma independente.

Aqui, ambos herança e acoplamento são ferramentas ótimas para lidar com esse aspecto, não a toa que existe toda essa discussão em torno de quando se usar cada um, sendo a herança melhor em reduzir o boilerplatena hora de reusar código e extender o mesmo, e a composição melhor em criar combinações a partir de códigos já existentes.

Extensibilidade

Esse é um aspecto bem importante, afinal, como apontado no aspecto de flexibilidade, é bem importante que os módulos do sistema possam ser reutilizamos na criação de novos módulos que sejam derivações dos originais, apesar disso, a extensibilidade por si é só um pedaço da flexibilidade, por isso sua importância não chega a ser a mesma da flexibilidade.

Aqui encontramos o primeiro trade-off onde herança começa a ganhar mais relevância, pois dependendo do cenário em que vamos acabar precisando estender os comportamentos na nova classe, alguns deles são impossíveis para a composição sem que nós violemos o encapsulamento, enquanto na herança temos um mecanismo específico desenhado para resolver esse problema na forma do modificador de visibilidade protected.

Esses cenários podem ser resumidos na seguinte tabela:

Cenário	Herança	Composição	Observações
Adicionar/Modificar + Sem Dependências	✅ Fácil	✅ Fácil	Sem dependências, ambas as abordagens são viáveis.
Adicionar/Modificar + Depende do Filho	✅ Fácil	✅ Fácil	Ambas as abordagens lidam bem com dependências específicas do filho.
Adicionar/Modificar + Depende do Comportamento do Pai (Público)	✅ Fácil	✅ Fácil	Métodos públicos funcionam igualmente em herança e composição.
Adicionar/Modificar + Depende do Comportamento do Pai (Protegido)	✅ Fácil	⚠️ Comprometido	A composição exigiria tornar métodos protegidos públicos.
Adicionar/Modificar + Depende dos Dados do Pai	✅ Fácil	❌ Quebra o Encapsulamento	A composição força o uso de getters, quebrando o encapsulamento.

Boilerplate

Aqui é o aspecto menos importante daquela tabela, pois enquanto é algo que torna a experiência de escrever código muito mais prazerosa, visto que não vamos perder tempo escrevendo código que não está contribuindo para a resolução do problema, ou seja, evitando de escrever código "por obrigação", sendo o mais prático de se escrever a curto prazo, é um benefício que a gente trocaria facilmente sempre que a troca nos der outros benefícios mais relevantes tais como os outros mais bem rankeados nesta comparação.

Essa troca entre praticidade e benefícios de longo prazo é a decisão que a gente toma constantemente quando decidimos desacoplar nosso código por exemplo.

Apesar disso é aqui que se encontra o trade-off mais favorável para a herança, pois a composição exige um monte de boilerplate em troca de todos os benefícios que ela oferece.

Em uma situação onde a classe base só tem um método, e queremos estender um único método, como vimos anteriormente, o código requerido por cada abordagem é mais ou menos o mesmo, entretanto quanto mais métodos nós adicionamos na classe base, mais a composição sofre, pois ela necessita que cada método não incrementado da classe base seja copiado no novo objeto só para chamar internamente o método do objeto original. Ex:

class Foo
{
    public function methodA(): void {}
    public function methodB(): void {}
}

class Bar
{
    public function __construct(private Foo $foo) {}

    public function methodA(): void
    {
        return $this->foo->methodA();
    }

    public function methodB(): void
    {
        $this->methodC();
        return $this->foo->methodB();
    }

    public function methodC(): void {}
}

Enquanto a herança elimina completamente o boilerplate do código, mantendo só as partes que interessa para gente, ou seja, as que contém código novo:

class Foo
{
    public function methodA(): void {}
    public function methodB(): void {}
}

class Bar extends Foo
{
    public function methodB(): void
    {
        $this->methodC();
        parent::methodB();
    }

    public function methodC(): void {}
}

Resultado

Sendo assim, o ditado se prova pois, apesar de ambos terem uma média final similar, os cenários onde a composição tem vantagem sobre a herança são os cenários que preferimos ter quando escrevemos os nossos códigos, por isso, via de regra, vamos acabar preferindo por composição mesmo.

Infelizmente, o alto acoplamento é algo que segura demais a herança quando vamos fazer essas comparações, tanto é que se removermos a importância do acoplamento, reduzindo ela a 0, a média ponderada vai mudar para um cenário que mostra a herança como mais favorável (por uma diferença de 0.2 mais ou menos).

O que os frameworks tem a ver com isso?

Ao analisar a nossa tabela, podemos concluir que o cenário ideal para herança seria quando nossas prioridades estão invertidas, por isso que ele é tão raro, sendo algo praticamente teórico, ou seja, nós precisamos desenhar um cenário onde desejamos um acoplamento alto ou ele não faz diferença para a situação, e que reúso de código seja o aspecto que damos mais importância ao invés de ser só algo secundário que seria bom ter. E adivinha qual cenário da vida real seria esse?

Exatamente meu caro leitor, os frameworks são o exemplo perfeito que atinge todos esses requisitos extremamente específicos onde a herança é algo favorável. Pelo menos é esse o caso quando falamos de frameworks opinativos tal como o Laravel ou Ruby on Rails.

Reúso

Frameworks existem para facilitar a nossa vida na hora de desenvolver uma aplicação, sendo assim, o seu princípal objetivo é prover abstrações já prontas de modo que esse código que vai ser comum a todos os projetos que necessitem dos processos que o framework busca automatizar ou facilitar possa ser reutilizado diretamente dele pelos desenvolvedores desse projeto.

Podemos notar isso através dessas duas definições obtidas da Wikipedia:

Uma estrutura é um termo genérico que geralmente se refere a uma estrutura de suporte essencial sobre a qual outras coisas são construídas em cima.
~ Wikipedia - Definição genérica

Um framework em desenvolvimento de software, é uma abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica.
~ Wikipedia - Definição em desenvolvimento de software

Resumindo, exatamente a nossa definição, sendo uma dependência externa que reúne várias abstrações diferentes comuns a diversos projetos de software com domínios semelhantes, de modo a prover uma base genérica para se escrever uma aplicação daquele tipo em cima.

Sendo assim, a princípal prioridade de um framework é escrever código que possa ser compartilhado e reúsado, que como vimos é uma área onde herança tende a ter mais vantagens, mesmo que composição possa ser situacionalmente melhor.

Além disso, permitir que os usuários de um framework possam estender suas capacidades, visto que cada usuário terá necessidades diferentes para ele, e, portanto, potencialmente, poderia necessitar de modificações em como ele funciona, a capacidade de sobrescrever certas funções e fornecer pontos de estensão, são coisas essenciais para bons frameworks.

Herança trás seus maiores benefícios justamente nesses dois casos, sobrescrever comportamentos como é comum usando polimorfismo de subtipo (que é o que você ganha ao usar herança), e criação de pontos de estenção por meio de template method.

Acoplamento

Apesar de mostrarmos que por sua própria natureza frameworks serem o tipo de código que mais se aproveita dos benefícios da herança, ainda assim temos frameworks inteiros baseados em composição, o que poderia fazer o argumento do alto acoplamento causado pela herança ganhar força novamente, para ela, no melhor dos casos, ser só uma alternativa escrita com uma funcionalidade pior.

Entretanto, mesmo que frameworks disponibilizem interfaces, módulos isolados baseados em composição, e etc, que façam parecer que o código é menos intrusivo, e mais desacoplado. A verdade é que acoplamento não importa muito num cenário onde você decide usar um framework, pelo menos não para quem escreve o código do framework pensando num benefício para quem usa.

Tão importante quanto a força do acoplamento é a direção em que ele acontece, estar desacoplado não significa que magicamente os dois módulos sempre vão estar isolados um do outro, na verdade, significa que o código que depende de membros abstratos está se defendendo de quem usa ele.

Essa noção é muito importante, pois isso significa que mesmo que os frameworks usem composição, e interfaces, expondo elas para manter tudo desacoplado e etc, na verdade, o que está acontecendo é que o código do framework está se protegendo do seu código, quando o que queremos ao ter um baixo acoplamento no código é justamente o contrário, proteger o nosso código do resto.

Se os desenvolvedores de framework fazem isso, interessante para eles que estão se previnindo de mudanças nos códigos dos seus usuários, mas isso adiciona pouquíssima vantagem para o objetivo de um framework que é facilitar a vida de seus usuários. Uma vez que eles que tem que se defender do framework, e não o contrário.

Outro motivo pelo qual o acoplamento importa pouco ou as vezes não importa quando estamos falando de frameworks é que, por definição, eles forçam os seus usuários a jogarem nas suas regras, então por definição usar um framework é decidir se acoplar a ele, e reagir as suas mudanças, afinal se você não usa uma arquitetura como a clean architecture ou similares, a estrutura do seu código é a própria estrutura do framework.

Logo, é uma premissa que para usar, você está aceitando estar acoplado a ele em menor ou maior grau, até porque a única maneira de não se acoplar é escrevendo seu código explicitamente para evitar o framework, o que é uma abordagem mais trabalhosa e faz você não colher todos os benefícios de usar um em primeiro lugar, ou simplesmente não utilizar ele, afinal a ideia é usar código pronto que não é você que controla.

Dessa forma, como o framework em si não tem como tornar o seu código desacoplado dele, visto que própria premissa dele é ser uma dependência do seu projeto, o acoplamento realmente tem pouquíssimo valor nessa situação em específico, o que nos trás uma situação exatamente como descrevemos anteriormente, onde temos alto acoplamento, e reúso é uma prioridade.

Coesão

Curiosamente, um ponto que continua o raciocínio por trás do acoplamento não ser tão relevante, é que, dependendo do caso, o fato de ter menos acoplamento pode até ser pior.

Uma vez que a maior flexibilidade trazida por ele, é uma vantagem quando você que é o dono desse código, mas pode ser uma desvantagem para um código já estável e coeso como é o caso dos frameworks.

Isso porque a ideia de um framework é forçar a estrutura dele nos seus usuários em maior ou menor grau, além disso, seus módulos tendem a ser altamente coesos, e já terem sido escritos para funcionarem bem entre si dentro dos casos esperados pelos seus autores.

Sendo assim, uma abordagem que oferece mais flexibilidade tal como a composição poderia fazer com que seja possível a criação de uma combinação inválida dentro das premissas do framework.

Outro "problema" é que reforçar uma consistência na forma de fazer as coisas, sendo uma noção vinda até pela própria definição de framework de ser uma base para se construir em cima, é um atributo bem relevante para um framework, e uma abordagem cujo os benefícios são menos controle por parte do framework (mais flexível), e menos dependência direta dele (menos acoplado) iria diretamente contra a promoção deste aspecto.

Uma maior flexibilidade pode ser uma vantagem para frameworks baseados em configuração (Spring, Synfony, etc), mas particularmente um problema para frameworks baseados em convenções, visto que vai tornar o código menos consistente o que pode ser um desafio para os autores na hora de forçarem certas convenções a se repetirem ao longo do código.

Fechando esse ponto da consistência, herança pode ser uma vantagem aqui, pois ela oferece uma forma de inversão de controle na forma do padrão template method que é mais rígido que a versão de composição que seria o strategy, com o benefício de ser mais conveniente de implementar os pontos de extensão (o que é um pró no caso de frameworks), e dar mais controle para o framework nesse caso, enquanto retém benefícios semelhantes a versão baseada em composição da aplicação desse conceito.

Conclusão

Sinceramente, quando eu comecei a pesquisa para este artigo, pensei que seria bem simples, iria falar mal do conceito, mostrar que template method era pelo menos algo que dava para ser utilizado e que era legal, e fechar por ali, no entanto, quanto mais eu lia sobre o assunto, mais ideias eu tinha sobre como talvez herança não fosse tão inútil quanto o senso comum faz parecer, o que resultou no texto de hoje sendo um dos que eu mais me diverti escrevendo.

E você? Se surpreendeu com o quanto a discussão poderia ser mais interessante do que simplesmente dizer que composição é melhor e ponto? Já havia pensando tão profundamente sobre a utilidade da herança? Mudou algo em como você encara esse princípio? Conta para gente aqui nos comentários.

Links que podem te interessar

Ass. Suporte Cansado

Tell Don't Ask: a arte da comunicação entre objetos.

Terminal Coffee — Sat, 19 Oct 2024 04:23:31 +0000

Um tópico que me manteve muito interessado recentemente foi o princípio Tell Don't Ask, citado originalmente no livro Smalltalk By Example (Alec Sharp), o autor destaca que um aspecto que difere muito o código orientado a objetos do código procedural é que usando objetos se diz para eles agirem, enquanto usando funções se pergunta pelos dados primeiro para depois decidir como se agir.

O princípio se tornou conhecido graças a Andy Hut e Dave Thomas, autores do livro The Pragimatic Programmer, onde, novamente, o conceito é destacado como algo fundamental para a aplicação das ideias orientadas a objeto no código.

Por fim, minha terceira fonte de inspiração para mergulhar de cabeça nesse assunto foram dois artigos incríveis abordando o tema para além de uma variação do artigo escrito pelo Fowler:

A Better Way to Handle Validation Errors: que mostra o potencial desse estilo no tratamento de erros, o que nos dá uma dica sobre como objetos se informam das coisas sem a necessidade de retornar valores ou uso de ifs;
Map, don't ask: que traça uma comparação muito interessante do estilo orientado a objetos de resolver problemas (tell don't ask), com o estilo funcional (monâdas representando efeitos colaterais);

Sendo assim, tenho pensado muito sobre como poderíamos escrever software apenas nos baseando nessa ideia, então hoje vou compartilhar com vocês, caros leitores, minhas reflexões sobre o assunto, na forma das várias interações que podemos observar entre objetos, e como lidamos com elas no tell style ao invés do ask style.

Tell Don't Ask

Antes de irmos de fato para o assunto de hoje, para manter todos na mesma página, vamos relembrar a definição do princípio:

Você envia comandos aos objetos dizendo para eles o que você quer feito. Nós explicitamente não queremos perguntar ao objeto sobre o seu estado, tomar uma decisão, e então dizer ao objeto o que fazer.

~ Andy Hunt e Dave Thomas (adaptação livre)

Situação 01: Quando o objeto possui todos os dados necessários

Aqui seria o exemplo mais simples do uso do Tell Don't Ask (TDA), vamos pensar em lidar com um objeto apenas, por exemplo num caso de uso de sacar dinheiro de uma conta bancária. Se nós seguirmos o ask style, teríamos o seguinte resultado:

class Account {
  constructor(
    private number: string,
    private balance: number
  ) {}

  getBalance(): number {
    return this.balance;
  }

  setBalance(balance: number): void {
    this.balance = balance;
  }
}

type WithdrawCommand = {
  account: Account;
  amount: number;
}

function useCase({ account, amount }: WithdrawCommand): void {
  if (account.getBalance() < amount) {
    throw new Error("Insufficient balance in the account");
  }

  account.setBalance(account.getBalance() - amount);
}

useCase({ account: new Account('12345-6', 100), amount: 50 });

Toda a lógica de negócio ficou acumulada no caso de uso, e pior de tudo, ela apenas usa dados presentes na classe Account, o que significa que ela poderia ter dado conta de fazer isso ela mesma, mas quem fez foi o caso de uso, logo, o princípio do encapsulamento, onde nos benefíciamos dos dados viverem ao lado das computações realizadas neles, está sendo gravemente violado aqui.

Podemos mudar isso ao reescrever no tell style:

class Account {
  constructor(
    private number: string,
    private balance: number
  ) {}

  withdraw(amount: number): void {
    if (this.balance < amount) {
      throw new Error("Insufficient balance in the account");
    }

    this.balance -= amount;
  }
}

type WithdrawCommand = {
  account: Account;
  amount: number;
}

function useCase({ account, amount }: WithdrawCommand): void {
  account.withdraw(amount);
}

useCase({ account: new Account('12345-6', 100), amount: 50 });

Temos que o código foi drasticamente simplificado para apenas:

account.withdraw(amount);

Logo, lidando com um único objeto, caso você estiver se pegando usando muitas queries antes de decidir fazer alguma coisa, considere se a lógica que você está escrevendo não poderia ser um método do objeto que é dono desses dados, assim você pode dizer para ele realizar a tarefa ao invés de perguntar se ele tem os dados para realizar a tarefa.

Situação 02: Quando um objeto precisa de informações de outro para agir

Se tudo pudesse ser modelado com os dados pertencendo a um objeto, e somente a ele, o mundo seria muito mais fácil, afinal, aplicaríamos sempre a regra que vimos anteriormente, e ai tudo sempre ia acabar se encaixando no método de um objeto, e o dono daquele método seria óbvio, entretanto existem situações onde uma operação exige a colaboração entre dois objetos, pois eles "operam no mesmo dado", ao mesmo tempo que precisam se manter independentes um do outro, pelo menos em termos de conhecimento de seus detalhes de implementação.

Por exemplo, se tivermos um caso de uso onde um cliente compra um produto, o cliente precisa pagar um preço que é uma propriedade de produto, sendo assim, ele precisa de um dado que não é dele para realizar suas operações.

Caso nós estejamos pensando de forma procedural, uma solução simples seria perguntar ao produto qual o seu preço, e então modificar a quantidade de dinheiro no cliente, ex:

class Customer {
  constructor(private name: string, private money: number) {}

  setMoney(money: number): void {
    this.money = money;
  }
}

class Product {
  constructor(private name: string, private price: number) {}

  getPrice(): number {
    return this.price;
  }
}

function useCase(customer: Customer, product: Product): void {
  if (customer.getMoney() < product.getPrice()) {
    throw new Error("Customer cannot pay for the Product");
  }

  customer.setMoney(customer.getMoney() - product.getPrice());
}

A princípio, parece que temos uma situação semelhante a do nosso primeiro exemplo, entretanto note a linha que contém a condicional:

if (customer.getMoney() < product.getPrice()) {

Ela não envolve só os dados de customer, por isso não podemos simplesmente converter ela num método, como podemos lidar com esse dado que não pertence ao cliente? A resposta é bem simples, se é algo de fora do objeto, então tem que vir de fora, por isso o preço é convertido num parâmetro, ex:

class Customer {
  constructor(private name: string, private money: number) {}

  pay(amount: number): void {
    if (this.money < amount) {
      throw new Error("Customer cannot pay for this amount");
    }

    this.money -= amount;
  }
}

class Product {
  constructor(private name: string, private price: number) {}

  getPrice(): number {
    return this.price;
  }
}

function useCase(customer: Customer, product: Product): void {
  customer.pay(product.getPrice());
}

Com isso o TDA foi aplicado com sucesso no cliente, mas o nosso objeto produto continua sendo só um saco de dados, então será que existe alguma forma de aplicar o TDA nele também?

A resposta é sim, pois ele tem uma ação relacionada com ele, que é a venda, da mesma forma que a gente tem uma ação faltando no cliente também, que é a compra, o que nos permite modelar a situação da seguinte maneira:

class Customer {
  constructor(private name: string, private money: number) {}

  pay(amount: number): void {
    if (this.money < amount) {
      throw new Error("Customer cannot pay for this amount");
    }

    this.money -= amount;
  }

  buy(product: Product) {
    product.sellItselfTo(this);
  }
}

class Product {
  constructor(private name: string, private price: number) {}

  sellItselfTo(customer: Customer) {
    customer.pay(this.price);
  }
}

function useCase(customer: Customer, aProduct: Product): void {
  customer.buy(aProduct);
}

Parece meio confuso a primeira vista, mas o que está acontecendo nesse código é que ao aplicar o TDA em todas as operações que devem acontecer para que a compra de um produto seja realizada, nós acabamos numa situação onde para implementar uma ação, nós repetimos o processo de descrever as ações que ela precisa realizar para ser executada também, o que nos leva a aplicar o TDA nessas sub-tarefas também, entrando num ciclo de adiar a resolução do problema o máximo possível, sempre empurrando a batata para frente até alguém conseguir resolver o problema. Em certo sentido, é semelhante a como a gente treina para escrever algoritmos recursivos.

Entrando mais em detalhes, o truque aqui é que a gente troca quem está no controle da execução do código entre ambos os objetos conforme a necessidade de um dado que não pertence ao objeto for surgindo. A lógica é a seguinte:

Para que o cliente possa comprar o produto, o produto precisa ser vendido para ele, então o cliente pede ao produto para que a ação de venda aconteça;
Para que o Produto possa se vender, ele precisa saber a quem ele está sendo vendido, então ele requere isso via um parâmetro;
Como Cliente sabe quem quer comprar o produto (ele mesmo), ele informa ao produto quem é o comprador se passando como parâmetro;
Sabendo para quem ele vai se vender, o Produto precisa que o Cliente pague por ele, então ele pede ao cliente para realizar o pagamento;
Para que o cliente pague, ele exige saber o valor a ser pago, então ele requere isso via um parâmetro;
O produto sabe qual valor deve ser pago (pois é o seu preço), então ele passa o preço como parâmetro, e o cliente consegue executar a ação de pagar, encerrando o caso de uso;

Visualizando a coisa acontecendo, o fluxo de execução seria algo como:

customer.buy(product);
product.sellItselfTo(customer);
customer.pay(product.price);

O truque para fazer com que o controle da execução seja trocado conforme ela for acontecendo, é ceder o controle para o outro objeto chamando um de seus métodos, e se passando como parâmetro, assim quando o outro objeto terminar de fazer o que ele precisa, ele pode devolver o controle da execução para o original ao chamar um de seus métodos.

Situação 03: Quando um objeto precisa reagir a eventos em outro

type Nothing = null | undefined | Promise<null | undefined>;

type Credentials = {
  email: string;
  password: string;
};

interface SignInOutputBoundary {
  emailNotFound(email: string): Nothing;
  invalidCredentials(credentials: Credentials): Nothing;
  userAuthenticated(user: User): Nothing;
}

class SignIn {
  constructor(
    private users: UserRepository,
    private encrypter: Encrypter
  ) {}

  async attemptFor(
    input: Credentials,
    andReportTo: SignInOutputBoundary
  ): Promise<void> {
    const output = andReportTo;
    const user = await this.users.userOfEmail(input.email);

    if (!user) {
      return output.emailNotFound(input.email);
    }

    if (!user.matchPassword(input.password, this.encrypter)) {
      return output.invalidCredentials(input);
    }

    return output.userAuthenticated(user);
  }
}

class SignInController implements SignInOutputBoundary {
  constructor(private signIn: SignIn, private res: ResponseBuilder) {}

  emailNotFound(email: string) {
    this.res.status(401).json({ error: `Email: ${email} not found` });
  }

  invalidCredentials(credentials: Credentials) {
    this.res.status(401).json({ error: `Invalid Credentials` });
  }

  userAuthenticated(user: User) {
    this.res.status(200).json({
      message: "User Authenticated",
      token: new Token(user).toString()
    });
  }

  private validateCredentials(data: unknow) {
    // lógica para validar o body...
  }

  async handle(req: Request): Response {
    this.validateCredentials(req.body);
    await this.signIn.attemptFor(req.body, this);
    return this.res.build();
  }
}

Neste exemplo não aplicamos o TDA em 100% do código para não deixa-lo tão complexo, feitas essas considerações, se você já entendeu a ideia de "trocar o controle da execução", então já deve ter matado a charada aqui também, basicamente quando precisamos notificar um objeto de coisas que aconteceram em outro objeto, podemos mandar uma mensagem para o objeto interessado avisando que o que ele queria saber aconteceu, e o que seriam mensagens senão métodos?

Por isso, para mandar uma mensagem para o objeto interessado, ele precisa ser capaz de receber essas mensagens para início de conversa, ou seja, ele precisa ter os métodos que vão responder a cada uma dessas situações implementados dentro dele, sendo uma solução bem interessante para lidar com lógica condicional num geral usando apenas troca de mensagens.

A aplicação do TDA aqui se dá pois ao invés de fazermos algo como o retornar um código de status ou, numa abordagem mais moderna, um objeto Result representando o resultado da execução do caso de uso, e depois decidindo o que fazer, ou seja, perguntando primeiro ao caso de uso qual foi o seu resultado, e depois decidindo o que fazer, sendo que o próprio caso de uso, que tem controle sobre essas informações, pode conversar com o controller, e dizer para ele o que fazer diretamente sem esse passo intermediário.

Em resumo, o truque aqui é que o objeto interessado em saber de coisas de outro objeto, deve declarar métodos para cada coisa que ele quiser saber desse segundo objeto, dessa forma o segundo objeto pode depender do interessado e chamar os seus métodos quando as condições para eles serem chamados forem atingidas. E se essa explicação soou familiar para você, é porque se nós implementarmos essa ideia de forma ainda mais desacoplada, o que nós temos é basicamente o padrão de projetos Observer.

Situação 04: Quando ações diferentes são necessárias para tipos diferentes de objetos

Continuando na ideia de aprender com padrões de projeto, o padrão Visitor nos ensina que podemos realizar a comunicação entre objetos mesmo quando a informação que precisamos é uma meta informação, por exemplo de qual tipo é o objeto.

No caso de se ter uma única operação ao longo de vários objetos, mas com implementações diferentes para cada um, podemos simplesmente usar polimorfismo simples para resolver o problema, mas e se nós precisarmos executar operações diferentes para tipos diferentes de objetos, quando essas operações podem ter implementações diferentes?

Por exemplo, podemos escrever o exemplo anterior de uma forma diferente caso se prefira lançar erros e tratar eles separadamente num bloco catch, ao invés de acoplar o caso de uso no presenter:

interface ExceptionVisitor {
  unknown(error: unknown): void;
  error(error: Error): void;
  productNotFound(error: ProductNotFoundException): void;
  outOfStock(error: OutOfStockException): void;
  insufficentStock(error: InsufficentStockException): void;
}

interface Exception {
  accept(visitor: ExceptionVisitor): void;
}

abstract class DomainException extends Error implements Exception {
  abstract accept(visitor: ExceptionVisitor): void;
}

class UnknownException implements Exception {
  constructor(private value: unknown) {}

  accept(visitor: ExceptionVisitor): void {
    visitor.unknown(this.value);
  }
}

class ErrorException implements Exception {
  constructor(private error: Error) {}

  accept(visitor: ExceptionVisitor): void {
    visitor.error(this.error);
  }
}

class ProductNotFoundException extends DomainException {
  constructor() {
    super("Product not found");
  }

  accept(visitor: ExceptionVisitor): void {
    visitor.productNotFound(this);
  }
}

class OutOfStockException extends DomainException {
  constructor() {
    super("Product out of stock");
  }

  accept(visitor: ExceptionVisitor): void {
    visitor.outOfStock(this);
  }
}

class InsufficentStockException extends DomainException {
  constructor() {
    super("Insufficient Stock of Product");
  }

  accept(visitor: ExceptionVisitor): void {
    visitor.insufficentStock(this);
  }
}

function exceptionFactory(value: unknown): Exception {
  if (value instanceof DomainException) {
    return value;
  }

  if (value instanceof Error) {
    return new ErrorException(value);
  }

  return new UnknownException(value);
}

function tryExecute<F extends (...args: any[]) => any>(
  fn: F,
  orHandleWith: ExceptionVisitor
): ReturnType<F> | void {
  try {
    return fn();
  } catch (error) {
    return exceptionFactory(error).accept(orHandleWith);
  }
}

class OrderController {
  constructor(private placeOrder: PlaceOrder) {}

  place(req: Request, res: Response) {
    tryExecute(() => this.placeOrder.execute(req.body), {
      unknown() {
        res.status(500).json({ error: "Unknown error" });
      },
      error(error) {
        res.status(500).json({ error: error.message });
      },
      insufficentStock() {
        res
          .status(400)
          .json({ error: "Cannot place an order due to insufficient stock" });
      },
      outOfStock() {
        res.status(400).json({
          error: "Cannot place an order for an product that is out of stock",
        });
      },
      productNotFound() {
        res.status(400).json({
          error: "Cannot place an order for a product that doesn't exist",
        });
      },
    });
  }
}

Nesse caso, com a ajuda de um pequeno helper para converter um valor unknow numa Exception que pode ser visitada, nós conseguimos implementar uma forma de lidar com todas as exceções lançadas pelo caso de uso PlaceOrder sem depender de um switch dentro do Controller.

Dessa forma, ao invés de ter um instanceof para cada tipo de Erro, nós limitamos a abordagem de perguntar pelas coisas apenas ao que está fora de nosso controle (valores unknow, e erros fora de DomainException), de forma a adaptar esses valores para objetos dentro de nosso controle novamente, e então usar apenas da abordagem tell para lidar com o problema, visto que dizemos para a Exceção aceitar um Visitor, e cada erro pode decidir por si mesmo como usar o Visitor para lidar com si mesmo, o que seria o contrário da abordagem ask, onde o Visitor teria que perguntar a cada Erro quem ele é para depois decidir qual código executar.

Conclusão

Tentar usar o Tell Don't Ask para tudo pode até não ser a abordagem mais pragmática possível, entretanto para que nós de fato consigamos aprender um paradigma, devemos tentar nos blindar o máximo possível de nossos vícios, enquanto tentamos abraçar ao máximo as premissas do paradigma, o que é uma experiência bem difícil, e que nos desafia a pensar fora da caixinha o máximo possível, mas os resultados são recompensadores, visto que depois de conquistar essa nova maneira de pensar, nosso cérebro fica cada vez mais flexível e aberto a novos tipos de soluções, o que melhora a nossa capacidade de resolver problemas.

Você leitor já havia olhado para a Orientação a Objetos por este ângulo da conversa entre objetos? Achou interessante? Conta para a gente sua opinião sobre o assunto aqui nos comentários.

Até a próxima!

ASS: Suporte Cansado...

Afinal de contas, qual a definição de Orientação a Objetos?

Terminal Coffee — Thu, 05 Sep 2024 19:04:50 +0000

Introdução

O paradigma da orientação a objetos certamente é um dos tópicos mais relevantes da programação, sendo encontrada em diversas das boas práticas da industria como SOLID, GoF Design Patterns, ou Object Calhistenics, e até mesmo em linguagens extremamente populares como Java, C#, Ruby, PHP, JavaScript, etc. E dada tamanha relevância, ela também é alvo de diversos debates tanto em discussões online ou até na própria acadêmia.

Uma das principais polêmicas em torno do paradigma seria: o que de fato seria a orientação a objetos? Visto que ninguém concorda com o que ela significa, sendo esse o cerne da questão em vários tipos de brigas de internet como por exemplo quando alguém clama que a sua linguagem é verdadeiramente orientada a objetos enquanto as outras não são, ou que determina linguagem não é realmente orientada a objetos, e etc.

O que pode parecer bobo a primeira vista, mas existe um problema escondido atrás disso que é o fato de realmente não existir uma definição formal para o que seria a orientação a objetos. Logo, ao se criticar algo relacionado com o paradigma não podemos realmente ter certeza se ela é justa ou não devido ao fato de ninguém saber do que a verdade se trata de fato, já que isso só vai levar a um debate onde ambas as partes podem acusar a outra de atacar um espantalho visto que elas não concordam com a definição do que elas estão debatendo, o que as leva a falar sobre coisas diferentes enquanto pensam falar sobre a mesma coisa.

Isso acontece pois ela não nasce de uma base formal que pode ser identificada como fonte primária das discussões tal como o paradigma estruturado/procedural - que nasce do teorema Boehm-Jacopini e do artigo Go-to statement considered harmful - ou do funcional que nasce do cálculo lambda, pelo contrário, tecnicamente, ela tem duas história de origens diferentes, o que dificulta muito as coisas, afinal é complicado até mesmo dizer quem foi a primeira linguagem orientada a objetos, se foi Simula ou o Smalltalk.

Se você não tem contato prévio com o tema, pode estar achando tudo o que eu estou descrevendo aqui um tanto quanto estranho, afinal, todos aprendemos sobre orientação a objetos, usamos a palavra para nos comunicarmos diariamente, e tudo parece seguir normalmente, sem ruídos na comunicação, não é mesmo?

Pode até estar pensando que é muito fácil visto que mesmo se olharmos em fontes diferentes como um tutorial genérico na internet, a Wikipedia, ou até se passarmos pelo ensino formal (como um curso técnico ou faculdade), vamos encontrar definições bem semelhantes à algo que eu chamo de: os 4 pílares da orientação a objetos:

Abstração;
Encapsulamento;
Herança;
Polimorfismo.

Só que isso na verdade só conta uma parte da história, pois como apontei anteriormente, na verdade, existem duas escolas diferentes de pensamento orientado a objetos, uma que cresceu baseada na tradição criada no Simula, e desenvolvida e popularizada pelo C++, e outra que cresceu na tradição criada pelo Smalltalk.

Mesmo que possamos aceitar o lado vencedor da história na tradição do C++ (visto que a grande maioria das linguagens consideradas OO atualmente seguem mais pelas suas ideias do que pelas de Smalltalk), ou seja, do legado de Simula que evoluiu nos 4 pílares, não se tem um consenso sobre se eles são exatamente esses 4 ou se realmente deveriam ser 4. Por exemplo:

O próprio criador da linguagem C++ considera uma definição que só possui 3 pílares (abstração, herança, e polimorfismo);
A linguagem Eiffel considera outro conjunto de 6 princípios (classes, asserções, genericidade, herança, polimorfismo, e dinamyc binding);
O criador da linguagem Smalltalk diz que o que ele quis dizer ao cunhar o termo não é nada disso que usamos atualmente, e descreve que na verdade se resume a 3 princípios (Troca de mensagens, encapsulamento, e Late-binding extremo de todas as coisas);
A linguagem Ada define apenas 3 princípios (encapsulamento, herança, e polimorfismo);
A linguagem Self se baseia em 3 ideias(protótipos, slots, e comportamentos) que apesar de terem outros nomes, são equivalentes a termos usados em outras definições (herança, campos, e troca de mensagens);
A linguagem Java define 5 conceitos (encapsulamento, campos, herança, métodos, e objetos);
A linguagem C# segue os 4 pílares;
O criador da linguagem Simula admite não existir uma definição concreta, mas cita alguns conceitos que acredita serem comuns as linguagens consideradas orientadas a objeto (objetos, classes, herança, polimorfismo);
A linguagem Python cita 4 conceitos como orientados a objeto (classes, objetos, herança, e polimorfismo);
A linguagem Ruby afirma seguir a definição de Smalltalk, com grande enfase nas ideias de que tudo deveria ser um objeto, e troca de mensagens;
A linguagem PHP não possui uma definição oficial sobre orientação a objetos, mas podemos derivar que ela segue algo como os 4 pílares com base nas funcionalidades que ele apresenta como orientadas a objeto;
A linguagem Objective-C não possui uma definição oficial sobre orientação a objetos, mas seu manual sugere a seguinte combinação de conceitos (tudo é um objeto, classes, troca de mensagens, encapsulamento, herança, e polimorfismo);
O site MDN, em sua seção sobre a linguagem JavaScript considera 3 conceitos (classes e objetos, herança e encapsulamento);
Grady Booch, autor do livro Object-Oriented Analysis and Design With Applications, define 7 princípios (abstração, encapsulamento, modularidade, hierarquia, tipagem, concorrência, e persistência);
A GoF (Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson, e John Vlissides), em seu livro Design Patterns : Elements of Reusable Object-Oriented Software cita encapsulamento, herança e polimorfismo como "padrões de projeto" numa linguagem procedural;
Peter Van Roy, em seu livro Concepts, Techiniques, and Models of Computer Programming, descreve OO em 4 items (objetos como mecanismo de abstração, estado explícito, polimorfismo, e herança);
A ISO/IEC 2382 item 2122503, que é o mais próximo que a gente tem de uma definição formal, considera 6 princípios (abstração, encapsulamento, herança, polimorfismo, troca de mensagens, e dynamic binding);
Yegor Bugayenko, define por meio de um modelo formal criado por ele chamado de phi-calculus, implementado na sua linguagem EOLANG;
etc...

Definindo uma perspectiva

Dessa forma, assim como Bjarne Stroustrup (criador do C++) argumenta em sua definição de orientação a objetos:

Qualquer definição de "orientação a objetos" deveria ser históricamente aceitável. Palavras são apenas úteis para comunicação, elas apenas significiam alguma coisa, se concordarmos em um significado para elas.

~ Bjarne Stroustrup, adaptado do inglês em tradução livre

Por isso gostaria de adotar uma abordagem holística (analisando pelo todo ao invés de pela soam das partes) para analisar o que deve ser considerado para a minha definição. Nisso avaliarei de acordo com 4 critérios em ordem de importância:

Alinhamento conceitual com a perspectiva definida;
Relevância histórica;
Implementações na prática (que também será considerada a percepção no senso comum);
Exclusividade para a OO (o quanto o conceito pode ser identificado como algo de orientação a objetos, ao invés de algo de paradigma X ou Y, ou um conceito mais geral);

Vamos começar por definir o nosso ponto de partida pela história, primeiro vamos decidir qual dos lados vamos escolher como fonte primária, e então seguir com as intenções do que deveria significar orientação a objetos dos autores dela como base para nossa definição, além de usa-la como parâmetro de comparação para julgar qual conjunto de princípios faz sentido a ser enquadrado nela.

Nessa questão, eu gosto da visão de que Alan Kay inventou a "orientação a objetos", mas não os "objetos", por isso nossa base vai ser a visão dele sobre o que deveria ser a orientação a objetos, que podemos resumir em algumas citações:

Apenas um gentil lembrete de que me esforcei no último OOPSLA para tentar lembrar a todos que Smalltalk não é apenas sua sintaxe ou biblioteca de classes, nem se trata de classes. Lamento ter cunhado há muito tempo o termo "objetos" para este tópico porque faz com que muitas pessoas se concentrem no ideia menor.

A grande ideia é "mensagens" - é isso que o núcleo do Smalltalk/Squeak é tudo sobre...

~ Alan Kay, adaptado do inglês em tradução livre

Pensei em objetos como células biológicas e/ou individuais computadores em uma rede, capazes apenas de se comunicar por meio de mensagens (então mensagens vieram logo no início - demorou um pouco para ver como enviar mensagens em uma linguagem de programação com eficiência suficiente para ser útil).

Eu queria me livrar dos dados. O B5000 quase fez isso através de seu arquitetura de HW quase inacreditável. Eu percebi que o A metáfora da célula/computador inteiro eliminaria os dados, e esse "<-" seria apenas mais um token de mensagem (demorei um pouco para pense nisso porque eu realmente pensei em todos esses símbolos como nomes para funções e procedimentos.

Minha formação em matemática me fez perceber que cada objeto poderia ter várias álgebras associadas a ele, e poderia haver famílias de estes, e que estes seriam muito úteis. O termo o "polimorfismo" foi imposto muito mais tarde (acho que por Peter Wegner) e não é muito válido, pois na verdade vem da nomenclatura de funções, e eu queria um pouco mais do que funções. Eu inventei um termo "genericidade" para lidar com comportamentos genéricos em um forma quase algébrica.

Não gostei da maneira como o Simula I ou o Simula 67 fizeram a herança (embora eu pensasse que Nygaard e Dahl eram apenas tremendos pensadores e designers). Então decidi deixar de fora a herança como uma funcionalidade built-in até que eu entendesse melhor.

~ Alan Kay, adaptado do inglês em tradução livre

POO para mim significa apenas troca de mensagens, retenção local dos dados e proteção e ocultamento do estado, e extremo late binding de todas as coisas.

~ Alan Kay, adaptado do inglês em tradução livre

Com isso podemos concluir que a perspectiva pelo qual vemos um programa orientado a objetos usando as definições de Kay, é a seguinte:

Um programa é visto como uma rede de objetos se comunicando por meio de troca de mensagens, no qual se busca programar evitando os dados, focando nas interações, de forma que uma mensagem possa carregar vários significados.

Falando em perspectiva, esse é a seção utilizado pelos criadores de Simula em seu livro Object-Oriented Programming in the BETA Programming Language para descrever o framework conceitual de um framework, ou seja, uma descrição de como enxergamos a estrutura de um programa escrito em determinado paradigma, por exemplo no caso da programação procedural, eles a descrevem como:

A execução de um programa é considerada uma sequência (parcialmente ordenada) de chamadas de procedimento que manipulam variáveis.

~ Nygaard at all, adaptado do inglês em tradução livre

No caso da funcional:

Um programa é considerado uma função matemática, que descreve uma relação entre entrada e saída.

~ Nygaard at all, adaptado do inglês em tradução livre

E para a orientação a objetos:

A execução de um programa é considerada um modelo físico, simulando o comportamento de uma parte real ou imaginária do mundo.

~ Nygaard at all, adaptado do inglês em tradução livre

Assim, mesmo que nosso foco seja na definição de Alan Kay, dado as grandes contribuições de Krysten Nygaard e Ole-Johan Dahl (criadores do Simula) no que diz respeito as funcionalidades encontradas em linguagens orientadas a objeto, e em quão bem sua perspectiva envelheceu ao longo do tempo, visto que quase todo tutorial moderno ainda segue essa história que os objetos representam conceitos do mundo real, sendo até formalizado como parte da definição de abstração, eu diria que é adequado incorporar suas visões na nossa definição final.

Dessa forma, onde puder ser feito um argumento em favor da conciliação das duas tradições numa definição unificada, assim respeitando nossa abordagem de uma análise holística, eu tentarei.

Por isso, como ela não é necessariamente exclusiva a nossa definição atual, podemos incrementar ela com o seguinte:

Um programa é visto como uma rede de objetos, sendo estes representações de conceitos do domínio, se comunicando por meio de troca de mensagens, no qual se busca programar evitando os dados, focando nas interações, de forma que uma mensagem possa carregar vários significados. Sendo sua estrutura geral algo semelhante a uma simulação do comportamento de uma parte real ou imaginária do mundo.

Uma consideração que pode ser feita é que isso pode direcionar as pessoas a focarem na "ideia menor", mas assim como admitimos antes é necessário reconhecer como as ideias evoluem ao longo do tempo pois uma palavra só tem valor se as pessoas entendem o que ela quer comunicar, portanto eu acredito que esta perspectiva encontra balanço o suficiente entre manter os objetivos iniciais de Alan Kay, e incorporar os valores do sistema de objetos de Nygaard e Dahl.

Definindo conceitos

Com o texto atual da definição, eu já poderia me dar por satisfeito, sendo essa a minha resposta a questão apresentada neste artigo, mas eu acredito que uma definição completa de um paradigma deveria incluir tanto a sua "perspectiva" do que representa a execução de um programa, quanto um conjunto de princípios associados a ela.

Por isso, podemos dizer que estamos na metade do caminho, e agora podemos voltar à aquela lista extensa de definições que eu dei mais cedo para buscar quais princípios se adequam a nossa perspectiva ao mesmo tempo que não traem a nossa visão base (o foco na troca de mensagens).

Para isso, novamente, vamos voltar a nossa fonte primária, os princípios da OO do Smalltalk:

Troca de mensagens;
Retenção local dos dados, junto com proteção e ocultamento do estado;
Extremo late binding.

Se usarmos o critério de relevância histórica de novo, poderia ser argumentado que como esses termos nem se usam mais hoje (com exceção de troca de mensagens), por isso deveríamos considerar usar os 4 pílares no lugar, e, novamente, acredito que usar uma abordagem conciliadora aqui seria o melhor dos dois mundos sem contradições:

Troca de mensagens;
Polimorfismo;
Encapsulamento;
Abstração;
Herança;

Existe uma explicação para a escolha desses 5 princípios é que:

Troca de mensagens

A troca de mensagens é algo inegociável dentro do contexto original da OO, afinal Alan Kay afirma ser a grande ideia do paradigma, seu conceito mais importante, por isso todos os outros conceitos devem ter algo a ver com ela.

Sua adoção na prática é bem considerável até, visto que linguagens com relevância histórica como Self, Objective-C, e Ruby mantém uma forte conexão com este conceito, e o próprio Ruby é considerado uma linguagem mainstream nos dias de hoje, com grandes aplicações construídas nele como o próprio github, além de ter uma comunidade bem ativa.

E eu diria que junto com herança e encapsulamento, é um dos conceitos que mais carrega a identidade da OO, visto que as outras duas instâncias (piada proposital) onde o termo é usado seria no Actor Model, que é um modelo matemático formal de lógica que basicamente tem quase as mesmas ideias de Alan Kay, mas é totalmente baseado em concorrência (algo como se OO fosse 100% async para vocês dev JS entenderem).

Polimorfismo

Esse é um conceito que acerta todos os critérios de nossa análise, visto que assim como notado por Nygaard e Dahl, ele está presente em praticamente todas as linguagens que implementam o paradigma, mesmo que de forma implícita (se tem suporta a herança, implícitamente se admite o suporte a polimorfismo também).

Ele está super alinhado com a ideia de troca de mensagens também, visto que é um benefício natual de seu uso. Fora que ele está presente na definição de Alan Kay (embora ele diga que prefere o termo genericidade) afinal late binding é o nome do processo presente em linguagens
de programação que permite a elas não relacionarem uma chamada a uma função com um código em específico, mas sim executarem baseado no contexto (que no caso da OO é o objeto que recebe a mensagem), sendo essa exatamente a definição de polimorfismo.

Em termos de percepção pública, seria o conceito mais importante dos 5 listados, sendo definido até mesmo como a essência da OO pelo Uncle Bob, além disso mesmo em situações onde não se planeja programar exatamente em orientação a objetos, se considera esse princípio como um bloco fundamental para a construção de algumas ideias como a arquitetura hexagonal ou a arquitetura limpa.

Entretanto, o conceito não é único da OO, sendo um conceito mais geral presente ao longo de vários paradigmas, muitas vezes com implementações de tipos diferentes na mesma linguagem. Apesar disso, pode-se argumentar que específicamente o polimorfismo de subtipo é único da OO, pois é um tipo dependente da capacidade da linguagem de realizar herança.

Encapsulamento

Se você leu o nosso artigo sobre o assunto (sim, gostamos de dar pitaco sobre definições por aqui), deve saber que dizer "Retenção local dos dados, junto com proteção e ocultamento do estado" é basicamente a definição completa de encapsualmento, então o lado do alinhamento conceitual, assim como os anteriores, está 100% neste princípio aqui.

Apesar de algumas linguagens não citarem o encapsulamento como princípio, o conceito está presente nelas mesmo que pela metade, o fato de ter objetos (ou como no caso de Java e Self enfatisar o conceito de campos nos objetos) mostra que elas possuem um mecanismo para menter os dados apenas sendo operados num contexto local junto as suas funções (o próprio objeto em si), por outro lado linguagens como o C++ e Eiffel apresentam mecanismos para proteção e ocultamento do estado na forma de modificadores de acesso (C++) ou asserções, pré-condições, pós-condições, e invariantes (Eiffel). Em Java mesmo temos um dos artigos mais famosos sobre a orientação a objetos que discute exatamente a aplicação do encapsulamento: Why getters and setters are evil.

Então eu diria que é um princípio que amadureceu muito bem no teste do tempo, apesar de ainda poder sofrer das mesmas críticas do polimorfismo já que não é um conceito associado exclusivamente com a OO, uma vez que é possível realizar ele com módulos (o que seria semelhante a ter um objeto singleton), ou closures, visto que elas podem atuar como objetos de pobre, entretanto, assim como no caso do polimorfismo, o conceito é aplicado "com um sabor único" na OO, visto que o mecanismo de retenção local dos dados é o objeto, e o ocultamento das informações ocorre por meio dos modificadores de acesso, essa sim uma funcionalidade amplamente associada com o paradigma.

Abstração

Ela não aparece tanto quanto o resto dos 4 pílares, entretanto, similar ao encapsulamento, sua presença ainda pode ser sentida de forma implícita ao invés de explícita, visto que, com exceção de Self, todas as linguagens mencionadas dispõe de um mecanismo de abstração de dados na forma das classes.

Adentrando na questão do Self, ele dá grande enfase nos objetos em si e na troca de mensagens, o que nos podemos aproveitar para analisar a questão do alinhamento conceitual, que nesse caso, eu diria que programar com troca de mensagens, em palavras mais modernas (apesar dos conceitos não serem exatamente a mesma coisa) seria o mesmo que "programar para uma interface", ou seja, programar apenas com abstrações, sem se preocupar com como a implementação final vai ser de fato, método esse muito bem descrito no livro Smalltalk by Example: The Developer's Guide, de Alec Sharp, como sendo "a forma orientada a objetos de se programar".

A ideia de abstração em conjunto com o polimorfismo que permite que toda metáfora de troca de mensagens funcione, pois a ideia é que não tem como saber qual vai ser o resultado da execução do código apenas olhando para as mensagens, afinal elas são abstrações (no mesmo sentido de que não dá para saber como as coisas vão executar ao ler os métodos de uma interface na OO moderna), e o resultado depende de suas implementações concretas que se encontram nos objetos em si, logo, a execução pode variar dependendo de qual objeto responde à aquela mensagem.

De todos os princípios, eu diria que a abstração é o mais fraco no critério de exclusividade, visto que abstração de dados é um princípio geral, acima do conceito de paradigmas como afirma Peter Van Roy no seu artigo Programming Paradigms for Dummies, apesar disso, novamente, estamos numa situação semelhante aos outros princípios no qual ela se utiliza de um mecanismo extremamente característico na forma das classes, que são amplamente reconhecidas como uma funcionalidade de OO, tão reconhecidas que muitas pessoas pensam que o paradigma se resume a programar com classes (esquecendo até dos objetos, e pior ainda, das mensagens no processo).

Herança

Ela está aqui pelo motivo oposto a troca de mensagens, se a troca de mensagens tem baixa pontuação de percepção pública, mas a mais altíssima em alinhamento conceitual, a herança tem o menor alinhamento conceitual dos conceitos selecionados (o que pode ser confirmado com a citação de que Alan Kay apenas adicionou herança em Smalltalk pois não sabia muito bem para quê ia servir direito, mas pensou que talvez fosse ser útil), mas possui a maior percepção pública, além de altíssimas contribuições históricas.

Para começar que ela era uma das princípais funcionalidades de Simula, era tida como a essência da OO, na era pós Smalltalk, embora isso tenha sido completamente invertido após a públicação da ideia de composição ao invés de herança pelo GoF.

Apesar disso, é o único conceito exclusivamente associado com a OO, sendo uma funcionalidade cujo a presença já seria o suficiente para diferenciar uma linguagem como orientada a objetos em muitos casos. Sendo os únicos argumentos que poderiam ir contra isso a ideia de records de Hoare, mas ela foi o que deu origem a herança em Simula, e product types, mas esse é um assunto bem diferente de herança, e nem se sofre dos mesmos problemas e polêmicas.

Conclusão

Finalmente temos ambos a perspectiva e os princípios, por isso nossa definição final fica:

Um programa orientado a objetos é visto como uma rede de objetos, sendo estes representações de conceitos do domínio, se comunicando por meio de troca de mensagens, no qual se busca programar evitando os dados, focando nas interações, de forma que uma mensagem possa carregar vários significados. Cujo os princípios são a troca de mensagens, polimorfismo, encapsulamento, abstração, e a herança. Tendo como estrutura geral algo semelhante a uma simulação do comportamento de uma parte real ou imaginária do mundo.

Enfim, essa é a minha resposta final para a pergunta apresentada no título do artigo, essa pesquisa toda deu bastante trabalho, então espero que o texto possa pelo menos ter te ensinado algo novo, ou levando algumas reflexões.

Caso concorde, ou discorde da minha definição não se esqueça de compartilhar sua opinião nos comentário, e até a próxima!

Links que podem te interessar

Ass: Suporte cansado

Personas - Como perfis psicográficos moldaram o game design

Terminal Coffee — Sun, 28 Jul 2024 22:18:31 +0000

Se você se interessa pelo assunto de UX Design já deve ter se deparado com o conceito de personas, e talvez não tenha dado tanto valor quanto deveria, por isso no post de hoje vamos ver como game designers aplicaram isso na área de jogos de carta para planejar as evoluções do conhecido Magic: The Gathering (MTG), assim analisando como esse conceito simples foi utilizado para causar impacto positivo num produto da vida real.

O que são personas

Persona aqui não se refere a uma série de jogos, mas sim a um conceito aplicado na área de UX Design onde se é criado uma representação fictícia de um usuário ideal para um determinado produto, serviço, site ou marca.

A ideia seria facilitar o processo de se empatizar com o seu público-alvo imaginando como um usuário ideal dentro desse grupo seria, seu nome, o que faz, quais os seus gostos, o que não gosta, etc. Assim, a partir disso, tentar imaginar como essa pessoa interagiria com o seu produto/serviço, e quais suas reações quanto a ele, de forma a encontrar os seus pontos positivos e negativos, fornecendo uma ótima fundação para que se começa a pensar em como melhorar ou projetar a experiência desse produto/serviço.

Normalmente, se criam várias personas de forma a capturar os diversos tipos de usuários que podemos ter, por isso antes de se criar qualquer persona é necessário que pesquisas sejam feitas com os usuários para entender quais os seus perfis, e coletar os detalhes que iremos utilizar para formar as nossas personas depois, pois elas devem capturar os aspectos-chave desse público.

As informações que buscamos coletar durante esse processo, geralmente, são:

Dados demográficos (idade, sexo, localização, ocupação, etc);
Relacionamento com seu produto/serviço, no caso como eles interagem com ele;
Quais objetivos eles possuem ao utilizar/consumir o seu produto/serviço;
As suas dores, ou seja, quais problemas, frustrações, e aspectos negativos em geral ele tem durante seu uso;
As suas motivações, afinal se tudo fosse dores, seu produto não estaria sendo utilizado, precisamos coletar os pontos positivos também né? Aqui descobrimos as razões pelo qual o seu produto/serviço é utilizado;

Elas podem ser coletadas de diversas maneiras como entrevistas, questionários, dados coletados durante o uso, trabalho de campo, ou seja, indo observar os seus usuários em seu ambiente natural pessoalmente, etc.

Assim, após analisar todos esses dados, podemos criar uma persona, por exemplo:

Persona: Maria Silva

Nome
Maria Silva

Idade
34 anos

Sexo
Feminino

Localização
São Paulo, SP

Ocupação
Gerente de Marketing

Biografia
Maria é uma profissional de marketing digital que vive em São Paulo. Ela adora aprender sobre novas tendências em marketing e está sempre procurando ferramentas que a ajudem a otimizar suas campanhas.

Comportamentos
Usa redes sociais diariamente, lê blogs de marketing, participa de webinars.

Objetivos
Aumentar o engajamento das campanhas de marketing, melhorar a conversão de leads.

Frustrações
Falta de tempo para analisar dados, dificuldade em acompanhar todas as novidades do mercado.

Motivações
Ver os resultados de suas campanhas, ganhar reconhecimento profissional.

Perfis psicográficos em MTG: um caso da vida real

Agora que introduzimos todo mundo ao assunto, vamos a parte mais interessante do artigo de hoje: como o time de game design do jogo de cartas Magic: The Gathering (MTG) integrou o conceito de personas na prática no processo de desenvolvimento do jogo.

Existe um artigo no blog oficial do cardgame onde Mark Rosewater, colunista e designer-chefe do MTG.com, conta que o seu time tinha a missão de criar um jogo que fizesse os jogadores felizes, e para tal, eles precisavam descobrir o que fazia os jogadores felizes, nisso eles realizaram a sua pesquisa se utilizando de vários métodos como: questionários, grupos focais, monitoraram sites de Magic, conversaram com os jogares pessoalmente, e até mesmo analisaram quais artigos no site oficial os usuários mais visualizavam.

Após vários anos coletando e analisando esses dados, eles chegaram a conclusão que haviam 3 tipos de jogadores, no qual eles nomearam esses tipos como "perfis psicográficos" que citamos anteriormente.

A ideia de perfis psicográficos que eles chegaram é basicamente a ideia de personas que nós estudamos até aqui, no caso do time do MTG, eles representam coisas como:

O que motiva esse perfil a jogar?
Quais cartas ele gosta?
O que o encoraja a continuar jogando?

O Resultado foi a criação de 3 perfis psicográficos (personas): Timmy, Johnny, e Spike.

Timmy

Timmy seria o tipo de jogador que anseia pela experiência, apesar de gostar de vencer, ele seria do tipo onde a jornada importa mais do que o destino, portanto, ele prefere realizar uma jogada muito incrível e perder uma partida à vencer várias delas de maneira apertada ou de uma forma que ele considere chata.

A "experiência" nesse caso varia muito de Timmy para Timmy, por exemplo existem os que gostam de grandes monstros, feitiços com grandes efeitos, tudo o que dê a ele a sensação de poder durante a partida.

Existem os que gostam do aspecto social do jogo, e apreciam a experiência em si de jogar com os amigos, ou de modos multi-player.

Também existem aqueles que gostam de explorar as possibildades que o jogo tem a oferecer testando todos os tipos de arquetipos, decks, modos de jogo, estilos de jogo, etc.

Johnny

O Johnny seria o tipo de jogador que gosta de se expressar ao jogar MTG, ele seria o diferentão, aquele que joga com o que ninguém mais joga, gosta de demonstrar ao mundo sua criatividade através de suas jogadas inteligentes. Dessa forma, ele é um perfil que aprecia o aspecto de personalização de um deck do jogo.

Assim como os Timmies, os Johnnies também variam entre si no que eles consideram uma "expressão".

Existem aqueles que gostam de pegar uma carta, analisar o seu potencial, e são fascinados pela conexão que as cartas podem ter, dessa forma se especializam em montar decks em volta de uma única carta, e todas as interações que ela pode ter com outras cartas.

Existem aqueles que gostam de expressar uma ideia como um deck apenas de terras, um deck que rouba todas as cartas do oponente, etc.

Também existem aqueles que gostam de remar contra a maré, eles não são convencidos que um deck não funciona, que algo é ruim, etc. Se não funciona, eles vão fazer funcionar.

Spike

MTG é um jogo onde o conceito de vitória existe, logo, grande parte de seus jogares são do tipo competitivo, e é exatamente isso que os Spikes representam: o meta player. Eles querem provar algo: o quão bons eles são. O que o motiva é a vitória, pois ela é uma prova de suas habilidades ao mundo, da mesma forma, ao contrário dos Timmies, ele odeia perder.

Existem Spikes que buscam sempre o novo deck que vai dominar o meta do jogo, assim como alguns Johnnies, gostam de analisar as cartas do jogo, suas interações, julgar o seu potencial, e sempre buscar por novos decks, no entanto, ao contrário dos Johnnies, eles o fazem para encontrar a nova melhor forma de se vencer, e não pela descoberta em si. Muitos Spikes nesse ramo seriam o que formam as comunidades envolvidas com theorycraft do jogo.

Apesar disso, eles podem não necessariamente ligar para descobrir novos decks, lembre-se a intenção é vencer, por isso se algo funciona, eles vão usar aquilo, o objetivo é dominar algo por completo para vencer da forma mais eficiente possível.

Nessa linha existem aqueles que estudam o metagame, analisando quais as forças e fraquezas dos decks mais populares, e bolando estratégias para lidar com cada uma dessas situações.

Conclusão

Com esses perfis em mente, o time de MTG agora pode ter um alvo em suas mentes ao desenhar uma nova carta, além de conseguir tentar prever como seria a sua recepção na comunidade, afinal o que agrada a um Spike pode não agradar um Johnny e vice e versa por exemplo.

Dessa forma, suas decisões de design são bem mais focadas, além de darem um direcionamento em seus lançamentos de novos conjuntos de cartas, onde eles tentam adicionar cartas que podem agradar pelo menos um dos 3 perfis em cada um.

Eles aprenderam muito com isso ao longo dos anos e compartilham várias de suas experiências em seu blog, mas e você? Aprendeu algo novo no artigo de hoje? Conhecer os perfis psicográficos te fez entender melhor que tipo de jogador você é mesmo que não seja um jogador de MTG? Conta para gente aqui nos comentários e não deixe de deixar a sua reação também.

Até a próxima!

Links que podem te interessar

Ass: Suporte cansado.

Você foi enganado! Encapsulamento não é apenas sobre getters e setters

Terminal Coffee — Sun, 07 Jul 2024 13:49:14 +0000

Introdução

Quando o assunto é encapsulamento é bem comum encontrar esse princípio tão central para a OO sendo associado ou até mesmo confundido com a ideia de getters e setters, e apesar deles terem uma certa relação, encapsulamento vai muito além de simplesmente getters e setters, por isso no artigo de hoje, iremos caçar mais esse mito da orientação a objetos.

Encapsulamento é um conceito meio complicado de pegar corretamente, visto que ele é um pouco abstrato, ainda mais se você vem só do paradigma procedural (lógica de programação) como conhecimento prévio, além disso ele tem várias definições, então a chance é que você já se deparou com uma que diz algo como:

Encapsulamento se refere a capacidade de controlar o acesso a um membro de um objeto

Nessa definição encapsulamento seria equivalente a um outro princípio que chamamos de information hiding (ocultamento de informação), além de ser, geralmente, utilizado para se referir aos mecanismos de modificadores de acesso em linguagens orientadas a objetos, o que nos leva a ideia de getters e setters visto que o primeiro (e único muitas vezes) exemplo nos mais variados conteúdos sobre OO por ai demontram o uso dessa funcionalidade por meio dos getters e setters.

Encapsulamento é sobre controlar acesso

Ao nos depararmos com as possibilidades que linguagens orientadas a objeto nos trazem, também entramos em contato com uma nova classe (piada intencional) de problemas que esse conjunto de ferramentas nos ajuda a resolver.

Por exemplo, nem todas as informações que vamos agrupar num módulo qualquer (como uma classe/objeto por exemplo) deveriam ser acessíveis fora dele, além disso existem casos onde você só quer expor ela parcialmente (por exemplo só permitir a leitura de uma informação ou só permitir a sobrescrita dela), ou controlar como ela vai ser exposta ou modificada.

Para ilustrar isso considere o seguinte exemplo:

class PositiveNumber {
  public value: number;

  constructor(value: number) {
    if (value <= 0) {
      throw new Error("Um número positivo deve ser maior do que 0");
    }

    this.value = value;
  }
}

const x = new PositiveNumber(1);
x.value = -1;

Aqui temos uma classe que representa um número positvo, ou seja, por definição, a propriedade value não poderia ser um número negativo ou zero, afinal isso não seria um número positivo, então o fato de podermos fazer algo como x.value = -1 demonstra que é possível fazer com que esse objeto contenha um estado inválido.

Para resolver isso, podemos modificar o código para que se faça um if antes de realizar a operação de atribuir um novo valor em value:

class PositiveNumber {
  public value: number;

  constructor(value: number) {
    if (value <= 0) {
      throw new Error("Um número positivo deve ser maior do que 0");
    }

    this.value = value;
  }
}

const x = new PositiveNumber(1);
const newValue = -1;

if (newValue > 0) {
  x.value = -1;
}

Só que isso gera um novo problema, pois não temos como garantir que um objeto PositiveNumber vai ser sempre um número positivo, afinal quem garante que ele vai continuar sendo positivo é o código que usa ele, e não ele em si. Logo, se você esquecer de colocar esse if em um local que seja, isso abrirá uma brecha para que x deixe de representar um número positivo, e se uma abstração mente sobre sua premissa, você constrói seu código sobre premissas falsas, o que certamente não é uma receita para o sucesso.

Modificadores de acesso oferecem uma solução para esse problema, dessa forma podemos dizer quem pode acessar determinado membro de um objeto:

public (público) - qualquer um pode acessar, é o mesmo que não ter modificador nenhum;
private (privado) - apenas o código dentro da própria classe pode acessar/modificar;
protected (protegido) - apenas o código dentro da própria classe ou de classes que herdam dela podem acessar/modificar;

Atualizando o nosso exemplo ficaria algo como:

class PositiveNumber {
  private value: number;

  constructor(value: number) {
    if (value <= 0) {
      throw new Error("Um número positivo deve ser maior do que 0");
    }

    this.value = value;
  }
}

const x = new PositiveNumber(1);
x.value = -1; // Erro!

Isso nos permite resolver o problema de códigos que não são o próprio objeto mexam no valor dele, se alguém tentar acessar/modificar um membro privado, isso vai gerar um erro, o que garante que estamos protegidos ao menos do código dos outros.

Só que isso gera um novo problema, não tem mais como fazer nada com o value, ele vai receber um valor durante a instanciação por meio do construtor, e vai ficar parado lá para sempre sem a gente poder mexer nele ou fazer qualquer coisa que seja com ele, certamente não parece ser o código mais útil do mundo.

Nesse cenário que getters e setters se apresentam como uma solução para tudo isso que discutimos até qui. Eles são um padrão onde substituímos as propriedades que estamos escondendo utilizando os modificadores de acesso por métodos que representam as operações de leitura e escrita nelas, assim controlando nos mínimos detalhes até mesmo os dados do objeto:

getter - representa a operação de leitura, então ao invés de fazer obj.prop usamos um método getter obj.getProp();
setter - representa a operação de escrita, então ao invés de fazer obj.prop = value usamos um método setter obj.setProp(value);

Isso permite que nós personalizemos a forma padrão como isso acontece nativamente no código, por exemplo, ao invés de só substituir o valor de uma propriedade ao realizar uma operação de escrita, um setter pode realizar uma validação ou transformar o dado antes dele substituir o valor original da propriedade.

Veja o código utilizando eles:

class PositiveNumber {
  private value: number;

  constructor(value: number) {
    this.setValue(value);
  }

  setValue(value: number): void {
    if (value <= 0) {
      throw new Error("Um número positivo deve ser maior do que 0");
    }

    this.value = value;
  }
}

const x = new PositiveNumber(1);
x.setValue(2); // Muda o value para 2
x.setValue(-1); // Erro!

Aqui nós atingimos todos os critérios levantados até então:

Mesmo realizando a mesma operação (escrita) em mais de um lugar (no construtor e no código que usa o objeto x), a validação é aplicada todas as vezes sem falta;
Limitamos o acesso a propriedade value apenas a classe PositiveNumber;
Ainda é possível realizar computações com value.

Encapsulamento é sobre unir dados e funções

Até o momento parece que getters e setters são uma forma bem efetiva de se aplicar o princípio do encapsulamento, ainda mais levando em conta a definição que utilizamos inicialmente, some isso com os exemplos mais comuns serem os próprios getters/setters, algumas bibliotecas te forçarem a usar o padrão, e um conselho comum ao se aprender OO ser:

Sempre mantenha as suas propriedades privadas ou protegidas

Não é surpresa que muita gente escuta a definição formal, não entende nada, olha o mundo ao redor dela, só vê getters/setters, e chega a conclusão que, sim, encapsulamento é só usar getters e setters ou saber colocar as propriedades como private ou protected.

O problema disso é que o que discutimos até aqui é só metade da definição, como disse mais cedo, se a definição fosse apenas essa não teria motivo para termos um princípio separado apenas para se referir a isso quando já tinhamos o information hiding para descrever essa ideia. Uma definição melhor seria:

Encapsulamento se refere a juntar dados com as funções que operam neles, formando uma unidade com capacidade de controlar o acesso a seus membros
~ Adaptado da Wikipedia

Existem definições que englobam apenas a primeira parte (juntar dados e funções), então acredito que a definição mais razoável para o termo seja essa que une ambas.

A princípio pode não parecer que isso muda muito, afinal, os getters e setters, de fato, se encaixam nessa definição. O pulo do gato é quando começamos a fazer algumas reflexões sobre essa definição:

Dados e funções formarem uma unidade significa que existe uma ou mais funções que usam aquele conjunto de dados representados nas propriedades de um objeto, então ao invés de fazer todas elas receberem os mesmos parâmetros repetidas vezes, nós podemos criar um objeto que permite que todas elas compartilhem dos mesmos dados.

Para visualizar isso vamos supor que vamos criar um sistema de conta bancária simples:

type Account = { money: number };

function deposit(account: Account, amount: number): void {
  if (amount > 0) {
    account.money += amount;
  }
}

function withdraw(account: Account, amount: number): void {
  if (account.money >= amount) {
    account.money -= amount;
  }
}

function showBalance(account: Account): void {
  console.log(account.money);
}

const anAccount: Account = { money: 100 };

deposit(anAccount, 50);
showBalance(anAccount); // 150

withdraw(anAccount, 125);
showBalance(anAccount); // 25

Note como todas as funções dependem dos dados de Account para funcionar, podemos tornar esse código bem menos repetitivo, mais limpo, e evitar os problemas de dados públicos, que exploramos anteriormente, aplicando o encapsulamento para unir todas elas numa única classe nos valendo dos modificadores de acesso ao mesmo tempo:

class Account {
  constructor(private money: number) {}

  deposit(amount: number): void {
    if (amount > 0) {
      this.money += amount;
    }
  }

  withdraw(amount: number) {
    if (this.money >= amount) {
      this.money -= amount;
    }
  }

  showBalance(): void {
    console.log(this.money);
  }
}

const anAccount = new Account(100);

anAccount.deposit(50);
anAccount.showBalance(); // 150

anAccount.withdraw(125);
anAccount.showBalance(); // 25

Encapsulamento é a arte de esconder coisas

Isso nos permite criar uma boa abstração (trabalhar com uma conta usando termos como depositar, sacar, ou mostrar saldo, ao invés das computações realmente sendo feitas por de baixo dos panos) sem nos preocupar com como isso tudo é implementado internamente.

O fato de mantermos os dados escondidos usando os modificadores de acesso, nos dá um outro benefício que é a capacidade de esconder COMO estamos resolvendo o problema de quem usa o nosso código.

Pode não parecer, mas isso é uma grande vantagem quando se trata de dar manutenção e escalar as coisas. Isso porque força quem vai usar o código a confiar na abstração que estamos provendo, ou seja nos que estamos prometendo que vamos fazer, ao invés de confiar no que estamos fazendo de fato.

Programar com abstrações é muito mais fácil do que sem, é por isso que você usa uma linguagem de programação de alto nível como JS ao invés de programar a nível de máquina usando assembly por exemplo, cada coisa que torna sua vida mais fácil numa linguagem de programação advem do fato que ela está abstraindo algo complexo de você.

Então nos forçar a criar abstrações melhores é um ponto positivo, outra vantagem que vem quando escondermos como estamos resolvendo o problema é que isso torna o código mais independente.

Veja, se quem usa não tem acesso a como as coisas funcionam internamente, caso mudarmos completamente o código de um método, mas mantivermos ele funcionando da exata mesma forma (por exemplo trocar um algoritmo por uma versão mais performática dele), o usuário dessa função vai se beneficiar da mudança sem ter que mudar uma linha do código que ele escreveu usando ela.

Podemos demonstrar isso com uma class Bhaskara que representa uma formula para cálcular equações de segundo grau:

class Bhaskara {
  constructor(
    public a: number,
    public b: number,
    public c: number
  ) {}

  delta() {
    return this.b ** 2 -4 * this.a * this.c
  }

  x1() {
    return -this.b + Math.sqrt(this.delta())) / (2 * this.a);
  }

  x2() {
    return -this.b - Math.sqrt(this.delta())) / (2 * this.a);
  }

  result() {
    return [this.x1(), this.x2()];
  }
}

Aqui temos uma situação onde controlar a modificação de a, b, ou c não parece impactar em nada o objeto, afinal, ao chamar qualquer um de seus métodos, simplesmente eles vão recalcular tudo com base nessa mudança.

Só que se você já ouviu a frase "se está no jogo é para usar", então talvez tenha sacado qual o problema dessa versão do código, nós podemos usar as propriedades a, b, e c para mostrar elas por exemplo:

const bhaskara = new Bhaskara(1, -5, 6);
console.log(bhaskara.a);

Isso é um caso de uso da nossa classe que nós não previmos ao criar ela, afinal o objetivo dela é prover para quem for usar uma forma simples de calcular o resultado usando a formula de bhaskara.

Só que, e se a gente resolver renomear as propriedades da classe para tentar falar a mesma lingua dos matemáticos, tornando assim o código mais descritivo?

class Bhaskara {
  constructor(
    public quadraticCoefficient: number,
    public linearCoefficient: number,
    public constantTerm: number
  ) {}

  delta() {
    return this.linearCoefficient ** 2 -4 * this.quadraticCoefficient * this.constantTerm
  }

  x1() {
    return -this.linearCoefficient + Math.sqrt(this.delta())) / (2 * this.quadraticCoefficient);
  }

  x2() {
    return -this.linearCoefficient - Math.sqrt(this.delta())) / (2 * this.quadraticCoefficient);
  }

  result() {
    return [this.x1(), this.x2()];
  }
}

Isso quebraria totalmente o nosso código que fazia console.log(bhaskara.a), visto que agora a não existe mais, virou quadraticCoefficient.

Por isso que esconder seria uma solução melhor, a gente só libera o que realmente for a nossa intenção que deveria ser utilizado, assim evitando que usos não previstos sejam realizados, o que nos dá paz de espírito para realizar uma mudança em como as coisas funcionam internamente sabendo que isso não vai afetar o código que usa o nosso código (o famoso bug que só some de um lugar para aparecer em outro), de quebra a gente ainda ganha uma abstração melhor ela vai, de fato, só mostrar o que interessa para quem for usar o código.

Podemos levar a ideia ainda mais longe, e esconder como os resultados são obtidos, assim não importaria se nós tivessemos implementado cada coisa em seu método como no exemplo, ou se fizemos tudo numa única função, ex:

class Bhaskara {
  constructor(
    public a: number,
    public b: number,
    public c: number
  ) {}

  private delta() {
    return this.b ** 2 -4 * this.a * this.c
  }

  private x1() {
    return -this.b + Math.sqrt(this.delta())) / (2 * this.a);
  }

  private x2() {
    return -this.b - Math.sqrt(this.delta())) / (2 * this.a);
  }

  result() {
    return [this.x1(), this.x2()];
  }
}

// ou

class Bhaskara {
  constructor(
    public a: number,
    public b: number,
    public c: number
  ) {}

  result() {
    const delta = this.b ** 2 -4 * this.a * this.c;

    return [
      -this.b + Math.sqrt(delta) / (2 * this.a),
      -this.b - Math.sqrt(delta) / (2 * this.a),
    ];
  }
}

Em qualquer uma dessas implementações, o método result é a única operação que um cliente dessa classe poderia realizar, e como ambos se comportam da mesma forma, efetivamente, por termos deixado os métodos privados, essa refatoração foi possível, visto que podemos remover eles em favor de um código menor por conta da garantia que eles não estavam sendo utilizados em nenhum outro lugar.

Encapsulamento não é sobre getters e setters

Agora que exploramos as motivações por trás do uso de getters e setters, além das diversas aplicações do encapsulamento, vamos voltar a questão que abriu este artigo.

Getters e setters, assim como vimos no início do artigo, até podem ser uma aplicação do encapsulamento, entretanto se nós considerarmos os outros pontos que vimos até aqui, fica claro que eles são uma forma bem pobre de aplicar o princípio, ao passo de que deveriam ser a exceção ao invés da regra.

Podemos avaliar isso de forma mais pragmática analisando como eles são usados, de fato, na prática. O que vemos na grande maioria dos casos é uma aplicação do padrão que claramente viola o YAGNI, onde criamos getters e setters no automático (muitas vezes até por comodidade da IDE prover uma função de criar eles com um click) pensando que, no futuro, pode ser que tenha que adicionar uma validação ali que justifique a criação deles, ex:

class Person {
  constructor(private name: string, private age: number) {}

  getName() {
    return this.name;
  }

  setName(name: string) {
    this.name = name;
  }

  getAge() {
    return this.age;
  }

  setAge(age: number) {
    this.age = age;
  }
}

Com esse simples código, acabamos de violar completamente o princípio do encapsulamento, perdemos tudo o que estamos tentando ganhar ao usar o princípio.

A começar que tudo o que fizemos aqui foi criar a mesma classe que teríamos se as propriedades fossem públicas, só que com 10 vezes mais código e trabalho.

Não apenas foi esforço desperdiçado como criamos potênciais problemas de abstração com isso, pois agora qualquer código fora da classe pode alterar qualquer estado interno dela sem problemas, o que volta no problema que discutimos na própria seção que justifica a existência desse padrão: a sobre controle.

Aqui você poderia argumentar que o problema não seria o padrão, mas sim quem usa errado, entretanto mesmo considerando que vamos ter setters que validam as coisas para evitar invariantes dos dados, getters que fazem algum tipo de transformação antes de retornar a propriedade, entre outras aplicações "perfeitas" do padrão, isso, novamente, ainda seria uma aplicação pobre do encapsulamento, e que potenciamente ainda viola o princípio.

Afinal, o benefício de centralizar o controle na classe não foi o único que perdemos ao fazer isso, nós também perdemos as vantagens discutadas no tópico sobre como encapsulamento seria a arte de esconder coisas, pois como temos a mesma coisa que teríamos caso as propriedades fossem públicas, nada do objeto foi escondido, como criamos cada par representando uma propriedade, se ela mudar, vamos ter que mudar o par junto, além de expor como o objeto faz as coisas internamente, dessa forma temos uma clara noção de como os seus dados estão estruturados.

Note como isso é um problema que permanece mesmo com os getters e setters cumprindo os seus papéis, assim por mais que tenhamos garantido que o objeto não vai aceitar estados inválidos, nada realmente foi escondido ali, o que vai contra um dos objetos de se usar o encapsualmento em primeiro lugar.

Além disso, eles não são lá uma forma muito interessante de abstração, visto que não traduzem nenhum conceito do problema sendo modelado na forma de uma classe, mas sim um problema seu como desenvolvedor. Por exemplo, numa classe Personagem, o que seria mais interessante um método setVida ou mais de um como tomarDano e curar?

Esse exemplo ilustra bem a natureza do encapsulamento como a união entre dados e funções, um dos motivos para criarmos funções seria abstrair alguma alteração que um dado ou um conjunto deles deveria sofrer, e se algo precisa ser alterado, é porque reflete uma necessidade do problema que existe na vida real.

De fato, existem casos onde a operação na vida real seria redefinir o valor de algo, como mudar uma configuração num painel ou o seu nome de usuário num formulário por exemplo, tornando um setter uma abstração correta no contexto do domínio.

Só que o mais provável é que a operação tenha um significado maior do que a ação que é executada na maioria dos casos, é só que não tentamos pensar nisso muitas das vezes, o que leva a uma abstração fraca do problema, indo contra o propósito de se tentar criar uma abstração em primeiro lugar.

A operação de dar um like num comentário por exemplo, apesar de no fim das contas ser a operação de pegar o número de likes de um post, e incrementar ela, carrega um significado importante para o contexto do problema, então ao invés de ter um setLikes que é usado por uma outra classe para atualizar o valor de uma classe Post, a própria classe Post poderia prover um método para se atualizar chamado curtir por exemplo.

A importância dessa abordagem fica ainda mais clara quando temos operações que envolvem atualizar múltiplas propriedades de um objeto de uma vez só, pois reflita comigo se tivermos um setter para cada propriedade, estamos protegidos de estados inválidos ao atualizar uma propriedade diretamente, só que nesse caso não temos nada que garante que vamos atualizar outra propriedade B como resultado de atualizar uma propriedade A em primeiro lugar. Assim, poderíamos considerar criar um "setter geral" que atualiza todas as propriedades de uma vez só, o que nesse caso só provaria o ponto que eu estou fazendo de que isso seria uma operação complexa, e portanto provavelmente existe um nome mais apropriedade para ela do que setTudo por exemplo.

E para fechar, quando se tem um setter, isso pressupõe a existência de pelo menos uma operação que vai alterar os dados do objeto, caso contrário isso é só código inútil que nunca vai ser usado, visto que o objeto seria imutável, fora isso vimos que se uma operação existe, ela provavelmente tem um nome melhor que setAlgumaCoisa, mas existe uma situações onde, de fato, você teria que pensar em métodos com nomes de verdade, que seria o caso da classe Personagem citada anteriormente, nela, existem pelo menos duas operações envolvendo a propriedade vida, sendo assim não poderíamos ter um método setter apenas, teríamos que diferenciar um do outro, e nesse ponto já provamos que cada ação deveria ter um nome mais apropriado.

Conclusão

Quando somos introduzidos a orientação a objetos, no que diz respeito ao encapsulamento, muitas vezes os getters e setters acabam sendo o nosso todo em relação a esse assunto, mas espero que com o artigo de hoje, você, caro leitor, tenha entendido as várias nuances que o princípio possui, além de ter entendido o motivo de muitas pessoas, eu incluso, considerarem getters e setters ruins, e sempre recomendarem ou a evitar eles completamente, ou usar apenas em último caso onde as outras estratégias para criar uma classe com bom encapsulamento já falharam.

Ass: Suporte cansado...

Links que podem te interessar

Por que a Apple Odeia o Brasil? A História Proibida que Ninguém Contou!

Terminal Coffee — Sat, 29 Jun 2024 15:55:13 +0000

Introdução

Bom dia, boa tarde e uma boa noite a todos nossos leitores. Já faz um tempinho que eu não escrevo aqui no blog, e hoje apresento uma história diferente e meio lenda urbana. Se gostar da ideia e quiser mais desse tipo de conteúdo, deixe nos comentários e dê seu like, pois o feedback de vocês é muito importante. Sem mais delongas, bora pro vídeo.

História

Você provavelmente já se perguntou por que os produtos da Apple são tão caros no Brasil. E você, usuário que recebe dois salários no nosso grande país, não consegue ter seu iPhone, MacBook ou iPad sem parcelar a alma junto. Claro, sabemos que a culpa disso é da economia atual e de mais um monte de coisas que não têm relação direta com a nossa história, independente se você gosta ou não do governo. Até porque o buraco é mais embaixo.

Sabemos que no Brasil não existe fabricação de produtos licenciados da Apple. Bom, se não sabia, tá aí a informação em primeira mão. ✋ Mas você, caro entusiasta da tecnologia, já pensou por um momento por que a Apple nunca nem ao menos ficou tentada em firmar base nas terras tupiniquins? Afinal de contas, o Brasil é muito populoso e um possível grande mercado consumidor da maçã mordida, mas mesmo assim eles nunca nem cogitaram. Desde 2021, o Brasil é o lugar mais caro para se comprar um celular que nem vem com o carregador na caixa. Vou deixar a matéria nas referências para provar que eu não tô mentindo.

Continuando ao que interessa, existe uma história que é meio lenda urbana, pois nunca foi confirmada pelo Steve Jobs, e agora nem é mais possível que ele confirme por motivos que não precisamos mencionar (F nos comentários em respeito) do real motivo dessa relação Brasil e Apple nunca ter acontecido. Jobs declaradamente não gostava do Brasil, e essa treta começa no final dos anos 1980, quando a Apple já tinha revolucionado o mercado de computadores pessoais com o Apple II em 1977, sendo o primeiro equipamento com interface amigável a usuários comuns. A empresa se superou com o lançamento do primeiro Macintosh em 1984 (acompanha as datas que vai ser importante), com a ideia de ser um aparelho fácil de usar e barato. Sim, eu sei, Apple e barato na mesma frase parece até piada, mas era a ideia da equipe de desenvolvimento na época e deu super certo novamente, sendo mais bem-sucedido que seu antecessor.

Esse era o contexto da Apple. Agora, no Brasil, a situação em todo o país era muito mais complicada. Nos anos 70/80, o Brasil estava na ditadura/regime militar e a vinda de tecnologia para nós não era muito simples. Mas com seu final em 1985, com a eleição do então presidente da época, Tancredo Neves, que acabou não assumindo por uma fatalidade na época, deixando seu vice no comando, José Sarney (uma pequena aulinha de história na faixa), e nesse momento, com mudança de gerência, se podemos dizer assim, o Brasil precisava correr atrás do tempo perdido e foi em busca de tecnologias. E qual era a tecnologia que estava em alta em 1985, 86 e 87? Exatamente, o Macintosh da Apple. E agora vamos à pergunta de 1 milhão de reais: o que o governo brasileiro fez a seguir?

Opções e valendo:

A) Comprou uma porrada de licenças e equipamentos Apple.

B) Firmou um acordo com a Apple para conseguir seus equipamentos na base da amizade.

C) Roubou o firmware do Macintosh e pirateou a sua BIOS para criar um clone do sistema.

D) Chorou e aceitou que é pobre.

Se você conhece um pouco do que é o Brasil, já sabe que demos nosso jeitinho especial de conseguir. Então, ponto para quem respondeu a opção "C". Sim, sem sacanagem, o governo brasileiro foi um dos primeiros do mundo a piratear o sistema operacional do Macintosh da Apple. Vai Brasil, finalmente sendo pioneiro em alguma coisa: avião e piratear Mac você encontra por aqui. E para fechar essa história com chave de ouro, o governo brasileiro foi pego com a mão na massa e recebeu uma carta do próprio Steve Jobs reivindicando direito à sua propriedade. Reza a lenda que o Brasil simplesmente mandou um: “Fica na tua, Jobs, e um cala a boca” e desde então o Jobs abertamente se dizia contra o mercado brasileiro e se recusando a ter produtos oficiais no Brasil.

O mais impressionante é que essa situação gerou tanto ódio na Apple que, mesmo Jobs tendo sido expulso da Apple nos anos 90, de todos os erros cometidos pela empresa sem o seu fundador, um deles não foi vir para o Brasil para ter operações (até para ser burro tudo tem limites). Mesmo com a morte do seu criador em 2011, eles não vieram para o Brasil e podemos ter certeza que eles nunca vão vir para o Brasil e a imagem abaixo mostra o porque eles nem precisam vir para o Brasil, todo dia um 7X1 diferente

Notícia da época

Claro, sabemos que mesmo que a Apple tivesse base na terra de Lulinhas, o valor do seu aparelho principal, seja o iPhone ou MacBook, ainda seria caro para o bolso do consumidor médio. Mas com certeza estaria mais barato e no valor médio de seu maior competidor, a sul-coreana Samsung.

Conclusão

Novamente se gostou desse formato de conteúdo com histórias e tretas da tecnologia e quiser mais desse quadro, coloque nos comentários alguma história cabulosa que nossa equipe de desocupados vai em busca de averiguar as informações e trazer em primeira mão. E claro, se souber alguma coisa do conteúdo, também deixa aí embaixo. Agradecemos a leitura e até a semana que vem com mais conteúdo informativo (ou não) sobre a tecnologia.

Ass: Estagiário mal remunerado.

Referências:

https://www.jornalopcao.com.br/ultimas-noticias/brasil-e-o-lugar-mais-caro-do-mundo-para-se-ter-um-apple-veja-motivos-364549/

https://ipdec.org/aniversario-de-35-anos-do-primeiro-macintosh-lancado-em-1984/#:~:text=O%20projeto%20Macintosh%20come%C3%A7ou%20a,barato%20para%20o%20consumidor%20comum.
https://www.estadao.com.br/link/nos-anos-80-apple-foi-copiada-no-brasil/
http://www.evolucaotecnologica.com.br/?p=1589

Design para programadores - Cores

Terminal Coffee — Tue, 04 Jun 2024 20:41:53 +0000

Design é uma área que muitos programadores acabam por ter bastante dificuldade em lidar, em alguns casos, a pessoa pode achar que não leva jeito para isso, que ela não tem criatividade, que ela não sabe desenhar (mesmo que essas áreas não tenham tanto assim em comum), que ela funciona melhor com lógica e números, enfim, diversos motivos diferentes, eu mesmo nunca me considerei como tendo uma grande veia artistica, entretanto existem coisas sim que podemos aprender sobre design (muitas na verdade), e inclusive utilizar lógica para lidar com isso, em favor de pelo menos não entregar algo que não sangre aos olhos dos usuários, ou pelo menos entender melhor o trabalho entregue a nós pelos designers com quem trabalhamos.

Algo que a área de design tem em comum com a de programação é que eles também seguem princípios e padrões por lá, e um dos princípais pílares do design visual seriam as cores, sendo isso que iremos explorar hoje.

O circulo cromático

Quando passamos pelo ensino básico, nas aulas de artes, certamente você já deve ter tido uma aula sobre as cores, aprendendo que existem as cores primárias, as secundárias - formadas pela combinação entre as primárias, e, dependendo, até mesmo as cores terciárias - formadas pela combinação entre as primárias e as secundárias - em diante.

Dessa forma, se organizarmos como essas cores se relacionam na forma de um circulo, conseguimos o circulo cromático, algo como:

Organizando elas dessa forma podemos utilizar essas relações entre as cores para formar as nossas paletas de cores. Aqui uma dica seria manter a quantidade de cores entre 1 e 3, isso desconsiderando as variantes de uma cor em específico, por exemplo se escolhermos azul, verde e roxo, as nossas 3 cores seriam essas, mas poderíamos ter azul escuro e verde claro na paleta também, de fato, paletas monocromáticas são baseadas em pegar uma cor, e derivar variações dela.

Vale lembrar que diferentes sistema de representação de cores vão mapear para circulos cromáticos diferentes, visto que eles são só sistemas de coordenadas para que o computador possa representar as cores, e é por isso que nós temos sistemas diferentes no CSS como: RGB, HSL, Hexadecimal, e etc. O circulo apresentado anteriormente segue a ideia de que as cores primárias são: Azul, Amarelo, e Vermelho, entretanto no computador, as cores são representadas pelo sistema RBG, então as cores primárias seriam: Vermelho, Azul, e Verde, por isso o circulo cromático usado pelo CSS seria algo próximo a esse daqui:

Montando uma paleta de cores

Decidir uma paleta de cores não é uma tarefa fácil, mas também não é algo totalmente abstrato onde nós precisamos sentir algo para conseguir criá-la. Existem inumeras técnicas para escolher quais cores vão fazer parte dela.

Paleta monocromática

A escolha mais simples é simplesmente pegar uma cor só, por exemplo a cor princípal da logo do sistema sendo trabalhado, e derivar o resto das variações dela utilizando cálculos, algo que podemos fazer graças a um dos sistemas de cores suportados pelo CSS: o HSL.

Derivando variações de uma cor

O HSL é um sistema onde dizemos qual cor nós queremos, informando o Hue, que significa qual cor no circulo cromático queremos usar por meio de um valor em graus, depois a Saturação, que seria o quanto daquela cor queremos aplicar (por isso que deixar a saturação em 0 deixa as fotos cinza no photoshop, e que dizemos que uma foto com cores muito fortes está muito saturada), e por fim a Luz, sendo o quão clara ou escura aquela cor vai ser (0 é preto e 100 é branco para qualquer cor). Ex:

div {
  background: hsl(0, 100%, 50%);
}

Nesse exemplo estamos representando o vermelho puro, pois 0 corresponde ao vermelho, estamos aplicando o máximo de vermelho possível com o 100% na saturação, e com 50% de luz estamos bem no meio entre preto e branco.

Um truque aqui é considerar saturação como inversamente proporcional a luz, então quanto mais escura uma cor, mais saturada ela deve ser, e quanto mais clara, menos saturada.

Assim é possível ir criando uma transição natural entre os tons, ao ponto de se colocar cada tom lado-a-lado é possível ver a formação de um degradê.

Isso é bem útil para gerar as variantes, mas também para conseguir variações de preto e branco, visto que uma técnica muito comum entre os designers é nunca usar preto ou branco puros, e sim versões mescladas com as cores sendo utilizadas para quando elas forem combinadas na interface, a composição final parecer mais harmoniosa.

Cores complementares

Aqui seria como aquele ditado: os opostos se atraem. Podemos combinar cores que são opostas uma da outra no circulo cromático, por exemplo vermelho e verde no sistema tradicional, ou azul e amarelo no RGB.

Vale lembrar que por essas cores serem completos opostos uma da outra, é interessante utilizar a técnica mencionada na seção anterior para combinar cores com valores de saturação e luz diferentes, dessa forma a diferença entre elas vai ser amenizada, evitando combinações famosas por agredirem os olhos. Caso as saturações sejam iguais, o efeito tende a ser o contrário, fazendo as cores colidirem ao invés de se combinarem na interface, causando desconforto em quem vê.

Essa combinação é particularmente útil para formar paletas com duas cores, e pode ser formada a partir de qualquer cor, pois considerando que o círculo tem 360 graus, podemos pegar qualquer valor de Hue, e adicionar mais 180, afinal metade de 360 é 180, dessa forma parando no exato oposto dessa cor no círculo cromático.

Tríade e Quadrado em diante

Seguindo o aumento na quantidade de Hues escolhidas, caso você queira formar uma paleta de 3 cores, uma opção é seguir a lógica das cores complementares, e dividir os 360 graus por 3, obtendo 120, dessa forma começando com 1 cor e ir somando 120 até ter as 3 cores.

Essa é uma abordagem onde você consegue as 3 cores primárias se começar por uma delas, ou as 3 secundárias caso começa por uma secundárias.

Se você tiver 4, pode formar um quadrado, se ir somando de 90 em 90 graus, de fato, se você pegou a lógica até aqui pode escalar isso para quantas cores você tiver na sua paleta simplesmente dividindo 360 (o circulo todo), pela quantidade de cores que você tiver.

Cores análogas

Outra forma de lidar com várias cores de uma vez só, seria utilizar os vizinhos no circulo para formar a sua paleta, voltando as aulas de arte, nós aprendemos sobre esse tipo de agrupamento quando pensamos nas cores quentes e nas cores frias.

Nesse modelo, o tamanho do pulo funciona bem seria somar ou subtrair 30 graus de cada vez, e ele funciona bem pois cada cor seria o próximo passo no circulo, assim sendo uma combinação natural para os nossos olhos.

Aplicando a paleta

Agora que já montamos a nossa paleta de cores, podemos aplicar ela no nosso projeto seguindo uma técnica conhecida como princípio 60-30-10, nesse modelo nós escolhemos uma cor primária, uma cor secundária, e uma cor de acento (normalmente chamada de accent). Por isso que paletas de até 3 cores são preferíveis, mas caso você tenha 4 ou mais, você pode dividir as cores que sobrarem entre as cores secundárias e de acento.

Nesse tópico vai ser necessário um pouco mais de sensibilidade para aplicar a técnica, pois não existe bem uma forma de calcular os valores, mas depois de um pouco de treino com esse princípio em mente, as coisas tendem a ficar mais fáceis, até porque você não precisa dividir perfeitamente.

A cor primária vai ser a cor predominante na sua interface, a princípal, ela vai ser a cor mais aparente quando se olhar para a tela, e por isso você deveria utilizar ela em cerca de 60% da sua interface.

A cor secundária seria a cor utilizada para dar contraste a cor primária, e enquanto ela ainda vai ser bem perceptível na tela, deve ser utilizada com parcimonia, em cerca de 30% das coisas.

Já a cor de acento seria a cor que você utiliza para os detalhes, e deve ser utilizada com ainda mais cuidado que as secundárias, estando presente em apenas 10% da tela.

(Não deixe de conferir o artigo original desta imagem no [uxmisfit.com]

Conclusão

Espero que tenha gostado do artigo de hoje, não se esqueça de compartilhar com aquele seu amigo que sofre para escolher uma paleta de cor, e até a próxima.

Links que podem te interessar

[Usando cores na prática do uxmisfit.com]- Princípio 60-30-10 no UX Planet
Adobe Color - Um site que cria paletas de cores
Um guia em mais detalhes para designers
Sobre criar shades via HSL
HSL no MDN
Sobre sistemas de cores

Ass: Suporte cansado...

Como classificar a sua linguagem - Introdução a sistema de tipos

Terminal Coffee — Tue, 28 May 2024 19:49:09 +0000

Introdução

Quando o assunto é linguagens de programação dois termos muito utilizados para classifica-las são: fortemente tipada, e fracamente tipada, o problema com essa abordagem é que ambos são termos meio subjetivos quanto ao seu significado, o que dificulta um debate sério ao tentar classificar algo como forte ou fracamente tipado. Entretanto, a teoria sobre sistemas de tipos nos fornece conceitos mais úteis nessa tarefa de classificar uma linguagem de programação pelo seu sistema de tipos.

TL;DR;

Podemos classificar um sistema de tipos pelas suas características:

Se é dinâmico ou estático;
Se é estrutural ou nominal;
Se a tipagem é implícita ou explícita;

Dinâmico vs estático

O primeiro critério que podemos usar para classificar propriamente um sistema de tipos, seria se o processo de checar e reforçar as restrições dos tipos ocorre em compile-time ou em run-time.

Em uma linguagem onde a checagem durante a execução do programa, ela ocorre em runtime, ou seja, ela seria considerada uma linguagem dinâmica.

Da mesma forma, se a checagem ocorre antes do código rodar, apenas analisando o conteúdo do código através de uma ferramenta, seja ela um analisador estático, o compilador, um linter, e etc, ela é considerada como ocorrendo em compile-time, dessa forma uma linguagem onde isso acontece seria uma com sistema de tipos estático.

Linguagens dinâmicas geralmente são mais simples de executar, e por isso são associadas com curvas menores de aprendizado, além de não necessariamente exigirem que os tipos sejam declarados explícitamente (tópico que iremos abordar em breve), tornando o aprendizado inicial bem mais simples, facilitando abordagens mais interativas de desenvolvimento (escrever o programa, rodar para testar, e repetir o ciclo).

Enquanto isso, as estáticas geralmente acabam por serem um pouco mais complicadas de executar devido a exigência de uma validação quanto a se o programa está "correto" antes que ele possa ser executado, resultando nas famosas experiências onde "o código não compila", em contrapartida, oferecem uma segurança maior quanto ao programa que vai ser executado, uma vez que esses tipos de erros são pegos durante o desenvolvimento, e não de surpresa depois que o código já está rodando em produção, e algum usuário faz algo que não devia, e acaba recebendo um erro inesperado na cara.

Apesar de linguagens dinâmicas serem associadas com uma experiência de desenvolvimento (DX) melhor, as estáticas possuem uma qualidade nesse quesito bem significativa, que é a capacidade de ajudar os editores a mostrarem os erros diretamente no código que o programador estiver escrevendo, além de ajudarem ele a navegar pelo código, e proverem funcionalidades de auto-complete, devido a capacidade analisar o código estáticamente enquanto ele é escrito.

Estrutural vs nominal

As linguagens mais famosas a serem associadas como "tipadas" ou "fortemente tipadas" como C ou Java, que acabaram por ditar parte do senso comum relacionado a tipagem, utilizavam o que é conhecido como sistema de tipos nominal, nesse caso, mesmo que dois valores sejam identicos, se eles pertecerem a tipos com nomes diferentes, então eles são de tipos diferentes, por exemplo, se você tiver duas classes com as mesmas propriedades e métodos no PHP, os objetos produzidos por essas classes não serão dos mesmos tipos, ex:

class Foo
{
    public function __construct(public string $property) {}

    public function method(): void
    {
        echo $this->property;
    }
}

class Bar
{
    public function __construct(public string $property) {}

    public function method(): void
    {
        echo $this->property;
    }
}

function acceptFoo(Foo $foo): void
{
    $foo->method();
}

acceptFoo(new Foo('A')); // Roda normal
acceptFoo(new Bar('A')); // Erro!

Isso ocorre pois apesar do conteúdo desses objetos ser o mesmo, eles são de tipos com nomes diferentes, e por isso são de um sistema nominal de tipos.

O contrário do sistema nominal seria o sistema estrutural, aqui se segue a filosofia do duck typing:

Se algo anda como um pato, faz quack como um pato, então deve ser um pato

Dessa forma, um valor é considerado de um tipo, se a sua estrutura é identica a estrutura desse tipo, então no caso de linguagens como o TS, nosso exemplo anterior rodaria sem problemas:

class Foo {
  constructor(public property: string) {}

  method(): void {
    console.log(this.property);
  }
}

class Bar {
  constructor(public property: string) {}

  method(): void {
    console.log(this.property);
  }
}

function acceptFoo(foo: Foo): void {
  foo.method();
}

acceptFoo(new Foo('A')); // Ok
acceptFoo(new Bar('A')); // Ok
acceptFoo({ property: 'A', method() {} }); // Ok

Aqui por Foo, Bar, e até o objeto literal declarado no final terem a mesma estrutura (métodos e propriedades obedecendo aos mesmos tipos), eles são considerados como do mesmo tipo, e por isso, dessa vez, a função executa sem problemas.

A comparação acaba sendo que um sistema estrutural acaba por ser mais flexível, e portanto mais amigável, enquanto um sistema nomimal acaba por ser um pouco mais rígido, embora nesse caso, ambos não serem diretamente opostos em seus prós e contras, pois existem muitas situações onde ter um sistema estrutural acaba sendo uma vantagem, geralmente em código que usa o paradigma funcional acaba por ser o caso, e existem situações onde o sistema nominal acaba por ser melhor como quando se tem valores "do mesmo tipo", mas com semântica diferente na aplicação, e por isso necessitam que o nome do tipo seja levado em consideração também, ex: moedas e números inteiros, seriam number em TS, mas possuem semânticas completamente diferentes, e não poderiam ser utilizados intercambiavelmente.

Implícito vs Explícito

Para nosso último critério podemos observar se a tipagem é explícita ou implícita, o que significa verificar se a linguagem necessita que todos os tipos sejam declarados (explícita), ou se podemos omitir a declaração deles, dessa forma deixando que a linguagem advinhe qual o tipo (implícito), funcionalidade também conhecida como inferência de tipos.

Em linguagens como o Java, antes da introdução do var, era necessário que você declarasse o tipo de tudo, variáveis, parâmetros, anotações de retorno e etc. Ex:

class Point {
  public int x;
  public int y;

  public Point(int x, int y) {
    this.x = x;
    this.y = y;
  }

  Point move(Point to) {
    int x = this.x + to.x;
    int y = this.y + to.y;

    return new Point(x, y);
  }
}

O que tem o benefício de garantir que se um valor errado foi inserido/retornado em qualquer uma dessas ocasiões, um erro vai ser desparado logo naquele ponto, além de deixar o código auto-documentado, já que os tipos estão explícitos para qualquer um que ler aquilo ler, assim já obtendo várias informações só de ler por cima o código.

O problema é que essa abordagem torna o código muito verboso, além de muitas vezes forçar com que o programador digite código que a acaba por dar a sensação de ser repetitivo, chato, ou desnecessário, uma vez que o tipo correto parece óbvio, e a linguagem até mesmo poderia advinhar qual seria o tipo nesse caso.

Sendo assim, quando uma linguagem possui suporte a inferência de tipos, ela tenta advinhar o máximo possível sobre a tipagem das coisas com base no código já escrito, e assim reforça a tipagem mesmo que o programador não tenha, de fato, tipado nada ainda, ex:

class Point {
  constructor(
    public x: number,
    public y: number
  ) {}

  move(to: Point) {
    const x = this.x + to.x;
    const y = this.y + to.y;

    return new Point(x, y);
  }
}

Aqui, apesar de termos que tipar algumas coisas, o TypeScript tenta adivinhar boa parte dos tipos utilizados nesse código, por exemplo inferindo qual seriam os tipos das constantes x e y, além do tipo de retorno do método move.

A vantagem é uma DX bem melhor, uma vez que a linguagem trabalha para te ajudar ao invés de fazer você digitar tudo, muitas vezes sendo até um fator que faz com que pessoas que não gostem de tipagem pelo fato de considerarem uma tarefa que deixa o código muito verboso ao mesmo tempo que não tem benefícios que compensem isso, começarem a gostar das vantagens de um sistema estático, graças a implementação de um sistema onde a tipagem é implícita na maioria dos casos também.

A desvantagem seria que ao confiar demais na linguagem, algumas vezes pode se tornar mais difícil de identificar erros de tipagem, pois eles vão ocorrer em outros lugares, além de tornar a função menos documentada, apesar do código mais limpo e conciso.

Conclusão

Ao utilizarmos esses 3 critérios, conseguimos descrever muito melhor as capacidades de uma linguagem e de forma bem mais objetiva, além de poder lançar um julgamento mais adequado quanto as capacidades disponíveis em uma linguagem ou outra.

Normalmente o termo fortemente tipado é relacionado a linguagens estáticas e explicítas, enquanto o termo fracamente é relacionado a linguagens dinamicas e implícitas, mas ainda existem nuances que variam de pessoa para pessoa, então fora que cada critério discutido ao longo deste artigo pode ser misturado com os demais na mesma linguagem, portanto dificultando a classificação entre forte ou fracamente tipado, pois a linguagem pode ser mais permissiva ao ser estrutural, mas mais rigída ao também exigir tipagem explícita por exemplo.

Assim, na próxima vez que for discutir o mérito, tente descrever a tipagem de uma linguagem com esses critérios, e acredito que será uma abordagem bem mais frutífera.

Não se esqueça de compartilhar esse artigo se ele te ajudou a aprender algo novo, até a próxima e deixe nos comentários o seu tipo favorito.

Links que podem te interessar

Ass: Suporte Cansado...

A Verdade Inconveniente sobre a Lógica de Programação - Por que Ela não Prepara os Alunos para a Orientação a Objetos

Terminal Coffee — Mon, 13 May 2024 20:02:10 +0000

Sendo você um estudante de programação ou até mesmo um programador, é bem provável que já tenha ouvido falar da tal lógica de programação seja como uma das "coisas essências para programar", ditados populares como "a lógica de programação é a mesma em todas as linguagens, então se aprender ela, aprende qualquer linguagem", como parte do conteúdo programático de algum curso, requisito de alguma vaga de emprego, e etc.

Dessa forma definindo a importância dela, na programação, como a base para todas as outras coisas, no entanto será que isso é realmente verdade? Normalmente, ela tende a ser o primeiro passo no ensino formal de programação, seguindo essa linha de "conceitos-chaves" que todos temos que aprender, viriam coisas como estruturas de dados, e a tal da orientação a objetos, conceito esse que, curiosamente, é motivo de relato de dificuldade para muitas pessoas (não acredita em mim? Faça uma busca rápida sobre a fama do Java entre iniciantes na internet).

Naturalmente, este é um assunto bem difícil, denso, e complexo, não a toa existe muito debate mesmo hoje em dia quanto a o que, de fato, seria a orientação a objetos, interpretação de seus princípios, real valor no desenvolvimento moderno, seus mais variados usos, e etc.

Agora, o que tudo isso tem a ver com a lógica de programação? Bom, acredito que ela, para além dos motivos já expostos, é um dos princípais motivos em dificultar o aprendizado de algo que já é muito complicado, o que contribui para os vários relatos que ouvimos por ai.

Como ela seria tão ruim assim?

Podemos começar com um problema de definição, não existe uma definição oficial para lógica de programação, apesar disso, ela, muitas vezes, é definida como:

O raciocínio lógico para escrever programas de computador, por meio da criação de algoritmos, ou seja, uma sequência de passos para se executar uma tarefa.

Sendo uma definição bem vaga, podendo causar várias confusões quanto ao seu significado, por exemplo, muita gente diz "lógica de programação" quando na verdade quer dizer "raciocínio lógico", e pior, muitas vezes direciona a pessoa a aprender algo completamente diferente, pois o que é ensinado quando se ensina lógica de programação não é o raciocínio lógico, mas sim princípios de programação procedural, estes sendo o que eu realmente considero como "lógica de programação".

Isso é algo que você pode confirmar por si mesmo indo pesquisar a ementa de diversos cursos, posts em blogs, e etc, só como exemplo vou deixar 3 links aqui que demonstram esse ponto:

O que um site que nem é sobre programação, uma universidade bem renomada aqui no Brasil, e uma das princípais plataformas de cursos de programação também aqui no Brasil teriam em comum nesse assunto? Justamente a presença do ensino sobre princípios de programação procedural ao invés de um treinamento sobre como desenvolver o seu raciocínio lógico, e embora isso faça sim parte do processo em alguma medida, não seria o suficiente para justificar que raciocínio lógico é a mesma coisa que lógica de programação.

Outra definição que parece colaborar mais com esse ponto seria essa dada pelo Chat-GPT:

A lógica de programação é a base fundamental para a criação de algoritmos e programas de computador. Ela envolve a habilidade de pensar de forma estruturada e sequencial para resolver problemas, transformando essas soluções em instruções claras e precisas que um computador pode entender e executar. Isso inclui entender os conceitos de variáveis, estruturas de controle (como loops e condicionais), operadores, funções e estruturas de dados básicas, entre outros elementos. Em essência, a lógica de programação é a capacidade de pensar logicamente e expressar esse pensamento de maneira que um computador possa seguir.

Essa diferença entre o que se fala e o que, realmente, se quer dizer seria o que resulta na diferença entre expectativa vs realidade nos conteúdos a serem aprendidos posteriormente a este assunto.

O ponto que este artigo gostaria de fazer é que não tem como tem como esperar atingir certos resultados se suas premissas iniciais estão erradas quanto aquilo.

Ok, mas mesmo que mal interpretada, ela ainda assim é basilar para todo resto que vem depois, não é mesmo?

Este é um questionamento bem válido quanto a linha de raciocínio apresentada até aqui, entretanto os conceitos normalmente relacionados a lógica de programação não são conceitos universais de programação, eles são os conceitos que servem de base para o paradigma procedural apenas.

Ao se estudar "lógica de programação", no fim, você vai ter desenvolvido uma forma de pensar na construção de algoritmos que envolve um raciocíonio bem imperativo, pois se aprende que um algoritmo seria como uma receita de bolo, na declaração de estados mutáveis, as variáveis, no controle fino de como a execução do programa vai se dar por meio das estruturas de controle de fluxo, e, se o ensino realmente for bom, na modularização de partes reutilízaveis do programa.

Só que cada ponto disso não é válido em todas as linguagens de programação (como é comumente dito), existem linguagens baseadas no paradigma declarativo, que é o contrário do imperativo, que não possuem variáveis, como as do paradigma funcional, e que não necessariamente precisam de estruturas de controle de fluxo para expressar lógica condicional ou de repetição, como o caso da orientação a objetos.

O único ponto realmente universal seria a ideia de modularizar o programa, no entanto, cada paradigma tem os seus próprios mecanismos de abstração e, geralmente, apenas se ensina sobre as funções durante a "fase da lógica de programação", mas funções tem um significado diferente em programação funcional, e a orientação a objetos usa classes por exemplo.

Existem sim conceitos bem universais aplicáveis a todos os paradigmas, entretanto não são eles que constituem a ideia de lógica de programação.

Isso quer dizer que lógica de programação é ruim?

Não, programação procedural ainda é um dos principais paradigmas adotados no mercado, sendo até considerado como sinônimo de programar em si dependendo do contexto (não a toa que existe toda essa confusão em relação ao tema de lógica de programação), a maioria das linguagens mainstream tem suporte a esse paradigma em alguma medida, e etc.

O problema é que um paradigma de programação é como se fosse um sistema de "lógica de programação" por si só, ele seria um conjunto de princípios, técnicas e funcionalidades utilizados para resolver um problema, ou seja, cada paradigma é como se fosse uma escola de pensamento sobre como programar a solução de determinado problema por si só, com cada uma tendo as suas vantagens e desvantagens para cada cenário.

Então, normalmente, aprender um novo paradigma tende a ser uma das coisas mais dificeis em programação, pois para aprender ele de fato, você tem que jogar fora tudo o que aprendeu até então para começar a reconstruir sua forma de pensar e encarar problemas do zero seguindo esse novo conjunto de ferramentas e princípios.

Logo, fica claro qual o problema de tratar a lógica de programação como o centro de tudo quando ela não é, só se refere aos princípios de um paradigma em específico. Além dos desafios já citados em se trocar de paradigma, a pessoa vai se aproximar desse tema com a mentalidade completamente errada, visto que ela vai tender a encarar esse novo paradigma como uma progressão do seu aprendizado até aqui, muitas vezes como "uma forma melhor" ou complementar ao que ele entende por lógica de programação, e pior, tentar programar usando a lógica de programação num cenário onde ele deveria estar aprendendo uma "nova lógica de programação".

Resumindo, trocar de paradigma já é dificil, imagina se você tentar aprender pelo caminho contrário ao ideal para se abordar este tema.

Isso trás complicações para além da dificuldade de aprendizado, visto que a pessoa pode até absorver os novos conceitos introduzidos pelo paradigma, e até conciliar com o que ele já sabe de alguma forma (o que é bem possível visto que ambos estão no espectro de paradigmas imperativos), o problema é que por ela estar tentando jogar nas regras de um paradigma estando no outro, muitos dos princípios vão ser mal aplicados (dado o vício de já saber fazer de outra forma), ou vão parecer sem sentido, resultando em um programador que conhece os princípios mas ou não sabe aplica-los corretamente ou nem ao menos os aplica.

Conclusão

Lógica de programação, ou melhor, a programação procedural realmente é uma parada bem importante nessa jornada rumo à aprender a programar, entretanto, ao contrário da crença popular, ela não realmente representa a base para tudo o que vem depois, e somado com as confusões associadas com o termo, isso se torna uma bola de neve que prejudica bastante o aprendizado de outros temas muito importantes no futuro como a orientação a objetos.

Então se esse artigo te trouxe uma nova perspectiva sobre esse assunto não deixe de dar o seu pitaco sobre esse assunto nos comentários, e compartilhar esse artigo para que mais pessoas possam aprender de forma mais informada também.

Até a próxima!

Ass: suporte Cansado

Lidando com valores inexistentes no JS

Terminal Coffee — Sat, 04 May 2024 18:37:50 +0000

Um dos erros mais comuns no JS, principalmente entre iniciantes, seria o famoso:

Uncaught TypeError: Cannot read property 'value' of null

Com outra variação aparecendo undefined no lugar de null, prova de como esse é um erro comum seria essa pergunta no stack overflow, o maior fórum de programação do mundo, com mais de 891 mil views ao longo de 9 anos.

Este problema ocorre ao tentar acessar um membro de um objeto, onde ele seria na verdade um valor nulo (null) ou indefinido (undefined). Aqui um exemplo:

const obj = { property: 'value' };

obj.property;

Onde se nós mudarmos o valor de obj para null ou undefined, o erro citado no início deste artigo irá acontecer. Ex:

let obj = null;

// TypeError: Cannot read property 'property' of null
obj.property;

//

obj = undefined;

// TypeError: Cannot read property 'property' of undefined
object.property;

E este não é exatamente um problema novo no mundo da programação, sendo até mesmo chamado de o erro de 1 bilão de dólares, por isso hoje iremos explorar formas de lidar com esse problema no JS.

# 1 Programação defensiva

A solução mais simples para isso seria validar se o valor é null ou undefined antes de usar esse valor (inclusive se você utilizar TypeScript, isso pode ajudar ele a inferir um novo tipo para a sua variável dentro do if agora que ele tem certeza que ela existe), ex:

const h1 = document.querySelector("h1");

if (h1) {
  h1.innerHTML = "Existo por aqui";
}

Ou se realmente quisermos verificar por null e undefined:

let acceptBool = false;

if (acceptBool !== undefined && acceptBool !== null) {
  console.log("false não é undefined e nem null")
}

A forma abreviada é útil quando você sabe que o valor que você vai validar não pode ser um valor falsy (que pode ser convertido em false, por exemplo uma string vazia ou 0 ou o próprio false), assim você garante que só vai cair na sua validação caso esse valor realmente não exista.

Para poder lidar com esses casos onde a forma abreviada não se aplica, podemos verificar diretamente se o valor é undefined ou null, porém assim como se pode notar no segundo exemplo, isso é o código mais legível do mundo, fora que existem diversas ocasiões onde precisamos lidar com esses tipos de valores, então uma forma de melhorar essa solução poderia ser tendo uma função que abstrai essa verificação, ex:

const isNone = (value) => value === undefined || value === null;

# 2 Usando operadores do JS

Por ser um problema tão comum o JS tem algumas funcionalidades nativas para lidar com alguns desses cenários, por exemplo o null coalescing operator (??), que nós podemos utilizar para prover um valor padrão caso o valor desejado seja null ou undefined:

const valorOrNone = null;
const value = valueOrNone ?? "Valor padrão";

Porém, apesar de muito útil, caso estivermos lidando com um objeto com outros objetos possivelmente nulos dentro dele, isso pode rapidamente se tornar um pouco confuso:

function showDeepProperty(obj) {
  const deepProperty = obj.a.b.c;
  console.log(deepProperty);
}

showDeepProperty({
 a: {
   b: {
     c: "propriedade profunda"
   }
 }
});

// TypeError: Cannot read property 'b' of undefined
showDeepProperty({
  a: null
});

Para corrigir isso teríamos que usar o operador de coalescencia nula para cada propriedade sendo acessada, ex:

function showDeepProperty(obj) {
  const a = obj.a ?? { b: c: '' };
  const b = a.b ?? { c: '' };
  const deepProperty = b.c ?? '';

  console.log(deepProperty);
}

Por isso podemos utilizar um outro operador do JS para tornar esse código bem legível e conciso novamente, o optional chaining operator, ex:

function showDeepProperty(obj) {
  const deepProperty = obj?.a?.b?.c;
  console.log(deepProperty);
}

Ao utilizar ?. antes de acessar uma propriedade ele vai acessar o valor dela se existir, entretanto se o valor for null ou undefined ele retornaria undefined, sendo a inovação aqui que ele além de não lançar um erro, permite que você vá encadeando (por isso o chaining no nome) esse operador para ir acessando camadas mais profundas desse objeto, e se em qualquer momento alguma dessas propriedades não existir ou cair no critério dito anteriormente, ele vai simplesmente retornar undefined ao invés de um erro.

Com isso, podemos combinar os dois e também definir um valor padrão ao final do encadeamento:

function showDeepProperty(obj) {
  const deepProperty = obj?.a?.b?.c ?? '';
  console.log(deepProperty);
}

Sendo isso o equivalente ao código mostrado que utilizava diversos operadores de coalescencia nula.

# 3 Null Object

Também podemos nos utilizar de técnicas dos paradigmas suportados pelo JS para resolver esse problema, por exemplo, ao utilizarmos as funcionalidades relacionadas a orientação a objetos presentes no JS podemos implementar um design pattern conhecido como Null Object.

O cenário onde podemos utilizar ele seriam os casos onde precisariamos retornar um valor nulo no código, e a solução seria retornar outro valor no lugar, afinal já vimos ao longe deste artigo como ele pode não ser o melhor valor para representar a não existencia de algo no código.

A ideia do Null Object para isso seria utilizar herança para ter uma classe que cria uma versão do objeto real, e outra nula, assim ambos vão ter os mesmos métodos, assim podemos confiar no polimorfismo para chamar os métodos do objeto real quando ele for retornado, e os métodos do objeto nulo no caso do valor não existir, e nesse caso os métodos do objeto nulo não fariam nada. Ex:

class Post {
  constructor({ id, title, tags }) {
    this.id = id;
    this.title = title;
    this.tags = tags;
  }

  match(tags) {
    return tags.every(tag => this.tags.includes(tag));
  }

  ifMatch(tags, perform) {
    if (this.match(tags)) {
      perform();
    }

    return this;
  }
}

class NullPost extends Post {
  constructor() {
    super({ id: 0, title: '', tags: [] });
  }

  match(_tags) {
    return false;
  }

  ifMatch(_tags, _perform) {
    return this;
  }
}

class PostsGateway {
  constructor(posts = []) {
    this.posts = posts;
  }

  findById(id) {
    return this.posts.find(post => post.id === id) ?? new NullPost();
  }
}

const posts = new PostsGateway();
const post = posts.findById(1);

post.ifMatch(['oop', 'js'], () => {
  console.log("Post is of OOP in JS");
});

Dessa forma, caso seja retornado um objeto Post real, ele vai executar a lógica correta e se as tags do artigo baterem, ele vai mostrar a mensagem no console, e caso seja retornado um null object, nada iria acontecer.

# 4 Optional Monad

Se você achou a ideia anterior interessante vai achar esta, que desta vez vai utilizar as capacidades de programação funcional do JS, muito útil também.

Na programação funcional um conceito que vem cada vez se tornando mais popular mesmo fora do paradigma são as monads, que são formas de representar computações dentro de um contexto, geralmente um efeito colateral, e compor essas computações, duas delas em específico vem aparecendo mesmo em linguagens tradicionalmente orientadas a objeto como a Optional, que vamos explorar hoje e representa computações em valores possívelmente nulos, e a Result, que representa computações que podem falhar. A propósito, as Promises do JS são inspiradas nesse conceito, sendo algo semelhante a uma Monad de Result assíncrona, muitas vezes conhecida como Task.

Dadas as explicações, show me the code:

const isNone = (value) => value === undefined || value === null;

const Optional = {
  none: () => ({
    map: (fn) => Optional.none(),
    flatMap: (fn) => Optional.none(),
    match: ({ none }) => none(),
    isNone: () => true,
    isSome: () => false
  }),
  some: (value) => ({
    map: (fn) => Optional.some(fn(value)),
    flatMap: (fn) => fn(value),
    match: ({ some }) => some(value)
    isNone: () => false,
    isSome: () => true
  }),
  of: (value) => isNone(value) ? Optional.none() : Optional.some(value);
};

Optional
  .of(1)
  .map(x => x + 1)
  .match({
    some: (value) => console.log(value),
    none: () => console.log("Valor não existe")
  }); // 2

Optional
  .of(null)
  .map(x => x + 1)
  .match({
    some: (value) => console.log(value),
    none: () => console.log("Valor não existe")
  }); // Valor não existe

Nesse caso nós temos o Optional.of para pegar um valor qualquer (mesmo null ou undefined) e envolver ele num Optional, em FP nós chamamos isso de lifting pois estamos elevando o valor a um dado contexto.

Assim, podemos utilizar o Optional.map para aplicar funções no valor dentro do Optional, semelhante a como se utilizaria o método then numa promise ou o map em um array, e assim como no Null Object, se for um valor some, então ele, de fato, vai aplicar a função callback no valor de dentro do Optional e fazer algo com ele, agora caso ele seja um none, ai nada acontece, ele simplesmente devolve outro none.

Podemos ver o Optional quase que como uma versão do Null Object, mas que funciona para qualquer valor, semelhante a como um Array funciona para qualquer valor e não precisamos sair por ai criando uma classe de Array para cada objeto existente no sistema só para fazer a mesma coisa todas as vezes.

O Optional.match serve para quando precisarmos retirar o valor de dentro desse contexto, assim nós provemos uma função para cada possibilidade, seja o valor real ou nulo, e o match vai devolver como resultado o valor devolvido pela função correspondente a identidade atual do valor sendo o Optional.

Tudo isso é bem legal, mas ao utilizarmos o map, o valor é envolvido novamente num contexto, e por isso se nós retornarmos um Optional no map, terminariamos com um Optional de um Optional de um valor, sendo que o que nós queremos é só que ele seja um Optional de um valor, e para resolver essa situação, nós temos o Optional.flatMap:

Optional
  .of(document.querySelector("figure"))
  .flatMap((figure) => Optional.of(figure.querySelector("figcaption")))
  .match({
    some(figcaption) {
      figcaption.innerHTML = "Legenda";
    },
    none() {
      console.log("Figure sem legenda");
    }
  })

Conclusão

Espero que o artigo de hoje tenha aberto sua mente para as várias técnicas que você pode usar para se livrar do null no seu código, e não se esqueça de compartilhar este artigo, até a próxima.

Links que podem te interessar

Ass: Suporte Cansado.

Especial 1 de Maio - Explorando a Diversidade da TI

Terminal Coffee — Wed, 01 May 2024 20:50:06 +0000

Introdução

O dia 1º de maio no Brasil comemora o Dia do Trabalho em nossa nação, marcando um grande feriado para a maioria dos trabalhadores desfrutarem de um dia de folga e relaxamento. Por isso, hoje nós, do Terminal Coffee, vamos apresentar 4 profissões para você que deseja trabalhar na área de Tecnologia da Informação, ou simplesmente T.I. para os íntimos. Então, sem mais delongas, segue a lista!

1 - Desenvolvimento de Software

No topo de nossa lista está o desenvolvimento de software, a mais famosa e, para muitos, a mais assustadora área para quem não é da área. Por isso, não poderíamos falar sobre T.I. sem começar por ela; seria quase um pecado da tecnologia. O desenvolvimento de software é a base das equipes e literalmente cria todas as ferramentas que usamos em computadores e smartphones. Eles são responsáveis pelos fundamentos e funcionalidades dos sistemas, assim como um bom pedreiro constrói uma casa. É por isso que os apelidei de 'pedreiros de código', pois quando algo dá errado, ou no caso, o sistema falha, eles são os primeiros que você lembra de ofender até a quinta geração.

Por ser uma área muito versátil e abrangente, com inúmeras linguagens para se especializar, há a possibilidade de atuar em diversos projetos, desde programas web com HTML e CSS até sistemas mais complexos com Java e suas variantes.

2 - Redes e Segurança

Se a pessoa que trabalha com desenvolvimento de software é como o pedreiro de um sistema, com certeza quem trabalha com redes e segurança é como o porteiro que impede a entrada de Trojans (Cavalos de Tróia), Malwares e Spywares indesejados no seu sistema. São eles que sabem como manter seus dados seguros e até mesmo encontrá-los. Portanto, agradeça todos os dias por seus dados do Facebook não terem sido vazados (quer dizer, não outra vez) e sempre tenha cuidado com onde você acessa. De nada adianta esses profissionais trabalharem se você desabilita seu firewall e DNS para baixar jogos e conteúdos ilegais.

3 - Análise de Dados e Business Intelligence (BI)

Análise de dados é uma função de suma importância nas empresas atualmente, pois seu trabalho bem feito é mandatório para tomadas de decisões bem-sucedidas e lucrativas de uma empresa. É uma área extremamente complexa e frequentemente subestimada no dia a dia dos profissionais do ramo.

4 - Gerenciamento de Projetos de TI

Por fim, para fechar nossa lista de hoje, temos o gerenciamento de TI. Toda equipe precisa de um bom líder para gerenciar seu desenvolvimento. É como no futebol: um bom técnico pode levar uma equipe mediana a ter grandes resultados, mas um técnico ruim pode levar a melhor das equipes a ter o pior dos resultados (Não é mesmo, Vitor Pereira?). São esses os 'caras chatos' que mantêm o cronograma de desenvolvimento em dia, calculam os gastos para o projeto não gerar prejuízos antes do término, garantem a boa comunicação da equipe e impedem que os membros se 'matem' nas reuniões de desenvolvimento. Geralmente, são eles que conversam diretamente com o cliente, tendo uma grande responsabilidade em suas mãos.

Conclusão

Um post curto só para não deixar o dia passar. Um bom feriado a todos! Se gostaram do texto, deixem seu like e comentem para que possamos trazer uma parte 2 com profissões menos conhecidas na área de TI.

Ass: Estagiário mal remunerado.