Design de Dados do App (Lição 03) — Um Mergulho Profundo com Tim Corey

Nesta terceira lição do curso "C# App Start to Finish", Tim Corey nos leva através do passo crucial do design de dados. Ele explica que antes de começar a construir a interface do usuário ou escrever código, você deve primeiro definir a estrutura dos dados que sua aplicação usará.

Neste artigo, exploraremos a abordagem de Tim para projetar os dados de um aplicativo rastreador de torneios, seguindo suas explicações e exemplos exatos do vídeo. Vamos dar uma olhada mais profunda no tópico de design de aplicativos, usando o vídeo de Tim para entender por que o design de dados é importante e como ele impacta toda a aplicação.

Por Que os Dados Vêm Primeiro

Tim começa a lição nos lembrando que já estabelecemos os requisitos e a estrutura para o aplicativo. Agora é hora de construir a estrutura de dados real. Ele aponta que alguns desenvolvedores preferem desenhar a interface do usuário primeiro, mas ele acredita que o maior sucesso vem de desenhar os dados primeiro.

Tim explica seu raciocínio:

"Seu aplicativo não é nada sem dados." Ele esclarece que um aplicativo é essencialmente um veículo para exibir, manipular, alterar e salvar dados.

Ele dá então exemplos para provar seu ponto. Mesmo um editor de texto como o Microsoft Word é construído em torno de dados — o próprio texto, formatação, espaçamento, etc. Tim leva isso adiante ao mostrar que mesmo jogos são baseados em dados. Um jogo de xadrez, por exemplo, é apenas uma coleção de peças, posições e movimentos — tudo dados. Um jogo de tiro em primeira pessoa também depende fortemente de dados como posições de personagens, velocidade de balas, detecção de acertos, valores de danos e condições de vitória.

Sua conclusão é clara:

"Tudo gira em torno de dados."

Então ele começa com o design de dados porque, uma vez que você conhece os dados, a interface do usuário se torna mais fácil de construir. Caso contrário, você está desenhando a partir de um ponto de partida sem direção. Essa abordagem ajuda desenvolvedores e designers que trabalham em ferramentas como suítes visuais, criadores de cartazes ou criadores de logotipos, porque mesmo esses aplicativos dependem de dados estruturados para criar modelos, fontes e elementos de imagem.

Planejando Antes de Programar

Tim então explica seu método preferido de planejamento: Ele desenha tudo no papel ou em um quadro branco porque é fácil de mudar e ajustar.

Ele recomenda fortemente não abrir o Visual Studio ainda, enfatizando que o planejamento deve acontecer fora do código. Ele diz que planejar no bloco de notas ou em uma tabela é essencial porque você pode facilmente riscar coisas e fazer mudanças sem ficar preso no código.

Tim mostra a versão limpa de seu design e percorre-a passo a passo. Sua primeira regra é:

"Apenas anote algo."

Ele começa com o objeto mais óbvio: Equipe.

Construindo o Objeto Equipe

Tim começa desenhando escrevendo o que uma Equipe precisa. Ele identifica duas propriedades principais:

1. Membros da Equipe

Ele observa que uma equipe precisa de pessoas, então ele escreve uma lista de pessoas:

"Eu sei que preciso de uma equipe que tenha pessoas."

Ele explica que não precisa construir o objeto Pessoa ainda. Em vez disso, ele se concentra primeiro na Equipe e escreve uma nota para criar um Pessoa depois. Isso mantém o design focado e evita perder de vista o objeto principal.

2. Nome da Equipe

Em seguida, Tim adiciona o nome da equipe como uma string.

Ele explica que a classe Equipe é simples e só precisa de algumas propriedades chave. Ele diz que o nome da equipe deve ser algo memorável como "Tim Bob Maris Su Al" ou "Torneio de Pingue-pongue", o que ajuda na marca e identificação, semelhante a como uma empresa usaria um logotipo, marca ou nome de empresa.

Desenhando o Objeto Pessoa

Em seguida, Tim desenha a classe Pessoa. Ele explica a importância de dividir nomes em primeiro e último nomes.

Por que separar primeiro e último nome?

Tim diz que é uma prática recomendada na indústria e ajuda com personalização, como chamar alguém pelo primeiro nome em emails.

Ele também alerta sobre problemas de divisão de nome:

• "Van Wilder" não é "Wilder"

• "Mary Sue" não é "Mary"

Então Tim enfatiza que separar primeiros e últimos nomes deve ser feito na etapa de entrada, não dividindo depois.

Outras propriedades

Tim adiciona mais campos:

• Endereço de email (string)

• Número de celular (string)

