Forem: Lucas Mateus

Print não é log: Melhore seu debug com logging

Lucas Mateus — Mon, 28 Jul 2025 19:23:51 +0000

Quando começamos a programar em Python, é quase instintivo usar print() pra tudo: pra ver se a função foi chamada, se o valor tá certo, onde deu erro… e por aí vai. E tudo bem, é simples, direto e funciona.

Mas conforme os projetos crescem, os prints começam a virar uma bagunça. Chega uma hora que fica difícil saber o que é debug, o que é erro, o que é só informação, resumindo, entender qualquer coisa quando o sistema quebra em produção será uma tarefa árdua. Mas aí que entra uma solução bem mais interessante, nativa do próprio Python, o módulo logging.

Mas porque usar logging?

Se você já tentou depurar um problema em produção só com os prints do código, sabe como essa tarefa pode ser difícil. Prints não têm contexto, não têm níveis, não vão para lugar nenhum além do terminal, e o pior: não foram feitos pra isso.

O logging, por outro lado, é um sistema de registro de eventos muito mais completo e organizado. Ele permite classificar mensagens por níveis de importância, o que ajuda a entender rapidamente a gravidade de cada evento. Além disso, é possível salvar esses logs em arquivos ou enviá-los para serviços externos como sistemas de monitoramento. O logging também registra informações detalhadas, como o horário em que o evento ocorreu, o módulo responsável e até a linha de código onde a mensagem foi gerada, o que pode facilitar e muito na resolução de problemas.

import logging

logging.basicConfig(
    filename='meu_app.log',
    level=logging.DEBUG,
    format='%(asctime)s - %(levelname)s - %(message)s'
)

logging.info("Esse log vai parar num arquivo!")

Um aspecto interessante que esse módulo traz é o controle sobre quando e onde essas mensagens aparecem, o que permite, por exemplo, ter diferentes configurações de log para ambientes de desenvolvimento, testes e produção, permitindo registros mais úteis e contextuais para cada situação.

import logging

logging.basicConfig(level=logging.INFO)

logging.debug("Mensagem de debug")      # não será exibida devido nível mínimo ser info
logging.info("Mensagem de informação")
logging.warning("Alerta!")
logging.error("Erro aconteceu!")
logging.critical("Problema crítico!")

Como integrar Logging nos seus projetos

Até aqui nós vimos como o logging funciona na teoria, mas de nada adianta sem saber como usar na prática, trarei um exemplo de uso em uma das grandes tecnologias usadas no ecossistema Python, o Django.

O Django já vem preparado para lidar com logs nativamente. A configuração é feita no settings.py, usando um dicionário que define formatadores, destinos e níveis.

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'padrao': {
            'format': '[%(asctime)s] %(levelname)s %(name)s: %(message)s',
        },
    },
    'handlers': {
        'console': {
            'level': 'DEBUG',
            'class': 'logging.StreamHandler',
            'formatter': 'padrao',
        },
    },
    'loggers': {
        'meu_app': {
            'handlers': ['console'],
            'level': 'DEBUG',
            'propagate': False,
        },
    },
}

Com essa configuração feita, o logging pode ser chamado nos seus apps, e ao chamar o método logging.getLogger('meu_app') ele buscará as os devidos formatadores e destinos que foram declarados no arquivo de configuração.

# signals.py
...
logger = logging.getLogger('meu_app')

@receiver(post_save, sender=User)
def enviar_email_boas_vindas(sender, instance, created, **kwargs):
    if not created:
        return  # só envia na criação

    try:
        send_mail(
            subject="Bem-vindo!",
            message=f"Olá {instance.username}, seja bem-vindo à plataforma!",
            from_email="noreply@meusite.com",
            recipient_list=[instance.email],
            fail_silently=False,
        )
        logger.info(f"E-mail de boas-vindas enviado para {instance.email}")
    except Exception as e:
        logger.exception(f"Erro ao enviar e-mail de boas-vindas para {instance.email}")

Com isso, seguindo a formatação definida nas configurações o log registrado com esse signal seria assim:

[2025-07-28 13:47:12] INFO meu_app: E-mail de boas-vindas enviado para fulano@email.com

Conclusão

O módulo logging parece simples, e é, mas simplicidade não é sinônimo de inutilidade. Ele te dá mais segurança, rastreabilidade e organização para lidar com qualquer aplicação que precise ser monitorada, analisada ou debugada de forma mais profissional. Não importa se você está construindo uma API, um sistema de filas, uma aplicação web ou mesmo scripts pontuais. Se você precisa saber o que está acontecendo, usar logging é o caminho natural.

Referências

logging — Logging facility for Python
logging in python
Logging - Django Documentation
How to configure and use logging- Django Documentation

Como e quando usar Django Signals

Lucas Mateus — Tue, 22 Jul 2025 22:13:38 +0000

O padrão Observer

Antes de abordarmos as signals no Django, vale entender o padrão de design que as inspira: o Observer.

O padrão Observer, também conhecido como "publicador-assinante" (ou pub-sub), consiste em definir um mecanismo onde certos objetos (os observadores) reagem automaticamente a mudanças em outro objeto (o sujeito). Isso é útil quando você quer que partes diferentes do sistema fiquem "de olho" em algum evento e ajam quando ele ocorrer, sem precisar acoplar diretamente os componentes envolvidos.

No contexto do Django, o sujeito geralmente é um model (por exemplo um User) e os observadores são funções que você registra para reagir a eventos como salvar ou deletar esse modelo. Sempre que um desses eventos acontece, todos os observadores registrados são notificados automaticamente.

Esse padrão ajuda a manter responsabilidades separadas, evitando que toda a lógica fique concentrada na view, no serializer ou no próprio model. Mas como veremos mais adiante, ele também pode ser uma armadilha se usado sem critério.

Introdução

As signals no Django oferecem uma maneira de reagir a eventos internos do framework. Por exemplo, você pode executar uma ação sempre que um objeto for salvo, deletado ou tiver uma relação alterada. São muito uteis principalmente quando temos varias partes do código que precisam observar os mesmos eventos. A promessa de "desacoplamento" é muito atrativa: você consegue executar lógicas importantes sem poluir sua view ou serializer com responsabilidades extras.

No entanto, com o tempo, o uso indiscriminado de signals pode tornar seu código imprevisível, difícil de testar e ainda mais difícil de manter. Nessa publicação, vou mostrar como usar Django signals de forma clara e controlada, além de discutir em quais casos elas devem ser evitadas.

