Olá, leitores do meu blog! Talvez não seja tão necessário mas devo dizer, que saudade de falar de PHP. Faz muito tempo que sequer encosto num código escrito nessa linguagem. Até cheguei a escrever alguns programas para tratar de uns freelances, mas nada perto do que costumava ser o dia-a-dia. O que não quer dizer que meu trabalho ficou mais fácil - e obviamente não seria o motivo de se tornar mais difícil, rs - apenas que deixei de ser 100% focado em desenvolver projetos em PHP para ser mais criterioso em resolver problemas da melhor forma que estiver disponível.

De qualquer forma, sinto que o blog ficou totalmente abandonado e pensei que chegaria por aqui e não encontraria ninguém. Para minha surpresa: o blog ainda recebe visitas diariamente, desde pessoas que estão começando no PHP (que era o propósito da série “PHP para Iniciantes”) quanto pessoas que estão revisitando tópicos que esqueceram por quaisquer motivos. Até eu já me peguei procurando um artigo no meu blog para lembrar de alguma coisa, haha. Já usei até para buscar documentações para assimilar alguma coisa de uma linguagem que desconheço. Eis a importância de se ter alguém na comunidade escrevendo releituras de documentações de forma didática: criar um conteúdo adicional para facilitar a compreensão de alguma coisa.

Caso não se lembrem (ou seja sua primeira vez por aqui, rs), eu criei, anos atrás, um servidor no Discord chamado “Code Aspiras”, com o objetivo de distribuir conhecimentos em reuniões que chamamos de “refinamento”, onde faríamos uma votação prévia para definir um assunto e depois apresentaríamos para quem estivesse interessado. Nesse servidor, incentivei a escrita de artigos como os que fiz nesse blog e até abri um blog para que os aspiras pudessem escrever seus artigos: https://blog.codeaspiras.dev/ . Assim como meu blog, o do Code Aspiras é gerenciado pelo HashNode.com, onde cada artigo publicado pode ser associado ao perfil de um autor. Portanto, quem escrevesse teria sua marcação de autoria, embora, ainda assim, estivesse promovendo o blog do grupo em conjunto. A ideia era poder promover meus mentorados e, simultaneamente, escalar a releitura das documentações.

Uma pena que, assim como os refinamentos, o blog do Code Aspiras não vingou. Não foi por falta de interesse. Acredito fortemente que meus mentorados queriam muito fazer essa roda girar, mas o principal objetivo do grupo era fazer todos os novatos conseguirem um emprego na área e crescerem: coisa que aconteceu e me dá muito orgulho. Estão todos empregados, sempre com notícias corriqueiras e cheio de tarefas, rs. Consequentemente, estamos todos sem tempo para escrever, hahah. Eu até conseguiria dedicar algumas horas do dia para escrever uma vez ou outra, mas me distanciei demais do PHP e já não consigo tirar a mesma quantidade de certezas que eu conseguia anteriormente. Aliás, já mudaram tanta coisa nas versões mais recentes do PHP que imagino que os problemas que eu conhecia dessa linguagem já não existam mais.

Enfim, a quem quer que ainda esteja por aqui, um muitíssimo obrigado por sempre visitar. Deixa um comentário, eu faço questão de responder! E, caso precise de ajuda sobre algo que não está no blog, fica a vontade de entrar no nosso Discord para perguntar, ok? O link é esse: https://discord.com/invite/V9crjS9jft .

PS.: isso segue não sendo um adeus. Mas com esse post, eu deixo claro que meu blog é meu e o conteúdo nem sempre vai ser sobre PHP, rs. Abs!

Inté!

Olá, leitores do CodeAspiras!

Quem participa do nosso canal no Discord sabe que, de tempos em tempos, nós lançamos alguns desafios de programação no canal #desafios. Alguns são bem simples, outros meio complexos. Eu vou destrinchar o que foi mais famoso até então por aqui pra disseminar conhecimento. Se você gostar e quiser buscar mais desafios, é só chegar junto no Discord e ir fazendo o que estiver por lá.

Ah, um detalhe antes de começar: esse é o desafio simplificado. O original exige um pouco mais de conhecimento, como leitura/escrita em arquivo, decodificar/encodar JSON, etc. Como ainda tem muito estudante no começo ainda, decidi retirar esses obstáculos e deixar o desafio mais simples, gerando o que verá a seguir.

O desafio

Faça um programa que inicializa algumas variáveis de um quiz, faz as perguntas para colher as respostas e imprime o resultado.

Obs.: não está sendo determinado como seu programa deve funcionar!

Impressão esperada no terminal

Pergunta 1: Essa seria a primeira pergunta...?
Opção 1: Sim...?
Opção 2: Não....?
Resposta: 1
--
Pergunta 2: Essa seria a terceira pergunta...?
Opção 1: Sim...?
Opção 2: Não....?
Resposta: 1
--
Resultado: você acertou 1 de 2 perguntas!!

E é isso, não tem mais nenhuma descrição. A ideia é que seu programa inicie já imprimindo:

Pergunta 1: Essa seria a primeira pergunta...?
Opção 1: Sim...?
Opção 2: Não....?
Resposta:

E aguarde o usuário responder. Daí o usuário responde 1, que é a resposta correta.

Então seu programa continuará o processo, imprimindo uma separação e a próxima pergunta:

--
Pergunta 2: Essa seria a terceira pergunta...?
Opção 1: Sim...?
Opção 2: Não....?
Resposta:

E aí, mais uma vez, irá aguardar o usuário responder. Respondendo 1, que é a resposta errada, o programa deverá então finalizar e imprimir uma separação e o resultado, informando que acertei apenas uma das duas perguntas:

--
Resultado: você acertou 1 de 2 perguntas!!

As únicas entradas do usuário são as respostas, que são números.

Sacou? Quer tentar desenvolver uma solução aí antes de continuar lendo?

Se for tentar, aprecie esse gif e só role a tela quando terminar!

A solução (em Golang)

A maior dificuldade que as pessoas tem ao tentar solucionar desafios como esse é dar o primeiro passo. É como se você estivesse dirigindo um carro bem velho, dando partida no meio de uma ladeira. Se você tentou pensar em alguma coisa e não conseguiu, espero que possa absorver um pouco da técnica que vou te passar agora, que é infalível para construção de linhas de raciocínio.

Essa técnica se chama Baby Steps, que significa Passos de Bebê, em inglês. A ideia é que, ao invés de tentar montar, na sua cabeça, toda uma história de "começo, meio e fim", você deveria dar um passo de cada vez. Conforme você se torna experiente, será capaz de montar a história inteira na mente antes de colocar a mão na massa, mas enquanto não chega lá, não faz mal algum dar pequenos passos de bebê.

Nesse caso, eu já dei uma ajudinha ali em cima descrevendo que o desafio não está determinando como deve ficar seu código e exibindo, passo-a-passo, como as coisas devem aparecer no terminal.

Nesse caso, você pode simplemente copiar tudo o que foi impresso no exemplo e... imprimir, Kiko?

Sim! Exatamente! Supondo que você ainda está aprendendo a fazer códigos em Golang, vamos por parte:

1 - Imprimindo todos os textos

package main

import "fmt"

func main() {
    // Pergunta 1
    fmt.Println("Pergunta 1: Essa seria a primeira pergunta...?")
    fmt.Println("Opção 1: Sim...?")
    fmt.Println("Opção 2: Não....?")
    fmt.Print("Resposta: ")
    // ler resposta
    fmt.Println("") // retirar essa quebra de linha temporaria
    fmt.Println("--")

    // Pergunta 2
    fmt.Println("Pergunta 2: Essa seria a terceira pergunta...?")
    fmt.Println("Opção 1: Sim...?")
    fmt.Println("Opção 2: Não....?")
    fmt.Print("Resposta: ")
    // ler resposta
    fmt.Println("") // retirar essa quebra de linha temporaria
    fmt.Println("--")

    // Conclusão
    fmt.Println("Resultado: você acertou 1 de 2 perguntas!!")
}

Veja o código no Playground: https://go.dev/play/p/HBrbJPnV_SY

O código acima irá imprimir:

Pergunta 1: Essa seria a primeira pergunta...?
Opção 1: Sim...?
Opção 2: Não....?
Resposta: 
--
Pergunta 2: Essa seria a terceira pergunta...?
Opção 1: Sim...?
Opção 2: Não....?
Resposta: 
--
Resultado: você acertou 1 de 2 perguntas!!

Nesse momento, nós já estamos fazendo 90% do que foi pedido no desafio, concorda? Falta, literalmente, ler dois números. Caso não saiba como ler a entrada do terminal, basta pesquisar <linguagem> scanf e você vai achar alguns bons artigos explicando como fazer. Note que é importante ler mais do que um site pra tirar alguma conclusão, hein?

2 - Lendo respostas

No caso do nosso desafio, eu poderia usar o pacote bufio, que nos permite ter mais controle sobre qual stream de entrada estamos utilizando e tal, mas, para simplificar, quero utilizar a função Scanln do pacote fmt. É similar ao scanf de algumas outras linguagens por aí. Quer ver?

