Modelando a agenda com classes

A classe Contato

Todo projeto de orientação a objetos começa perguntando quais coisas existem no problema. Na agenda, existem duas: um contato e a agenda que reúne os contatos. Comece pelo contato, porque a agenda depende dele. Um contato é um agrupamento de três valores que andam juntos: nome, telefone e e-mail. Guardar isso em três variáveis soltas seria frágil. Uma classe amarra os três em um objeto só, com nome próprio, e abre espaço para dar comportamento a ele depois.

class Contato:
    def __init__(self, nome, telefone, email=""):
        self.nome = nome
        self.telefone = telefone
        self.email = email

    def __str__(self):
        return f"{self.nome} | {self.telefone} | {self.email}"

A classe Contato: três atributos e um __str__ que a mostra em uma linha.

Duas escolhas merecem atenção. O parâmetro email recebe um valor padrão, a string vazia, o que o torna opcional: dá para criar um contato só com nome e telefone. E o método __str__ define como o contato aparece quando você o imprime. Sem ele, print(contato) mostraria algo técnico e inútil como <Contato object at 0x7f...>. Com ele, mostra Ana | 11999998888 | ana@exemplo.com, pronto para o usuário ler. É um detalhe pequeno que muda toda a experiência do programa.

A classe Agenda

Com o contato pronto, a agenda é quase natural. Ela é o objeto que guarda muitos contatos. A informação que ela precisa manter é uma coleção, e a coleção certa aqui é uma lista: os contatos têm ordem e podem ser adicionados e removidos. No __init__, a agenda começa com uma lista vazia. Ainda não há métodos para operar sobre ela; isso é o assunto da próxima aula. Por enquanto, a classe só reserva o lugar onde os contatos vão morar.

class Agenda:
    def __init__(self):
        self.contatos = []


# Testando o esqueleto do programa
agenda = Agenda()
ana = Contato("Ana Souza", "11999998888", "ana@exemplo.com")
agenda.contatos.append(ana)

print(len(agenda.contatos))   # 1
print(agenda.contatos[0])     # Ana Souza | 11999998888 | ana@exemplo.com

A classe Agenda guarda uma lista de contatos. O teste no fim confirma o esqueleto.

Rode esse arquivo e observe o que acontece. Você cria uma agenda vazia, cria um contato, coloca o contato na lista da agenda com append e confere. O print(agenda.contatos[0]) mostra a linha bonita porque a classe Contato tem __str__. Neste momento, o programa já tem os dois tipos de objeto que importam. Falta dar à agenda métodos próprios, para que ninguém precise mexer diretamente na lista contatos de fora. Escrever agenda.contatos.append(ana) funciona, mas o certo é agenda.adicionar_contato(ana), e é o que vem a seguir.

Por que classes e não dicionários

Uma dúvida honesta: por que não guardar cada contato como um dicionário, algo como {"nome": "Ana", "telefone": "..."}? Funcionaria. A diferença é que a classe reúne, no mesmo lugar, os dados e o comportamento. O __str__ vive junto do contato; não é uma função solta que alguém pode esquecer de usar. Quando a agenda crescer e cada contato precisar de mais capacidades, como se transformar em dicionário para salvar, essas capacidades ficam todas na classe, organizadas. É a diferença entre uma pasta com etiqueta e papéis espalhados na mesa.

Isso não significa que dicionários sejam ruins. Para dados muito simples e passageiros, eles são ótimos. A regra prática é: quando um agrupamento de dados começa a ganhar comportamento e a se repetir pelo programa, promova-o a classe. O contato é exatamente esse caso. Curiosamente, quando formos salvar em JSON, cada contato vira um dicionário de novo, só que de propósito e por um instante. As duas ideias convivem, cada uma no seu momento.