O que são Django Signals?

As signals permitem conectar funções a determinados eventos do ciclo de vida de um objeto. Por exemplo, o post_save é executado depois que um objeto é salvo, e o pre_delete é chamado antes de um objeto ser deletado.

Essas funções são chamadas automaticamente quando o evento ocorre. Isso é feito com a função connect ou usando o decorador @receiver.

Vejamos um exemplo simples: após salvar um novo usuário, um e-mail de boas-vindas é enviado.

from django.db.models.signals import post_save
from django.dispatch import receiver
from django.contrib.auth.models import User
from .utils import enviar_email_de_boas_vindas

@receiver(post_save, sender=User)
def enviar_email_apos_cadastro(sender, instance, created, **kwargs):
    if created:
        enviar_email_de_boas_vindas(instance.email)

O decorator @receiver conecta essa função ao evento post_save do modelo User. Sempre que um novo usuário for criado, a função será executada automaticamente.

Exemplos práticos de uso

Outro uso comum de signals é a remoção de arquivos físicos relacionados a um model quando ele for deletado, pois como sabemos o Django por padrão salva os arquivos (fotos, pdfs e etc) em um diretório escolhido em disco. Suponha que você tenha um model Documento com um campo arquivo que armazena o caminho do arquivo em disco. Ao deletar esse objeto, você pode garantir que o arquivo também seja removido:

@receiver(pre_delete, sender=Documento)
def deletar_arquivo_fisico(sender, instance, **kwargs):
    instance.arquivo.delete(save=False)

Também é possível usar signals para reagir a alterações em relações ManyToMany. No exemplo abaixo, quando alunos são adicionados a um curso, a aplicação registra o evento:

from django.db.models.signals import m2m_changed

@receiver(m2m_changed, sender=Curso.alunos.through)
def logar_mudancas_em_alunos(sender, instance, action, pk_set, **kwargs):
    if action == "post_add":
        print(f"Alunos adicionados ao curso {instance.id}: {pk_set}")

Quando não usar signals

Apesar da utilidade, signals não são indicadas para toda e qualquer lógica. Um dos principais problemas é que elas introduzem comportamentos "ocultos" no sistema. Isso pode tornar o fluxo da aplicação difícil de entender, já que a lógica associada não está visível no lugar onde a ação original acontece.

Por exemplo, imagine que você cria um pedido (Order) e, em algum lugar escondido, uma signal gera uma fatura. Se essa signal falhar silenciosamente ou não for executada, a fatura simplesmente não será criada. E o pior: você provavelmente nem vai notar.

Além disso, signals não garantem a ordem de execução entre si. Se você tem duas functions escutando o mesmo evento e espera que uma rode antes da outra, está assumindo algo que o Django não promete.

Outro problema comum é que signals não têm acesso direto ao contexto da requisição. Se você precisa saber quem é o usuário autenticado que disparou um evento, ou acessar dados da request, esse tipo de lógica não deve estar numa signal.

Por isso, lógica de negócio importante ou complexa não deve depender de signals. Nesses casos, é melhor usar métodos explícitos.

Alternativas mais claras

Uma abordagem mais controlada é encapsular a lógica em uma camada de serviço. Isso significa criar funções que executam ações de negócio de maneira previsível e que você chama diretamente da view, serializer ou command.

Por exemplo, ao invés de criar um usuário e deixar a signal cuidar do envio de e-mail, você pode fazer isso em uma função de serviço:

def criar_usuario_e_enviar_email(data):
    user = User.objects.create(**data)
    enviar_email_de_boas_vindas(user.email)
    return user

Esse padrão torna a lógica mais clara, mais fácil de testar e reduz o acoplamento entre os componentes.

Outra opção é sobrescrever os métodos save() ou delete() do modelo. Isso é útil quando a lógica está diretamente relacionada à integridade do próprio objeto, como deletar um arquivo ao excluir um modelo:

def delete(self, *args, **kwargs):
    self.arquivo.delete(save=False)
    super().delete(*args, **kwargs)

Testando signals de forma segura

Signals podem dificultar a criação de testes, principalmente quando geram efeitos colaterais. Para contornar isso, você pode usar mock.patch para simular funções chamadas pela signal, evitando que a lógica externa seja realmente executada durante o teste.

from unittest import mock

with mock.patch("app.signals.enviar_email_de_boas_vindas"):
    response = client.post("/api/usuarios/", data)

Outra opção é desconectar a signal durante o teste:

from django.db.models.signals import post_save
post_save.disconnect(enviar_email_apos_cadastro, sender=User)

Ambas as técnicas ajudam a garantir que seus testes sejam confiáveis e não dependam de eventos implícitos.

Conclusão

Django Signals são úteis para acionar efeitos colaterais de forma automática e desacoplada. Mas sua aparente simplicidade pode esconder perigos: acoplamento oculto, falta de controle sobre o fluxo e dependência de eventos implícitos.

Use signals para tarefas secundárias, como logs, manipulação de arquivos ou notificações simples. Para lógica de negócio central, prefira abordagens explícitas, como uma camada de serviço.

Um bom critério é se perguntar: essa lógica precisa ser previsível, rastreável e testável? Se sim, não deve estar em uma signal.

Esse tipo de clareza é o que diferencia sistemas sustentáveis de sistemas frágeis. O uso consciente dessa ferramenta pode melhorar bastante a arquitetura da sua aplicação ou destruí-la silenciosamente.

Referências

Essa publicação foi baseada no que consta na própria documentação do Django que pode ser vista nesse link.

Você também pode querer aprender um pouco mais sobre o Observer, então fica aqui minha indicação de um conteudo bem simples e educativo a respeito desse e dos demais padrões de projeto, só dar uma olhadinha nesse link.

Django ORM: consultas complexas pt.2

Lucas Mateus — Thu, 10 Jul 2025 16:13:03 +0000

Na parte 1 falamos sobre F, Subquery e Window que são otimos recursos nativos do Django ORM que resolvem muitos problemas complexos sem sair do Python.

Agora chegou a hora de explorar ainda mais os recursos desse ORM.

Testando existência de dados sem JOIN

A classe Exists permite incluir subqueries que retornam True/False na cláusula WHERE ou como anotações, o que pode ser extremamente útil para filtros booleanos complexos. Vejamos o exemplo a seguir onde faremos uso também do que aprendemos na parte 1, o OuterRef.

