DEV Community: Raphael da Silva

Injeção de dependência, interfaces e Laravel

Raphael da Silva — Tue, 05 Sep 2023 17:14:43 +0000

Em 2020 eu fiz um repositorio com o Laravel, o objetivo era testar o framework, busquei usar inferfaces para desacoplar o código. Nisso injetei nos controllers a dependencia para uma interface, que é programar voltado para abstrações, pois isso desacopla o código, o que significa poder trocar de implementações.

<?php

namespace App;

use \stdClass as User;

/**
 *
 * @author Raphael da Silva
 *
 */
interface UserFinder
{
    public function getById(int $id): User;
}

<?php

namespace App\Http\Controllers;

use Illuminate\Contracts\Support\Renderable;
use App\UserFinder;

/**
 *
 * @author Raphael da Silva
 *
 */
class UserDetailsController extends Controller
{
    private $userFinder;

    public function __construct(
        UserFinder $userFinder
    ){
        $this->userFinder = $userFinder;
    }

    public function index(int $id): Renderable
    {
        return view('user-details', [
            'user' => $this->userFinder->getById($id)
        ]);
    }

}

Ou seja, a interface UserFinder permite criar qualquer classe para buscar um usuário. A implementação padrão foi usando os componentes (as classes) de acesso a banco de dados o Laravel, pois essa implementação em questão busca usuários no banco de dados. Mas poderia ser em qualquer outra fonte de dados (um arquivo XML, um arquivo JSON).

E o acesso ao banco de dados do Laravel é um monte de método estático (agrupado num namespace chamado DB, que significa DataBase) do qual nao gosto muito, mas a beleza da coisa é que isso nao importa porque todo esse código está abstraido com a interface, apenas a implementação (LaravelDBUserFinder) usa esses métodos estáticos que são pertinentes a como o Laravel faz as coisas no seu ecossistema.

<?php

namespace App;

use App\UserFinder;
use Illuminate\Support\Facades\DB;
use \stdClass as User;
use Illuminate\Database\Eloquent\ModelNotFoundException;

/**
 *
 * @author Raphael da Silva
 *
 */
class LaravelDBUserFinder implements UserFinder 
{
    public function getById(int $id): User
    {
        $user = DB::table('users')->find($id);

        if(is_null($user)){
            throw new ModelNotFoundException('User not found.');
        }

        return $user;
    }
}

Eu nao sou fluente em Laravel, nem domino esse framework, o máximo que fiz com ele foi testes para vagas de emprego (porque ele é muito usado pelo mercado, virou uma espécie de convenção), mas tento observar a arquitetura das coisas e busco desacoplar o código no paradigma da orientacao a objetos. Então gosto de ver as interfaces aplicadas e como isso traz legibilidade e desacoplamento para o código.

Link para o repositório: https://github.com/raphael-da-silva/testando-o-laravel

Originalmente publicado em: https://raphael-da-silva.github.io/injecao-de-dependencia-laravel/

Aprendendo a arquitetura das coisas com o produtor musical 9th Wonder

Raphael da Silva — Mon, 03 Apr 2023 12:50:41 +0000

Na internet tem obras de desenvolvedores da comunidade que escreveram artigos e fizeram hangouts com o objetivo de propagar conhecimento, ter acesso a isso me possibilitou estudar os assuntos de programação de uma forma um pouco mais aprofundada.

Todo esse conhecimento compartilhado por terceiros (como o código da pasta vendor que é baixada pelo Composer) me permitiu construir uma base de conhecimento para trabalhar com objetos e ter interesse suficiente para querer escrever sobre o tema.

Na atividade musical existe a prática de samplear (principalmente no Rap), essa prática consiste em extrair partes/pedaços de músicas antigas já existentes para compor um instrumental de uma música nova.

Todo o conhecimento sobre o paradigma que consumi foram as coisas “sampleadas” por mim, é como se eu estivesse sampleando o conhecimento difundido na área para compor uma nova obra, que aqui não é uma nova batida, mas sim este blog e posts como esse.

O produtor de Rap 9th Wonder foi a minha inspiração para começar a tentar fazer batidas, ele tem uma visão sobre a pratica de samplear que é muito rica e traz uma sabedoria. Em um tweet ele fala o seguinte:

In short…our whole culture is a sample, our government, our buildings, holidays, our way of life….we spend our day saying slang and using terms that were NOT create by any of us, but saying it like it’s ours….

Traduzindo fica o seguinte:

Em suma … toda a nossa cultura é um sample, nosso governo, nossos edifícios, feriados, nosso modo de vida… passamos o dia dizendo gírias e usando termos que NÃO foram criados por nenhum de nós, mas que dizemos como se fosse nosso….

Toda essa ideia de que tudo se constrói com base em alguma coisa usando a arte de samplear foi algo que fez sentido para mim, pois se conectou com o meu entusiasmo com a construção de batidas de rap, construção essa que envolve a programação de timbres dentro de um padrão, são sons programados para operar e se repetir dentro de um BPM, é um outro tipo de programação que eu fazia antes de entrar na programação de objetos.

O produtor 9th Wonder

Este post foi originalmente publicado no meu blog:

A tal da alta coesão e baixo acoplamento

Raphael da Silva — Wed, 09 Jun 2021 19:24:16 +0000

Quando tive os primeiros contatos com a Orientação a Objetos, eu ouvia a frase "Alta coesão e baixo acoplamento" diversas vezes. O problema é que aquilo ficava vago, pois não era mostrado como obter essas vantagens.

O acoplamento é o grau de ligação entre classes, se o acoplamento for alto as classes são engessadas, logo estão limitadas. Para ter baixo acoplamento entra em jogo as abstrações possibilitando trocar as implementações entre objetos.

O conceito de coesão é utilizado para definir o quanto as operações presentes em um objeto estão relacionadas umas com as outras. Basicamente, um objeto é coeso quando faz exatamente o que se propõe, sem ir além disso. Ou seja, é quando ele que possui operações que estão focadas em compor uma determinada responsabilidade, sem misturar conceitos que não estão relacionados entre si.

Por exemplo, um objeto feito para salvar um cadastro no banco de dados e também gerar mensagens de log não é coeso, pois a responsabilidade de gerar uma mensagem de log não deveria estar nele. Para que esse objeto fosse coeso, ele deveria ter somente métodos relacionados ao cadastro no banco de dados e os detalhes necessários para realizar esse tipo de operação. Já o log deveria ter uma classe própria para ele.

Na minha visão, a frase "alta coesão e baixo acoplamento" usa palavras rebuscadas e complexas que não ajudam muito os iniciantes. Talvez se a frase "Alta coesão e baixo acoplamento" fosse traduzida por "Objetos flexíveis e com responsabilidades limitadas" as coisas seriam mais intuitivas logo de início.

Ou melhor, se a frase fosse traduzida por "use abstrações como parâmetros e mantenha só uma responsabilidade" tudo ficaria ainda mais evidente.

O papel da linguagem (não a de programação)

O propósito desse artigo foi fazer essa simplificação didática que evita o uso desses termos complexos e pouco intuitivos para quem inicia a aventura de entender melhor a Orientação a Objetos.

A linguagem rebuscada e complexa dos termos do paradigma foi uma barreira que encontrei no começo, ou seja, a barreira não foi a linguagem da programação, mas sim a linguagem usada entre programadores no seu vocabulário.

POO - Revisando o princípio da inversão de dependência (DIP)

Raphael da Silva — Sat, 10 Oct 2020 13:01:07 +0000

Eu sempre entendi o princípio da inversão de dependência (DIP) como dependender de abstrações (interfaces e classes abstratas), essa visão veio do contato que tive com esse princípio no meio do aprendizado da injeção de dependência, que é incentivada com abstrações para seguir o principio DIP. Só que essa visão era limitada e focada em um só lado do conceito.

Além depender de abstrações (usando a injeção de dependência), existe um outro lado na inversão de dependência que é mais conceitual e consiste em módulos de alto nível (mais próximos no usuário) que dependem de módulos de baixo nível (mais próximos do computador/máquina). Módulos, nesse contexto, se referem ao código (classes, interfaces e etc).

O lado que eu abordava não estava errado, porém o meu foco restrito fez eu não ver o outro lado desse princípio, ou seja, a visão que eu tinha era incompleta. Antes eu não tinha me atentado e percebido essa relação entre código de alto nível e o código de baixo nível, essa é mais uma das revisões em orientação a objetos que me mostram que quando mais estudo, mais vejo que não sei nada.