Ele enfatiza que números de celular devem ser armazenados como strings porque eles não são números a serem calculados ou manipulados. Eles podem incluir formatação como parênteses e traços.

Tim também esclarece que usa a palavra "propriedades" porque essas se tornarão propriedades de classe em C#.

O Objeto Torneio

Tim então apresenta o objeto mais importante: Torneio.

Ele explica que o torneio é o centro de dados, já que este aplicativo é um rastreador de torneios.

Propriedades do Torneio

Tim lista o que um torneio precisa:

1. Nome do Torneio Apesar de não estar nos requisitos, ele o adiciona porque vários torneios podem existir ao mesmo tempo. O nome ajuda a distingui-los.

2. Taxa de Inscrição Tim explica que uma taxa de inscrição permite que o administrador cobre equipes quando entram. Ele enfatiza que a taxa de inscrição deve ser armazenada como decimal, não double, porque é um dinheiro.

3. Equipes Inscritas Uma lista de equipes que entraram no torneio.

4. Prêmios Uma lista de prêmios, que podem ser zero ou mais.

5. Rodadas Essa parte é complexa. Tim explica que cada rodada contém confrontos, então a estrutura se torna uma lista de listas:

• Rodada 1: lista de confrontos

• Rodada 2: lista de confrontos

• Rodada 3: lista de confrontos Assim, Rodadas = Lista<Lista>

Tim observa que neste ponto, objetos Prêmio e Confronto ainda não estão criados, mas tudo bem porque eles serão desenvolvidos mais tarde.

Chaves Naturais e Dados Ausentes

Tim alerta que você perderá alguns dados durante o planejamento. Ele fala sobre Chaves Naturais e como alguns desenvolvedores as usam como identificadores. Por exemplo, um nome de torneio poderia ser único e atuar como um identificador.

No entanto, Tim prefere usar uma propriedade ID personalizada:

"Eu gosto de criar o meu próprio e chamá-lo de ID."

Ele diz que é mais fácil para indexação e gerenciamento.

Ele também nos lembra:

"Está tudo bem esquecer coisas."

Ele incentiva a fazer pesquisa e a olhar exemplos como cadastro da Amazon ou contatos de telefone para ver qual informação é tipicamente coletada para uma pessoa.

Mas ele avisa para não pensar demais nisso — erros acontecerão e podem ser corrigidos depois.

Não Planeje Demais

Tim enfatiza um equilíbrio crucial:

"Um aplicativo bem planejado que ainda está em sua tabela é inútil."

Ele explica que o planejamento é necessário, mas gastar muito tempo planejando pode impedi-lo de realmente construir o aplicativo. Ele incentiva seguir em frente e aceitar que o design evoluirá.

Objeto Prêmio

Tim apresenta o objeto Prêmio e suas propriedades:

1. Número do Lugar (int) Exemplo: 1 para primeiro lugar, 2 para segundo.

2. Nome do Lugar (string) Exemplo: "Campeão", "Vice-Campeão".

3. Quantidade do Prêmio (decimal) Quantia em dinheiro para esse lugar.

4. Percentual do Prêmio (double) Exemplo: 0.5 para 50%

Ele explica como o sistema decidirá entre usar a quantidade ou o percentual com base em qual não for zero.

Objeto Confronto

Tim então apresenta o objeto Confronto:

• Entradas: Lista de ConfrontoEntrada

• Vencedor: Equipe

• Número da Rodada: int

Ele explica que uma entrada de confronto representa uma equipe em um confronto.

Objeto Entrada de Confronto

Tim descreve as propriedades de ConfrontoEntrada:

• Equipe

• Pontuação

• Confronto Pai

Ele explica por que escolheu uma lista de entradas em vez de propriedades de equipe separadas. Isso permite flexibilidade, como ordenar entradas por pontuação.

Ele também explica o propósito do Confronto Pai: Ele vincula o vencedor de uma rodada à próxima rodada.

Conclusão - Plano de Dados Completo

Tim conclui que essas seis classes (Equipe, Pessoa, Torneio, Prêmio, Confronto, EntradaConfronto) são a base do aplicativo. Ele nos lembra que o plano de dados está completo e que a próxima lição se concentrará em construir a interface do usuário.

Ele termina dizendo que, embora esse design possa parecer confuso, ficará mais claro uma vez implementado no código.

Seguindo a abordagem de dados-primeiro de Tim no vídeo, agora você tem um entendimento claro de como estruturar os dados principais para um aplicativo de rastreamento de torneio. O próximo passo é construir a interface do usuário com base nesses dados, o que Tim cobre na Lição Quatro.