# Exemplo: clientes com pedidos
from django.db.models import Exists, OuterRef
from pedidos.models import Pedido
from clientes.models import Cliente

pedidos_do_cliente = Pedido.objects.filter(
    cliente=OuterRef('pk')
)

clientes = Cliente.objects.annotate(
    tem_pedido=Exists(pedidos_do_cliente)
).filter(tem_pedido=True)

# ou a versao inline desse codigo
clientes = Cliente.objects.annotate(
    tem_pedido=Exists(
        Pedido.objects.filter(cliente=OuterRef('pk'))
    )
).filter(tem_pedido=True)

-- equivalente em sql
SELECT *
FROM clientes_cliente c
WHERE EXISTS (
    SELECT 1
    FROM pedidos_pedido p
    WHERE p.cliente_id = c.id
);

Usar Exists é mais eficiente em muitos casos porque o banco de dados para de procurar assim que encontra um único registro correspondente, evitando a leitura desnecessária de várias linhas (como ocorreria com um JOIN). Além disso, Exists evita duplicatas na tabela principal, que podem surgir com JOIN 1:N, e geralmente resulta em planos de execução mais rápidos para checagens booleanas simples como "existe ou não".

Lógica condicional

Lógica condicional no SQL permite executar diferentes ações ou retornar diferentes valores com base em condições específicas, funcionando de forma semelhante às estruturas if/else de outras linguagens. Ela é usada principalmente com as expressões CASE, IF e COALESCE (veremos esse logo a frente), permitindo que o SQL avalie condições e retorne resultados dinâmicos conforme os dados da consulta. Isso é útil, por exemplo, para categorizar registros, substituir valores nulos ou criar colunas calculadas com base em regras. Como podem adivinhar, o ORM do django fornece estruturas para aplicarmos essa lógica sem sair do python, as classes Case e When.

# Exemplo: classificar clientes como VIP
from django.db.models import Case, When, Value, CharField

clientes = Cliente.objects.annotate(
    status=Case(
        When(gastos__gt=1000, then=Value('VIP')),
        default=Value('Regular'),
        output_field=CharField()
    )
)

SELECT *,
       CASE
           WHEN gastos > 1000 THEN 'VIP'
           ELSE 'Regular'
       END AS status
FROM clientes_cliente;

Além da propria consulta, essa classes podem ser usadas em ordenções:

from django.db.models import Case, When, Value, IntegerField
from clientes.models import Cliente

clientes = Cliente.objects.order_by(
    Case(
        When(status='VIP', then=Value(0)),
        default=Value(1),
        output_field=IntegerField()
    ),
    'nome'
)

Lidando com valores Nulos

Existem situações onde no banco de dados existem campos que podem ser nulos (ai já é culpa de que projetou o banco rsrs), mas isso pode acabar com outras operações que usem esse campo, o django oferece ferramentas para lidar com isso, a classe Coalesce, onde é feita a verificação se um campo é nulo, e definido um valor padrão para não quebrar os resultados esperados. Vejamos esse exemplo onde queremos somar dois campos numéricos, por exemplo saldo e bonus, mas qualquer um deles pode ser NULL no banco, então vamos definir que se é nulo, o valor será 0 para a operação,e não quebraremos nosso código. Vamos aproveitar e utilizar a classe F, que conhecemos na parte anterior, para acessar os valores que precisamos.

from django.db.models import F
from django.db.models.functions import Coalesce

clientes = Cliente.objects.annotate(
    total=Coalesce(F('saldo'), 0) + Coalesce(F('bonus'), 0)
)

-- equivalente sql
SELECT *,
       COALESCE(saldo, 0) + COALESCE(bonus, 0) AS total
FROM clientes_cliente;

Consultas com lógica condicional dinâmica

a classe Q permite compor filtros com AND, OR, NOT e lógica dinâmica, que é excelente para combinar vários filtros. O Q que é utilizado principalmente quando queremos impor uma negação ou um OR no nosso filtro, já que por padrão o .filter() usa AND.

# Exemplo: busca flexível
from django.db.models import Q

Produto.objects.filter(
    Q(nome__icontains='teclado') | Q(descricao__icontains='teclado')
)

SELECT *
FROM produtos_produto
WHERE LOWER(nome) LIKE '%teclado%' OR LOWER(descricao) LIKE '%teclado%';

O Q geralmente é utilizado quando temos várias opções de filtros que não são obrigatórios, ou seja, dependendo de quais filtros eu escolha, terei diferentes resultados, de forma dinâmica.

# views.py
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework import status
from django.db.models import Q
from produtos.models import Produto
from produtos.serializers import ProdutoSerializer

class ProdutoBuscaAvancadaAPIView(APIView):
    def get(self, request):
        termo = request.query_params.get('q')
        categoria = request.query_params.get('categoria')
        excluir_gratis = request.query_params.get('excluir_gratis') == 'true'
        destaque = request.query_params.get('destaque') == 'true'

        query = Q()

        if termo:
            query |= Q(nome__icontains=termo) | Q(descricao__icontains=termo)

        if categoria:
            query &= Q(categoria__nome__iexact=categoria)

        if excluir_gratis:
            query &= ~Q(preco=0)

        if destaque:
            query |= Q(status='destaque')

        produtos = Produto.objects.filter(query).distinct()

        serializer = ProdutoSerializer(produtos, many=True)
        return Response(serializer.data, status=status.HTTP_200_OK)

Conclusão

As ferramentas que vimos são subestimadas, mas dominá-las permite escrever queries sofisticadas sem abrir mão da expressividade do ORM. Na maioria dos casos, você não precisa abandonar o ORM. Basta conhecê-lo a fundo. Espero ter agregado conhecimento a quem leu, e trazer mais conteudos em uma proxima ocasião (que seja logo), até mais.

Referências

Todos os conteudos abordados nessa publicação foram feitos com base na própria documentação do Django.

Django Docs - Making Queries
Django Docs - Query Expressions
Django Docs - Conditional Expressions

Django ORM: consultas complexas

Lucas Mateus — Sat, 05 Jul 2025 01:14:12 +0000

O ORM do Django é simples e intuitivo no seu uso mas muitos devs acreditam que consultas SQL mais avançadas são demais para essa ferramenta.

A verdade é que o ORM do Django vai muito além do consultas básicas, e nesta publicação vou mostrar como usar recursos poderosos deste ORM para resolver situações reais de forma limpa e performática.

Expressões

