Guardar as tarefas: a estrutura de dados

Cada tarefa é um registro

A primeira grande decisão do gerenciador é como guardar uma tarefa, e ela ilustra tudo que você aprendeu sobre estruturas. Uma tarefa não é uma informação só: ela tem uma descrição (comprar pão) e um estado (pendente ou concluída), e pode ganhar mais campos depois, como prazo ou prioridade. Guardar informações nomeadas que descrevem uma única coisa é exatamente o papel do dicionário: cada tarefa vira um dicionário com as chaves descrição e estado. Assim, tarefa[descrição] dá o texto e tarefa[estado] dá a situação, de forma clara e expansível. Modelar o dado assim, com campos nomeados, é bem melhor do que tentar espremer descrição e estado em duas listas paralelas, uma solução que embola e quebra fácil.

Decidido que cada tarefa é um dicionário, falta guardar o conjunto delas. Aqui a escolha é a lista, e por bons motivos: as tarefas têm uma ordem (a de chegada, por exemplo), a coleção cresce e encolhe conforme o usuário adiciona e conclui, e você vai querer percorrer todas para listar. Tudo isso é território da lista. A combinação final, portanto, é uma lista em que cada item é um dicionário, a famosa lista de dicionários. Esse é o formato mais comum para representar dados do mundo real, de uma agenda de contatos a uma planilha de vendas: a lista guarda as linhas em ordem, e cada dicionário guarda os campos daquela linha. Reconhecer que o gerenciador pede essa estrutura é aplicar, num caso real, o faro de escolher a estrutura certa que o curso treinou.

As funções de adicionar e listar

Com a estrutura definida, as duas primeiras funções saem quase sozinhas. Adicionar uma tarefa é montar um dicionário novo com a descrição informada e o estado pendente, e acrescentá-lo à lista. Listar as tarefas é percorrer a lista com um laço e mostrar cada uma de forma legível, numerando para o usuário poder se referir a elas depois. Repare como cada função faz uma coisa só, tem um nome honesto e opera sobre a estrutura compartilhada: é o código limpo em ação. E note que o estado pendente entra automaticamente na criação, porque uma tarefa recém-adicionada nunca nasce concluída, uma pequena regra de negócio embutida na função, no lugar certo.

função adicionarTarefa(tarefas, descricao)
  novaTarefa <- { "descricao": descricao, "estado": "pendente" }
  adicione(novaTarefa, tarefas)
fim

função listarTarefas(tarefas)
  numero <- 1
  para cada tarefa em tarefas faça
    escreva(numero, ". [", tarefa["estado"], "] ", tarefa["descricao"])
    numero <- numero + 1
  fim
fim
// exemplo de saída:
// 1. [concluída] comprar pão
// 2. [pendente] pagar conta

Adicionar cria um dicionário pendente e o põe na lista; listar percorre a lista mostrando cada tarefa numerada.

tarefas <- lista vazia
adicionarTarefa(tarefas, "comprar pão")
adicionarTarefa(tarefas, "pagar conta")
adicionarTarefa(tarefas, "estudar")
// a segunda tarefa é marcada como concluída
tarefas[1]["estado"] <- "concluída"
// quantas continuam pendentes?

A força da estrutura certa

Vale reparar quanto trabalho a estrutura certa já economizou. Como cada tarefa é um dicionário, acrescentar um campo novo no futuro (um prazo, uma prioridade) é só adicionar uma chave, sem mexer no resto. Como a coleção é uma lista, percorrer, contar e numerar as tarefas usa os padrões que você domina desde o básico. Mudar o estado de uma tarefa específica é acessar seu dicionário na lista e trocar uma chave, uma linha. Nada disso seria tão limpo com uma escolha ruim de estrutura, como listas paralelas de descrições e estados, que obrigariam a manter os índices sincronizados na mão e quebrariam ao primeiro descuido. A lição do módulo de estruturas de dados se confirma na prática: escolher bem a estrutura no início é o que torna todas as operações seguintes fáceis. Com as tarefas guardadas e as funções de adicionar e listar prontas, o esqueleto começa a ganhar vida. Falta dar ao usuário o poder de consultar e concluir, com a devida validação, o assunto da próxima aula.