Usar camadas como Domain e Infrastructure me fizeram perceber mais ainda como é a aplicação completa do princípio DIP, pois a primeira camada é alto nível e não depende da segunda, já a segunda é baixo nível e depende da primeira. Ou seja, módulos de alto nível não dependem de módulos de baixo nível, mas sim o contrário. É justamente isso que a definição clássica do princípio DIP diz.

Splinter Cell + Objetos

Raphael da Silva — Wed, 15 Jul 2020 16:14:04 +0000

Anos atrás eu criei algumas classes para representar o jogo Splinter Cell através de objetos e com um uso de interfaces para mostrar tipos sendo compartilhados. Basicamente, é a representação de elementos (personagens e equipamentos) do jogo Splinter Cell da ubisoft através do paradigma da orientação a objetos.

Por exemplo, Sam Fisher (o protagonista do jogo) é composto por nightvision googles (óculos e visão noturna) com injeção de dependência e implementa a interface que define um agente especial.

<?php

namespace SplinterCellOOP;

use SplinterCellOOP\ThirdEchelonAgent;
use SplinterCellOOP\FourthEchelonAgent;
use SplinterCellOOP\Goggles;

/**
 *
 * @author Raphael da Silva
 *
 */
class SamFisher implements FourthEchelonAgent
{

    private $goggles;

    public function __construct(
        Goggles $goggles
    ){

        $this->goggles = $goggles;

    }

    public function actStealth()
    {

        $this->goggles->enable();

    }

}

Ao implementar a inteface FourthEchelonAgent, o personagem também implementa a interface ThirdEchelonAgent, pois a primeira é uma extensão da segunda, já que na história do jogo, a FourthEchelon é a sucessora da ThirdEchelon.

<?php

namespace SplinterCellOOP;

use SplinterCellOOP\ThirdEchelonAgent;

/**
 *
 * @author Raphael da Silva
 *
 */
interface FourthEchelonAgent extends ThirdEchelonAgent
{

}

Além de Sam Fisher, outros agentes podem implementar a mesma interface, pois fazem parte da mesma organização (sendo do mesmo tipo).

<?php

namespace SplinterCellOOP;

use SplinterCellOOP\FourthEchelonAgent;
use SplinterCellOOP\Weapon;
use SplinterCellOOP\Goggles;

/**
 *
 * @author Raphael da Silva
 *
 */
class IssacBriggs implements FourthEchelonAgent
{

    private $weapon;
    private $goggles;

    public function __construct(
        Weapon $weapon,
        Goggles $goggles
    ){

        $this->weapon  = $weapon;
        $this->goggles = $goggles;

    }

    public function actStealth()
    {

        $this->goggles->enable();
        $this->weapon->use();

    }

}

É isso! Segue o link para todo o código no repositório.

Algumas das fases que passei no aprendizado de programação orientada a objetos

Raphael da Silva — Wed, 15 Jul 2020 14:45:22 +0000

Eu passei por algumas fases diferentes no aprendizado para tentar ter um código mais orientado a objetos (desde 2014). Entre essas fases então:

Quase desistir de um curso técnico em 2011 quando tive o primeiro contato com a orientação a objetos.
Aprender a fazer algumas classes ruins (usando varíaveis globais para passar a pdo para a classe) e (achar esse código ruim) o máximo.
Insistir em estudar e começar a ter mais conforto com objetos por volta da metade de 2013.
Ter um código com muita herança, onde tudo estava estendendo de um model mais genérico que era gigante.
Entender injeção de dependência se empolgar e querer parametrizar tudo (até o que nem precisaria variar).
Criar um framework próprio (aka framework caseiro) em 2014 e se empolgar (atualizando o código com o que eu ia aprendendo).
Ler muitos artigos que questionam getters, setters, entidades e outras práticas e achar que tinha descoberto o jeito "certo" e passar a achar que determinadas práticas são sempre ruins sem analisar.
Ler muitos artigos e achar que código estáticos são sempre ruins, o que é uma generalização sem análise da situação.
Eu gosto muito do conceito de interfaces, logo acabei criando interfaces para todas as classes, até as que não precisariam de uma interface por não exigirem novas implementações diferentes.
Ter interfaces e classes com o mesmo nome separadas por um prefixo I e não enxergar que isso era um sinal de erro de abstração.
Começar a rever as minhas posturas sobre as opniões que eu tinha formado e ir ficando menos intrasigente (mais flexível). Com isso, comecei a reavaliar as práticas que eu aplicava cegamente. Disso surgiram as etapas a seguir.
Ver que código estático nem sempre é um problema e pode ser aplicado para coisas simples como factorys e operações simples que agem com funções e não precisam ser trocados (através de injeção de dependência).
Ver que nem toda classe precisa de interface para variar a sua implementação.
Usar array para tudo e achar entidades desnecessárias pela complexidade adicionada (sem enxergar o contexto/informação sobre o domínio/regras de negócio que elas dão).