Um dev iniciante com o ORM, provavelmente faria uma operação de atualizar um campo dessa seguinte maneira, o que não só requer mais etapas, além de que esse fluxo pode ser problemático, especialmente em situações de concorrência, porque o valor pode mudar entre o SELECT e o UPDATE.

produto = Produto.objects.get(id=1)  # Isso faz um SELECT no banco
produto.estoque -= 1                 # Operação feita em Python
produto.save()                       # Isso faz um UPDATE com o novo valor

A classe F permite referenciar valores de outros campos da mesma linha diretamente no banco, sem precisar carregar os dados pro Python.Com F, a operação ocorre direto no banco de dados de forma segura:

from django.db.models import F

Produto.objects.filter(id=1).update(
    estoque=F('estoque') - 1
)

Essa operação é atômica, ou seja, evita condições de corrida entre processos concorrentes. O Django gera diretamente um UPDATE estoque = estoque - 1 no banco, sem realizar um SELECT antes. Sendo esse o código equivalente em SQL.

UPDATE produto
SET estoque = estoque - 1
WHERE id = 1;

Subconsultas

Como já estamos acostumados a fazer utlizando SQL,Subqueries são ideais quando você precisa anexar dados derivados de outras tabelas. Vejamos essa consulta feita em SQL puro que anexa o último pedido de um cliente a consulta.

SELECT *,
       (SELECT data
        FROM pedidos
        WHERE pedidos.cliente_id = clientes.id
        ORDER BY data DESC
        LIMIT 1) AS data_ultimo_pedido
FROM clientes;

A primeiro momento parece bem chato fazer essa subquery usando somente o ORM, mas vamos ver algumas classes que irão nos ajudar com isso. Subquery e OuterRef são usados juntos para inserir subconsultas SQL dentro de uma consulta principal. O Subquery permite definir uma consulta que será executada para cada linha da consulta externa. Já o OuterRef é usado dentro da subconsulta para referenciar dinamicamente uma coluna da consulta externa (como o ID do cliente no nosso caso). Essa mesma consulta agora feita somente com o Django ORM ficaria assim:

from django.db.models import OuterRef, Subquery
from pedidos.models import Pedido
from clientes.models import Cliente

ultima_data = Pedido.objects.filter(
    cliente=OuterRef('pk')
).order_by('-data').values('data')[:1]

clientes = Cliente.objects.annotate(
    data_ultimo_pedido=Subquery(ultima_data)
)

# ou podemos fazer isso tudo inline
clientes = Cliente.objects.annotate(
    data_ultimo_pedido=Subquery(
        Pedido.objects.filter(
            cliente=OuterRef('pk')
        ).order_by('-data').values('data')[:1]
    )
)

NOTA: Sempre use.values('campo')[:1] nas Subquery() para garantir que a subconsulta retorne exatamente um valor escalar, evitando erros e tornando a consulta válida para ser usada em annotate().

Window functions

Em SQL, window functions (ou funções de janela) são funções que realizam cálculos em um conjunto de linhas relacionando à linha atual sem colapsar o resultado como fazem as funções de agregação tradicionais (SUM, AVG, COUNT, etc). Queries com window functions são úteis para análises que dependem de agrupamentos e ordenações, e o Django já suporta isso de forma nativa.

# ranquear os produtos mais vendidos por categoria
from django.db.models import Window, F
from django.db.models.functions import RowNumber
from produtos.models import Produto

produtos = Produto.objects.annotate(
    rank=Window(
        expression=RowNumber(),
        partition_by=[F('categoria')],
        order_by=F('vendas').desc()
    )
)

--Equivalente em SQL puro
SELECT *,
       ROW_NUMBER() OVER (
           PARTITION BY categoria_id
           ORDER BY vendas DESC
       ) AS rank
FROM produtos_produto;

Conclusão

O Django ORM vai muito além do que parece. Ferramentas como as vistas nesta publicação permitem expressar consultas complexas com clareza e segurança, direto do Python. Em vez de fugir pro SQL cru de cara, tente explorar esses recursos. Muitas vezes, a solução está ao seu alcance e pode deixar o seu código bem mais limpo do que você imagina. Existem ainda mais funções complexas do ORM a serem exploradas, quem sabe não exploro elas numa próxima publicação, até a próxima.

Referências

Você pode dar uma olhada com mais calma nessa e outras várias funções avançadas de consulta, diretamente na documentação do Django:

Django Docs - Query Expressions

Introdução à Programação Orientada a Objetos em Python com Pygame(parte 2)

Lucas Mateus — Wed, 04 Oct 2023 02:19:09 +0000

Resumo

Este guia tem como objetivo simplificar o ensino da programação orientada a objetos de forma lúdica e acessível, usando Python como linguagem de base e o Pygame como ferramenta de apoio. A programação orientada a objetos é uma abordagem crucial para desenvolvedores, pois oferece um meio organizado e eficiente de criar sistemas complexos e reutilizáveis. Está é a segunda parte do guia, e nela abordaremos conceitos de herança e suas aplicações.

Requisitos para compreensão desta publicação:

Noção de programação estruturada
Compreensão da linguagem Python
Biblioteca pygame devidamente instalada no ambiente de desenvolvimento
Ter já ter executado as instruções da parte-1 desse guia

Herança

Herança é um conceito fundamental na programação orientada a objetos, que permite que uma classe herde atributos e métodos de outra classe, criando uma relação de hierarquia entre elas. Isso segue o princípio de reaproveitamento de código, onde se eu preciso de duas classes diferentes porem que tenham bases similares, essas classes vão ter suas distinções porem com uma mesma origem. É um conceito parecido com o que vimos até agora, porém ficara mais claro em código.

Herança em Python

Em python para se fazer uma classe herdar de outra, basta apenas na criação da classe, entre parênteses inserir a classe que se está herdando.

class Animal:
    def __init__(self, nome):
        self.nome = nome

    def comer(self):
        print(f"{self.nome} está comendo.")


class Cachorro(Animal):
    def latir(self):
        print(f"{self.nome} está latindo.")


class Gato(Animal):
    def miar(self):
        print(f"{self.nome} está miando.")


# Criando objetos
rex = Cachorro("Rex")
mingal = Gato("Mingal")

# Usando métodos da classe base (Animal)
rex.comer()
mingal.comer()

# Usando métodos das subclasses
rex.latir()
mingal.miar()

Perceba que quando as subclasses(ou classes filhas) herdam todos os métodos e atributos de sua classe mãe, porém ainda podem possuir seus próprios métodos e atributos únicos, sem interferir na classe mãe ou nas outra subclasses.

