Concevoir les données de l'application (Leçon 03) - Une plongée en profondeur avec Tim Corey

Pourquoi les Données Priment

Tim commence la leçon en nous rappelant que nous avons déjà établi les exigences et la structure de l'application. Il est maintenant temps de construire la structure réelle des données. Il souligne que certains développeurs préfèrent d'abord concevoir l'interface utilisateur, mais il croit que le meilleur succès provient de la conception des données en premier.

Tim explique son raisonnement :

"Votre application n'est rien sans données." Il précise qu'une appli est essentiellement un véhicule pour afficher, manipuler, modifier et enregistrer des données.

Il donne ensuite des exemples pour prouver son point. Même un éditeur de texte comme Microsoft Word est construit autour de données — le texte lui-même, le formatage, l'espacement, etc. Tim pousse cela plus loin en montrant que même les jeux sont basés sur les données. Un jeu d'échecs, par exemple, est juste une collection de pièces, positions et mouvements — que des données. Un jeu de tir à la première personne repose également fortement sur des données comme les positions des personnages, la vitesse des balles, la détection des coups, les valeurs de dommages et les conditions de victoire.

Sa conclusion est claire :

"Tout tourne autour des données."

Ainsi, il commence par la conception des données car une fois que vous connaissez les données, l'UI devient plus facile à construire. Sinon, vous concevez à partir d'une ardoise vierge sans direction. Cette approche aide les développeurs et les concepteurs qui travaillent sur des outils comme les suites visuelles, les créateurs d'affiches ou de logos, car même ces applications dépendent de données structurées pour créer des modèles, polices et éléments d'image.

Planification avant le Codage

Tim explique ensuite sa méthode préférée de planification : Il dessine tout sur papier ou un tableau blanc car il est facile de changer et d'ajuster.

Il recommande fortement de ne pas ouvrir encore Visual Studio, soulignant que la planification doit se faire en dehors du code. Il dit que planifier sur un bloc-notes ou un carnet est essentiel car vous pouvez facilement barrer des choses et apporter des modifications sans vous coincer dans le code.

Tim montre la version nettoyée de son design et la parcourt étape par étape. Sa première règle est :

"Mettez juste quelque chose."

Il commence par l'objet le plus évident : Équipe.

Construire l'Objet Équipe

Tim commence le design en notant ce dont une Équipe a besoin. Il identifie deux propriétés principales :

Concevoir l'Objet Personne

Ensuite, Tim conçoit la classe Personne. Il explique l'importance de séparer les prénoms et noms.

L'Objet Tournoi

Tim introduit ensuite l'objet le plus important : le Tournoi.

Il explique que le tournoi est le centre de données, car cette application est un suiveur de tournoi.

Clés Naturelles et Données Manquantes

Tim prévient que vous manquerez certaines données pendant la planification. Il parle des Clés Naturelles et de la façon dont certains développeurs les utilisent comme identifiants. Par exemple, un nom de tournoi pourrait être unique et agir comme un identifiant.

Cependant, Tim préfère utiliser une propriété ID personnalisée :

"J'aime créer la mienne et l'appeler ID."

Il dit que c'est plus facile pour l'indexation et la gestion.

Il nous rappelle aussi :

"C'est correct de manquer des trucs."

Il encourage à faire des recherches et à observer des exemples comme l'inscription Amazon ou les contacts téléphoniques pour voir quelles informations sont généralement collectées pour une personne.

Mais il avertit de ne pas trop y réfléchir — des erreurs se produiront et pourront être corrigées plus tard.

Ne pas trop planifier

Tim souligne un équilibre crucial :

" Une application bien planifiée qui est encore sur votre bloc-notes est inutile. "

Il explique que la planification est nécessaire, mais que passer trop de temps à planifier peut vous empêcher de jamais construire l'application. Il encourage à aller de l'avant et à accepter que le design évoluera.

Objet Prix

Tim introduit l'objet Prix et ses propriétés :

1. Numéro de place (int)\ Exemple : 1 pour première place, 2 pour seconde.

2. Nom de la place (chaîne)\ Exemple : " Champion ", " Premier dauphin ".

3. Montant du prix (décimal)\ Montant d'argent pour cette place.

4. Pourcentage du prix (double)\ Exemple : 0,5 pour 50 %

Il explique comment le système décidera d'utiliser le montant ou le pourcentage selon lequel est non nul.

Objet Match

Tim introduit ensuite l'objet Match :

• Entrées : Liste de MatchupEntry

• Gagnant : Équipe

• Numéro de la ronde : int

Il explique qu'une entrée de match représente une équipe dans un match.

Objet Entrée de Match

Tim décrit les propriétés de MatchupEntry :

• Équipe

• Note

• Match parent

Il explique pourquoi il a choisi une liste d'entrées au lieu de propriétés d'équipe séparées. Cela permet de la flexibilité, comme ordonner les entrées par score.

Il explique également l'objectif du Match parent :\ Il lie le gagnant d'une ronde à la ronde suivante.

Conclusion - Plan de données terminé

Tim conclut que ces six classes (Équipe, Personne, Tournoi, Prix, Match, MatchupEntry) sont la base de l'application. Il rappelle que le plan de données est terminé et que la prochaine leçon portera sur la création de l'interface utilisateur.

Il termine en disant que bien que ce design puisse sembler confus, il deviendra plus clair une fois mis en œuvre dans le code.

En suivant l'approche de Tim orientée données dans la vidéo, vous avez maintenant une compréhension claire de la structuration des données essentielles pour une application de suivi de tournoi. La prochaine étape consiste à construire l'interface utilisateur basée sur ces données, ce que Tim couvre dans la leçon quatre.