As mudanças de 2020

Antes eu acha que para seguir DIP era só depender de abstrações com uma interface e classe abstrata, sem entender a relação entre o que está baixo nível (infraestrutura) e o que está alto nível (domínio).

Depois disso passei a buscar expressar o domínio de forma mais intuitiva e nítida, por isso estou tentando usar alguns conceitos mais simples de DDD (entidades, value objects).

Junto com os conceitos de DDD também estou tentando aplicar a separação do código de infraestrutura e domínio, pois só depois dessa separação eu comecei a entender o que realmente significa o princípio da inversão de dependência do SOLID.

POO - Relacionamentos e interfaces (de objetos)

Raphael da Silva — Sun, 12 Jul 2020 14:46:11 +0000

Imagine que alguém quer ter um amigo e deseja que esse amigo seja verdadeiro. Para isso, um amigo deve se comportar de certa maneira, pois para ser um amigo ele deve fazer o seguinte:

Confiar

Ou seja, para ser o amigo esperado, ele deve implementar a seguinte interface e fazer as seguintes ações (operações):

<?php

/**
 *
 * @author Raphael da Silva
 *
 */
interface Amigo
{

    public function confiar(): void;

}

Agora uma pessoa mais introvertida pode implementar essa interface fazendo as ações (a.k.a operações) do seu jeito (de acordo com a sua implementação):

<?php

/**
 *
 * @author Raphael da Silva
 *
 */
class PessoaIntrovertida implements Amigo
{

    public function confiar(): void
    {

        echo 'Estabelece um vínculo de confiança silenciosa.';

    }

}

Além da pessoa mais introvertida, uma pessoa extrovertida também pode implementar a interface e, com isso, ser um amigo também:

<?php

/**
 *
 * @author Raphael da Silva
 *
 */
class PessoaExtrovertida implements Amigo
{

    public function confiar(): void
    {

        echo 'Estabelece um vínculo de confiança bem explícido.';

    }

}

Para a pessoa que quer o amigo que atenda a interface Amigo é esperado alguém que se comporte dessa forma como a interface representa através de suas operações. Segue a classe que representa a(o) quem vai ter o amigo:

<?php

/**
 *
 * @author Raphael da Silva
 *
 */
class PessoaQueQuerUmAmigo
{

    public function __construct(
        private Amigo $amigo
    ){}

    public function estabelezerAmize()
    {

        $this->amigo->confiar();

    }

Ter um amigo é algo que expressa uma relação de composição (e injeção de dependência), pois a classe PessoaQueQuerUmAmigo tem um objeto do tipo da interface Amigo passada como parâmetro no seu construtor.

No uso de interfaces na comunicação entre objetos tudo gira em torno de ação, confiança e expectiva, assim como acontece nas relação humanas.

O projeto Programador Cansado

Raphael da Silva — Sat, 11 Jul 2020 22:21:01 +0000

Eu acabei tendo a ideia de criar uma organização no Github para agrupar informações sobre saúde mental. O nome do projeto é Programador Cansado, o objetivo é dedicar uma atenção para a mente e a sua saúde no contexto da programação.

Eu tive algumas experiências pessoais que me atrapalharam na construção de uma carreira estável, esse projeto é uma tentativa de tentar criar algo construtivo a partir do meu fracasso pessoal ligado a sáude mental e esgotamento trabalhando com programação (por falta de autopreservação).

A ideia base do projeto é a seguinte: antes de cuidar do código-fonte, é importante cuidar da mente, caso contrário, ela vai bugar mais que o código-fonte.

O Objetivo de forma sintetizada

O objetivo do projeto pode ser descrito com as seguintes palavras: cuidando da saúde mental (para a mente não bugar).

My favorite Rap producers with code

Raphael da Silva — Sat, 11 Jul 2020 16:53:32 +0000

I like Rap, I tried be a beatmaker at 16, in 2012 I started programming. In this article I mix Rap with programming. Let's start.

My favorite rap producers:

9th Wonder.
Apollo Brown.
DJ Premier.

All these artists create boom bap beats, so they beats share a common type of music. A interface can represent this:

// Author: Raphael da Silva
interface BoomBapProducer
{
    public function makeABeat();
}

All producers can implement the same interface:

// Author: Raphael da Silva

class 9thWonder implements BoomBapProducer
{