Polimorfismo

Mas e se quisermos que algum método da classe mãe se comporte de maneira diferente na minha subclasse? No mundo da orientação a objetos isso se chama Polimorfismo, O termo polimorfismo é originário do grego e significa "muitas formas". Em termos simples o polimorfismo é definido quando subclasses usam um método da sua superclasse, que apesar de ter a mesma assinatura (nome) ele irá se comportar de maneira distinta em cada subclasse.

Reescrever

Quando queremos que algum método da subclasse se comporte de maneira diferente de um método da superclasse, podemos reescrever esse método. Para fazer isso em python basta apenas literalmente reescrever o método da superclasse com o mesmo nome na subclasse, só que dessa vez adicionando sua própria lógica.

class Animal:
    def fazer_som(self):
        print("Som genérico de um animal.")

class Cachorro(Animal):
    def fazer_som(self):
        print("Latir!")

Estender

Como o próprio nome diz, estamos estendendo uma funcionalidade, ou seja, estamos adicionando algo a mais. Quando estendemos um método estamos fazendo com que o novo método que estamos criando, execute o método que herdamos da superclasse e logo após execute nossa funcionalidade, e para isso usamos o operador super().metodo_da_superclassse().

class Veiculo:
    def mover(self):
        print("O veículo está se movendo.")

class Carro(Veiculo):
    def mover(self):
        super().mover()  # Chama o método da superclasse
        print("O carro está se movendo a 60 km/h.")

Ao criar um novo objeto da classe Carro e chamarmos o método mover(), ele executará o método vindo da classe Veiculo e logo após o que inserimos, então em seu terminal estará assim:

O veículo está se movendo.
O carro está se movendo a 60 km/h.

De volta ao jogo

Em ultimo momento de nosso projeto, criamos nossa tela mas ainda não possuíamos nada nela, então agora iremos mudar isso e adicionar novos elementos e lógica ao nosso jogo.

Plano cartesiano no pygame

Antes de prosseguirmos é importante salientar que o pygame segue uma dinâmica de plano cartesiano um pouco diferente, onde o eixo Y é invertido, logo se quisermos que algo caia pelo cenário temos de incrementar valores a sua posição Y e não decrementar.

Novas constantes e sprites

Em seu arquivo de constantes consts.py adicione essa linhas, elas serão importantes para o funcionamento das nossas novas classes.

# conf plane
GRAVITY = 0.25
FLAP_STRENGTH = 7

# conf pipe
PIPE_GAP = 150
PIPE_SPEED = 4

# color
BROWN = (163, 128, 104)
WHITE = (255, 255, 255)
BLACK = (0, 0, 0)

Agora no diretório do seu projeto crie um novo subdiretório chamado sprites e adicione as imagens contidas aqui. Com isso feito, no diretório principal crie 3 arquivos com esses nomes: ground.py, pipe.py e plane.py. Logo seu diretório principal deve estar nessa configuração:

Criando classes

Plane

Em seu arquivo plane.py adicione o seguinte código:

import pygame

import consts