PS.:daqui para baixo\, para rodar o programa, precisará criar o arquivo localmente e rodando na mão. Pra fazer isso,* [baixe o Golang](https://go.dev/doc/install), instale, depois crie uma pasta em qualquer lugar, abra essa pasta pelo terminal e digitego mod init quizsimp. Daí crie o arquivomain.goe cole o código nesse arquivo. Para executar, rode:*go run .

package main

import "fmt"

func main() {
    var resposta string

    // Pergunta 1
    fmt.Println("Pergunta 1: Essa seria a primeira pergunta...?")
    fmt.Println("Opção 1: Sim...?")
    fmt.Println("Opção 2: Não....?")

    // Resposta 1
    fmt.Print("Resposta: ")
    if _, err := fmt.Scanln(&resposta); err != nil {
        fmt.Printf("Um erro aconteceu ao ler a resposta: %s\n", err)
        return
    }

    fmt.Println("--")

    // Pergunta 2
    fmt.Println("Pergunta 2: Essa seria a terceira pergunta...?")
    fmt.Println("Opção 1: Sim...?")
    fmt.Println("Opção 2: Não....?")

    // Resposta 2
    fmt.Print("Resposta: ")
    if _, err := fmt.Scanln(&resposta); err != nil {
        fmt.Printf("Um erro aconteceu ao ler a resposta: %s\n", err)
        return
    }

    fmt.Println("--")

    // Conclusão
    fmt.Println("Resultado: você acertou 1 de 2 perguntas!!")
}

3 - Contabilizando acertos

Agora você está armazenando a resposta do usuário na nova variável resposta, certo? Só que não estamos fazendo nada com isso!! Que tal adicionarmos uma outra variável acertos que contabiliza quantas respostas foram certas?

Além disso, podemos mudar a impressão de resultados de Println para Printf e formatar o texto, injetando o número de acertos:

package main

import "fmt"

func main() {
    var resposta string
    acertos := 0

    // Pergunta 1
    fmt.Println("Pergunta 1: Essa seria a primeira pergunta...?")
    fmt.Println("Opção 1: Sim...?")
    fmt.Println("Opção 2: Não....?")

    // Resposta 1
    fmt.Print("Resposta: ")
    if _, err := fmt.Scanln(&resposta); err != nil {
        fmt.Printf("Um erro aconteceu ao ler a resposta: %s\n", err)
        return
    }

    if resposta == "1" {
        acertos++
    }

    fmt.Println("--")

    // Pergunta 2
    fmt.Println("Pergunta 2: Essa seria a terceira pergunta...?")
    fmt.Println("Opção 1: Sim...?")
    fmt.Println("Opção 2: Não....?")

    // Resposta 2
    fmt.Print("Resposta: ")
    if _, err := fmt.Scanln(&resposta); err != nil {
        fmt.Printf("Um erro aconteceu ao ler a resposta: %s\n", err)
        return
    }

    if resposta == "2" {
        acertos++
    }

    fmt.Println("--")

    // Conclusão
    fmt.Printf("Resultado: você acertou %d de 2 perguntas!!\n", acertos)
}

E pronto! Solucionamos o desafio............... Certo?

A verdade é que estamos gerando a mesma saída esperada que coloquei no começo desse desafio. Então, sim, solucionamos, porém não está nada elegante. Se quisermos fazer um Quiz com 100 perguntas, esse código ficaria gigantesco!

Nós podemos separar um pouco as responsabilidades aqui: que tal agruparmos todos os dados de cada pergunta em uma estrutura, deixando, então, o trecho de impressão/leitura fica responsável apenas por isso mesmo, simplificando os deveres?

4 - Organizando dados em estruturas

E o que teria nessa estrutura de pergunta, Kiko?

Bem... A pergunta em si, as opções e a resposta esperada (vulgo gabarito). Seria algo assim:

type QuizItem struct {
    Question string
    Options map[string]string
    RightOptionIndex string
}

E poderíamos organizar a primeira pergunta assim:

QuizItem{
    Question: "Essa seria a primeira pergunta...?",
    Options: map[string]string{
        "1": "Sim...?",
        "2": "Não....?",
    },
    RightOptionIndex: "1",
}

E, com isso, teríamos quase todas as informações para imprimir tudo, concorda?

Como assim, quase todas, Kiko?

É que falta sabermos qual é o número dessa pergunta. Como a ideia é termos uma lista de perguntas, teremos essa informação de outro lugar. Enfim, vamos transformar o código:

package main

import "fmt"

type QuizItem struct {
    Question         string
    Options          map[string]string
    RightOptionIndex string
}

func main() {
    // prepara o quiz
    quiz := []QuizItem{
        {
            Question: "Essa seria a primeira pergunta...?",
            Options: map[string]string{
                "1": "Sim...?",
                "2": "Não....?",
            },
            RightOptionIndex: "1",
        },
        {
            Question: "Essa seria a terceira pergunta...?",
            Options: map[string]string{
                "1": "Sim...?",
                "2": "Não....?",
            },
            RightOptionIndex: "2",
        },
    }

    // executa o quiz
    acertos := 0
    for index, item := range quiz {
        // número da pergunta vem do index+1 !
        fmt.Printf("Pergunta %d: %s\n", index+1, item.Question)

        for num, opt := range item.Options {
            fmt.Printf("Opção %s: %s\n", num, opt)
        }

        fmt.Print("Resposta: ")
        var resposta string
        if _, err := fmt.Scanln(&resposta); err != nil {
            fmt.Printf("Um erro aconteceu ao ler a resposta: %s\n", err)
            return
        }

        if resposta == item.RightOptionIndex {
            acertos++
        }

        fmt.Println("--")
    }

    // Conclusão
    fmt.Printf("Resultado: você acertou %d de 2 perguntas!!\n", acertos)
}

E podemos ir ainda além!! E se quisermos exibir o resultado em forma de gabarito? Bem, só faz sentido se você puder distinguir as opções corretas das erradas, concorda? E pra isso você pode usar símbolos e tal, mas eu prefiro COLORIR.

5 - Exibindo gabarito após resultado

Oi?! Dá pra colorir texto no terminal, Kiko?

Sim, dá! E para isso é só usarmos um comando que altera as propriedades de texto do terminal. Eu não sei exatamente qual é o nome disso, até tentei pesquisar mas parece que cada pessoa chama do jeito que quer, então não me ajudou muito, rs. Então vamos chamar do nosso jeito também! E deixo isso aberto para que alguém me corrija publicamente a vontade, hehe.

Eu chamo esse comando de Editor de Fonte. Ele funciona como uma tag HTML, tendo um comando no início de onde você quer trocar a fonte e outro no final. Em algumas linguagens, você pode acessar esse escape pela inicial \e, mas em Golang nós acessamos pela inicial \033:

• Começa com: \033[<nums>m

• Termina com: \033[0m

Nesse caso, a ideia é que, no lugar de <nums>, você coloque os números que vão definir o estilo de fonte a utilizar no trecho seguinte. Depois que acabar de imprimir o texto no estilo desejado, você reseta o estilo novamente com \033[0m. Sim, 0 é um dos possíveis códigos a se colocar no lugar de <nums>. E quando utilizamos mais de um código, nós separamos eles com ponto-e-vírgula (;).

Eu não vou colocar nenhuma tabela dos possíveis estilos aqui, mas o que nos interessa no momento:

• cor vermelha: 31;

• cor verde: 32.

Então, se você quiser imprimir uma linha vermelha, é só imprimir:

fmt.Println("\033[31mEsse é o estilo com a cor vermelha\033[0m")

Dito isso, podemos fazer três constantes com as cores e uma função para fazer essa impressão formatada, o que acha?

const (
    COLOR_RED = "31"
    COLOR_GREEN = "32"
)

func printStyled(text string, styles ...string) {
    fmt.Println("\033[" + strings.Join(styles, ";") + "m" + text + "\033[0m")
}

Assim, é só chamar:

printStyled("Opção 1: ...", COLOR_GREEN) // para opções corretas
printStyled("Opção 2: ...", COLOR_RED) // para opções marcadas incorretamente

Mas ainda não estamos prontos, pois... Não salvamos nenhuma resposta do usuário.

Então vamos adicionar uma nova informação no QuizItem: Answer string, além de mudar o slice []QuizItem para []*QuizItem para usarmos sempre as mesmas referências, alterando e salvando as respostas na própria estrutura:

package main

import (
    "fmt"
)

type QuizItem struct {
    Question         string
    Options          map[string]string
    RightOptionIndex string
    Answer           string
}

func main() {
    // prepara o quiz
    quiz := []*QuizItem{
        {
            Question: "Essa seria a primeira pergunta...?",
            Options: map[string]string{
                "1": "Sim...?",
                "2": "Não....?",
            },
            RightOptionIndex: "1",
        },
        {
            Question: "Essa seria a terceira pergunta...?",
            Options: map[string]string{
                "1": "Sim...?",
                "2": "Não....?",
            },
            RightOptionIndex: "2",
        },
    }

    // executa o quiz
    acertos := 0
    for index, item := range quiz {
        fmt.Printf("Pergunta %d: %s\n", index+1, item.Question)

        for num, opt := range item.Options {
            fmt.Printf("Opção %s: %s\n", num, opt)
        }

        fmt.Print("Resposta: ")
        if _, err := fmt.Scanln(&item.Answer); err != nil {
            fmt.Printf("Um erro aconteceu ao ler a resposta: %s\n", err)
            return
        }

        if item.Answer == item.RightOptionIndex {
            acertos++
        }

        fmt.Println("--")
    }

    // Conclusão
    fmt.Printf("Resultado: você acertou %d de 2 perguntas!!\n", acertos)
}

E agora, podemos fazer um novo loop nas perguntas, colorindo as respostas corretas e erradas!!

package main

import (
    "fmt"
    "strings"
)

const (
    COLOR_RED    = "31"
    COLOR_GREEN  = "32"
)

type QuizItem struct {
    Question         string
    Options          map[string]string
    RightOptionIndex string
    Answer           string
}

func printStyled(text string, styles ...string) {
    fmt.Print("\033[" + strings.Join(styles, ";") + "m" + text + "\033[0m")
}

func main() {
    // prepara o quiz
    quiz := []*QuizItem{
        {
            Question: "Essa seria a primeira pergunta...?",
            Options: map[string]string{
                "1": "Sim...?",
                "2": "Não....?",
            },
            RightOptionIndex: "1",
        },
        {
            Question: "Essa seria a terceira pergunta...?",
            Options: map[string]string{
                "1": "Sim...?",
                "2": "Não....?",
            },
            RightOptionIndex: "2",
        },
    }

    // executa o quiz
    acertos := 0
    for index, item := range quiz {
        fmt.Printf("Pergunta %d: %s\n", index+1, item.Question)

        for num, opt := range item.Options {
            fmt.Printf("Opção %s: %s\n", num, opt)
        }

        fmt.Print("Resposta: ")
        if _, err := fmt.Scanln(&item.Answer); err != nil {
            fmt.Printf("Um erro aconteceu ao ler a resposta: %s\n", err)
            return
        }

        if item.Answer == item.RightOptionIndex {
            acertos++
        }

        fmt.Println("--")
    }

    // gabarito
    fmt.Println("Gabarito:")
    for index, item := range quiz {
        fmt.Printf("Pergunta %d: %s\n", index+1, item.Question)

        for num, opt := range item.Options {
            label := fmt.Sprintf("Opção %s: %s", num, opt)
            if num == item.RightOptionIndex {
                printStyled(label, COLOR_GREEN)
            } else if num == item.Answer {
                printStyled(label, COLOR_RED)
            } else {
                fmt.Print(label)
            }

            fmt.Println("")
        }

        fmt.Println("--")
    }

    // Conclusão
    fmt.Printf("Resultado: você acertou %d de 2 perguntas!!\n", acertos)
}

Conclusão

Nesse desafio, nós fizemos um código estritamente imperativo, mas poderíamos evoluir ainda mais. Por exemplo, eu fiz minha versão do desafio com Bubbletea, sendo o desafio completo (lendo arquivos). Enfim, essa é uma excelente atividade para iniciantes! Vocês aprendem a colocar em prática várias coisas de uma vez só. Além disso, você pode brincar com seus colegas fazendo perguntas reais nos programas finais! E se puder aceitar múltiplas respostas? E se for um Quiz de scoring ao invés de gabarito? No scoring, não existe opção errada, apenas pontuações. No final, o total de pontuação do usuário varia pelas opções marcadas, encaixando ele em algum grupo de pontuações esperadas. O que acha de desenrolar esse desafio?

E por hoje é só! Curtiu? Comenta e compartilha!! Como falei no início, temos outros desafios lá no canal do Discord. Pode chegar que a casa é aberta, rs. Qualquer coisa, é só falar aí nos comentários!

Abraços...

Inté!

Olá, leitores do CodeAspiras!

Estava aqui revisando os vídeos do nosso canal no YouTube e me deparei com o refinamento onde falamos sobre DTOs, estrutura que mencionei em um artigo de Golang anteriormente nesse blog. Esse vídeo traz outros exemplos sobre como usar DTO e quais suas limitações. Por isso, vou indicar o vídeo por aqui, beleza?!

A curtida no vídeo é opcional (não está público mesmo), mas no blog é lei, hein?!

Assim como esse, temos outros refinamentos ocultos em nosso canal no YouTube. Você pode acessar todos eles pelo nosso Discord! No canal #log, fica o registro de todos os refinamentos que fizemos, materiais trabalhados, link do vídeo, etc. Fique a vontade para explorar lá ;)

Curtiu?! Comenta e compartilha! O que acha de divulgarmos mais vídeos dos refinamentos que fazíamos pelo Discord? E se voltássemos a fazer os refinamentos? Deixa aí sua opinião... Abraço!

Inté!!

Olá, leitores do CodeAspiras! Tudo bem por aí?

Estamos de volta com mais um artigo sobre Golang, dessa vez falando sobre tratativa de erros e explicando mais um conceito relevante pra quem está começando a trabalhar nessa linguagem.

Primeiramente, gostaria de destacar o fato de que muitas pessoas odeiam os fluxos de erro do Golang, porque ficam com a sensação de que somos obrigados a criar diversas operações de condição para tratativas de erro.

É comum ficar puto por isso aqui, oh:

_, err := algumacoisa()
if err != nil {
    return nil, err
}

Esse é um padrão que se repete bastante em todo o fluxo do seu código. É praticamente certo dizer que, quanto mais funções você desenvolve, mais checagens de erro você precisará injetar.

O jeito errado

Ah, Kiko, eu burlei isso. Eu decidi lançar panic e tratar com recover().

Por favor, NÃO FAÇA ISSO. Você só deve lançar panic em cenários que deveriam ser impossíveis de acontecer. Além disso, assumir que todos os trechos de código que chamarem sua função vão estar preparados para tratar panic como fluxo de erros comuns, definitivamente, não é uma boa forma de manter a qualidade do seu código em dia.

Infelizmente, o certo é aprender a lidar com os erros. É até filosófico colocar a frase desse jeito, né? A ideia é que você se acostume com o fato de que, sim, seu código vai falhar. Algumas falhas serão esperadas na regra de negócio, outras não.

Por exemplo, erros de validação são sempre falhas esperadas, se não você nem validaria, sabe? Erros de conexão ao banco de dados também são esperados, afinal, toda e qualquer transmissão de dados está exposta à falhas temporárias. Isso não é motivo para gerar um panic. Falhas de parsing também são esperadas - isso é, inclusive, uma forma de validação de dados. No geral, é pouco provável que você precise declarar qualquer sentença explícita de panic.

Ainda assim, é uma boa prática ter tratativas de panic com recover() na camada mais "alta" da aplicação. Por exemplo, em caso de servidores web, você pode fazer com que todas as suas rotas usem um middleware de recuperação de panic. E é um middleware bem simples:

defer func() {
    panicError := recover()
    if panicError == nil {
        return
    }

    // trata o panicError, enviando algum log ou sei lá o quê, mas impedindo o servidor de parar de funcionar
    // também deve encerrar a conexão da requisição, mandando algum status do que aconteceu para quem a enviou
}()
// suponha que a variável "next" segue a implementação de http.HandlerFunc: https://pkg.go.dev/net/http#HandlerFunc
// w é http.ResponseWriter
// r é *http.Request
next.ServeHTTP(w, r)

Se acontecer um panic durante a execução do handler, o código acionado no defer irá impedir que o processo do servidor seja encerrado, garantindo que falhas inesperadas não matem o serviço.

Já no caso de comandos CLI, que você roda no terminal e só executa uma tarefa, não faz sentido colocar tratativa de panic. Deixa o problema estourar e veja o que aparece no terminal... A menos, é claro, que seu terminal esteja programado para fechar automaticamente. Aí sim, você pode fazer uma tratativa de recover() pedindo para o usuário digitar algo para continuar antes de encerrar o código.

O jeito certo

Voltando aos erros, o certo é sempre transferir os erros até a camada "mais alta", sempre. Claro, se sua intenção não for interromper o fluxo, você pode só enviar um log de erro e continuar o fluxo normalmente sem nenhum return. A ideia é que você jamais ignore um cenário de erro. E aí, quando esse bendito erro respingar no handler da requisição ou no fluxo principal da aplicação, você pode verificar qual erro que aconteceu e tomar uma decisão adequada para tal.

package main

import "errors"

func vaiDarRuim() error {
    return errors.New("deu ruim")
}

func vouTentar() error {
    // isso aqui é meramente ilustrativo
    // na prática, eu teria colocado um "return vaiDarRuim()" direto
    err := vaiDarRuim()
    if err != nil {
        return err
    }

    return nil
}

func main() {
    err := vouTentar()
    if err != nil {
        // deu ruim, faz alguma coisa, loga, sei lá, reaja
        return
    }

    // deu bom, uhu
}

Mas se você cria um erro durante o fluxo do código, como você faz para detectar qual foi o erro? Bem, uma forma é verificar o texto:

switch(err.Error()) {
case "deu ruim":
     // trata o cenário "deu ruim"
default:
     // trata um cenário imprevisto
}

Porém isso não é recomendado, pois nada impede que dois erros de contextos diferentes tenham exatamente o mesmo texto, correto? Então não faz sentido analisar a mensagem de erro em si, mas a instância.

E nesse caso, para comparar instâncias significa que você precisa ter isso centralizado em um lugar: um pacote de erros. Independente se você prefere definir structs distintas de erro, inicializar erros com errors.New() ou fmt.Errorf(), o fato é que seus erros precisam ficar em um pacote sem referências a outras partes do projeto. Isso é sério, se você referenciar qualquer outro pacote da aplicação, você pode gerar um problema de importação cíclica.

package errs

import "errors"

var (
    ErrDeuRuim = errors.New("deu ruim")
)

Com essa variável, agora poderíamos mudar a função vaiDarRuim para:

func vaiDarRuim() error {
    return errs.ErrDeuRuim
}

E a tratativa de erros para:

switch(err) {
case errs.ErrDeuRuim:
    // agora sim, deu ruim mesmo
default:
    //...
}

Conclusão

Depois de passar um tempo implementando esse pacote em vários projetos, comecei a sentir uma maior facilidade em várias coisas. Por exemplo, se alguém pergunta "qual a lista de possíveis erros da aplicação?", eu consigo rapidamente checar tudo em um pacote só. Obviamente, o erro daqui não demonstra muita coisa, afinal, a frase era uma string fixa, então não é muito difícil de migrar casos como esse. Os erros mais complexos de se transferir para o pacote foram os que tinham alguma injeção de valor no texto. E aí, ao invés de ter uma variável fixa de erro, eu tive de fazer uma struct implementando a interface error. Logo, na hora de analisar se o erro era o mesmo dessa struct, eu tinha de fazer a validação por casting:

if errCast, castable := err.(errs.ErrViaStruct); castable {
    // é o erro da struct errs.ErrViaStruct{}
}

O pacote errors até provê algumas funções como errors.Is() e errors.As(), mas não sinto muita segurança em utilizá-las, pois cada pacote que importo trata seus erros de forma diferente e essas funções não funcionam para todas as maneiras de lidar com erros.

E o mais importante é apenas criar tratativas especiais, não necessariamente identificar todos os erros possíveis em um switch-case só. Então a grande maioria dos erros que preciso tratar são de variáveis fixas. Vale a pena a implementação.

Indicação de leitura

• Creating Custom Errors in Go (Digital Ocean);

• Error handling in Go: Best practices (Raphael Ugwu via LogRocket).

E é isso aí! Curtiu? Comenta e compartilha! Está sentindo falta de algum artigo de uma linguagem específica? É só pedir que, se eu souber, eu escrevo alguma coisa, rs. Quero ver, hein? Abraço!

Inté!

Nota: esse artigo foi publicado primeiramente no blog.codeaspiras.dev, que foi encerrado. Transferi para esse blog para que o mesmo não se perdesse.

Olá, leitores do CodeAspiras! Tudo tranquilo por aí?

Conforme prometido, segue um artigo que não seja de Golang! Sinceramente, eu quase publiquei um, mas lembrei da nossa promessa e resolvi mantê-lo em rascunho, rs. Então refleti sobre possíveis assuntos que poderia trazer a tona aqui no blog e lembrei de uma discussão que tive recentemente com um amigo, Wendel, sobre um projeto que ele estava desenvolvendo baseado em uma planilha do Google. No geral, esse artigo não é uma resposta a ele, pois nós encerramos a conversa no mesmo dia. Ainda assim, é um conhecimento que acredito ser interessante para outros iniciantes, pois pode trazer boa noção sobre responsabilidades de projetos front-end versus back-end. Vamos começar?

Premissa

Suponha que você tem uma planilha de gestão de custos de uma organização pública e quer prover mais transparência sobre essas informações para os interessados nesse assunto.

Você pode:

• compartilhar a planilha com a permissão restrita de leitura;

• fazer um site para expor esses dados:

  • migrando tudo para um banco de dados, ou;

  • fazendo o site ler o contéudo da própria planilha.

Prover acesso à planilha é, sem dúvida, a decisão mais rápida. Porém, pode ser que você coloque informações com nomenclaturas que os usuários comuns não compreendam. Por exemplo, dados com termos em inglês podem gerar barreiras de linguagem no entendimento da leitura da planilha.

Fazer um site e migrar todas as informações para um banco de dados seria a decisão mais demorada. E, aliás, pode ser até desnecessária caso não tenham a intenção de incluir mais "planilhas" ou "páginas de planilha" nesse site (banco de uma tabela só). Então, fica a pergunta: é possível usar a planilha do Google como banco de dados e importar os dados de lá?

SIM, É POSSÍVEL. Mas não é recomendado que você faça isso diretamente do seu front-end. Tudo o que você coloca no código do projeto front-end acabará sendo exposto na rede, de alguma forma. Então, se você colocar suas credenciais (leia-se token) de Google APIs para acessar a planilha diretamente lá, não estranhe se coisas estranhas começarem a aparecer em sua conta. Isso é, basicamente, um prato cheio para hackers tentarem todo tipo de malícia com suas credenciais, rs. O ideal é que, sempre que quiser acessar algum conteúdo com credenciais, crie uma rota em um servidor back-end para fazer essa requisição por você.

Jamais exponha credenciais no front-end

Salvo algumas raríssimas exceções, como, por exemplo, credenciais que servem para identificar a build do seu front-end para usar como autenticação na comunicação com o back-end. Disso, não tem como fugir, não é mesmo? E, mesmo assim, você não usará um token fixo. Vai ser a combinação de alguns fatores e recursos, como Cookies, Local Storage, SQLite, dados do navegador, etc.

E sobre esse projeto do exemplo, como são dados públicos, sinceramente, não acho que faz sentido criar uma barreira de credenciais entre o front-end e o back-end. O máximo que vai acontecer é que outros desenvolvedores vão poder enviar requisições diretamente ao seu back-end para acessar os dados da planilha. Se os dados são para dar transparência, então, qual o problema? Se não fosse esse cenário, aí sim seria um elemento obrigatório a se desenvolver também.

Resultado

title Planilha do Google como Banco de Dados



actor Usuário



Usuário->Front: GET /planilha-de-custo

note over Front: renderiza o HTML estático

Front->Usuário: mostra página padrão com\n efeito de "carregando..."

note over Front: prepara uma requisição para\n obter os dados da planilha

Front->Back: GET /api/v1/spreadsheet

note over Back: prepara as credenciais de Google APIs

Back->GoogleAPIs: GET https://sheets.googleapis.com/v4/spreadsheets/{SPREADSHEET_ID}/values/{page}!{range}

note over GoogleAPIs: processa a requisição

GoogleAPIs->Back: retorna os dados

Back->Front: retorna os dados obtidos do GoogleAPIs

note over Front: renderiza os dados de acordo com o público-alvo

Front->Usuário: mostra a página final

A depender da linguagem que você vai utilizar no back-end, você pode ter uma biblioteca do Google APIs para facilitar a construção da requisição. Dá uma olhada na documentação:

• usando Google Client: https://developers.google.com/sheets/api/guides/values?hl=pt-br#read

• implementando a requisição manualmente: https://developers.google.com/sheets/api/samples/reading?hl=pt-br#single-range

E é isso. Você pode até melhorar essa arquitetura implementando algum esquema de cache para evitar excesso de requisições para os servidores da Google (eles não gostam nada disso). E o melhor de tudo: se o projeto evoluir e precisar armazenar mais recursos, você já teria meio caminho andado para migrar para banco de dados.

EDIT:

Recebi de um amigo de longa data, Nahum Sá, uma informação que complementa essa postagem com um caso de uso real que fizeram no projeto levels.fyi usando uma planilha do Google como banco de dados, provendo dados para milhões de usuários usando essa logística. No artigo do blog deles, mencionam que não desenvolveram back-end pois utilizaram um recurso serverless da Amazon, o AWS Lambda. Na arquitetura deles, o Lambda faz o mesmíssimo papel que descrevi no diagrama sequencial desse artigo, com o objetivo de não expor credenciais do Google APIs. Além disso, por ser um recurso da AWS, provavelmente trouxe já outros critérios de segurança, como a identificação de build de front-end que mencionei anteriormente também. Vale muito a pena a leitura para expandir seus horizontes e ver o que é possível de ser feito com muita performance como Menor Produto Viável (MVP), onde vocês podem fazer experimentos a baixo custo.

É claro que "baixo custo" é algo relativo. Para eles, sustentar invocações de Lambdas é baixo custo. Para desenvolvedores solitários que querem só rodar alguns experimentos com uma quantidade menor de usuários, pode ser caro. Tudo é relativo na hora de analisar quantos recursos você tem a sua disposição na construção da arquitetura, mas sempre haverá uma forma de montar alguma coisa. Enfim, é isso, um conteúdo extremamente relevante para o tópico deste artigo, espero que dê tempo de alguém ler, rs. E mais uma vez, obrigado, Nahum!!

Fonte do artigo: https://www.levels.fyi/blog/scaling-to-millions-with-google-sheets.html (em inglês)

Curtiu?! Comenta e compartilha!! Você já tinha parado pra pensar na arquitetura dos projetos on-line como agora? Acha que devo enviar mais artigos como esse, discutindo e refinando ideias e abordando assuntos como cybersec? Deixa seus pensamentos aí nos comentários e até a próxima!

Inté!!

Olá, leitores do CodeAspiras! Prometo que depois desse artigo eu vou escrever qualquer outra coisa que não seja Golang, beleza? É que, no momento, todo o meu foco está nessa linguagem de programação e, por isso, está mais fácil escrever sobre ela.

Dessa vez, trago mais um assunto bem relevante pra quem está começando a desenvolver nessa linguagem, principalmente se você ainda não criou o hábito de escrever interfaces. Vamos começar?

Interfaces

Antes de mais nada, é preciso entender que interfaces são contratos. Elas não tem nenhum código atrelado a elas diretamente, apenas dizem: "o que quer que esteja implementando isso aqui, está de acordo com as assinaturas desta interface".

Diferente de outras linguagens, Golang não tem o conceito de classe da Orientação a Objeto. Isso por si só já foi motivo de ódio de muitos, mas calma. Na realidade, isso expandiu as possibilidades do que você pode fazer. Ao invés de ser obrigado a anunciar quais interfaces suas structs implementam, basta que as structs implementem as funções da assinatura das interfaces que, automaticamente, já será interpretada como implementação.

QUÊ?!

Calma, calma, calma... Vamos comparar para entender melhor.

Interfaces em PHP

Se você cria, no PHP, uma interface cuja assinatura declara que suas implementações possuem uma função chamada Ping() que retorna uma string, toda classe que implementar essa interface deverá ter essa função:

interface PingableInterface {
    public function Ping(): string;
}

class Pingable implements PingableInterface {
    public function Ping(): string {
        return "pong";
    }
}

Porém, se você fizer uma classe com a mesma função sem declarar na hierarquia que a mesma está implementado a interface, o interpretador entenderá que não implementa a assinatura:

interface PingableInterface {
    public function Ping(): string;
}

class Pingable implements PingableInterface {
    public function Ping(): string {
        return "pong";
    }
}

class Pingable2 {
    public function Ping(): string {
        return "pong";
    }
}

var_dump(is_a(new Pingable(), 'PingableInterface')); // true
var_dump(is_a(new Pingable2(), 'PingableInterface')); // false - é exatamente o mesmo código do Pingable, só que sem a declaração "implements PingableInterface"

Experimente o código: https://onlinephp.io/c/38b0a

Interfaces em Golang

Aqui, isso não acontece, dado que nem existe opção para você declarar que uma "struct implementa uma interface". As implementações são dinâmicas, então basta que sua struct esteja de acordo com a assinatura das interfaces para que o interpretador aceite-a como implementação.

package main

import "fmt"

type PingableInterface interface {
    Ping() string
}

type Pingable struct{} // não tem nada como "implements PingableInterface"

func (p Pingable) Ping() string {
    return "pong"
}

func main() {
    var pingable interface{} = Pingable{}
    if _, is := pingable.(PingableInterface); is { // equivalente ao is_a() do PHP
        fmt.Println("implements PingableInterface")
    } else {
        fmt.Println("does not implement PingableInterface")
    }
}

Experimente o código: https://go.dev/play/p/GKHEC6bd-CT

E com isso, você consegue criar structs que implementam interfaces de terceiros e vice-versa. Mesmo se a interface for algo interno de alguma biblioteca importada, basta que os pacotes se comuniquem por interfaces ao invés de implementações. É isso que é um "pacote adaptável": é um pacote onde todas as chamadas públicas são tratadas por interfaces. Eu usei o termo "adaptável" aqui derivando do Design Pattern "Adapter". Recomendo a leitura!

Escrevendo um pacote regido por interfaces

Uma forma simples de atingir esse objetivo é seguir as seguintes regrinhas:

1. Se vai expor alguma coisa, tem de estar em uma interface;

2. Toda implementação real tem de ser privada, restrita ao pacote.

No Golang, tudo que começa com letra maiúscula é público, ou seja, toda nomenclatura que você escreve é case sensitive (a caixa alta/baixa importa). Então é considerado uma boa prática escrever a interface com letra inicial maiúscula e a sua implementação usando o mesmo nome, mas com letra inicial minúscula.

package exping

type Pingable interface {
    Ping() string
}

type pingable struct {}
func (p *pingable) Ping() string {
    return "pong"
}

Assim, quando você fizer uma função de inicialização, essa função deverá declarar que retorna a interface. Mas, na prática, retorna sua implementação privada:

package exping

func NewPingable() Pingable {
    return &pingable{}
}

E em todo lugar que você precisar dessa implementação, você sempre irá referenciar pela interface, nunca pela struct:

package expong

func HandlePing(p exping.Pingable) {
    // ...
    p.Ping()
}

O que eu ganho com isso, Kiko?

Bem... Quando você for escrever testes unitários, você poderá mockar a interface (usando mockery ou qualquer outra coisa, você pode até escrever a implementação de mock na mão, se quiser). Se o que estiver desenvolvendo for uma biblioteca, você estará permitindo que seus consumidores possam injetar implementações próprias ao invés de usar o que você fez... Por ser interface, você também pode passar dados nulos e criar um fluxo mais flexível, coisa que não seria possível ao passar uma struct sem referência. Isso também permite que você faça cast para outras interfaces.

Enfim, tem muitos usos para isso. No geral, eu gosto de pensar que isso torna o código um pouco mais seguro e dá mais possibilidades do que podemos fazer posteriormente. E é por isso que eu acredito que esse seja um conhecimento relevante para novatos da linguagem.

Ah, Kiko, então só vale a pena fazer interfaces em Golang?

De jeito nenhum! Interfaces são contratos. Ao anunciar qual estrutura sua implementação irá seguir, fica mais fácil para todos de entender como o código irá se comportar. Então, sempre que uma linguagem der suporte para interfaces, dê um jeito de aprender a usar!

E por hoje é só! Curtiu? Comenta e compartilha! Lembrando que ainda temos muitas vagas para colaboradores do blog. Sinta-se a vontade para entrar em contato e começar a mandar suas publicações. Sua conta irá aparecer como autor(a) e você aparecerá na página de membros do blog. Isso é um incentivo para que cada um possa fazer sua parte de girar a roda da comunidade, ok?

E eu vou indo nessa. Abraço!

Inté!

Olá, leitores do CodeAspiras! Estou aqui novamente com mais um artigo de Golang para disseminar conhecimentos relevantes para a área. Dessa vez, venho com mais um conceito de desenvolvimento que é bom conhecer mas que não deve ser tão utilizado assim, que é o Config Pattern ou "padrão de configuração".

Como o próprio nome diz, trata-se de uma estratégia de estrutura de argumentos e/ou configurações de qualquer coisa. Você consegue até aplicar em outras linguagens, pois o conceito é abrangente o suficiente para produzir em quaisquer linguagens que fornecem alguma ferramenta de captura de argumentos dinâmicos. No caso do Golang, nós usamos o pack operator.

O que raios é isso, Kiko?!

É o oposto de unpack ou spread. Em outras linguagens, em situações onde você quer quebrar um array em uma lista de valores, geralmente você "desempacota" o array com a assinatura array..., onde os três pontos no final significam que você vai pegar todos os valores e distribuir na linha onde a sentença está escrita.

No caso do pack, é justamente o oposto. Você vai ter uma lista de valores e quer "empacotar" tudo em um único array. No caso do Golang, é em um slice, ficando assim:

func MyFunc(arguments ...string) {
    // nesse caso, a assinatura final do argumento 'arguments' é []string
}

Se a linguagem que você usa fornece algum recurso para capturar uma lista indefinida de argumentos, então você consegue aplicar o Config Pattern.

OK, mas o que é isso?

Config Pattern nada mais é que um DTO gerenciado por pequenas funções.

Não sabe o que é DTO? Dá uma lidanesse outro artigo que expliquei direitinho(escrevi via Telegraph, numa época obscura que eu publicava coisas para só uma pessoa ler... Eu deveria republicar aqui no CodeAspiras? Comenta aí).

A principal diferença seria sobre qual lado da função retém a responsabilidade de alimentar os dados do objeto que carrega informação. O DTO é alimentado por quem chama a função, antes de chamá-la. Já o Config Pattern, é alimentado dentro da função. Por isso você cria funções que servem para injetar valores no objeto de configuração.

E pra que serve isso tudo, Kiko?!

Para ter um controle rígido do que pode e não pode ser inserido. Por exemplo, no Golang, você pode desenvolver uma configuração 100% privada, expondo somente algumas possibilidades pra quem vai chamar sua função.

Digamos que estamos desenvolvendo um Logger e queremos que o desenvolvedor que irá usá-lo possa configurar somente prefixo ou sufixo. Se você implementar em DTO, você teria algo mais ou menos assim:

package mylog // logger.go

type LoggerConfigDTO struct {
    Prefix string
    Suffix string
}

type Logger struct {
    config LoggerConfigDTO
}

func New(config LoggerConfigDTO) *Logger {
    return &Logger{config: config}
}

E aí, quem fosse inicializar seu Logger poderia fazer algo assim:

mylog.New(mylog.LoggerConfigDTO{
    Prefix: "$timestamp [$level]",
    Suffix: "/n",
})

Só tem um problema nisso. Lá no enunciado, eu disse que era para ter somente prefixo ou sufixo, não ambos simultaneamente, correto? Então essa implementação não está adequada.

Uma possível solução seria somente aplicar o prefixo se o sufixo estiver vazio e/ou vice-versa, porém isso iria impactar o tempo de escrita de logs, adicionando uma condição para o momento de execução. Outra solução seria, já na hora de inicializar a struct, verificar se os dois estão preenchidos e apagar um arbitrariamente.

Em ambas as soluções, nós estamos decidindo algo e gerando um comportamento obscuro na nossa aplicação. O desenvolvedor que usasse seu Logger só iria perceber esse comportamento quando já estivesse vendo os logs em produção com alguma informação faltando. Claro, você também pode deixar um aviso gigante na documentação... Enfim...

Em busca do Config Pattern

Antes de prosseguir, deixe-me alertá-lo(a) novamente: só use isso se você precisar de controle rígido sobre configurações, pois a implementação pode deixar o código bem massante. Outro ponto: embora você possa implementar a configuração de forma privada, sempre que possível, faça-a pública. Assim você facilita a escrita de testes de outros desenvolvedores, beleza? Tendo uma interface de configuração pública, eles conseguem mockar o setup e fazer seu código ter um comportamento específico nos testes. Mas chega de papo e vamos lá.

O primeiro passo que você precisa para transformar seu DTO em um Config Pattern é criar uma assinatura para funções de manipulação dos dados. No caso, eu vou chamar de LoggerOption:

package mylog // logger_config.go

type LoggerOption func(c *LoggerConfigDTO)

Nessa assinatura, estou dizendo que um LoggerOption é uma função que recebe uma referência/ponteiro de LoggerConfigDTO e não retorna nada. Basicamente, essa função deve alterar a referência que recebe no argumento e nada mais.

Tendo essa definição, você pode criar as funções que manipulam os dados do DTO. Essas funções recebem como argumento o dado a ser inserido na configuração e retornam um LoggerOption, ou seja, retornam a função de injeção do dado no DTO:

package mylog // logger_config.go

type LoggerOption func(c *LoggerConfigDTO)

// WithPrefix defines the prefix to be injected in all logs. It erases the suffix, if it's filled.
func WithPrefix(prefix string) LoggerOption {
    return func(c *LoggerConfigDTO) {
        c.Prefix = prefix // aqui aplicamos o prefixo na configuração
        c.Suffix = "" // aqui limpamos o sufixo para não ter coexistência
    }
}

// WithSuffix defines the suffix to be injected in all logs. It erases the prefix, if it's filled.
func WithSuffix(suffix string) LoggerOption {
    return func(c *LoggerConfigDTO) {
        c.Suffix = suffix // aqui aplicamos o sufixo na configuração
        c.Prefix = "" // aqui limpamos o prefixo para não ter coexistência
    }
}

Note que adicionei dois comentários indicando o comportamento de cada configuração. Esses comentários são chamados de godoc e são suportados por quase toda IDE que podemos usar para desenvolver Golang. Dito isso, ao invocar a função, o desenvolvedor já vai saber dos efeitos obscuros - se ele ler, claro. E isso não é exclusivo de Config Pattern. Por favor, use godoc em tudo, até em propriedades, rs.

E por último mas não menos importante, agora podemos modificar a função de inicialização para receber um pack de LoggerOption ao invés de um DTO preenchido, migrando a responsabilidade de construção do DTO para dentro da função:

package mylog // logger.go

type LoggerConfigDTO struct { // isso pode permanecer assim
    Prefix string
    Suffix string
}

type Logger struct {
    config LoggerConfigDTO // aqui também
}

func New(options ...LoggerOption) *Logger {
    config := LoggerConfigDTO{} // construimos o DTO
    for index := 0; index < len(options); index++ {
        options[index](&config) // executamos cada LoggerOption na referência do DTO
    }

    return &Logger{config: config}
}

E com isso, ao invés de inicializar um DTO, agora o desenvolvedor poderá inicializar o Logger com várias chamadas de LoggerOption:

mylog.New(
    mylog.WithPrefix("$timestamp [$level]"),
    // mylog.WithSuffix("\n"),
)

Fim. Você rapidamente migrou o padrão do seu projeto de DTO para Config Pattern. Caso mantenha a assinatura das opções e do DTO como públicas, você dará ao desenvolvedor a possibilidade de criar novos controles de configuração, mas ele só vai poder manipular o que for público.

Então você realmente vai ter muito mais domínio sobre o código e a escrita vai ficar mais semântica. Às vezes temos de lidar com campos com nomes esquisitos e, com Config Pattern, temos a possibilidade de escrever funções com nomenclaturas mais claras sobre o que estamos configurando.

A documentação em godoc está disponível tanto para DTO quanto para Config Pattern, então isso não é exatamente vantagem pra ninguém. Porém, quando se trata de sobreescrever configurações padrões, o Config Pattern é a melhor escolha.

Como assim, Kiko?

Digamos que, por padrão, eu que o prefixo seja sempre "$timestamp [$level]". Com o pattern, é bem simples:

package mylog // logger.go

type LoggerConfigDTO struct {
    Prefix string
    Suffix string
}

type Logger struct {
    config LoggerConfigDTO
}

func New(options ...LoggerOption) *Logger {
    config := LoggerConfigDTO{
        Prefix: "$timestamp [$level]", // valor padrão
    }
    for index := 0; index < len(options); index++ {
        options[index](&config)
    }

    return &Logger{config: config}
}

Basta instanciar o DTO com o valor inicial de cada opção, certo? Mas se você não é responsável pela inicialização dele, como você vai garantir esse valor padrão? Você teria de partir para solução de mesclagem de structs e isso não é exatamente necessário se você usa Config Pattern, dado que você é quem inicializa o DTO.

É nesses casos que esse padrão ganha força e se torna prático.

Alguém já usou isso antes, Kiko?

Com certeza! Eu já cheguei a dar palpite num Config Pattern do Tracer do Datadog. Eles fizeram as configurações privadas e eu queria modificar o logger deles em outro pacote. Você pode ver a issue que abri aqui: https://github.com/DataDog/dd-trace-go/issues/1331 . No final das contas, eles perceberam que centralizaram a configuração de logger de todos os produtos no Tracer e resolveram refatorar essa lógica.

Outra biblioteca bem famosa que usa o Config Pattern é o GORM.

Se você procurar direitinho, você vai perceber que muitas bibliotecas usam essa estratégia para estabelecer um controle mais rígido sobre os argumentos. Então sim, muita gente usa.

Curtiu? Comenta e compartilha! E lembrando: esse blog é nosso! Se tiver algo que queira publicar por aqui, fala comigo que te convido como colaborador do blog. Pode ser sobre qualquer coisa da área de tecnologia! Algo que acabou de estudar e tal. Antes de publicar, nós revisamos o conteúdo, assim podemos te corrigir se tiver aprendido algo errado e reforçamos nossos conhecimentos juntos. Bora?

E por hoje é só!

Inté.

Muito se fala sobre designs de projeto mas pouco se aplica na realidade. Por exemplo, seguir o Domain-Driven Design à risca não é uma tarefa fácil. Sua ideia até foi moldada de forma abstrata, mas, quando uma linguagem traz limitações estruturais, isso aumenta a dificuldade de aprendizado.

Golang é esse tipo de linguagem: toda vez que você pensa que está fazendo algo prático, alguma hora depois irá descobrir que algo ficou redundante a ponto de prejudicar a legibilidade do código ou deixar o esquema de importações bastante confuso. Eu passei muito por isso, rs.

Eu fui aprendendo muita coisa com o tempo, absorvendo conteúdos de muitas pessoas. Dito isso, eu não sei a quem dar créditos por cada pequeno conhecimento que me trouxe ao ponto que cheguei. Vou evitar atribuir nomes aos bois, ok? Mas prometo colocar alguns artigos ao final deste, pode ser?!

Vamos começar pelo começo.

Iniciando um projeto em Go

Se você pesquisar um pouco, vai ver que nem precisa de pastas para fazer um projeto Golang. Você pode simplesmente despejar quantos arquivos .go quiser na raiz e deixar a desorganização tomar conta.

OK, pera, tem projetos que isso até faz sentido. São bibliotecas (libs), projetos menores, que não costumam ter mais de 2 arquivos (o principal e o de teste). Você não vai criar todo um sistema de pastas pra colocar dois arquivos, certo??

Todavia, se o seu projeto é um pouquinho maior que isso, faz sentido repensar sobre a estrutura utilizada.

Como você organiza seus projetos, Kiko?

Primeiramente, gosto de pensar que toda aplicação Go é um recurso CLI, mesmo se o objetivo for rodar um servidor web. Dito isso, a primeira pasta que me vem em mente tem como função "organizar os comandos que irei disponibilizar para o CLI", ou seja, a pasta "cmd" (abreviação de command).

A ideia dessa pasta é expor, por exemplo, a execução principal do código (vulgo main.go) e, quando aplicável, os comandos abaixo dele, como nos exemplos abaixo:

• myapp serve -p 80 => chama o arquivo cmd/main.go, que inicializa o servidor na porta 80, importando alguma execução em cmd/serve.go;

• myapp cron:reset-quotas => chama o arquivo cmd/main.go, que inicializa o fluxo de Cronjobs, importando alguma execução em cmd/cron.go;

• myapp db:migrate => chama o arquivo cmd/main.go, que inicializa o arquivo de migrations do banco em cmd/migrate.go;

• myapp db:revert (...);

• myapp db:seed (...);

• e por aí vai.

É muito importante refletir quantos comandos você quer expor no terminal e quais opções de controle você quer fornecer antes de começar o projeto, pra validar a real necessidade da pasta. De repente, ter só um comando desfaz a necessidade de criar isso e você pode deixar o main.go na raiz da aplicação. É algo a se pensar, certo?

Após isso, a próxima pasta que me vem em mente e que é obrigatória a quase todos os projetos é a pasta internal.

Que pasta é essa, Kiko?

A ideia dessa pasta é separar o código público do código interno do projeto (daí o nome). Isso não significa que o código será secreto nem nada do tipo, só que outros projetos não conseguirão importar nada que estiver dentro dessa pasta. O compilador do Golang não permite a importação de pastas dentro de alguma pasta com o nome internal.

Não é sobre guardar segredos, mas de impedir que alguém use sua biblioteca da forma errada.

É qualidade de código!

E igualmente serve para centralizar a sua camada de domínio. Gosto de dizer que "o que é exclusivo do projeto, fica na pasta internal". Implicitamente, isso também significa que "o que não é exclusivo do projeto, fica fora".

Se não for comando e não for exclusivo do projeto, fica onde então, Kiko?

Re: na pasta pkg!

"pkg" é uma abreviação para "package" e é lá que você vai colocar a parte pública da sua aplicação que não está em fluxo de execuções. Tem algumas pastas que vejo ter quase como um padrão em todos os projetos que já trabalhei:

• pkg/platform: todas as lógicas de plataforma usadas pela aplicação. Clients, Middlewares, Autenticação, etc. Sinceramente, isso poderia estar em um kit-repository e ter as "configurações" (ou divergências) importadas por variáveis de ambiente, mas isso é outro assunto;

• pkg/util: são funções "auxiliares" que podem ser facilmente confundidas com "serializers". A grande maioria apenas transforma dados e são importadas tanto pelos pacotes internos quanto os de comando;

• pkg/services: quando você precisa desenvolver um serviço de terceiros, quando não há um SDK ou algo do gênero para usar, você acaba colocando aqui, focando em criar apenas o serviço, sem embutir regra de negócio da sua aplicação;

• etc.

Só com isso você já consegue organizar um projeto tranquilo, mas preciso te alertar sobre outras pastas:

• docs: se você está fazendo uma aplicação HTTP, é comum usar gerador de documentações que extraem informação de godoc para criar uma OpenAPI (vulgo Swagger). A documentação compilada geralmente é exportada na pasta docs nos projetos em Golang. É tipo um padrão que foi instalado silenciosamente;

• mocks: outra pasta bastante comum pra quem usa mockery. Basicamente, se você faz interface pra tudo, você consegue compilar todas as interfaces em mocks para fazer testes unitários bem refinados. Na minha humilde opinião, Golang foi a linguagem que achei estupidamente mais fácil de mockar qualquer coisa... E olha que eu já fiz todo tipo de teste automatizado aqui, hein?

• vendor: se você usa o comando go mod vendor, o Golang irá baixar todas as suas dependências e colocar na pasta vendor. Quase toda linguagem provê esse tipo de pasta (no Node, seria a node_modules. No PHP com Composer, é vendor também, etc), então já é de senso comum não mexer em nada que estiver nela. É importado automaticamente, então não é SEU.

E agora sim, tendo noção dessas pastas, você pode começar a investigar melhor os códigos que encontrar por aí. Ainda pode haver outras pastas mas, sinceramente, isso pra mim é o necessário. Você pode ler mais sobre isso em um dos links no final desse artigo.

Desenvolvendo

Um detalhe que os iniciantes se batem em Golang é sobre como nomear e importar projetos. Eventualmente, percebe-se que há uma certa simplicidade nisso: tudo é baseado no que está definido no go.mod. Quando você batiza o nome de uma aplicação, você deve ter em mente que, se ela for ser importada em outros projetos, toda a navegação de diretórios será inciada a partir da raiz, onde fica o go.mod.

Por exemplo, se eu crio uma pasta vazia e rodo o comando no terminal go mod init myproject, o compilador da linguagem vai criar os arquivos go.mod e go.sum na raiz do projeto chamando-o myproject. Assim, quando você importar alguma função myproject.Blablabla, ele vai procurar nesse diretório-raiz.

Já os pacotes, que são outras pastas, não mencionam o nome do projeto mais. Portanto, se você repetir nomes de pastas, eventualmente você vai ter de gerar apelidos (traduzindo alias) pra não dar conflitos nas importações.

O ideal é que você jamais repita nomes de pacotes, interfaces, nada. Evite repetir qualquer coisa. Outro ponto é que todas as pastas devem ser escritas em letras minúsculas e somente letras. Nada de underline, etc. É pra dar nomes pequenos mesmo, sabe?

Explorando um pouco da estrutura de pastas que discutimos, alguns dos pacotes que vejo em comum nos projetos são:

• internal/entity: fica a implementação de entidades de domínio, assim como algumas regras de negócio (as que forem independentes). Evite ao máximo importar outros pacotes dentro desse;

• internal/db/model: fica a implementação de modelagem de banco de dados referente as entidades criadas anteriormente, deixando claro que o pacote entity deve evitar ao máximo mencionar qualquer coisa de banco salvo algumas exceções como dados anuláveis (ex: sql.NullTime). Na Model você geralmente descreve o nome da tabela de cada entidade e campos adicionais que só importam para o banco (ex: DeletedAt é um campo geralmente utilizado para soft-deleting ~ não é consumido pela sua aplicação, apenas pro banco, e raramente há necessidade de expor essa informação. Nesse cenário, você não coloca esse campo na entidade, somente no modelo do banco). Outro detalhe é que cada Model implementa suas funções de conversão aqui, como NewBlablablaModel() recebendo entidade e retornando model e model.ToEntity(), convertendo a modelagem para entidade;

• internal/db/repository: aqui fica a implementação de comunicação com banco, encapsulando o que quer que use para se comunicar com banco em funções mais simplificadas pra sua aplicação. Note que há variações gigantescas de como implementar esse pacote. Algumas pessoas preferem centralizar tudo em uma interface de Repository e uma implementação que serve para todas as entidades e outras preferem ter um repository pra cada entidade. No geral, o objetivo aqui é dar aos demais pacotes algo que possa receber ou prover entidades sem expor as modelagens do banco;

• internal/usecases/<fluxo>: como diz o nome, nesses pacotes implementamos os casos de uso da aplicação, independente de qual protocolo esteja sendo usado. A ideia é que todos os fluxos nesse pacote não saibam o que é uma requisição web ou comando CLI. Eles vão ter seus argumentos completamente restritos para somente executar o caso de uso e retornar o que precisar retornar ou erro. Um exemplo simples seria casos de uso de uma loja online, onde poderia ter os pacotes de CRUD product, category, customer, etc, e pacotes de fluxo de compra como shopping, publishing, etc. A forma como você vai separar os fluxos só depende de você. O importante é não receber *http.Request aqui dentro, muito menos http.ResponseWriter;

• internal/http: essa pasta aqui é um verdadeiro dilema. Na minha opinião, isso poderia ser uma pasta lá no pacote cmd. Porém também é uma configuração interna da aplicação, então faz total sentido estar na internal. Então minha conclusão é mais simples: siga seu coração.

Implementando esses pacotes, teu serviço estará praticamente pronto, restando somente configurar as coisas no pacote cmd e rodar.

Ah, Kiko, não vai dar nenhum exemplo de código??

Quem disse que não? Toma aí: https://github.com/kaiquegarcia/gomarket/

Eu fiz esse projeto para explorar alguns conceitos na minha mente. Por exemplo, o armazenamento em disco, gerenciado de forma abstrata por uma collection. Funcionou perfeitamente nos primeiros experimentos e deu até pra escrever testes de ponta.

Como pode ver no git, praticamente toda struct implementa uma interface. Isso serve para que o mockery consiga mockar absolutamente qualquer coisa da minha aplicação, facilitando a escrita de quaisquer testes.

Além disso, a clara separação de responsabilidades por pacotes deixa claro onde poderia estar alguma coisa. Nesse projeto, eu coloquei a pasta http dentro da cmd. Como falei: siga seu coração! E dessa vez eu quis jogar lá mesmo. Mas também tenho projetos com a presença do pacote dentro da internal. É meio louco isso, né?

Enfim, por hoje é só! Diferentemente do meu blog pessoal, aqui, no Code Aspiras, não pretendo dar continuidade de um artigo pro outro. Nesse escrevi sobre Golang, no próximo pode ser um Typescript, Angular, Javascript, PHP, Java, sei lá. Não estou com um foco em mente e ultimamente não sobra muito tempo pra fazer um trabalho mais prolongado nas escritas.

Então vou escrever o que percebo que poderia ser relevante pra quem fosse trabalhar comigo, por exemplo. Esse artigo é extremamente relevante pra qualquer iniciante de Golang que for se aventurar nos meus projetos.

Outro detalhe é que Go é uma linguagem muito nova. Não existe nada como regras absolutas. O que eu disse aqui é apenas uma das milhares de formas de se fazer um projeto bem limpo, legível e fácil de manter. Ainda há muitos assuntos que não foram discutidos, como conceitos de redução de código (DRY, AHA, etc) e técnicas para enxugar complexidades lógicas. Pretendo escrever artigos sobre eles, voltados a Golang, assim como redigir alguns aprendizados importantes que tive com outros colegas de equipe.

Artigos interessantes

• Socorro! Como posso organizar os pacotes em Go? (Odilon Jonathan Kröger);

• Mocking an Interface using Mockery in Go (Mert Kimyonşen);

• Documentanto uma api Go com Swagger (Vinícius Boscardin).

E agora eu vou indo nessa. Abraço!

Inté!

Eu não vou enrolar muito nas desculpas, mas quero abrir um espaço para nos comunicarmos caso alguém queira um mentor pra tirar dúvidas no tempo livre. O que acha? Enfim, se você quiser me contactar, tem algumas redes onde sou sempre bem receptivo pra galera de TI (mesmo se você AINDA não for da área, mas tem intenção de migrar):

• Twitter (\EDIT: vazei do Twitter);

• Blue Sky;

• Telegram.

É, só essas duas mesmo. Tenho um WhatsApp mas prefiro não expor meu telefone (embora acreditando fortemente que Telegram >>> WhatsApp).

Então deixo essa mensagem como uma despedida temporária. Não consegui concluir a missão de pregar a palavra do PHP, hahaha.

PS.: lembre-se que além de trabalhar em empresa multilíngue, eu sou pai de gêmeas. Então eu tô SEMPRE mentalmente esgotado. Na grande maioria das vezes eu costumo não responder desconhecidos automaticamente, mas depois que começamos a conversar (e eu passe a acreditar que não é um bot), a conversa vai fluir mais rápido, rs.

Assuntos que consigo mentorar:

• PDI (plano de desenvolvimento individual ou plano de carreira);

• Indicação de cursos de front-end / back-end;

• Avaliar soluções JS (incluindo frameworks como Node.js, React.js, Angular, Vue.js, etc), PHP (Laravel, Lumen e me arrisco um pouco sobre Swoole), Golang (aqui é onde estou mais forte no momento), etc (também consigo direcionar a pesquisas quando não sei sobre o assunto);

• Enfim, coisas relacionadas ao técnico, eu geralmente sou bem prestativo, mas só oriento! Não faço trabalho nenhum por você.

Se for do teu interesse, só vem!

E até a próxima, pessoal...

Inté!!

Ah, não, Kiko... Que que você quer dessa vez?!

Hahaha, só conhecer quem está lendo! Eu tenho dois grandes objetivos para esse ano de 2022:

1. ajudar 100 aspirantes a dev a, de fato, conseguir um emprego como dev: pelo andar da carruagem, acho que não vou conseguir... Mas já ajudei quase 30, hein?! e não, eu não mexo pauzinhos para alguém pular uma catraca e entrar... A única coisa que faço é guiar as pessoas a seguir uma direção de forma lógica e explorar os conhecimentos para ver com o que se identifica. Bora?
2. criar um evento cíclico de coding dojo para devs Golang, nem que seja só na empresa onde estou: percebi que a correria da vida está sendo um verdadeiro problema pra tocar isso. Nem eu tenho energia pra fazer no horário livre, nem os devs demonstram querer, de fato, que isso aconteça. Será que é porque nunca foram a um coding dojo ou só não acham isso tão relevante assim? Talvez o problema seja eu?

Enfim... Se você se encaixa de alguma forma em um dos meus objetivos, seja por querer participar de um coding dojo ou por querer trabalhar como dev, não hesite em me procurar, fechado?! Eu também ajudo empresas a organizar coding dojos para seus colaboradores, mas geralmente eu não participo dos eventos, por serem fechados. Eu só digo o que fazer, opino se o desafio tá bem interessante, etc. Eu nem cobro por essas paradas! Aiai...

Agora chega, vamos falar de PHP!

Operador de Resolução de Escopo (::)

Esse nome pode nos confundir bastante, mas eu já mostrei esse operador diversas vezes ao longo dos artigos sobre classes, será que você reparou? Em algum momento até aqui, eu te ensinei, de forma explícita, como acessar propriedades e métodos de um objeto, usando o operador ->. Esse operador é específico para dados não-estáticos, ou seja, que precisam de uma instância para existir.

E da mesma forma que esse tipo de estrutura existe, também temos os dados estáticos, que não precisam de uma instância. São eles:

• constantes: se o valor é fixo, por que raios eu precisaria instanciar a classe para acessá-lo?;
• propriedades estáticas: ok, não é fixo, mas tem um valor que transita entre instâncias, ou seja, compartilhado... Não necessariamente precisa de uma instância para existir;
• métodos estáticos: são funções quase desacopladas de uma classe, presente por apenas dois motivos - ou para tornar a legibilidade de um código mais semântico, ou para poder acessar outros dados estáticos da própria classe que tem visibilidade protegida ou restrita. Temos apenas uma exceção para fábricas, que é um design pattern que usa função estática como gerador de instâncias... Isso não vai ser abordado aqui, mas achei relevante mencionar.

Para exemplificar os cenários acima, escrevi o código a seguir:

<?php

class Sirene {
    // Constantes
    public const SOM = "UEEENNNNNNNNNN";
    private const REPETICOES = 20;

    // Propriedades estáticas
    public static $RESPONSAVEL = "";

    // Métodos estáticos
    public static function tocar(string $autor): void {
        Sirene::$RESPONSAVEL = $autor;
        for ($contador = 0; $contador < Sirene::REPETICOES; $contador++) {
            echo Sirene::SOM . PHP_EOL;
        }
    }
}

// 1. Qual é o som da sirene?
echo "O som da sirene é: " . Sirene::SOM . PHP_EOL;

// 2. Ligue a sirene!
Sirene::tocar("Fulano");

// 3. Quem ligou a sirene?!
echo "Quem ligou a sirene foi " . Sirene::$RESPONSAVEL;

Veja o código em ação: https://onlinephp.io/c/900c7

Tá, Kiko, se o objetivo desse operador é acessar dados de uma classe, por que se chama Operador de Resolução de Escopo?

Porque ele pode ser aplicado de diversas formas. Eu te disse que ele acessa dados estáticos, certo? Mas jamais falei que só poderia ser usado em classes, pois também é possível aplicarmos em um objeto ou em palavras-chave como self, static e parent. Ele irá funcionar em qualquer uma, desde que o dado que está tentando acessar exista para aquela referência.

Ou seja: você diz o escopo e a referência do dado que você quer acessar e o operador resolve isso pra você. Faz mais sentido agora?

Nós podemos reescrever o código acima para mostrar a aplicação em objeto e nas palavras-chave self e static:

<?php

class Sirene {
    // Constantes
    public const SOM = "UEEENNNNNNNNNN";
    private const REPETICOES = 20;

    // Propriedades estáticas
    public static $RESPONSAVEL = "";

    // Métodos estáticos
    public static function tocar(string $autor): void {
        self::$RESPONSAVEL = $autor;
        // "self" equivale a Sirene, pois está dentro dessa classe
        // e nesse caso, poderíamos usar também a palavra "static"
        // "self" representa a classe que implementa o método acionado
        // "static" representa a classe acionada
        // vou mostrar mais exemplos, não se preocupe... mas vamos de static:
        for ($contador = 0; $contador < static::REPETICOES; $contador++) {
            echo static::SOM . PHP_EOL;
        }
    }
}

// Digamos que, ao invés de acessar a classe, por algum motivo nós temos um objeto Sirene
$sirene = new Sirene();

// Então, ao invés de usar Sirene::, podemos usar $sirene::

// 1. Qual é o som da sirene?
echo "O som da sirene é: " . $sirene::SOM . PHP_EOL;

// 2. Ligue a sirene!
$sirene::tocar("Fulano");

// 3. Quem ligou a sirene?!
echo "Quem ligou a sirene foi " . $sirene::$RESPONSAVEL;

Veja o código na prática: https://onlinephp.io/c/0653b

Mas Kiko, se eu posso escrever o nome da classe, por que que eu usaria as outras formas? Onde que isso faz sentido?

Concordo que, em cenários onde é possível escrever o nome da classe, é muito mais legível deixar a classe por extenso. Ainda assim, nem sempre isso é possível de se fazer, principalmente se você está desenvolvendo um código utilizando interfaces, como mencionei no artigo anterior, que pode obrigar a desenvolver métodos estáticos e você não faz ideia de qual implementação está recebendo na função.

Por exemplo, veja a função calcularDano a seguir:

<?php

interface Arma {
    public static function gerarDano(float $defesa): float;
}

class Bazuca implements Arma {
    public static function gerarDano(float $defesa): float {
        return rand(500, 2000) - $defesa;
    }
}

class Metralhadora implements Arma {
    public static function gerarDano(float $defesa): float {
        return rand(50, 350) - $defesa;
    }
}

function calcularDano(Arma $arma, float $defesa): float {
    // não sabemos com qual implementação da interface Arma estamos lidando
    // a única coisa que sabemos é que, o que quer que seja, implementa o método estático "gerarDano"
    // nesse caso, podemos usar o operador de resolução de escopo para nos dar acesso a esse método:
    $dano = $arma::gerarDano($defesa);
    if ($dano < 0) {
        return 0.0;
    }
    return $dano;
}

$defesa = rand(0,200);
$bazuca = calcularDano(new Bazuca(), $defesa);
$metralhadora = calcularDano(new Metralhadora(), $defesa);
echo "Defesa: $defesa" . PHP_EOL;
echo "Dano aleatório da Bazuca: $bazuca" . PHP_EOL;
if ($bazuca > 2*$defesa) {
    echo "Foi crítico!" . PHP_EOL;
}
echo "Dano aleatório da Metralhadora: $metralhadora" . PHP_EOL;
if ($metralhadora > 2*$defesa) {
    echo "Foi crítico!" . PHP_EOL;
}

Veja o código na prática: https://onlinephp.io/c/e46e8

Ok, acho que entendi o uso desse operador com objetos... Mas e as palavras-chave? Quando faz sentido usar?

Em cenários onde há o uso de Herança. Vamos revisar cada palavra-chave:

self

Trata-se de uma referência para a classe onde o método acionado está registrado.

<?php

class Mae {
    public static $EXPERIMENTO = "MÃE";
    public static function teste(): void { // método registrado na classe Mae
        echo self::$EXPERIMENTO; // self = Mae, sempre
    }
}

class Filha extends Mae {
    public static $EXPERIMENTO = "FILHA";
}

Filha::teste(); // imprimirá "MÃE"

Veja o código em ação: https://onlinephp.io/c/81e90

static

Trata-se de uma referência para a classe acionada.

<?php

class Mae {
    public static $EXPERIMENTO = "MÃE";
    public static function teste(): void {
        echo static::$EXPERIMENTO; // static = depende
    }
}

class Filha extends Mae {
    public static $EXPERIMENTO = "FILHA";
}

Filha::teste(); // imprimirá "FILHA", pois o "static" aqui é a classe "Filha"

Veja o código em ação: https://onlinephp.io/c/d7fcc

Observações:

• eu apenas troquei self::$EXPERIMENTO por static::$EXPERIMENTO;
• se a classe Filha não sobreescrevesse a propriedade $EXPERIMENTO, herdaria o valor da classe Mae. Não significa que está acessando a classe Mae, apenas usando o valor que foi herdado, beleza? Faz o teste aí: https://onlinephp.io/c/271ce.

parent

Trata-se de uma referência a classe que vem antes da classe onde o método acionado está registrado.

Que descrição complexa, né?! Você pode pensar dessa forma: ele funciona como o self, só que busca a classe que foi extendida pela classe presente em self. Para isso, vamos fazer mais uma classe:

<?php

class Mae {
    public static $EXPERIMENTO = "MÃE";
}

class Filha extends Mae {
    public static $EXPERIMENTO = "FILHA";
    public static function teste(): void {
        echo parent::$EXPERIMENTO; // parent = Mae, sempre
    }
}

class Neta extends Filha {
    public static $EXPERIMENTO = "NETA";
}

Neta::teste(); // imprimirá "MÃE"

Veja o código em ação: https://onlinephp.io/c/ece

E por hoje é só! Curtiu?? Comenta e compartilha!! Uma curiosidade bacana sobre esse operador é que o nome oficial que deram a ele é Paamayim Nekudotayim, que é a fonética para פעעמיים נקודותיים, que significa dois pontos duplos em Hebreu!

Então, se por algum motivo você encontrar um erro com essas palavras no PHP, já vai ficar ligado que se trata de algum uso errado do operador de resolução de escopo! Hehehehe. Espero que tenham curtido, hein?! No próximo artigo, falaremos um pouco mais sobre a palavra-chave static. Hoje só falamos a ponta do iceberg, usando static como referência. No próximo, vamos falar sobre dados estáticos. Não perca, hein?

Inté!!

O assunto de hoje vai ser mais um pequeno salto no fluxo atual da documentação oficial do PHP, pois ao invés de falarmos somente sobre Visibilidade, falaremos de Herança.

Ué, Kiko... Por que pularemos esse assunto?

Pelo simples fato de que eu já falei sobre ele. Lembra das palavras public, private e protected? Eu expliquei nos artigos onde esse tópico estava relevante:

1. Visibilidade de Propriedades (procura por 1.1.1);
2. Visibilidade de Métodos (procura por 3. O que é e como declarar métodos).

Ainda assim, há um pequeno detalhe que não falei a respeito: visibilidade em outros objetos. Vou dedicar essa introdução para isso, ok? Afinal, está relacionado com herança.

Visibilidade entre objetos

A visibilidade que damos às propriedades e métodos pertence à assinatura da classe que estamos desenvolvendo. Isso significa que mesmo que você escreva uma propriedade privada, instâncias diferentes da mesma classe poderão acessar esse valor. Basta injetar a outra instância em algum método:

<?php

class Exemplo {
    public function __construct(
        private int $codigo
    ) { }

    public static function imprime($ex Exemplo) {
        echo $ex->codigo;
        // $ex->codigo é uma propriedade privada da instância $ex
        // mas eu consigo acessar seu valor, pois estamos dentro da classe que conhece toda a assinatura dele
    }
}

$ex = new Exemplo(123);
Exemplo::imprime($ex);

Notou que o método estático imprime está recebendo um objeto da classe Exemplo? E que esse método também pertence à classe Exemplo? Dessa forma, é possível trabalhar com todas as propriedades e métodos privados de $ex.

E o que isso tem a ver com herança, Kiko?

Tudo. Nós podemos acessar propriedades protegidas de outra classe, se estiver herdada na classe atual. É por isso que digo que a visibilidade entre objetos faz parte de herança.

<?php

class Person {
    public function __construct(
        protected string $name
    ) { }
}

class Pilot extends Person {
    public function criticize(Person $person): void {
        echo $person->name . " ainda tem muito o que aprender..." . PHP_EOL;
    }
}

$john = new Person("John Doe");


$pilot = new Pilot("José");
$pilot->criticize($john);

Veja o código funcionando: https://onlinephp.io/c/b7bb0

1. $person->name é uma propriedade protegida de Person;
2. Pilot extende Person, logo ele herda todos os métodos e propriedades protegidos e públicos de Person, incluindo $person->name;
3. Quando Pilot recebe um objeto Person, ele pode acessar tudo aquilo que herdou dele.

É por isso que vemos por aí o pessoal divulgando herança sempre como uma relação Pai e Filho. Hoje vou quebrar um pouco esse ciclo vicioso:

<?php

class Mae {
    protected array $imoveis;
    protected array $contasBancarias;
}

class Filho extends Mae { }

Esse exemplo faz sentido e, ao mesmo tempo, não faz.

Como é, Kiko?

Olhando somente pela herança entre as classes, nós entendemos que a classe Filho herda as propriedades imoveis e contasBancarias da classe Mae. Porém, da forma como está, Filho herda tudo, não somente bens e dinheiro. Se a gente cria uma propriedade que define o emprego da mãe, o filho estaria herdando isso também... E na vida real, a gente sabe que isso não faz sentido algum, não é mesmo?

Se fossemos replicar a herança da vida real, esse relacionamento seria limitado aos objetos e não às classes. O que poderíamos fazer é criar uma abstração, definindo o que é uma pessoa e criando relacionamento entre pessoas, sem herança:

<?php

class Pessoa {
    protected array $imoveis;
    protected array $contasBancarias;
    protected Pessoa|null $pai; // sutilidade triste aqui, mas é realidade. Se você se identificou, força! Eu te respeito muito.
    protected Pessoa $mae;

    public function herancaMaternal() {
        array_push($this->imoveis, $this->mae->imoveis...);
        // na real, aqui a gente precisa dividir com os irmãos ainda, né? mas vamos deixar assim só pra explicar o que eu tava falando
        array_push($this->contasBancarias, $this->mae->contasBancarias...);
    }
}

Com isso, a pessoa que acionar $pessoa->herancaMaternal() só vai receber o que de fato herdou, quando for a hora. Percebeu que eu acessei os atributos protegidos imoveis e contasBancarias de $this->mae? Só foi possível pois a visibilidade de qualquer instância de Pessoa nos permite "ver" esses dados naquele bloco.

E com isso, temos uma boa introdução para o artigo...

Herança

Oloko, Kiko, isso foi só uma introdução?!

Eu queria que fosse, mas eu já escrevi bastante, né? Hahaha. Pelo menos agora eu vou poder ser um pouco mais direto...

Resusmo: herança, em orientação a objeto, é o compartilhamento de recursos entre classes. Se a classe A extende a classe B, ela herda todos os métodos e propriedades públicos e privados dela. Esses métodos e propriedades passam a coexistir tanto em B quanto em A.

A forma de escrita é na declaração da classe. Até aqui, você me viu declarando classes como class AlgumaCoisa, certo? Em herança, a declaração inclui a palavra extends que indica de qual classe você está herdando:

<?php

class A { }
class B extends A { } 
class C extends B { }

Sim, é possível fazer heranças contínuas.

Um tópico interessante sobre herança é o override, ou seja, sobreescrever alguma coisa. Uma amostra bem simples disso seria uma classe A implementar o método vibrar() de um jeito e a classe que a herda reimplementar de outra forma:

<?php

class A {
    public static function vibrar(): void {
        echo "zzz" . PHP_EOL;
    }
}

class B extends A {
    public static function vibrar(): void {
        echo "BZZZZ" . PHP_EOL;
    }
}

class C extends A { }

Se você chamar:

• A::vibrar(): irá imprimir zzz;
• B::vibrar(): irá imprimir BZZZZ;
• C::vibrar(): irá imprimir zzz.

Veja o código rodando aqui: https://onlinephp.io/c/98c0e

Ué, por que só B::vibrar() está diferente?

Porque ele sobreescreveu o comportamento de A ao reimplementar o método vibrar().

Override é um recurso comumente utilizado quando encontramos alguma particularidade no meio das heranças, por isso podemos fazer isso. Mas é preciso tomar cuidado com um pequeno detalhe: antes do PHP 8, nós não tínhamos a capacidade de informar o tipo de dado que cada função e/ou método poderia retornar, por isso sempre foi possível sobreescrever os métodos herdados retornando um tipo de dado completamente diferente.

A partir do PHP 8.1, esse tipo de comportamento gera um aviso de depreciação, o que significa que, muito em breve, essa prática não irá mais funcionar nas novas versões.

Ou seja: precisou reimplementar um método e mudou a assinatura dele? É melhor refatorar enquanto ainda pode... Veja o alerta de depreciação aqui: https://onlinephp.io/c/c6e6d.

Na documentação, consta a possibilidade de omitir esse alerta ao aplicar o atributo #[ReturnTypeWillChange] acima da assinatura do método ou função, porém não recomendo e nem vou explorar isso... Até porque, se há esse risco nas suas heranças, isso só mostra que você está quebrando o seu código.

O que nos leva à seguinte polêmica...

Herança é anti-pattern

A herança entre classes, apesar de ser bem aceito na programação com abstrações, também pode ser considerado um anti-pattern ou anti-padrão. O exemplo que dei ali de pessoas, mãe, filho e tal evidencia isso: muitas vezes aplicamos uma lógica de herança porque queremos reduzir código, mas quase sempre estamos enxergando a abstração da forma errada.

Como esse artigo é pra quem nunca viu a parada, eu preciso mostrar o erro acontecendo, não é mesmo? Então vamos lá...

Digamos que nós queremos criar uma classe que represente um fusca e que tenha uma função de buzinar, sendo o som da buzina "bibii".

<?php

class Fusca {
    public function buzinar(): void {
        echo "bibii";
    }
}

$fusca = new Fusca();
$fusca->buzinar();

E agora, além do fusca, queremos uma lamborghini, sendo a buzina "pompom".

<?php

class Lamborghini {
    public function buzinar(): void {
        echo "pompom";
    }
}

$lamborghini = new Lamborghini();
$lamborghini->buzinar();

Ué, Kiko... Repetiu tudo?!

Sim, criamos uma repetição de código, onde a única diferença é o som da buzina. Se eu quiser criar uma função que chama essa buzina independente do modelo de carro, nós teremos um problema, pois as classes não tem relação entre si.

Geralmente, a primeira coisa que as pessoas pensam quando querem resolver esse tipo de problema é em herança, pois é a saída mais fácil: ah, pega o que tem em comum, cria uma classe abstrata com isso e pronto.

<?php

abstract class Carro {
    public function buzinar(): void {
        echo static::BUZINA . PHP_EOL;
    }
}

class Fusca extends Carro {
    protected const BUZINA = "bibii";
}

class Lamborghini extends Carro {
    protected const BUZINA = "pompom";
}

// Função genérica para todos os carros
function apertarBuzina(Carro $carro) {
    $carro->buzinar();
}

// Aplicando a função
$fusca = new Fusca();
$lamborghini = new Lamborghini();

apertarBuzina($fusca);
apertarBuzina($lamborghini);

Veja o código em ação: https://onlinephp.io/c/cb978

Pô, Kiko, para mim ficou muito legível... Por que isso seria considerado um anti-pattern??

Sim, herança pode até deixar tudo mais organizado, porém a manutenabilidade disso é péssima pois criamos perigos invisíveis. Por exemplo, para indicar o som da buzina de cada carro, eu preciso declarar a constante BUZINA. Se eu escrever um carro sem declarar isso, nós teremos um erro:

<?php

class CarroQuebrado extends Carro { }

$carro = new CarroQuebrado();
$carro->buzinar();

Veja o que acontece: https://onlinephp.io/c/2e033

Toda vez que precisarmos abstrair alguma coisa no nosso código, o ideal é criarmos uma estrutura rígida que nos force a criar tudo o que for obrigatório. Essa estrutura rígida é chamada de interface e é amplamente utilizada em várias linguagens de programação.

Quando você define uma interface Carro, você está dizendo ao interpretador: olha aqui, cara... Toda vez que alguma classe implementar essa estrutura, obrigue o desenvolvedor a escrever todos esses métodos do mesmo jeitinho que eu estou assinando aqui, ok?!

E o dev que se vire pra respeitar isso:

<?php

interface ICarro { // colocamos o I na frente pra deixar claro que é uma interface
    public function obterBuzina(): string
}

Diferente de herança, a declaração de uma interface é precedido pela palavra-chave interface. Em herança, nós declaramos classes mesmo... Da mesma forma, para declarar que uma classe está seguindo as regras de uma interface, nós usamos a palavra-chave implements, diferente do extends da herança.

Toda classe que implementar a interface ICarro precisará ter um método obterBuzina() que retorna uma string. Com isso, a gente pode recriar aquelas classes Fusca e Lamborghini para parar de usar herança e passar a assinar a nova interface:

class Fusca implements ICarro {
    public function obterBuzina(): string {
        return "bibii";
    }
}

class Lamborghini implements ICarro {
    public function obterBuzina(): string {
        return "pompom";
    }
}

Ficou um pouco mais verboso? Ficou, duas linhas... Ainda assim, as próximas classes de carro que forem criadas não terão o risco de alguém esquecer de escrever o que é obrigatório.

Mas Kiko, cadê o método buzinar?

É aqui que fica o pulo do gato: apesar de fazer total sentido colocar um método buzinar nos carros, nós podemos criar uma função que faça a buzina em si... Afinal, na outra implementação, nós teríamos de criar essa função do mesmo jeito, lembra? Tínhamos carro->buzinar dentro de apertarBuzina($carro).

Agora só precisamos do apertarBuzina($carro):

function apertarBuzina(ICarro $carro): void {
    echo $carro->obterBuzina() . PHP_EOL;
}

$fusca = new Fusca();
$lamborghini = new Lamborghini();

apertarBuzina($fusca);
apertarBuzina($lamborghini);

Veja o código funcionando aqui: https://onlinephp.io/c/cd215

Então mesmo herança sendo muito legal, tente pensar um pouco além, tudo bem? Você precisa fazer um código com o menor risco possível de erros acidentais. Pense sempre que outro desenvolvedor vai precisar mexer: é melhor força-lo a seguir um padrão do que criar padrões invisíveis, concorda?

E por hoje é só!! Curtiu? Comenta e compartilha! Acho que, com esse artigo, consegui deixar bem claro o motivo de herança ser considerado um anti-pattern... Ou você ainda discorda? Você teria feito esse exercício dos carros diferente? Pode mandar aí nos comentários, hehe.

No próximo artigo, falaremos sobre Operador de Resolução de Escopo (::), que é o que usamos para acessar propriedades e métodos estáticos das classes. Tá preparade?

Inté!!

E não, não foi uma falha no manual oficial do PHP, pois lá também está separado dessa forma. Eu que pulei algum conteúdo mesmo. Ainda assim, se prestarmos atenção sobre a temática daquele tópico, faz muito sentido mencioná-lo enquanto falamos sobre classes, concorda? Talvez meio cedo demais, mas com certeza tem muito a ver.

Nesse artigo, voltaremos ao fluxo natural das coisas e vamos abordar o que estava agendado como "próximo tópico" no final do penúltimo artigo (Autoloading):

Construtores & Destrutores

Como de costume, antes de irmos direto para o código eu gostaria de abrir um espaço para reflexão semântica, que é um espaço para pensarmos no significado das coisas. Por exemplo: o que raios é um construtor?? E o que é um destrutor?! São opostos?

De acordo com o dicionário, construtor é:

1. que ou aquele que constrói; construidor.
   "indústria c. de navios"
2. que ou aquele que possui empresa dedicada à construção de imóveis.

E destrutor é:

m.q. DESTRUIDOR.

Ou seja:

que ou quem destrói; destrutor.

Pô, Kiko, essa seção foi uma perda de tempo, não é mesmo? Como isso poderia ajudar a entender o que isso deveria ser no código?

Se você pensou assim, calma, jovem! Na realidade, entender o significado das coisas antes de ir atrás delas ajuda a compreender 10000% melhor na hora de ver a prática, ok?! Vamos avançando...

Falando de classes e objetos, eu tentei deixar evidente que "Classe" é apenas uma definição de alguma coisa e nada mais que isso. O que deve representar algo "mais consolidado" é o "Objeto".

Esse sim, pode ter todo um ciclo de vida. Por exemplo: se temos uma classe "Pessoa", você seria um objeto dessa classe, uma instância dela. Depois de ler isso, o que você imagina que é um construtor e um destrutor? Sobre o que está relacionado?

Pô, Kiko, para de mistério e fala de uma vez...

Hahaha, ok! É simples: construtor é a função que inicializa um objeto. Ou seja, quando você está criando um objeto a partir de uma classe, o construtor é acionado.

Enquanto isso, destrutor é a função que finaliza o objeto. Quando ele está prestes a ser eliminado no ciclo de vida do sistema, o destrutor é acionado.

Construtores

Quando você chama o operador new junto do nome de uma classe, o que você está acionando, na verdade, é uma função __construct dentro dela. Os argumentos que você insere no nome são injetados diretamente dentro dela, portanto, precisa respeitar a assinatura do que quer que tenha criado ali dentro.

Exemplificando:

<?php

class Example {
    private int $a;
    public function __construct(int $a) {
        $this->a = $a;
    }
}

No construtor da classe Example acima, eu espero como argumento obrigatório int $a. Se você chamar new Example(1), tudo vai funcionar perfeitamente. Mas se chamar new Example() (sem argumentos), teremos um grande erro acontecendo ao executar esse código.

Como você percebeu, a única coisa que meu construtor faz é pegar o argumento que você injetou na construção do objeto e definí-lo como valor de uma propriedade com mesmo nome dentro. Essa propriedade poderia ter qualquer outro nome:

<?php

class Example {
    private int $a;
    public function __construct(int $b) {
        $this->a = $b;
    }
}

O importante aqui é perceber que $a é diferente de $this->a. $a no exemplo anterior era apenas a variável criada dentro do construtor, recebida como argumento. $this->a era uma propriedade interna do objeto que estamos instanciando. No exemplo atual, agora ficou bem mais claro pois nomeei de forma diferente.

Ah, Kiko, eu preciso declarar a propriedade fora e dentro do construtor?

Depende. Se você usa PHP antes do 8.1: sim, você precisa. O PHP até consegue criar propriedades dinâmicas mas isso é horrível! Principalmente se você usa alguma ferramenta de análise estática do seu código. Então sempre declare essas propriedades direitinho.

Agora se você já está mais atualizado, é possível declarar as propriedades na assinatura do construtor! Veja o exemplo a seguir:

<?php

class Example {
    public function __construct(
        private int $a
    ) { }
}

Sim, isso é o equivalente ao primeiro exemplo, mas não preciso nem declarar a propriedade fora do construtor, nem atribuir o valor de uma variável do argumento. O PHP já faz isso pra mim nessa assinatura aí!

Tirando esse detalhe, outro fator muito importante para as versões mais recentes da linguagem é sobre os campos readonly, ou seja, somente leitura. Quando você cria uma propriedade que não pode ser alterada, significa que o único momento de todo o ciclo de vida do objeto em que podemos atribuir algum valor à propriedade é no construtor. Dá pra fazer um monte de coisa bacana, hein?

<?php

class Cents {
    public function __construct(
        public readonly int $value
    ) { }

    public function add(Cents $cents): Cents {
        return new static($this->value + $cents->value);
    }

    public function sub(Cents $cents): Cents {
        return new static($this->value - $cents->value);
    }

    public function toString(string $symbol = "R$ "): string {
        $str = "{$this->value}"; // só dá pra fazer isso aqui com inteiros pequenos, OK???
        return $symbol . preg_replace("/(\d{2})$/", ",$1", $str);
    }

    public static function fromFloat(float $num): Cents {
        return new static(intval($num*100));
    }
}

Com uma classe como essa, podemos fazer a seguinte brincadeira:

<?php

include_once( __DIR__ . "/Cents.php"); // ou substitua isso aqui pela classe criada anteriormente

$venda = new Cents(0);
$venda = $venda->add(Cents::fromFloat(1.20));
$venda = $venda->add(Cents::fromFloat(3.99));
$venda = $venda->add(Cents::fromFloat(5.32));
echo $venda->toString(); // R$ 10,51

// também é possível acessar a variável somente leitura
var_dump($venda->value); // int(1051)

Destrutores

Diferentemente do construtor, nós não temos a liberdade de injetarmos argumentos nos destrutores. Isso porque não somos nós que o acionamos, mas o interpretador do PHP. Para escrever um destrutor, basta adicionar um método __destruct na classe. Por exemplo:

<?php

class Example {
    public function __destruct() {
        echo "Adeus mundo!";
    }
}

Os destrutores são acionados somente em duas situações:

1. quando um objeto perde todas as referências ligadas a ele (isso seria o limbo absoluto para uma instância - felizmente o PHP consegue eliminar isso sozinho);
2. quando nós solicitamos propositalmente que o PHP o elimine.

Em ambos os casos, se trata do fim do ciclo de vida do objeto, então podemos sempre resumir dessa forma.

Pra que eu usaria isso, Kiko?

Olha, tirando Graceful Shutdown, eu nunca vi nenhuma outra aplicação que não fosse algum tipo de gambiarra. Isso que mencionei é basicamente uma garantia de que os recursos do seu sistema serão encerrados da melhor forma possível quando o servidor estiver prestes a ser desligado.

Um exemplo disso é quando o servidor recebe um comando de shutdown no meio de um processo onde coisas estão sendo armazenadas no banco de dados... Nesse cenário, faz sentido ter uma tratativa no objeto onde essas coisas estão acontecendo para evitar que os dados se percam, seja salvando todo o estado atual em algum lugar temporário para continuar quando o servidor iniciar novamente ou só direcionando para que outra máquina continue o trabalho.

O Graceful Shutdown não é a parte de controlar a máquina de estado do seu produto, somente a parte de garantir que, ao desligar, nada será brutalmente interrompido. Sacou?

Aí sim, faz sentido ter um destrutor.

Você também pode usar isso para centralizar o disparo de logs, mas isso pode dar muito errado. Vou dar um exemplo básico:

<?php

class Logger {
    public function __construct(
        private string $logs = ""
    ) { }

    public function log(string $message): void {
        $timestamp = date('Y-m-d H:i:s');
        $this->logs .= PHP_EOL . "[$timestamp] $message";
    }

    public function __destruct() {
        echo $this->logs;
        // imagine que, no lugar de echo, estaríamos registrando os logs onde quer seja
        // desse modo, os logs só seriam enviados quando o objeto responsável por acumular os logs fosse destruído
        // mas isso pode dar muito errado!
        // se você for armazenar num banco, por exemplo, o tempo de conexão pode não ser tão rápido quanto o comando de desligamento do servidor e aí você perderia esses logs todinhos :)
    }
}

O uso da classe acima seria:

<?php

include_once( __DIR__ . "/Logger.php"); // ou só trocar pela classe declarada acima

function exemplo(): void {
    $logger = new Logger();
    $logger->log("testando"); // nada acontece
    $logger->log("ue"); // nada acontece
} // quando a função morre, é que os logs vão parar no echo!

exemplo();

Observações importantes

1. Os destrutores são acionados mesmo se você tentar matar a execução do script com um exit();
2. Entretanto, se você acionar o exit() dentro de um destrutor, outros destrutores de outros objetos não serão executados;
3. Lançar exceções (Exception) dentro de um destrutor resultará em um erro fatal no PHP - não faz sentido acontecer isso num ciclo de destruição, não é mesmo? Se houver a mínima possibilidade de algo disparar uma exceção, encapsule com um try-catch e faça um tratamento, beleza?

E por hoje é só! Curtiu?? Comenta e compartilha!! Comecei a escrever esse artigo para testar meu novo teclado mecânico, o qual estou amando MUITO. Não sei porque não tinha aderido a isso ainda, é gostoso demais de digitar, hahaha. Dá uma saudade enorme de datilografar (sim, eu peguei o final do final dessa fase com a máquina de datilografar da minha mãe). De qualquer forma, estou tentando voltar, pessoal!

Vocês já conheciam o destrutor? Já fizeram alguma solução com ele que não foi uma gambiarra? Comenta aí! Confesso que me falta experiência com ele, por isso nem pude mostrar algo muito relevante sobre isso. Deixa sua marca, hein?

Inté!!

Antes de mais nada, qual seria a tradução da palavra "Namespace"?

"Espaço de nomes"? Bom, não tem uma tradução no dicionário e levar a composição da palavra ao pé da letra também não parece uma boa solução. Logo, o que você quer saber aqui não é sobre a escrita disso em português (que seria namespace mesmo) e sim o que ele significa, certo?

No contexto de Classes e Objetos, namespace tem o mesmo significado de grupo, na mesmíssima intenção da palavra workspace. Deram esse nome porque, no geral, a única coisa que muda quando se relaciona a um namespace é o seu nome absoluto.

Como assim, Kiko?

No artigo anterior, sobre autoloading, eu citei uma proposta sobre colocar a classe Evento dentro do namespace Entidades. Isso faz com que o nome que devemos utilizar para chamar essa classe mude para Entidades/Evento.

E como faz isso, Kiko?

Temos duas formas. Se você trabalha da forma recomendada pela maioria dos desenvolvedores PHP, você provavelmente fragmenta todo o seu projeto em vários arquivos .php, onde cada classe tem seu próprio arquivo.

A ideia de Namespace é possibilitar abstrairmos ainda mais as coisas, organizando cada arquivo em uma estrutura de pastas que deixe tudo mais organizado. Não que você não consiga fazer isso sem namespaces, mas certamente ele facilita na hora de criar um esquema de autoloading, como apresentei no artigo passado.

Então esse recurso tem como principal finalidade unir o poder de autoloading com organização, tirando a dificuldade de ficar usando include e require ou varrendo pastas inteiras para mapear classes e fornecendo a facilidade de mapear somente um namespace.

Ainda não entendi, Kiko...

Supomos que, na sua aplicação, todas as suas classes de domínio começam no namespace \Domain, enquanto as de infraestrutura começam no namespace \Infraestructure. O primeiro fica na pasta domain/ e o segundo na pasta infra/ (já é bem diferente do que está escrito no namespace).

Como você faria para incluir todos os domínios precedidos dele automaticamente via autoloading?

Reflita um pouquinho, tente exercitar se quiser ou pula direto pra resposta mais abaixo.

Conseguiu? Se sim, você já manja de namespace. Se não, vamos estudar um pouco mais. Se nem tentou, tudo bem também! Mas uma dica que te dou sobre programação é que só aprendemos de verdade quando colocamos em prática, beleza? Enfim, vamos lá.

<?php // autoload.php

// primeiramente, nós precisamos configurar nosso autoload
// de alguma forma, ele precisa saber que nomes de classes precedidos por "\Domain" serão convertidos para "/domain" e por "\Infraestructure" para "/infra"
// lembrem que a barra "/" do sistema de arquivos do sistema operacional pode ser diferente (alguns usam "/", outros "\"). nesse caso, sempre use a constante pré-definida DIRECTORY_SEPARATOR para evitar bugs desnecessários na sua vida
$autoloadNamespaces = [
    "\\Domain" => DIRECTORY_SEPARATOR . "domain",
    "\\Infraestructure" => DIRECTORY_SEPARATOR . "infra",
];

// agora que temos um dicionário indicando que todo namespace "\\Domain" vira "/domain" e "\\Infraestructure" vira "/infra", podemos registrar uma função de autoload

spl_autoload_register(function ($className) use ($autoloadNamespaces) {

    // para usar a função str_replace, nós precisamos separar tudo o que estamos buscando ($replaceFrom) de tudo o que queremos aplicar ($replaceTo)
    // quando essas duas entradas são arrays de comprimento igual, o PHP faz a substituição 1 para 1, de índice para índice
    // essa é uma dica legal hein? ;)
    $replaceFrom = array_keys($autoloadNamespaces); // array_keys pega todas as chaves do dicionário, ficando array("\\Domain", "\\Infraestructure")
    $replaceTo = array_values($autoloadNamespaces); // array_values pega todos os valores do dicionário, ficando array("/domain", "/infra")

    // Além dos namespaces, para usar o include_once corretamente, precisamos trocar todas as barras invertidas do namespace para a barra do sistema operacional (DIRECTORY_SEPARATOR)
    $replaceFrom[] = "\\";
    $replaceTo[] = DIRECTORY_SEPARATOR;

    // Então, acionamos o str_replace
    $className = str_replace($replaceFrom, $replaceTo, $className);

    // Daí incluímos o endereço, considerando que está no mesmo caminho desse arquivo
    include_once __DIR__ . DIRECTORY_SEPARATOR . "{$className}.php";
});

Se quiser testar na prática aí na sua máquina, cria uma index.php assim:

<?php

require_once __DIR__ . DIRECTORY_SEPARATOR . "autoload.php";

Depois cria algumas classes. Você pode explorar tanto só as pastas raízes (/domain e /infra) quanto subpastas para explorar mais namespaces. Exemplo: /domain/Entities e /infra/Database.

Daí chama essas classes na index e veja o autoload mágico acontecer!

E por hoje é só! Curtiu? Comenta e compartilha! Enquanto escrevia esse artigo, aproveitei para revisar o anterior. Acabei descobrindo que digitei duas funções erroneamente, a spl_autoload_register estava spl_register_autoload e str_replace estava replace. Peço desculpas caso alguém tenha se frustrado tentando executar os ensinamentos e tenha enfrentado alguma dificuldade com esses erros. Já corrigi lá.

Aiaiai se eu pudesse ter um code review nesse blog... Hahaha

Inté!!

Como assim, Kiko?

Se você programa seguindo a POO, você certamente vai transcrever várias abstrações de domínio da sua aplicação em classes. Por exemplo:

<?php

class Evento {
    public function __construct(
        public int $idEvento,
        public string $titulo,
        public string $detalhes,
        public string $dataInicio,
        public string $dataFim,
    ) { }
}

<?php

class Ingresso {
    public function __construct(
        public int $idIngresso,
        public int $idEvento,
        public int $idUsuario,
        public int $valorCentavos,
        public bool $foiPago,
    ) { }
}

Considerando essas duas classes hipotéticas, não faz sentido escrever as duas no mesmo arquivo, certo? E até aqui, nós chamamos as duas em um terceiro arquivo usando as operações de inclusão via include(), include_once(), require() ou require_once(), confere?

<?php

include_once __DIR__ . "/Evento.php";
include_once __DIR__ . "/Ingresso.php";

// faz o que quiser

Não tem nenhum problema em construir um sistema inteiro dessa forma. Você só vai precisar criar um arquivo exclusivo para inicialização, comumente chamado de bootstrap, onde você centralizaria toda essa chamada de includes e requires.

Isso só tem um grande problema: performance.

Você estará incluindo em todas as requisições do seu servidor, por exemplo, todas as classes que você já desenvolveu, incluindo aquelas que não irá utilizar. Isso faz sentido pra você?

Ah, Kiko, então ao invés de centralizar os includes e requires no bootstrap, eu tenho de fazer onde for precisar?

Também poderia fazer isso, mas é bem mais difícil de controlar as dependências de cada fluxo. Começar estruturando o projeto dessa forma é o jeito ideal de destruir esperanças de refatoração. Hahahah

Ah, Kiko, e se eu fizesse uma classe para tratar importações dinâmicas?

Até poderia dar certo. Eu cheguei a fazer isso no framework da primeira agência onde trabalhei. A ideia inicial era de modularizar a aplicação (que nem classes tinha antes) de forma a reduzir as importações. Assim, você usava a classe para importar módulos inteiros, não somente classes.

Funcionou bem, mas o problema resolvido não era exatamente o mesmo do proposto por aqui. Naquela época eu não conhecia o autoloading do PHP, caso contrário, não teria perdido meu tempo fazendo isso, hahaha.

Tá bom, Kiko, aceitei o fato de que tem alguma coisa melhor. Mostra isso logo!

OK, ok! O que você precisa é de apenas uma função!!

spl_autoload_register()

Com essa função, é possível ensinar ao PHP "o que fazer quando uma classe ou interface não-definida for acionada?". E é basicamente isso. Então você pode centralizar as suas classes em uma pasta e simplesmente ensinar o PHP a importar as classes a partir daquele diretório.

Por exemplo, digamos que você tenha um sistema de arquivos assim:

• /index.php: seu arquivo que é sempre executado em todas as rotas (seja via .htaccess, configuração no NGINX, no Apache, sei lá, mas você manda tudo passar por lá);
• /bootstrap.php: seu arquivo de inicialização, para centralizar coisas obrigatórias e onde iremos colocar o spl_autoload_register();
• /classes/Evento.php: aquela classe de evento que mencionei lá em cima;
• /classes/Ingresso.php: aquela outra classe (...);
• etc (outros arquivos irrelevantes no momento).

Note que já temos duas classes dentro da pasta /classes e que o arquivo de inicialização (que chama o spl_autoload_register) está logo acima dela. Portanto, a chamada pode ficar assim:

spl_autoload_register(function (string $className) {
    $slash = DIRECTORY_SEPARATOR; // isso aqui é a barra "/" de forma amigável para todos os sistemas operacionais
    $basePath = "{$slash}classes{$slash}";
    include_once __DIR__ . "{$basePath}{$className}.php";
});

Assim, quando o você chamar new Evento() em alguma parte do fluxo, o interpretador vai:

1. verificar se Evento é uma classe ou interface definida;
2. não sendo, irá verificar se nós definimos alguma instrução para tentar incluir uma classe indefinida;
3. como nós definimos, irá acionar a função que passamos como instrução, introduzindo nos argumentos o nome do que estamos tentando acionar: "Evento";
4. dentro da função, irá chamar include_once __DIR__ "/classes/Evento.php", que irá importar aquele arquivo que define a classe Evento;
5. por fim, irá tentar executar o new Evento(), com sucesso.

Nas próximas vezes que alguma coisa chamar a classe no mesmo fluxo, não precisará importar novamente pois a classe já está definida (saltando do passo 1 ao 5).

E isso não é tudo!

Se você usar namespaces, poderá deixar tudo ainda mais organizado, colocando o caminho do namespace em forma de pastas. Tudo o que precisaria mudar é colocar uma tratativa de barras, pois o namespace vem todo bugado para dentro da instrução.

No caso, ficaria algo assim:

spl_autoload_register(function (string $className) {
    $slash = DIRECTORY_SEPARATOR; // isso aqui é a barra "/" de forma amigável para todos os sistemas operacionais
    $basePath = "{$slash}classes{$slash}";
    $className = str_replace("\\", $slash, $className);
    include_once __DIR__ . "{$basePath}{$className}.php";
});

Então, se você armazena a classe Evento na pasta classes/Entidades e atribuindo o devido namespace (namespace Entidades;) antes da declaração da classe, ao chamar new Entidades\Evento(), o PHP iria rodar a instrução include_once __DIR__ . "/classes/Entidades/Evento.php" no passo 4.

Ok, Kiko, e qual é o real benefício disso?

Primeiramente, você ensina ao PHP sistematicamente onde encontrar classes indefinidas no seu sistema de arquivos. Isso automaticamente retirará a obrigação de sair importando todas as classes, mesmo onde não precisa. Deixa que o PHP encontre-as!

E, consequentemente, seus fluxos só importarão as classes que precisam. Maravilhoso, não é mesmo? E você pode ir muito além, criando uma função mais complexa para estruturar tudo o que for necessário.

É desse jeito que funciona o Composer. Exceto que você, como desenvolvedor, só precisa configurar o composer.json para mapear namespaces fictícios.

Por exemplo, no Laravel, todas as classes que são colocadas dentro da pasta app/ são acionáveis pelo namespace App. Se você olhar no composer.json do Laravel, vai encontrar isso aqui:

    // ...
    "autoload": {
        "psr-4": {
            "App\\": "app/",
            "Database\\Factories\\": "database/factories/",
            "Database\\Seeders\\": "database/seeders/"
        }
    },
    // ...

Esse trecho das configurações diz, basicamente, o seguinte:

1. Se a classe começar com o namespace App\\, retire esse namespace e procure o resto da instrução dentro da pasta app/ (a partir da raiz do projeto);
2. Se a classe começar com o namespace Database\\Factories\\ (...) dentro da pasta database/factories/;
3. Se a classe (...) Database\\Seeders\\ (...) database/seeders/.

E assim, ao compilar as dependências usando o composer, um arquivo grande de autoload será gerado dentro da pasta vendor/. Se você abrir, encontrará uma implementação bem genérica do spl_autoload_register, que é o que faz a mágica acontecer para gente.

Você sabia disso?? Hehehe, na época que descobri eu fiquei super fascinado por esse rolê, espero que tenha transmitido o mesmo sentimento pra você! E se curtiu, lembra de curtir e compartilhar, hein?! No próximo artigo voltaremos falando sobre Construtores e Destrutores, onde falaremos sobre o ciclo de vida dos objetos e é bem relacionado a outros assuntos como Graceful Shutdown. Não perca, hein?

Inté!!

As constantes em classes são declaradas da mesmíssima forma que as constantes do escopo global sem uso da função define(). Note que eu estou falando em declaração, não em uso e muito menos em escopo.

Ou seja, se para criar a constante CARNAVAL eu faço const CARNAVAL = "vale-night", o mesmo se aplicaria dentro de uma classe:

<?php
class Exemplo {
    const CARNAVAL = "vale-night";
}

E temos aqui a mesma sintaxe e limitações que menciono no artigo Constantes - Sintaxe, que são, em resumo:

• o primeiro caractere do nome da constante precisa ser uma letra ou underline (_);
• os próximos caracteres podem ser letras, underline ou números;
• o valor atribuído à constante só pode ser de tipos de dados primitivos escalares ou arrays contendo somente tipos (...) escalares.

Se alguma linha desse resumo te confundiu, peço que releia o artigo, tudo bem? Lá está um pouco mais detalhado.

Ok, Kiko, então o que muda?

A forma de acionar essa constante. Como ela está sendo declarada dentro de uma classe, é óbvio que, para acessar seu valor, você vai precisar usar o nome da classe de alguma forma. É uma sintaxe bem simples: NOME_DA_CLASSE::NOME_DA_CONSTANTE.

O que são esses quatro pontos (dois pontos duas vezes), Kiko?

Lembra que, quando você quer acessar uma propriedade de um objeto, você usa o operator de objeto ->? Assim como existe esse operador, temos um para acessar as propriedades de uma classe, que é os quatro pontos ::.

Portanto, se formos acessar aquela constante da classe anterior, seria algo como:

echo Exemplo::CARNAVAL; //vale-night

Hummm, interessante, Kiko! Então toda constante nas classes é pública?

NÃO

Antigamente eram, mas hoje o PHP nos dá a possibilidade de controlar a visibilidade das constantes nas classes. No artigo anterior, sobre propriedades, eu mencionei detalhes sobre como funcionam as visibilidades private, protected e public, certo? Nas constantes funcionam da mesma forma! Então deixo o link para revisar caso não lembre, hehe.

Por isso, é seguro dizer que constantes em classe tem escopos totalmente diferentes das constantes globais. Se você pode fazer uma constante ser visível somente dentro da classe, não tem como outra parte do código acessar aquilo, sabe? Diferente de constantes globais que podem ser acessadas de qualquer parte depois que forem declaradas.

Dito isso, vamos falar sobre um ponto muito importante.

Boas práticas

Não, eu não vou dizer como você tem de escrever o seu código. Eu vou falar o que é considerado boas práticas pela comunidade de desenvolvimento. Na real, é errado chamar algo de bom ou mal, porque o sentido aqui é sobre criar um padrão sólido que deixe o código compreensível e de fácil manutenção. Toda vez que alguém mencionar "boas práticas", lembre-se disso, tá bom?

Tá, Kiko, mas diz aí, o que que a comunidade diz sobre constantes em classes?

Não somente sobre constantes em classes, mas constantes no geral. É dito que é uma boa prática escrever as constantes com todas as letras maiúsculas, por exemplo. Também é importantíssimo que você controle bem as visibilidades das constantes: não tem porque algo ser visível em escopos onde sua existência não importa, sabe? Porém, se você não tem certeza de onde vai usar, tudo bem deixar no escopo global.

E outro detalhe que, na minha opinião, foi a minha maior lição de vida e que posso confirmar por experiência que impacta diretamente na manutenabilidade de código é: nunca deixe números mágicos no seu código.

Quando falamos em números mágicos, não estamos falando somente de números. Qualquer valor misterioso que está aplicado diretamente no código deve ser substituído por uma constante com um nome que descreva o que é aquele valor.

Por exemplo, se eu faço:

if ($status == 0) {
    throw new Exception();
}

Você entende qual é o status validado?

Não, né? Agora se eu faço:

if ($status == STATUS_INDEFINIDO) {
    throw new Exception();
}

Fica bem mais claro, concorda?

Nesse exemplo, a pessoa que está desenvolvendo provavelmente saberia que o status 0 é o status indefinido. Porém, parte do desenvolvimento é sobre escrever códigos para que OUTROS DESENVOLVEDORES façam manutenção no futuro. Então você deve pensar: se um novato pegar esse código, ele vai entender rapidamente o que está acontecendo?

É isso. Constantes funcionam bem aqui.

Legal, Kiko... Mas você usou uma constante global ali, não foi?

Sim! E falando em status, aquela constante poderia ser o valor de um Enum.

O que é isso, Kiko?

Se jogar no Google "o que é enum?", irá encontrar a definição mais comum que é:

(...) Enum(eração) é um tipo de dado abstrato, cujos valores são atribuídos a exatamente um elemento de um conjunto finito de identificadores escolhidos pelo programador (...)

E é isso mesmo. Enums servem para definir os possíveis valores de alguma coisa, atribuindo um nome mais claro para cada um desses valores. Antes do PHP 8.1, não existia nenhuma implementação de enums nativamente, então nós criávamos classes com constantes públicas dentro delas para fazer esse mapa e evitar números mágicos no código. Por exemplo:

class StatusEnum {
    const INDEFINIDO = 0;
    const PUBLICADO = 1;
    const RASCUNHO = 2;
}

// (...)

if ($status == StatusEnum::INDEFINIDO) {
    throw new Exception();
}

Com uma Enum bem definida no código, você não teria a necessidade de decorar os possíveis valores que pode atribuir.

Ah, Kiko, e como são os Enums no PHP 8.1?

MARAVILHOSOS

enum StatusEnum: int {
    case INDEFINIDO = 0;
    case PUBLICADO = 1;
    case RASCNHO = 2;
}

// (...)

if ($status == StatusEnum::INDEFINIDO) {
    throw new Exception();
}

Ah, Kiko, a usabilidade não é a mesma?

Absolutamente não. No caso dos Enums no PHP 8.1, nós temos as Enums e as backed values Enums. Atualmente só funciona com os tipos int e string. Se você faz apenas uma Enum (sem informar tipagem e valores), o interpretador automaticamente implementa um método cases que retorna um array com todos os cases que você criou.

Já se você usa o backed values enums, informando uma tipagem e os valores de cada case, o interpretador adiciona dois métodos:

• from, que serve até pra validar se um valor é um dos cases presente na Enum, disparando exception se não for;
• tryFrom, que é o mesmo que o from exceto que não dispara erro, apenas retorna nulo se não for um valor válido.

São métodos que teríamos de implementar na mão, se fôssemos desenvolver com classes, sabe? E eles vem nativamente.

Tá, Kiko, mas quando eu devo usar um backed value enum e quando não usar?

Quando você estiver desenvolvendo uma Enum cujos valores não importam fora do código, tanto a nível de resposta de requisição quanto a enviar para o banco de dados, você não precisa usar o backed value enum. Já se você está criando algo que será armazenado no banco ou que irá preencher a resposta da aplicação, é interessante atribuir os valores.

Eu já não vou dar mais detalhes sobre Enum por agora porque vai ser conteúdo de outro artigo, tudo bem? Só escrevi o necessário para complementar a importância das constantes no seu código.

Enums são sempre globais, porque estão ali para deixar o seu código mais legível em qualquer parte dele. Mas é válido lembrar que teremos constantes que não precisam ser globais, podem ser um dado específico de uma classe, sabe? Tem de fazer sentido estar ali ou não. Fechado??

Por hoje é só! Curtiu? Comenta e compartilha!! Eu demorei bem mais do que o esperado para voltar a escrever, né?! Tanto que só consegui tempo agora no carnaval, hahahaha. Feliz carnaval pra você, se estiver lendo antes/durante. Se já passou, bem, que sua vida seja verdadeiramente feliz!

Não sei o quanto vou demorar para escrever a continuação, por isso solta aí nos comentários "faz ele escrever, Jéssica!" para eu mostrar para minha esposa, assim ela vai me instigar mais a escrever também! HUEHUEHUE

Inté!!

E antes de começar, quero destacar um fato importante: mock não é para ser usado em tudo. Em algumas situações, o que você vai precisar é de um spy, que é bem menos "agressivo" que um mock. Então eu não estou dizendo que você deve mockar tudo em todos os testes, por favor. Se seu teste pode ser escrito de forma simples e clara sem ele, escreva sem!

Mas Kiko, o que é um mock?

O mock é um clone de alguma classe ou objeto, que serve para substituir a classe original de modo a te dar o controle sobre o que é esperado de acontecer durante o fluxo de testes.

Por exemplo, se você tem uma classe Panela que tem um método cozinhar(), em testes onde é preciso chamar esse método sem se importar com o que acontece dentro, você pode mockar a classe e criar a expectativa de que o método deve ser acionado pelo menos uma vez. Assim, se após a checagem isso não acontecer, uma falha será detectada.

Além desse cenário, o mock também serve para retirar dependências desnecessárias para o seu teste. Isso fica claro em situações onde uma classe tem acúmulo de responsabilidade e você quer testar somente uma delas. Para ignorar todas as outras, você vai mockar algumas classes chamadas ali dentro para criar retornos falsos, de modo que o teste não dependa do sucesso delas.

Interessante... Mas como funciona um mock, Kiko?

Via injeção de dependência. Isso é uma estratégia que depende inteiramente de como o seu projeto foi desenvolvido. Por exemplo, se você usa um framework com gerenciamento de container como o Laravel, o mock pode ser atrelado diretamente a uma classe. Assim, quando você for instanciar essa classe usando o gerenciador, o Laravel instanciará o mock no lugar da classe.

Outra forma de injeção é quando você não instancia classe alguma no seu código, recebendo isso como entrada via construtor ou algum método em específico, que exemplifiquei no artigo anterior.

Hum... Acho que entendi... Acho...

Então vamos ver na prática, continuando o exemplo da classe Panela:

class Panela
{
    public function __construct(
        private array $ingredientes
    ) { }

    public function cozinhar(): void
    {
        foreach($this->ingredientes as $ingrediente) {
            $ingrediente->aumentarTemperatura();
        }
    }
}

Para complementar, farei uma classe Ingrediente:

class Ingrediente
{
    protected float $congelado = 10.0;
    protected float $cru = 30.0;
    protected float $malCozido = 55.0;
    protected float $cozido = 65.0;
    protected float $bemCozido = 75.0;

    public function __construct(
        public readonly string $nome,
        protected float $temperatura = 25.0
    ) {
    }

    public function temperaturaAtual(): float
    {
        return $this->temperatura;
    }

    public function aumentarTemperatura(): void
    {
         $this->temperatura += 0.01;
    }

    public function estado(): string
    {
        if ($this->temperatura <= $this->congelado) {
            return "congelado";
        }

        if ($this->temperatura <= $this->cru) {
            return "cru";
        }

        if ($this->temperatura <= $this->malCozido) {
            return "mal cozido";
        }

        if ($this->temperatura <= $this->cozido) {
            return "cozido";
        }

        if ($this->temperatura <= $this->bemCozido) {
            return "bem cozido";
        }

        return "queimado";
    }
}

Nota: eu não manjo nada de cozinha, apenas chutei alguns valores.

Ué, Kiko, como vai funcionar isso tudo?

Eu vou explorar um pouco de Design Patterns aqui. Cada ingrediente será uma classe que herda essa base de ingredientes, precisando configurar somente o nome do ingrediente e sua temperatura inicial (vindo via construtor). Já a temperatura de cada estado, é uma configuração opcional da hierarquia.

Também podemos fazer um override no método aumentarTemperatura, já que cada ingrediente tem um tempo de cozimento diferente.

Isso nos permitirá configurar ingredientes completamente diferentes. Por exemplo:

class PeitoDeFrango extends Ingrediente
{ 
    public function __construct()
    {
        parent::__construct(
            nome: 'Peito de frango',
            temperatura: 20.0
        );
    }
}

class CoxaoMole extends Ingrediente
{ 
    public function __construct()
    {
        parent::__construct(
            nome: 'Coxão Mole',
            temperatura: 28.0
        );
    }
}

Com isso, você pode ter a seguinte usabilidade:

$coxaoMole = new CoxaoMole();
$panela = new Panela(ingredientes: [$coxaoMole]);

$repeticoes = 0;
while ($coxaoMole->temperaturaAtual() < 67.0) {
    $panela->cozinhar();
    $repeticoes++;
}

echo "Levou $repeticoes aumentos de temperatura para deixar o {$coxaoMole->nome} {$coxaoMole->estado()}!";

Brinque com o código: https://paiza.io/projects/MmMfRYUKATVnyER0NLw5oQ?language=php

Agora que montamos o nosso projetinho, vamos refletir sobre como podemos mockar alguma das classes citadas a fim de comprovar alguma coisa. Dada que a principal classe é a Panela e ela é a única que recebe outra em algum trecho do código, faz muito sentido que ela não seja mockada, somente suas dependências. No nosso experimento, ela só tem dependência com a classe Ingrediente.

E se você pensou dessa forma, você está plenamente certo(a). Ingrediente é o nosso alvo aqui. Se eu quero testar se a panela funciona, eu não preciso colocar um ingrediente de verdade, concorda? É só cozinhar qualquer coisa.

Nesse caso, nós vamos cozinhar um ingrediente falso. Para isso, nós precisamos criar essa classe falsa, por exemplo:

class IngredienteMock extends Ingrediente
{
    public function __construct()
    {
        parent::__construct(
            name: "Mock",
            temperatura: -50.0
        );
    }
}

Essa é uma classe falsa, que tem como único objetivo validar interações entre os ingredientes e a panela. Digamos que eu queira comprovar que a classe panela aciona o método aumentarTemperatura do ingrediente... Há várias formas de se fazer isso.

class IngredienteMock extends Ingrediente
{
    public bool $acionou = false;

    public function __construct()
    {
        parent::__construct(
            nome: "Mock",
            temperatura: -50.0
        );
    }

    public function aumentarTemperatura(): void
    {
        $this->acionou = true;
    }
}

E aí, no seu teste, você teria algo assim:

$ingrediente = new IngredienteMock();
$panela = new Panela(ingredientes: [$ingrediente]);
$panela->cozinhar();
if ($ingrediente->acionou) {
    echo "Acionou o método aumentarTemperatura()";
} else {
    echo "Não acionou o método aumentarTemperatura()";
}

Veja essa brincadeira aqui: https://paiza.io/projects/ppWVYgKRKjOxztCMzGIFPQ?language=php

Ah, então o Mock não necessariamente precisa fazer o que o código original faz, apenas registrar os métodos acionados, Kiko?

Exatamente. No geral, nós usamos o Mock para simular coisas. Então muitas vezes você vai ter um Mock que retorna algum resultado fictício para testar se esse resultado está influenciando no resto do código, etc.

A forma como montamos esse mock não é a ideal, na verdade, está bem longe! Afinal, nós temos diversas bibliotecas que nos fornecem várias classes auxiliadoras para clonar classes e tornar as verificações ainda mais assertivas.

Uma das bibliotecas mais usadas é a Mockery.io, que já vem integrada no PHPUnit e é bem simples de se usar. Por exemplo, aquele teste que fizemos poderia ser bem mais compacto:

$ingrediente = Mockery::mock(Ingrediente::class);
$ingrediente->shouldReceive('aumentarTemperatura')->once();

$panela = new Panela(ingredientes: [$ingrediente]);
$panela->cozinhar();

Se o método não for chamado, durante o processo de desconstrução do objeto, o Mockery lançará um erro. Seu teste não terá nenhum problema se for chamado conforme esperado (somente uma vez).

Conclusão

Embora o ato de mockar possa ser feito do zero, trabalhar com bibliotecas mais robustas e com um bom tempo de mercado pode ser uma escolha melhor. Até porque seu código fica mais legível e você perde menos tempo escrevendo os seus testes.

Outro detalhe é o fato de que Mocks estão aí para deixar seus testes mais focados, unitariamente falando. Se eu estou testando a panela, pouco importa o ingrediente, confere? Agora se eu estivesse testando o ingrediente, não teríamos o que mockar.

Se a classe que estiver mockando tiver algum método essencial para o teste (que faz parte do que está testando), não faça esse mock! No máximo, faça um spy, como mostra o Adam Wathan nesse artigo sobre Mockery mock vs spy. Não deixe brechas no seu teste!

E por hoje é só! Curtiu?? Comenta e compartilha! Acabei ficando até tarde escrevendo esse artigo só pra dar mais uma variada no blog. Prometo que no próximo eu voltarei com a série de PHP para Iniciantes, hahaha. Não deixa de acompanhar!

Inté!

O ponto forte deste artigo será sobre funções anônimas (closures). Se você não sabe nem o que é função, começa pelo meu artigo introdutório. Se já tem conhecimentos mas ainda se sente meio inseguro sobre o que é uma closure, lê meu artigo específico sobre Closures, Funções variáveis e Arrow Functions.

Há um outro pré-requisito que é estruturas de try-catch, que ainda não falei em nenhum artigo... Se só não souber isso, tenta ler assim mesmo. Ficando alguma dúvida, sinta-se a vontade para perguntar nos comentários ou mandando mensagem lá no meu BlueSky!

Agora que já estabeleci os pré-requisitos para nos aventurarmos na leitura de hoje, vamos nos jogar de cabeça!

Mas Kiko, o que é uma função auxiliar?

É um bom começo, não é mesmo? Quem programa com Orientação a Objeto há algum tempo pode ter a mesma sensação que eu tenho hoje, sobre parecer um tabu escrever qualquer função que não seja um método de uma classe. Porém isso não é tão errado assim, tem momentos que uma função deixa o código bem mais legível do que instanciar uma classe para chamar apenas um método, sabe?

Um exemplo bem legal sobre isso vem de um problema que investiguei no trabalho hoje sobre transações de banco de dados. Calma, você não precisa entender isso a fundo para sacar o que está acontecendo, apenas pega o resumo e você vai entender o problema geral.

Quando nós enviamos um comando para o banco de dados fora de uma transação, esse comando é persistido nos dados instantaneamente (leia-se, no momento que o banco processar o seu comando). Já dentro de uma transação, você pode efetuar vários comandos em sequência, mas eles só serão persistidos quando você fizer o commit dos comandos. Isso serve para, caso algo dê errado, você possa reverter todos os comandos de uma só vez.

Então você tem a seguinte situação:

1. Vou fazer vários comandos complexos, então inicio uma transação com o banco de dados;

2. Faço um comando;

3. Faço outro comando;

4. ... Faço vários comandos de banco de dados;

5. Se deu tudo certo, mando o sinal de commit e salto para o passo 7;

6. Se algo deu errado, reverto com o sinal de rollback e salto para o próximo passo;

7. Concluo transmitindo se deu certo ou não.

Em vários frameworks você terá uma classe que fornece esses comandos de banco de dados. Hoje eu vou me basear no Laravel, usando como referência a classe DB, que, por sinal, já fornece um método auxiliar sobre o que iremos ver mais abaixo.

Enfim, então você pode fazer os passos acima da seguinte forma:

DB::beginTransaction(); // passo 1
$success = false;
try {
    // passo 2
    // passo 3
    // ... passo 4
    DB::commit(); // passo 5
    $success = true;
} catch (Throwable $throwable) {
    DB::rollback(); // passo 6
    // eu colocaria um log aqui, mas não convém ao caso
}
return $success; // passo 7

O que é desagradável nessa situação, é ver essa estratégia repetida diversas vezes ao longo do código, sendo que temos pelo menos quatro passos iguais em todos os casos, concorda? Então por que não criar uma função que dá a possibilidade de executar um callabe?

Criando a função auxiliar transaction()

Se você encapsular isso tudo em uma função, teremos o seguinte cenário:

function transaction(): bool
{
    DB::beginTransaction(); // passo 1
    $success = false;
    try {
        // passo 2
        // passo 3
        // ... passo 4
        DB::commit(); // passo 5
        $success = true;
    } catch (Throwable $throwable) {
        DB::rollback(); // passo 6
    }
    return $success; // passo 7
}

Porém, os passos 2, 3, 4 e 7 não são exatamente responsabilidades dela. Isso precisa ser algo que possa ser criado do lado de fora dela... É aí que entra as funções anônimas: você dá para quem usar a função auxiliar o poder de escrever outra função para executar dentro.

Isso nos leva a criar um argumento callable $closure, chamando-o dentro da estrutura de try-catch:

function transaction(callable $closure): mixed
{
    DB::beginTransaction(); // passo 1
    $result = null;
    try {
        $result = $closure();
        DB::commit(); // passo 5
    } catch (Throwable $throwable) {
        DB::rollback(); // passo 6
    }
    return $result; // passo 7
}

Notou que mudei o $sucess para $result? Porque eu não quero forçar o desenvolvedor a só responder booleanos. Ele vai responder o que precisar e isso poderá ter a tipagem que precisar.

Se o PHP tivesse Generics, nós poderíamos forçar a criação de um tipo genérico, modificando a assinatura do argumento para algo como callable<Response> $closure e a assinatura da função para : Response. Assim poderíamos facilmente mapear a partir da criação das closures qual seria o tipo de resposta...

QUÊ?!

Ok, eu só estava pensando em como a linguagem ficaria ainda mais divertida se tivesse Generics, mas foi total fuga do tema: nota zero na redação. Mas, voltando ao assunto... Com o retorno mixed, o desenvolvedor já tem total controle para fazer algo assim:

transaction(function() {
    // passo 2
    // passo 3
    // ... passo 4
    return true; // sucesso
});

Você pode até ajudá-lo, dando opção para definir o valor padrão do retorno negativo:

function transaction(callable $closure, $defaultResult = null): mixed
{
    DB::beginTransaction(); // passo 1
    $result = $defaultResult;
    try {
        $result = $closure();
        DB::commit(); // passo 5
    } catch (Throwable $throwable) {
        DB::rollback(); // passo 6
    }
    return $result; // passo 7
}

Deixando o uso dessa forma:

transaction(
    function() {
        // passo 2
        // passo 3
        // ... passo 4
        return true; // sucesso
    },
    false // erro
);

De todo modo, isso ainda não está tão legal assim. A função faz o que promete: transaciona baseado no sucesso de tudo o que for executado na sua closure... Mas não te dá o controle de poder enviar sinal de commit quando quiser... Além de fornecer outros controles que vamos ver mais embaixo.

Para melhorar esse controle, você terá de ter uma classe de gerenciamento de transações, a qual irei chamar de TransactionManager. Ela terá os métodos públicos para inicializar a transação, comitar ou reverter:

class TransactionManager
{
    public function beginTransaction(): void
    {
        DB::beginTransaction();
    }

    public function commit(): void
    {
        DB::commit();
    }

    public function rollback(): void
    {
        DB::rollback();
    }

    public function bind(callable $closure): callable
    {
        return $closure->bindTo($this); // vincula a instância à closure
    }
}

Notou que coloquei um método bind? Esse método é o que vai tornar a execução de tudo bem mais legível... Você vai ver mais abaixo! Agora nós precisamos ajustar a função auxiliar para não chamar mais nada diretamente, apenas o gerenciador de transações:

function transaction(callable $closure, $defaultResult = null): mixed
{
    $transactionManager = new TransactionManager();
    $transactionManager->beginTransaction();
    $result = $defaultResult;
    try {
        $closure = $transactionManager->bind($closure);
        $result = $closure();
        $transactionManager->commit();
    } catch (Throwable $throwable) {
        $transactionManager->rollback();
    }
    return $result;
}

Ué, Kiko? O código ficou bem mais extenso de se ler... Não era pra ser simples?

Funções auxiliares raramente são simples. Elas estão ali para centralizar o grosso do código de modo que o seu controle, do lado de fora, seja simples. Quer ver na prática?

Bem, agora você pode controlar o commit e rollback de dentro da sua função:

transaction(
    function() {
        // passo 2
        $this->commit();
        // passo 3
        // ... passo 4
        return true; // sucesso
    },
    false // erro
);

Legal?! Percebeu que eu chamei $this->commit() dentro de uma closure que é chamada dentro de uma função? Em cenários comuns, isso resultaria em um belíssimo erro. O que nos possibilita chamar o $this aqui é aquele método bind que mencionei lá em cima.

Ele vincula a função anônima ao objeto $transactionManager, de modo que ela passa a ter praticamente o mesmo escopo dos outros métodos ali dentro. Eu acho isso iradíssimo! E esse é o ponto forte desse artigo, mas vamos além...

Kiko, e se eu quiser que alguma coisa rode após todo o fluxo de sucesso?

O céu é o limite! Você pode adicionar uma estrutura no gerenciador de transações para empilhar várias funções anônimas e chamar todas sequencialmente após qualquer commit. Para não deixar isso amarrado ao gerenciador de transações, vamos criar uma pilha de callbacks, pode ser? Chamarei de CallbackStackManager:

class CallbackStackManager
{
    private array $stack = [];

    public function addCallback(callable $callback): void
    {
        $this->stack[] = $callback;
    }

    private function popStack(): array
    {
        $stack = $this->stack;
        $this->stack = [];
        return $stack;
    }

    public function run(): void
    {
        foreach($this->popStack() as $callback) {
            $callback();
        }
    }
}

É um controle de pilha bem simples. Você vai adicionando suas funções anônimas com o método addCallback. Conforme o código for funcionando, em algum momento você irá rodar todos os callbacks chamando o método run(). Simples assim!

E o que é aquele popStack, Kiko?

É um método de segurança para evitar loops infinitos. Passei por um problema onde uma função desenvolvida por outra pessoa gerou um loop infinito por voltar ao ponto onde o código chamava o run() antes de resetar a stack. Com o método pop, você já reseta a stack antes mesmo de começar.

Ok, Kiko, e como unimos essa classe ao resto da obra de arte?

HEHEHE, primeiramente: nem pense em instanciar o CallbackStackManager dentro do TransactionManager. Se fizer isso, você estará gerando uma dependência interna... Essa classe precisa ser uma entrada no construtor do outro gerenciador, de modo a nos permitir mockar a dependência quando precisarmos escrever algum teste.

Na prática, já era pra termos escrito algum teste para validar nossa teoria... Mas aí iria ser mais um conhecimento de pré-requisito e eu quero tornar esse artigo mais acessível, ok? Se você não conhece o TDD (Test-Driven Development), recomendo a leitura.

Tá, tá, e como faz a parada?

Pra já:

class TransactionManager
{
    public function __construct(
        private CallbackStackManager $callbackStackManager
    ) { }

    public function runAfterCommit(callable $closure): void
    {
        $this->callbackStackManager->addCallback($closure);
    }

    public function beginTransaction(): void
    {
        DB::beginTransaction();
    }

    public function commit(): void
    {
        DB::commit();
        $this->callbackStackManager->run();
    }

    public function rollback(): void
    {
        DB::rollback();
    }

    public function bind(callable $closure): callable
    {
        return $closure->bindTo($this); // vincula a instância à closure
    }
}

O que alterei:

• incluí um construtor, recebendo uma instância da nova classe CallbackStackManager;

• incluí um método runAfterCommit para facilitar o uso na closure do desenvolvedor;

• incluí uma chamada ao callbackStackManager->run() dentro do método commit.

Lembrando que, em cada run(), o gerenciador apaga todas as funções anônimas da pilha.

Além dessas alterações, precisaremos modificar a função auxiliar:

function transaction(callable $closure, $defaultResult = null): mixed
{
    $callbackStackManager = new CallbackStackManager();
    $transactionManager = new TransactionManager($callbackStackManager);
    $transactionManager->beginTransaction();
    $result = $defaultResult;
    try {
        $closure = $transactionManager->bind($closure);
        $result = $closure();
        $transactionManager->commit();
    } catch (Throwable $throwable) {
        $transactionManager->rollback();
    }
    return $result;
}

O que modifiquei:

• instanciei a nova classe CallbackStackManager;

• adicionei a nova instância no construtor da classe TransactionManager.

E como seria o uso disso na prática, Kiko?

transaction(
    function() {
        // passo 2
        // passo 3
        $this->runAfterCommit(function() {
            event(new Event('bonequinho_criado'));
        });
        // ... passo 4
        return true; // sucesso
    },
    false // erro
);

Resultado final

class CallbackStackManager
{
    private array $stack = [];

    public function addCallback(callable $callback): void
    {
        $this->stack[] = $callback;
    }

    private function popStack(): array
    {
        $stack = $this->stack;
        $this->stack = [];
        return $stack;
    }

    public function run(): void
    {
        foreach($this->popStack() as $callback) {
            $callback();
        }
    }
}


class TransactionManager
{
    public function __construct(
        private CallbackStackManager $callbackStackManager
    ) { }

    public function runAfterCommit(callable $closure): void
    {
        $this->callbackStackManager->addCallback($closure);
    }

    public function beginTransaction(): void
    {
        DB::beginTransaction();
    }

    public function commit(): void
    {
        DB::commit();
        $this->callbackStackManager->run();
    }

    public function rollback(): void
    {
        DB::rollback();
    }

    public function bind(callable $closure): callable
    {
        return $closure->bindTo($this); // vincula a instância à closure
    }
}

function transaction(callable $closure, $defaultResult = null): mixed
{
    $callbackStackManager = new CallbackStackManager();
    $transactionManager = new TransactionManager($callbackStackManager);
    $transactionManager->beginTransaction();
    $result = $defaultResult;
    try {
        $closure = $transactionManager->bind($closure);
        $result = $closure();
        $transactionManager->commit();
    } catch (Throwable $throwable) {
        $transactionManager->rollback();
    }
    return $result;
}

OBS.: você não vai conseguir rodar esse código se só copiar e colar, pois falta importar a classe DB do Laravel/Lumen. Além disso, não está nada organizado... O ideal é que cada classe esteja em um arquivo separado, assim como a função auxiliar.

Se ainda assim, quiser ver isso funcionando para brincar um pouco, eu criei um projeto no site paiza.io para te fornecer o código pronto para brincadeira. Dá uma olhada: https://paiza.io/projects/Qrb2UOhRGHHH3hdEBDrMVg.

Como o objetivo era apenas mostrar um bom uso de funções auxiliares para simplificar a legibilidade do código, acredito que atingi o objetivo desse artigo. Só não sei se está tão claro assim pra quem nunca viu transações de banco de dados... Mas não era o foco, tá bom?

Curtiu?! Comenta e compartilha! E me conta o que mais gostou, o que mais odiou e se concorda que dá sim pra ter funções auxiliares legais nos projetos? Estou ansioso para saber sua opinião! Sei que esperava um artigo da série PHP para Iniciantes, mas hoje resolvi quebrar a rotina, hahahah.

Inté!!

1. Como declarar uma propriedade?
2. É possível determinar o tipo de uma propriedade nessa linguagem?
3. Essa linguagem possui controle de visibilidade?
4. Como acesso o valor de uma propriedade de um objeto?
5. Como altero o valor dessa propriedade?

São todas perguntas-chave que te farão entender mais rapidamente como a linguagem estudada funciona... Apesar de que nem todas tem o conceito literalmente chamado de "propriedade", você poderá encontrar a mesma intenção em nomes distintos.

Focando no PHP, você já sabe que a escrita de variáveis é precedida de $, certo? E que quando atribuímos um objeto a uma variável, na verdade, estamos apenas atribuindo uma referência ao objeto, o que significa que você nunca vai ter uma variável com um objeto irreferenciável.

Onde você quer chegar, Kiko?

Com uma particularidade tão agressiva, é lógico que a forma que interagimos com o que quer que esteja "dentro" do objeto é diferente das outras coisas que você viu até então. Por exemplo, em array, você poderia acessar um índice dele apenas encapsulando o índice desejado entre colchetes ([ e ]) logo após acessá-lo. A frase ficou confusa? Então deixa que eu mostro na prática:

<?php

$matriz = [
    [1, 0, 0],
    [0, 1, 0],
    [0, 0, 1],
];

// acessando a primeira linha da matriz
$primeiraLinha = $matriz[0];

// acessando a última coluna da primeira linha da matriz
$ultimaColuna = $primeiraLinha[2];
// OU
$ultimaColuna = $matriz[0][2]; // acessei o array $matriz, peguei o índice 0 - acessando outro array, depois peguei o índice 2

Quando eu quis acessar o array armazenado na variável $matriz, escrevi algo simples e fácil de entender, concorda? Mas a partir do momento que você precisa acessar um dado que está dentro de outro, o caos começa a crescer. Você deve evitar situações como essa sempre que possível. O código fica ilegível.

Agora voltando ao que estava falando sobre a particularidade de objetos... Para acessar um dado dentro de uma instância, você usa o operador de objetos (->, sinal de menos seguido do sinal de maior que), que é colocado imediatamente após um objeto. Ele irá te dar acesso ao que quer que exista na instância de acordo com a visibilidade atual. É literalmente $objeto-><alguma coisa aqui>.

Antes de te mostrar isso na prática, vamos responder aquelas perguntinhas pra seguir a ordem da evolução da minha linha de raciocínio?

1. Como declarar uma propriedade?

Quando falamos da declaração de propriedade, não estamos falando na criação de uma - sim, é possível criar uma propriedade não-declarada... E assim como isso é crime pra Receita Federal (quando falamos de imóveis), deveria ser crime aqui também.

Estamos falando, na verdade, no ato de definir suas características antes mesmo de utilizá-la, logo, isso só se aplica na escrita de classes. Concorda? A classe define as características de como seus objetos irão se comportar e é sobre isso que estamos falando.

Existe duas formas de declarar uma propriedade em uma classe:

1. a boa: {visibilidade} {opcional: tipo de dado primitivo} ${nome da propriedade};
2. a ruim: var ${nome da propriedade}.

Você conhecia essa segunda forma? Cavernosíssima. Há muito tempo escrevíamos da segunda forma pois o entendimento comum era de que as propriedades são variáveis dentro de uma classe. Felizmente isso evoluiu, embora a linguagem aceite essa escrita até hoje.

Por favor, finja que só existe a primeira forma:

<?php

class Exemplo
{
    private string $propriedade;
}

1.1. Destrinchando a declaração de propriedade

1.1.1. Visibilidade

O primeiro texto, private, remete a privacidade, que podem ser as seguintes:

• private: visibilidade privada, ou seja, somente métodos da classe onde estamos declarando podem acessar essa propriedade diretamente;
• protected: visibilidade protegida, ou seja, somente métodos da classe onde estamos declarando e das classes que herdarem as propriedades dela poderão acessar diretamente;
• public: visibilidade pública, todo mundo pode acessar diretamente.

Exemplos:

<?php

class Exemplo
{
    private string $myPrivate = "ola";
    protected string $myProtected = "mundo";
    public string $myPublic= "louco";

    public function getMyPrivate(): string
    {
        return $this->myPrivate;
    }
}

class ExemploHerdeiro extends Exemplo
{
    public function getMyProtected(): string
    {
        return $this->myProtected;
    }

    public function getMyPrivateWithError(): string
    {
        return $this->myPrivate;
    }
}

$exemplo = new Exemplo();
$exemploHerdeiro = new ExemploHerdeiro();

// se você descomentar a linha abaixo, receberá um erro:
// var_dump($exemplo->myPrivate);
// isso acontece porque, nesse escopo, fora da classe, essa propriedade não é visível
// então o interpretador dá um erro como se ela não existisse

// para acessar o valor de uma propriedade com visibilidade restringida, eu criei o
// método getMyPrivate, que retorna o valor dela:
var_dump($exemplo->getMyPrivate()); // string(ola)

// da mesma forma, se você descomentar a linha abaixo, também receberá um erro:
// var_dump($exemplo->myProtected);
// por ser protegida, é preciso expor seu valor em outro método
// como seu só escrevi esse método na classe herdeira (ExemploHerdeiro),
// então é preciso acessar por lá:
var_dump($exemploHerdeiro->getMyProtected()); // string(mundo)

// já a propriedade pública é acessível normalmente
var_dump($exemplo->myPublic); // string(louco)

// sendo pública, a classe herdeira também irá herdá-la de forma pública:
var_dump($exemploHerdeiro->myPublic);

// porém, a classe herdeira não consegue acessar nada que estiver privado na
// classe pai, como mostro no erro a seguir (descomente para ver):
// var_dump($exemploHerdeiro->getMyPrivateWithError());

1.1.2. Tipo de dado primitivo

Eu já te mostrei toda a seção sobre os tipos de dados primitivos existentes no PHP, certo? Você basicamente deve trabalhar com os tipos que sua propriedade irá aceitar.

Antes do PHP 8, você estava limitado a declarar somente um tipo por vez. Agora é possível declarar mais de um tipo aceito concatenando com o operador OU (|). Deixando isso mais flexível de modo a não precisar aceitar todos os tipos para aceitar mais de um. Mas mesmo sendo possível... Tente limitar sempre a um tipo, ok?!

1.1.3. Nomenclatura da propriedade

As regras são as mesmas de quando vamos escrever uma variável. Como eu já mencionei isso no artigo anterior (e acho que já ficou bem claro), vou evitar essa repetição, rs.

1.2. Outras novidades do PHP 8

Além dessas formas que te apresentei, a partir do PHP 8, passamos a ter novas possibilidades no que diz respeito a declaração de propriedades. Por exemplo: uma das dores de cabeça de escrever uma propriedade não-pública, é que muitas vezes somos forçados a escrever comandos get para dar acesso ao dado armazenado. Quando um dado é exposto somente para leitura, nós não poderíamos torná-lo public, pois isso iria expor, também, para escrita.

Agora nós podemos declarar um tipo de somente leitura informando a palavra-chave readonly.

1.2.1. Propriedade readonly

Essa definição deve ficar entre a visibilidade e o tipo de dado da propriedade, modificando aquela assinatura que escrevi mais cedo para {visibilidade} readonly {tipo de dado primitivo} ${nome da propriedade}. Simples, não? Com isso, você pode manter a propriedade pública, sem medo.

Quando declaramos uma propriedade readonly, o PHP irá limitar o escopo de alteração da mesma somente no processo de construção. Ou seja, se você tentar alterar o dado depois da instância estar construída, mesmo que executando dentro da própria classe, você terá um belo de um erro. Quer ver?

<?php // PHP 8.1

class Exemplo
{
    public readonly string $text;

    public function __construct(string $text)
    {
        // aqui podemos alterar
        $this->text = $text;
    }

    public function setText(string $newText): void
    {
        // aqui não podemos
        $this->text = $newText;
    }
}

$exemplo = new Exemplo("Ola mundo");
var_dump($exemplo->text); // string(Ola mundo)

// descomente para ver o erro
// $exemplo->setText("Adeus mundo");

// aqui também não podemos
// descomente para ver o erro
// $exemplo->text = "Adeus mundo";

Você pode rodar os códigos do PHP 8.1 no site 3v4l.org.

Ah, e quando eu digo que essa propriedade só pode ser escrita no construtor, significa que ela também não pode ter nenhum valor padrão.

<?php
class Exemplo
{
    public readonly int $vida = 42; // erro
}

Mesmo que não seja permitido alterar um dado, o readonly não impede mutação. Como você já sabe, objetos se tornam referências onde quer que você os atribua, seja em uma variável ou em uma propriedade.

Você não pode alterar de uma referência para outra, mas você pode alterar os valores dentro dessa referência:

<?php

class Exemplo
{
    public int $vida = 42;
}

class ExemploReadonly
{
    public readonly Exemplo $exemplo;

    public function __construct(Exemplo $exemplo)
    {
        $this->exemplo = $exemplo;
    }
}

$readonly = new ExemploReadonly(new Exemplo());
$readonly->exemplo->vida = 43; // permitido
var_dump($readonly->exemplo->vida);

// não permitido:
$readonly->exemplo = new Exemplo();

Então muito cuidado com o que você deixa readonly... Se sua intenção era proteger o dado dentro do objeto de ser alterado, era para aquele dado ser readonly também.

1.2.2. Declaração de propriedades via construtor

Se você já escreveu algumas classes em PHP, você já deve ter se deparado bastante com situações como essa:

<?php
class Exemplo
{
    private string $propriedade1 = "abc";
    private int $propriedade2 = 123;
    private array $propriedade3 = [];
    private float $propriedade4 = 3.21;

    public function __construct(
        string $propriedade1,
        int $propriedade2,
        array $propriedade3,
        float $propriedade4
    ) {
        $this->propriedade1 = $propriedade1;
        $this->propriedade2 = $propriedade2;
        $this->propriedade3 = $propriedade3;
        $this->propriedade4 = $propriedade4;
    }
}

Você não acha super redundante? Olha quantas vezes eu escrevi o mesmo nome só nesse trecho... E então, no PHP 8.0, trouxeram uma novidade que resolveu essa questão: declaração de propriedade em construtor.

Você só precisa incluir a visibilidade nos argumentos, então o interpretador sabe que precisa eleger aqueles argumentos como propriedades, ficando assim:

<?php

class Exemplo
{
    public function __construct(
        private string $propriedade1 = "abc",
        private int $propriedade2 = 123,
        private array $propriedade3 = [],
        private float $propriedade4 = 3.21
    ) {
    }
}

Bem mais simples, não?! Conseguiram unificar de uma vez só:

1. necessidade de declarar propriedade;
2. necessidade de declarar argumento;
3. necessidade de atribuir o argumento à propriedade.

Magnífico.

E com isso, você já sabe tudo o que precisaria saber sobre declaração de propriedades, o que nos leva à próxima pergunta.

2. É possível determinar o tipo de uma propriedade nessa linguagem?

Eu já respondi isso ao explicar que, na declaração da propriedade, é possível informar qual tipo de dados primitivos é esperado. Isso é realmente opcional. Se por algum motivo você não sabe com qual tipo irá lidar, é possível não colocar nada.

Logo, a resposta para essa pergunta é sim, é possível.

3. Essa linguagem possui controle de visibilidade?

Também respondi no momento em que mostrei em qual trecho da declaração nós determinamos a visibilidade da propriedade, confere? Nesse caso, informar a visibilidade também é opcional - exceto em declaração no construtor. Quando você não informa a visibilidade, o interpretador entende que é uma propriedade pública.

Mesmo que seja opcional, por favor, sempre determine qual a visibilidade desejada.

E a resposta para essa pergunta é sim, possui.

4. Como acesso o valor de uma propriedade de um objeto?

Lembra que mencionei o Operador de Objetos? Sinal de menos com sinal de maior que, ->. Esse operador serve para requisitar qualquer coisa de um objeto, incluindo uma propriedade. Se você escrever $objeto->nomeDaPropriedade, irá ler o dado da propriedade nomeDaPropriedade, se ela existir.

Veja um exemplo mais claro:

<?php // PHP 8.1

class Tomada
{
    public function __construct(
        public readonly string $corrente = '220v'
    ) { }
}

$tomada220 = new Tomada();
$tomada110 = new Tomada(corrente: '110v'); // named arguments, do PHP 8.0

// quanto é a corrente da tomada 220?
var_dump($tomada220->corrente); // string(220v)

// quanto é a corrente da tomada 110v?
var_dump($tomada110->corrente); // string(110v)

5. Como altero o valor dessa propriedade?

Usando o mesmo Operador de Objetos em conjunto com o Operador de Atribuição, é possível atribuir o valor a uma propriedade.

Basicamente, você só precisa acessar a propriedade que deseja atribuir um (novo) valor e colocar a atribuição que desejar. Por exemplo:

<?php // PHP 8.0
class Porta
{
    public function __construct(
        public string $status
    ) { }
}

const ABERTA = 'aberta';
const FECHADA = 'fechada';

$porta = new Porta(status: FECHADA);
// acessando:
var_dump($porta->status); // string(fechada)

// atribuindo:
$porta->status = ABERTA;

// confirmando, acessando novamente:
var_dump($porta->status); // string(aberta)

Você pode usar qualquer expressão de atribuição, até aquelas atribuições mescladas com outros operadores:

<?php
class Moeda
{
    public function __construct(
        public int $centavos
    ) { }

    public function saldo(): float
    {
        return $this->centavos / 100;
    }
}

$cinquenta = new Moeda(50);
$vinteECinco = new Moeda(25);
$dez = new Moeda(10);
$cinco = new Moeda(5);

$carteira = new Moeda(0.0);
$carteira->centavos += $cinquenta->centavos; // 50 centavos
$carteira->centavos *= 2; // 1 real
$carteira->centavos -= $dez->centavos; // 90 centavos
$carteira->centavos += $cinco->centavos * 2; // 1 real
$carteira->centavos /= $cinco->centavos; // 20 centavos
$carteira->centavos += $cinco->centavos; // 25 centavos

var_dump($carteira->saldo()); // float(0.25)

Legal, né? Hehe...

E então zeramos as perguntas, o que nos leva ao fim desse artigo. Curtiu?! Comenta e compartilha! Qual foi o melhor exemplo desse artigo? Quando eu estava escrevendo o código da tomada, estava pensando em criar um método tipo colocarODedo que responderia se você vive ou morre baseado na voltagem dela, hahaha. Mas acho que iria fugir muito do tema, então deixei pra lá.

E me conta aí: como tá sendo o aprendizado? Tem algum assunto que você tem muita dificuldade e quer ler em um artigo dedicado? Manda aí!

Inté!!

É de senso comum chamar a primeira de "básico", mas as próximas não são "intermediário" nem "avançado", pois aqui é tudo assunto pra iniciante, né?

E o que nós chamamos de básico é bem simples:

1. Como declarar uma classe;

2. O que é e como declarar propriedades ;

3. O que é e como declarar métodos.

E tem muitas outras coisas pra gente falar e que muita gente chama de básico, mas eu acho que não é bem assim.

Se você der uma espiada na documentação oficial do PHP, também verá a menção de outros recursos que eu já falei em outros artigos e não são tão relevantes assim, logo não irei mencionar. Se você começou a ler meu blog a partir desse artigo, estou me referindo às constantes pré-definidas e métodos mágicos. Recomendo a leitura!

Ok, Kiko, eu já vi alguma dessas coisas básicas em outro artigo?

Sim, quase tudo. Mas eu vou repetir esses pontos para te ajudar a reforçar sua base de conhecimento. Repetição é importante nesse processo, então... Vamos recapitular!

1. Como declarar uma classe

A declaração de classe é similar a qualquer estrutura de controle que agrupa conjuntos de instruções, onde precedimos tudo com a palavra reservada class, atribuímos um nome e depois encapsulamos sua estrutura entre chaves ({ e }), ficando:

<?php
class NossaClasse
{
    // conteúdo da classe
}

Notou que eu escrevi a primeira letra da classe com letra maiúscula? Isso não é uma regra da linguagem, mas uma boa prática. As regras de escrita são as mesmas da escrita de variáveis:

• só começa com uma letra ou underline;

• pode ter números.

E o mais importante de tudo é que esse nome precisa fazer sentido quando você for acionar seus recursos. Por exemplo, faz sentido nomear uma classe que gerencia banco de dados de Gerente? Primeiro que o termo correto para o papel seria Gerenciador, segundo que o que o diferencia dos demais é o fato de ser sobre banco de dados. Então não faria sentido algum dar somente esse nome para a classe.

Kiko, eu vi na internet algumas pessoas discutindo se era melhor escrever em inglês ou português... O que você acha?

Eu não acho é nada, rs. Eu defendo que o time tem de definir em conjunto. Se você vai trabalhar sozinho, então reflita bastante sobre quais profissionais poderão trabalhar no seu código no futuro e vise fornecer um código legível para a maioria. Colocando isso em pauta e falando do meu contexto, acho que o inglês deixa o código mais fácil de ler, pois as palavras reservadas são escritas nesse idioma e o PHP foi feito para ter legibilidade semântica. O único lugar onde a mistura de idiomas consegue fazer sentido de algum jeito é nas músicas asiáticas (pode discordar, mas eu gosto de algumas que todos os versos são no idioma da banda e, de repente, vem uma frase em inglês hahaha).

De todo modo, não feche sua mente pensando "só se programa desse jeito", porque isso é uma mentira.

Dito isso, vamos mudar nosso exemplo para:

<?php
class OurClass
{
    // ...
}

2. O que é e como declarar propriedades de uma classe

Propriedades, além de imóveis, também é um termo utilizado para referenciar aquilo que se apropria. Eu acho estupidamente vago, e você?

Mas quando estamos falando de Orientação a Objeto, propriedade é qualquer informação que um objeto pode conter. E por informação, nós estamos falando de tipos de dados primitivos.

Portanto, propriedade aqui é qualquer informação que você desejar atrelar à sua classe. Por exemplo, digamos que você quer construir a classe Caderno. Para fazer isso, você deve refletir: o que um caderno tem que poderia ser diferente dos outros?

• a. Marca?

• b. Quantidade de páginas?

• c. Quantidade de seções?

• d. Quantidade de páginas por seção?

• e. Quantidade de figurinhas?

• f. Tema?

Cada um desses pontos pode ser uma propriedade dessa nova classe. Eu digo pode porque alguma dessas questões podem ser relacionamentos também, o que seria um pouco mais complexo de explicar. Por agora, vamos apenas criar uma classe tendo isso tudo como propriedades:

<?php
class Caderno
{
    public $marca;
    public $page_quantity;
    public $section_quantity;
    public $pages_per_section;
    public $sticker_quantity;
    public $theme;
}

Ué, Kiko... Você criou variáveis dentro da classe?

Basicamente. Isso é uma propriedade. Porém, a forma que coloquei é a pior possível, pois não estou especificando nada além do nome da propriedade e deixando tudo completamente visível. A forma ideal é colocarmos:

• o tipo de dados primitivos que aceitamos;

• a visibilidade que precisamos.

Supondo que essas propriedades sejam acessíveis de forma pública, podemos manter cada uma das declarações precedidas pela palavra reservada public. Isso significa que você poderá acessar e alterar a informação a partir de qualquer parte do código. Se você quer que seja acessível somente pela própria clase e outras que herdarem algo dela, então use a visibilidade protected. Se não houver nenhuma necessidade de ter isso acessível de fora da classe, use o private.

Sobre a tipagem, o que for texto será string e o que for quantidade será int.

Vamos reescrever a classe agora?

<?php
class Caderno
{
    private string $marca;
    private int $page_quantity;
    private int $section_quantity;
    private int $pages_per_section;
    private int $sticker_quantity;
    private string $theme;
}

Kiko, por que você deixou tudo private?

Como eu não tenho nenhum uso fora da classe, ainda, convém deixar tudo assim mesmo. A menos que apareça uma real necessidade de modificar a visibilidade, aí sim nós mudamos.

Com isso, nós conseguimos definir propriedades à classe que queremos criar. Porém, temos alguns problemas aqui:

1. Qual é o valor padrão de cada propriedade?

2. Como definir um valor inicial quando instanciarmos a classe?

Bem, para determinar um valor padrão na sintaxe que estamos usando, basta chamar o operador de atribuição e colocar o tal valor:

<?php
class Caderno
{
    private string $marca;
    private int $page_quantity = 125;
    private int $section_quantity = 5;
    private int $pages_per_section = 25;
    private int $sticker_quantity = 20;
    private string $theme = "Abstrato";
}

É desnecessário comentar, mas, lembre que o dado padrão precisa respeitar a tipagem que você definiu.

E sobre atribuir os valores iniciais, para isso precisaremos escrever um método mágico usado no processo de construção de um objeto.

3. O que é e como declarar métodos

O método que veremos a seguir é chamado de Construtor e é acionado toda vez que você usar o operador new na sua classe (ex: new Caderno()), mesmo se você não defini-lo.

O nome desse método deve ser escrito dessa forma: __construct, ficando assim:

<?php
class Caderno
{
    private string $marca;
    private int $page_quantity = 125;
    private int $section_quantity = 5;
    private int $pages_per_section = 25;
    private int $sticker_quantity = 20;
    private string $theme = "Abstrato";

    public function __construct()
    {
    }
}

Note que esse método precisa ter a visibilidade public, por isso já a escrevi por padrão. Outros métodos poderiam ter a visibilidade que você precisar. Lembre de nunca dar liberdade demais a um método ou propriedade, use somente o que precisa.

E assim como funções, você pode passar argumentos de entrada e usa-los com as propriedades do novo objeto. Por exemplo:

<?php
class Caderno
{
    private string $marca;
    private int $page_quantity = 125;
    private int $section_quantity = 5;
    private int $pages_per_section = 25;
    private int $sticker_quantity = 20;
    private string $theme = "Abstrato";

    public function __construct(
        string $marca,
        int $page_quantity = 125,
        int $section_quantity = 5,
        int $pages_per_section = 25,
        int $sticker_quantity = 20,
        string $theme = "Abstrato"
    )
    {
        $this->marca = $marca;
        $this->page_quantity = $page_quantity;
        $this->section_quantity = $section_quantity;
        $this->pages_per_section = $pages_per_section;
        $this->sticker_quantity = $sticker_quantity;
        $this->theme = $theme;
    }
}

Notou que eu praticamente repeti toda a assinatura da classe? Bem, no PHP 8 fizeram uma parada muito legal que é a Definição de Propriedade via Constructor (tradução não-literal para constructor property promotion). Tudo isso que eu escrevi pode ser reescrito da seguinte forma no PHP 8:

<?php
class Caderno
{
    public function __construct(
        private string $marca,
        private int $page_quantity = 125,
        private int $section_quantity = 5,
        private int $pages_per_section = 25,
        private int $sticker_quantity = 20,
        private string $theme = "Abstrato"
    )
    {
    }
}

Com o termo de visibilidade escrito antes do argumento, o interpretador sabe que você quer transformar aquele argumento em uma propriedade da classe. No PHP 8.1 ainda veio a opção de somente leitura, isto é, propriedades que funcionam como a visibilidade public mas somente para acessar o dado. Se você tentar sobreescrever, não funcionará.

Enfim, com essa definição toda, você pode, finalmente, instanciar um objeto:

// PHP 8: Argumentos nomeados
$caderno = new Caderno(
    marca: "KG",
    page_quantity: 60,
    section_quantity: 2,
    pages_per_section: 30,
    sticker_quantity: 0,
    theme: "PHP is the best"
);

Em caso de versões anteriores ao PHP, você não poderá indicar o que está populando, apenas seguir a ordem da assinatura dos métodos.

Achou complexo? Foi muita coisa de uma vez?! Bem, isso foi apenas o básico, aquele choque de realidade que sou obrigado a te passar... Mas com certeza iremos ver todos esses tópicos bem mais mastigados nos próximos artigos. Espero não demorar tanto quanto demorei pra lançar esse, hehe.

Curtiu?! Comenta e compartilha! Ainda não segue meu BlueSky? Corre lá!! E não deixa de avisar os amigos que o pai de gêmeas está de volta! ;P

Inté!!