    public function makeABeat()
    {
        echo 'Classic soul samples.';
    }

}

class ApolloBrown implements BoomBapProducer
{

    public function makeABeat()
    {
        echo 'Hard drums and soul sample.';
    }

}

class DJPremier implements BoomBapProducer
{

    public function makeABeat()
    {
        echo 'Classic NY east coast style.';
    }

}

I don't speak english (I try write to share ideas), please be nice with me and forgive my mistakes.

POO - Compondo os vingadores (da marvel) com objetos

Raphael da Silva — Sat, 11 Jul 2020 16:19:03 +0000

Criar objetos do mesmo tipo e usá-los para compor outros objetos é algo que permite juntar todos os objetos em uma composição única que faz algo que reune todos eles. Para ilustrar essa união eu irei usar os hérois da Marvel que formam os vingadores.

Primeiramente, será criada uma interface para representar esses heróis e seus atos:

<?php

/**
 *
 * @author Raphael da Silva
 *
 */
interface Vingador
{

    public function avante();

}

Depois disso serão criados os heróis que são implementações diferentes dessa mesma interface que representa cada um dos heróis. Segue o código:

<?php

/**
 *
 * @author Raphael da Silva
 *
 */
class CapitaoAmerica implements Vingador
{

    public function avante()
    {

        return 'Jogar o escudo';

    }

}

class PanteraNegra implements Vingador
{

    public function avante()
    {

        return 'Usar a tecnologia de Wakanda e artes marciais.';

    }

}

class HomemFormiga implements Vingador
{

    public function avante()
    {

        return 'Encolher com a tecnologia do Hank Pym.';

    }

}

class DoutorEstranho implements Vingador
{

    public function avante()
    {

        return 'Projetar magia do plano astral.';

    }

}

Depois de ter vários objetos do mesma da mesma interface (ou seja, do mesmo tipo), será criada uma classe que é composta por todos esses objetos juntos e representa a junção de todos eles, no exemplo desse artigo essa classe junta todos os heróis e, com isso, forma os Vingadores, já que ela é composta por todos os heróis juntos (composta é a palavra-chave aqui).

Segue a classe que representa os Vingarores:

<?php

/**
 *
 * @author Raphael da Silva
 *
 */
class Vingadores
{

    private $vingadores;

    public function __construct(
        Vingador ...$vingadores
    ){

        $this->vingadores = $vingadores;

    }

    public function avanteVingadores()
    {

        foreach($this->vingadores as $vingador){
            echo $this->vingador->avancar(), PHP_EOL;
        }

    }

}

Para usar as classes o código e juntar tudo na prática ficaria da seguinte forma:

<?php

$vingadores = new Vingadores(
    new CapitaoAmerica,
    new PanteraNegra,
    new HomemFormiga,
    new DoutorEstranho
);

$vingadores->avanteVingadores();

Agora todos os hérois em formação podem ir avante!

O autor do desenho do banner é o artista Rafael Grampá.

PHP - Funções anônimas estáticas

Raphael da Silva — Sat, 11 Jul 2020 16:16:31 +0000

Olhando um repositório no Github (uma dia antes da criação desse post) me achamou a atenção o uso da palavra reservada static em uma função anônima, pois eu nunca tinha visto isso e, portanto, não sabia que existia essa possibilidade no PHP. Depois de estudar resolvi escrever sobre isso.

A finalidade

Fui pesquisar e entendi o porquê do uso de uma função anônima assim. Basicamente, ao declarar a função estática a variável $this não existirá no escopo da função, ou seja, a função não irá referenciar um contexto de onde ela foi declarada. Segue o exemplo em código:

<?php

class Contexto
{