class Plane(pygame.sprite.Sprite):
    def __init__(self):
        super().__init__()
        # importando a imagem
        self.image = pygame.image.load("sprites/plane.png")
        # criando caixa em torno da imagem
        self.rect = self.image.get_rect()
        self.rect.center = (100, consts.SCREEN_HEIGHT // 2)
        self.velocity = 0

    def update(self):
        self.velocity += consts.GRAVITY
        self.rect.y += self.velocity

    def flap(self):
        self.velocity = -consts.FLAP_STRENGTH

Estamos herdando de uma classe predefinida do pygame Sprites, e estendendo seu método construtor para moldarmos a nossa necessidade. Estamos reescrevendo o método update() que vem da superclasse, que é responsável por atualizar o objeto na tela com o passar dos frames, adicionando nossa lógica de queda. Por ultimo estamos criando nosso método flap() que será responsável pelo "salto" do avião. Todas as próximas classes vão seguir o mesmo esquema de construção.

Pipe

Em seu arquivo pipe.py adicione o seguinte código:

import pygame

import consts


class Pipe(pygame.sprite.Sprite):
    def __init__(self, x, y, path):
        super().__init__()
        self.image = pygame.image.load(path)
        self.rect = self.image.get_rect()
        self.rect.x = x
        self.rect.y = y
        self.speed = consts.PIPE_SPEED

    def update(self):
        # a cada momento atualizada a posicao
        self.rect.x -= self.speed
        if self.rect.right < 0:
            self.kill()

Ground

Em seu arquivo ground.py adicione o seguinte código:

import pygame

import consts


class Ground(pygame.sprite.Sprite):
    def __init__(self):
        super().__init__()
        self.image = pygame.Surface((consts.SCREEN_WIDTH, 20))
        self.image.fill(consts.BROWN)
        self.rect = self.image.get_rect()
        self.rect.x = 0
        self.rect.y = consts.SCREEN_HEIGHT - 20

Criando objeto dentro da tela

Com todos os passos anteriores feitos, no nosso arquivo game.py devemos fazer as seguintes alterações:

import pygame

import consts
from plane import Plane


class Game:
    def __init__(self):
        # iniciando o pygame
        pygame.init()
        # criando tela
        self.screen = pygame.display.set_mode(
            (consts.SCREEN_WIDTH, consts.SCREEN_HEIGHT))
        pygame.display.set_caption(consts.TITLE)
        self.clock = pygame.time.Clock()
        self.running = True

        # Inicialização de grupos de sprites
        self.all_sprites = pygame.sprite.Group()
        self.plane = Plane()
        self.all_sprites.add(self.plane)

    def game_events(self):

        # retorna todos os objetos do tipo event
        for event in pygame.event.get():
            # acessa o atributo type do objeto event
            if event.type == pygame.QUIT:
                self.running = False

            if event.type == pygame.KEYDOWN:
                if event.key == pygame.K_SPACE:
                    self.plane.flap()

    def run(self):
        while self.running:
            # o metodo tick define os FPS do jogo
            self.clock.tick(consts.FPS)
            self.game_events()
            # desenha as imagens na tela
            self.all_sprites.draw(self.screen)
            # chama o metodo update das classes
            self.all_sprites.update()
            pygame.display.flip()

Agora adicionamos novos atributos que vão tomar conta das sprites na tela, e criamos um novo objeto da classe Plane. Nos eventos adicionamos um novo evento que verifica as teclas pressionadas, e ao apertar a tecla SPACE iremos chamar o método flap() do nosso objeto plane. Por ultimo no loop do nosso jogo, chamamos os métodos que desenham os sprites na tela, e atualizam a tela de acordo com o clock que definimos*(60 FPS)*. Volte ao arquivo main.py e o execute agora.

Parece errado? E está mesmo! Nosso objeto está sendo desenhado na tela porem a ultima posição em que ele estava ainda fica desenhada tambem, gerando essa situação feia. Resolveremos isso de forma simples, entre um frame e outro nossa tela vai ser limpa, fazendo com que tudo na tela seja apagado, porem no frame seguinte quando o loop iterar, a imagem irá se redesenhar, dando a ilusão de movimento. Vamos fazer isso em código, modifique seu método run() com o trecho a seguir e verá tudo funcionando como devia.

    def run(self):
        while self.running:
            # o metodo tick define os FPS do jogo
            self.clock.tick(consts.FPS)
            self.game_events()
            # desenha as imagens na tela
            self.all_sprites.draw(self.screen)
            # chama o metodo update das classes
            self.all_sprites.update()
            pygame.display.flip()
            # sem isso a posicao anterior dos desenhos continua na tela
            self.screen.fill(consts.BLACK)

Adicionando os canos e nossas telas

Agora que nossa mecânica de voo está totalmente funcional, precisamos adicionar obstáculos a nossa tela. Vamos adicionar o chão e os canos a tela, modifique seu arquivo game.py dessa maneira:

import random

import pygame

import consts
from ground import Ground
from pipe import Pipe
from plane import Plane


class Game:
    def __init__(self):
        # iniciando o pygame
        pygame.init()
        # criando tela
        self.screen = pygame.display.set_mode(
            (consts.SCREEN_WIDTH, consts.SCREEN_HEIGHT))
        pygame.display.set_caption(consts.TITLE)
        self.clock = pygame.time.Clock()
        self.running = True

        # Inicialização de grupos de sprites
        self.all_sprites = pygame.sprite.Group()
        self.plane = Plane()
        self.ground = Ground()
        self.all_sprites.add(self.plane, self.ground)
        self.pipes = pygame.sprite.Group()

    def game_events(self):

        # retorna todos os objetos do tipo event
        for event in pygame.event.get():
            # acessa o atributo type do objeto event
            if event.type == pygame.QUIT:
                self.running = False

            if event.type == pygame.KEYDOWN:
                if event.key == pygame.K_SPACE:
                    self.plane.flap()

    def run(self):
        while self.running:
            # o metodo tick define os FPS do jogo
            self.clock.tick(consts.FPS)
            self.game_events()
            # desenha as imagens na tela
            self.all_sprites.draw(self.screen)

            if len(self.pipes) < 2:
                self.spawn_pipe()
            self.remove_pipes()

            # chama o metodo update das classes
            self.all_sprites.update()
            pygame.display.flip()
            # sem isso a posicao anterior dos desenhos continua na tela
            self.screen.fill(consts.BLACK)

    def randomize_height(self):
        # Define a altura aleatória dos canos
        self.y = random.randint(100, 500)

    def spawn_pipe(self):
        self.randomize_height()
        self.pipe_bot = Pipe(300, self.y, "sprites/pipe.png")
        self.pipe_top = Pipe(
            300,
            (self.y - consts.PIPE_GAP - 500),
            "sprites/pipe_top.png")
        self.pipes.add(self.pipe_bot, self.pipe_top)
        self.all_sprites.add(self.pipe_bot, self.pipe_top)

    def remove_pipes(self):
        for pipe in self.pipes:
            if pipe.rect.x < 0:
                self.pipes.remove(pipe)
                self.all_sprites.remove(pipe)

Adicionamos muitos novos métodos e atributos, porém não é nada que já não tenhamos trabalhado antes. Agora temos o nosso chão de forma fixa, e os canos que tem a altura gerada aleatoriamente pelo método randomize_height(). Quando um cano chega o final da tela, um novo cano é gerado e o anterior é descartado do nosso grupo de sprites a serem exibidas. Com tudo pronto, execute o arquivo main.py.

Com o código rodando em sua tela deve aparecer algo do gênero. Todas classes estão operantes e funcionais no nosso programa, porem ainda falta um ultimo tchan para finalizarmos. Precisamos reconhecer quando nosso avião se choca contra o solo ou contra um dos canos, então vamos modificar mais uma vez nosso código, e aproveitar o embalo e inserir alguns adicionais gráficos. Em game.py cole o código a seguir:

import random
import sys

import pygame

import consts
from ground import Ground
from pipe import Pipe
from plane import Plane


class Game:
    def __init__(self):
        # iniciando o pygame
        pygame.init()
        # criando tela
        self.screen = pygame.display.set_mode(
            (consts.SCREEN_WIDTH, consts.SCREEN_HEIGHT))
        pygame.display.set_caption(consts.TITLE)
        self.clock = pygame.time.Clock()
        self.running = True

        # Inicialização de grupos de sprites
        self.all_sprites = pygame.sprite.Group()
        self.plane = Plane()
        self.ground = Ground()
        self.all_sprites.add(self.plane, self.ground)
        self.pipes = pygame.sprite.Group()

        # score
        self.score = 0

    def game_events(self):

        # retorna todos os objetos do tipo event
        for event in pygame.event.get():
            # acessa o atributo type do objeto event
            if event.type == pygame.QUIT:
                self.running = False

            if event.type == pygame.KEYDOWN:
                if event.key == pygame.K_SPACE:
                    self.plane.flap()

    def run(self):
        while self.running:
            # o metodo tick define os FPS do jogo
            self.clock.tick(consts.FPS)
            self.game_events()
            # desenha as imagens na tela
            self.all_sprites.draw(self.screen)

            if len(self.pipes) < 2:
                self.spawn_pipe()
            self.remove_pipes()

            # Verifica colisões com o solo
            hits = pygame.sprite.spritecollide(
                self.plane, [self.ground], False)
            if hits:
                self.running = False

            # Verifica colisões com os canos
            hits = pygame.sprite.spritecollide(self.plane, self.pipes, False)
            if hits:
                self.running = False

            # Mostra a pontuação na tela
            self.font = pygame.font.Font(None, 36)
            self.score_text = self.font.render(
                f"Score: {self.score}", True, consts.WHITE)
            self.screen.blit(self.score_text, (10, 10))

            # chama o metodo update das classes
            self.all_sprites.update()
            pygame.display.flip()
            # sem isso a posicao anterior dos desenhos continua na tela
            self.screen.fill(consts.BLACK)

        pygame.quit()
        sys.exit()

    def randomize_height(self):
        # Define a altura aleatória dos canos
        self.y = random.randint(100, 500)

    def spawn_pipe(self):
        self.randomize_height()
        self.pipe_bot = Pipe(300, self.y, "sprites/pipe.png")
        self.pipe_top = Pipe(
            300,
            (self.y - consts.PIPE_GAP - 500),
            "sprites/pipe_top.png")
        self.pipes.add(self.pipe_bot, self.pipe_top)
        self.all_sprites.add(self.pipe_bot, self.pipe_top)

    def remove_pipes(self):
        for pipe in self.pipes:
            if pipe.rect.x < -80:
                print('entrou')
                self.pipes.remove(pipe)
                self.all_sprites.remove(pipe)
                self.score += 1

Com essas mudanças feitas, agora temos verificações se as nosso objetos na tela estão colidindo contra nosso avião, caso ocorra o jogo se encerrará. Com isso nosso joguinho agora está totalmente funcional, e tudo isso foi feito usando os conceitos de OO que aprendemos até aqui.

Considerações finais

O nosso jogo está pronto mas ainda há muito a aprender, o mundo da orientação a objetos ainda tem muito conteúdo porem com o que foi visto durante esse guia, já é mais do que o suficiente para entender os demais conceitos. Estarei deixando uma lista de tópicos relevantes para se estudar a respeito:

Encapsulamento
Sobrecarga
Herança Múltipla
Classes abstratas

E caso tenha gostado da nossa brincadeira pygame você pode dar uma olhada na documentação da biblioteca e começar a fazer seus próprios projetos. E se quiser visualizar esse projeto completo, ele está disponível na minha página do github.

Agradeço demais por me acompanhar até aqui com essa ideia. Planejar esse guia foi muito prazeroso, pois foi literalmente com essa biblioteca, fazendo pequenos jogos, que eu pude fixar e ver na prática o que estava aprendendo com OO pela primeira vez, então fiz tudo isso com muito carinho. Espero poder estar trazendo novos conteúdos logo mais, dito isso...

OBRIGADO PELA ATENÇÃO!

Introdução à Programação Orientada a Objetos em Python com Pygame(parte 1)

Lucas Mateus — Wed, 27 Sep 2023 13:45:58 +0000

Resumo

Requisitos para compreensão desta publicação:

Noção de programação estruturada
Compreensão da linguagem Python
Biblioteca pygame devidamente instalada no ambiente de desenvolvimento

Programação Orientada a Objetos vs. Programação Estruturada

Na programação estruturada, o programa é dividido em funções ou procedimentos, onde o foco está na sequência de instruções para manipular dados. Já na programação orientada a objetos, o código é estruturado em torno de objetos, que são instâncias de classes que representam entidades do mundo real. Esses objetos contêm dados (atributos) e funções (métodos) que operam nesses dados. A programação orientada a objetos utiliza da reutilização de código e a modelagem mais precisa de sistemas complexos, enquanto a programação estruturada é mais linear e depende de funções independentes para executar tarefas específicas.

O que são classes e objetos?

Classe

Imagine uma classe como um modelo, um conjunto de regras para criar instâncias que seguem esse modelo. Ela é como uma forma que permite a criação de vários objetos, cada um com suas próprias características e funcionalidades, mas todos baseados na mesma estrutura inicial.

Objetos

Se uma classe é a forma de um bolo, um objeto é o próprio bolo. Usando a mesma forma (classe), podemos criar múltiplos bolos (objetos) com diferentes sabores e detalhes, mas todos compartilhando a mesma base estrutural.

Atributos

Atributos são as características de um objeto, ou em termos de programação, os dados associados a esse objeto. Por exemplo, uma classe chamada Bolo pode ter um atributo chamado "sabor". Cada instância dessa classe pode ter um sabor único, como chocolate ou morango. Essas instâncias compartilham o atributo "sabor" da classe, mas cada objeto individual possui um sabor próprio.

Métodos

Os métodos são as ações que um objeto pode realizar, ou seja, as funções que um objeto pode desempenhar. Continuando com a analogia do bolo, imagine que, além de possuir um sabor, um bolo também pode realizar a ação de ser cortado em fatias. Portanto, em nossa classe Bolo, podemos criar um método chamado "cortar" que define como um bolo deve ser dividido em pedaços. Quando aplicamos esse método a um objeto bolo específico, ele segue as instruções da classe para cortar-se em fatias, produzindo fatias de bolo prontas para serem servidas. Cada objeto da classe Bolo tem a capacidade de cortar-se em fatias, mas a ação real de cortar é realizada individualmente por cada objeto quando chamamos o método. Assim, os métodos possibilitam objetos a executarem tarefas específicas, mantendo a consistência e a flexibilidade da lógica de programação orientada a objetos. Em resumo, é uma função porém ela opera em cima dos dados do próprio objeto.

Entendendo o Método construtor e pondo a mão na massa

O método construtor é uma parte fundamental da programação orientada a objetos, em Python ele é representado pelo nome especial __init__. Ele desempenha um papel crucial na criação de objetos a partir de uma classe. O principal propósito do método construtor é inicializar os atributos de um objeto quando ele é criado. Em resumo o método construtor, é um método que é executado assim que um novo objeto é criado, e é responsável por atribuir dados aos atributos dos objetos.

Falamos tanto na nossa classe Bolo, mas até agora não vimos em código. Agora vamos criar não somente um bolo, como também a forma dele. Em python (e a maioria das demais linguagens de programação) as classes tem a primeira letra maiúscula, e é usado o operador class para a criação.


class Bolo:

    # metodo construtor
    def __init__(self, sabor, textura):
        # atributos
        self.sabor = sabor
        self.textura = textura

    # metodo fatiar
    def fatiar(self, fatias):
        print(f'Bolo de `{self.sabor} fatiado em `{fatias} fatias\n')

Como dito anteriormente, um método funciona de forma similar a uma função, logo é possível passar parâmetros para esse métodos, e esses serão os dados que irão ser alocados nos atributos deste objeto, como visto no código.

Mas o que é esse parâmetro "self" que esta sendo passado nos métodos? Em Python, self é uma convenção usada como o primeiro parâmetro em métodos de uma classe. O objetivo principal do self é representar a instância do objeto atualmente em execução, permitindo o acesso aos atributos e métodos dessa instância dentro dos métodos da classe. Em outras palavras, o self é a representação de um instância, se eu tenho um objeto bolo1, é como se quando eu chamasse o método, eu passasse o próprio bolo1 como parâmetro, sinalizando que é para operar em cima dos dados daquele objeto específico, iremos ver um método funcionando logo a frente.

Com nossa forma pronta, vamos criar os nosso bolos. Para criar um novo objeto em python basta apenas chamar a classe pelo nome e entre parênteses, passa os parâmetros que são exigidos no construtor.


# Criando um objeto bolo usando o construtor
meu_bolo1 = Bolo('Chocolate', 'Fofa')
meu_bolo2 = Bolo('Morango', 'Molenga')

Pronto, agora temos dois novos objetos vindos da mesma classe, com características distintas. Para acessar métodos e atributos de um objeto basta apenas usar o . e chamar o atributo, e no caso dos método usar os parênteses, como uma função. Rode o código e veja a mágica acontecer.


# verificando sabores

print(meu_bolo1.sabor)
print(meu_bolo2.sabor)

# Fatiando um bolo
# com o parametro self é como se estivesse ocorrendo algo assim:
# meu_bolo1.fatiar(meu_bolo1, 8)
meu_bolo1.fatiar(8)

E com esses conhecimentos já estamos preparados pra começar o nosso joguinho.

Iniciando o projeto do jogo

A habilidade de abstrair os conceitos abordados é essencial para poder compreender o que está acontecendo em código de agora em diante. Vamos fazer uma réplica do jogo Flappy Bird usando pygame e o que aprendemos até agora. Vamos ver da maneira de maneira mais prática as classes e objetos em funcionamento .

Criando o arquivo de constantes

Existem dados que nunca irão ser mudados no nosso código, logo podemos declara-los como constates, para isso vamos deixa-las em um arquivo separado. Crie um arquivo chamado consts.py e cole o código abaixo. Iremos adicionar mais futuramente, mas por hora o que precisamos já está ai.


# Configurações do jogo

# tamanho da tela
SCREEN_WIDTH = 400
SCREEN_HEIGHT = 600

# titulo
TITLE = 'Flappy Bird'

# taxa de atualização da tela
FPS = 60

Com nossas constantes definidas podemos usa-las no nosso código para a criação da primeira classe do nosso projeto, que será literalmente a classe do jogo, vamos criar uma classe que contenha com atributos parâmetros importantes para o funcionamento do jogo que está para ser criado. Em seu diretório crie uma classe um arquivo de nome game.py e cole o o código abaixo.

import pygame
import consts


class Game:
    def __init__(self):
        # iniciando o pygame
        pygame.init()
        # criando tela
        self.screen = pygame.display.set_mode(
            (consts.SCREEN_WIDTH, consts.SCREEN_HEIGHT))
        pygame.display.set_caption(consts.TITLE)
        self.clock = pygame.time.Clock()
        self.running = True

Perceba que o método construtor não recebe nenhum parâmetro, todos os atributos foram definidos dentro da própria classe, lembre que o construtor não precisa nescessariamente receber parâmetros, podemos inicializar os atributos com os dados que quisermos, no caso estamos usando os módulos do pygame. Perceba que o atributo clock recebe uma classe vinda do pygame, um atributo pode conter qualquer coisa, incluindo outros objetos. Posteriormente iremos interagir com esse atributo novamente.

Precisamos fazer nosso jogo rodar de alguma forma, vamos criar um método que faça isso. na sua classe Game, faça essas mudanças a seguir.

import pygame
import consts


class Game:
    def __init__(self):
        # iniciando o pygame
        pygame.init()
        # criando tela
        self.screen = pygame.display.set_mode(
            (consts.SCREEN_WIDTH, consts.SCREEN_HEIGHT))
        pygame.display.set_caption(consts.TITLE)
        self.clock = pygame.time.Clock()
        self.running = True

    def game_events(self):
        # retorna todos os objetos do tipo event
        for event in pygame.event.get():
            # acessa o atributo type do objeto event
            if event.type == pygame.QUIT:
                self.running = False

    def run(self):
        while self.running:
            # o metodo tick define os FPS do jogo
            self.clock.tick(consts.FPS)
            self.game_events()

Perceba que a partir do nosso atributo clock que é um objeto, chamamos um método dessa classe, método esse que define a quantos frames por segundo nosso jogo irá rodar. Note também que para chamarmos um método da classe, dentro dela mesma, nos utilizamos o self, já que estamos operando dentro da própria instância. Agora não só estamos criando nossa própria classe, como tambem estamos utilizando outras dentro dela.

    def game_events(self):
        # retorna todos os objetos do tipo event
        for event in pygame.event.get():
            # acessa o atributo type do objeto event
            if event.type == pygame.QUIT:
                self.running = False

Como visto nesse trecho, também estamos buscando dentro do módulo do pygame, todos os objetos do tipo event, estamos acessando o seu atributo type, para fazer uma verificação. Com essa verificação agora temos uma opção de fechar a tela de nosso jogo, quando tornamos o atributo responsável por manter o loop do jogo para False.

Rodando o jogo

Com o que foi feito até então, temos o nosso modelo, porém ainda não fizemos nosso bolo. Em seu diretório crie um arquivo chamado main.py e cole o seguinte código e execute-o.

import game

if __name__ == "__main__":
    my_game = game.Game()
    my_game.run()

Em sua tela deve estar algo similar a isso:

Ainda não temos nada além uma tela vazia, porém ai está! Essa tela vazia é o nosso objeto! Os métodos que criamos estão sendo executados em tempo real! O nome na nossa guia é o atributo que definimos lá no começo! Até mesmo se fecharmos essa simples tela sem nada, vai ser um método que criamos que está sendo executado. Tudo que estamos vendo compõe o nosso objeto mygame, que vem da classe game que criamos, e ainda tem muito mais por vir.

Considerações finais

Esse é só o começo do nosso projeto, ainda há muito a ser feito, e muito conhecimento pra ser aprendido. Obrigado por chegar até aqui comigo e espero que possa me acompanhar nos próximos capítulos desse projeto.

Caso queira ver o progresso do código, ele está no meu perfil do github, sinta-se a vontade para opinar e contribuir.

ATÉ A PROXIMA