    public function exemplo(){

        $funcaoSemContexto = static function(){

            // Essa variável é indefinida no escopo dessa função.
            var_dump($this);

        };

        $funcaoSemContexto();

    }

}

Sem usar a palavra reservada static, a variável $this iria apontar para uma instância da classe Contexto, já que foi nessa classe que a função anônima foi criada e, consequentemente, ela seria o contexto dessa função. Como a função foi declara estática, o seguinte erro aparece:

Fatal error: Uncaught Error: Using $this when not in object context

Troca de contexto

Vale lembrar que uma função anônima no PHP é uma instância da classe (interna do PHP) Closure e essa classe tem métodos como o método bindTo, que é responsável por adicionar um novo contexto (aka a variável $this) em uma função anônima.

Só que trocar de contexto não é possível em uma função declarada como estática, já que ela impossibilita ter contexto. Em outras palavras, não dá para usar o método bindTo em função anônima quando ela é estática.

Segue isso exemplificado mantendo o exemplo de código criado:


<?php

class Contexto
{ 

    public function exemplo(){

        $funcaoSemContexto = static function(){

            // Essa variável é indefinida no escopo dessa função.
            var_dump($this);

        };

        $novoContexto = new stdClass;
        $novoContexto->texto = 'Esse objeto é o novo contexto.';

        // Isso não é possível porque a função foi criada estática
        $funcaoSemContexto = $funcaoSemContexto->bindTo($novoContexto);
        $funcaoSemContexto();

    }

}

Ao executar o código acima, o erro a seguir aparece por conta da função anônima ser estática.

Warning: Cannot bind an instance to a static closure

Finalizando

Esse comportamento alcançado através funções anônimas estáticas é semelhante ao de classes estáticas, já que elas não tem contexto por não serem uma instância de um objeto. Declarar uma função anônima como estática dá essa mesma natureza (de não ter contexto) para a função.

Esse comportamento pode ser útil se por algum motivo é necessário evitar que o $this possa ser usado em uma função anônima.

Atualização

Atualizei um projeto que fiz com Slim Framework para usar as funções estáticas nos arquivos de configuração que isolam o escopo do código, pois nessas funções não existe sentido em usar o $this.

PHP - Nullable types vs. Parâmetros opcionais

Raphael da Silva — Sat, 11 Jul 2020 16:15:33 +0000

Nullable Types é um recurso adicionado a partir da versão 7.1 do PHP, ele serve para permitir que um parâmetro possa receber nulo além do tipo definido como type hinting. A função printName a seguir espera um parâmetro do tipo StdClass, só que o ponto de interrogação (?) antes da declaração do tipo define esse parâmetro como nullable type.

<?php

function printName(?StdClass $user)
{

    if(!is_null($user)){
        echo sprinf('Meu nome é %s', $user->name), PHP_EOL;
        return;
    }

    echo 'Nenhum nome!', PHP_EOL;

}

Como o parâmetro é nullable type, ele pode ser executado de duas formas: passando o tipo esperado ou passando um valor nulo.

<?php

$user = new \StdClass;
$user->name = 'Usuário da Silva';

printName($user); // Imprime 'Meu nome é Usuário da Silva'
printName(null); // Imprime 'Nenhum nome!'

Isso difere o recurso de nullable types dos parâmetros opcionais, pois quando um parâmetro opcional é definido, significa que a função pode ser chamada sem nenhum parâmetro. Segue o código:

<?php

// Agora o parâmetro é opcional
function printName(StdClass $user = null)
{

    if(!is_null($user)){
        echo sprinf('Meu nome é %s', $user->name), PHP_EOL;
        return;
    }

    echo 'Nenhum nome!', PHP_EOL;

}

$user = new \StdClass;
$user->name = 'Usuário da Silva';

printName($user); // Imprime 'Meu nome é Usuário da Silva'
printName(null); // Imprime 'Nenhum nome!'

// É possível executar a função sem parâmetro.
printName(); // Imprime 'Nenhum nome!'

Como é possível perceber na terceira execução da função, nenhum parâmetro está sendo passado, isso é possível porque o parâmetro foi declarado como opcional. Essa é a diferença principal, já que no nullable type não dá para omitir um parâmetro, pois é necessário que ele receba um valor nulo explicitamente (além do tipo esperado, é claro).