Diseño de Datos de Aplicaciones (Lección 03) — Un Análisis en Profundidad con Tim Corey

Por qué los datos son lo primero

Tim comienza la lección recordándonos que ya establecimos los requisitos y estructura de la aplicación. Ahora es el momento de construir la estructura de datos real. Señala que algunos desarrolladores prefieren diseñar la interfaz de usuario primero, pero él cree que el mayor éxito proviene del diseño de datos primero.

Tim explica su razonamiento:

"Tu aplicación no es nada sin datos." Aclara que una aplicación es esencialmente un vehículo para mostrar, manipular, cambiar y guardar datos.

Luego da ejemplos para demostrar su punto. Incluso un editor de texto como Microsoft Word se construye alrededor de datos: el texto en sí, el formato, el espaciado, etc. Tim lleva esto más allá al mostrar que incluso los juegos están basados en datos. Un juego de ajedrez, por ejemplo, es solo una colección de piezas, posiciones y movimientos: todo es datos. Un juego de disparos en primera persona también depende en gran medida de datos como posiciones de personajes, velocidad de bala, detección de impactos, valores de daño y condiciones de victoria.

Su conclusión es clara:

"Todo gira en torno a los datos."

Así que comienza con el diseño de datos porque una vez que conoces los datos, la interfaz de usuario se vuelve más fácil de construir. De lo contrario, estás diseñando a partir de una hoja en blanco sin dirección. Este enfoque ayuda a los desarrolladores y diseñadores que trabajan en herramientas como suites visuales, creadores de carteles o creadores de logotipos, porque incluso estas aplicaciones dependen de datos estructurados para crear plantillas, fuentes y elementos de imagen.

Planificación antes de codificar

Tim luego explica su método preferido de planificación: Dibuja todo en papel o en una pizarra porque es fácil cambiarlo y ajustarlo.

Recomienda encarecidamente no abrir Visual Studio todavía, enfatizando que la planificación debe hacerse fuera del código. Dice que planear en un bloc de notas o en un cuaderno legal es esencial porque puedes tachar fácilmente cosas y hacer cambios sin quedarte atascado en el código.

Tim muestra la versión depurada de su diseño y lo recorre paso a paso. Su primera regla es:

"Solo coloca algo."

Comienza con el objeto más obvio: el Equipo.

Construyendo el objeto Equipo

Tim comienza el diseño escribiendo lo que un Equipo necesita. Identifica dos propiedades principales:

Diseñando el objeto Persona

A continuación, Tim diseña la clase Persona. Explica la importancia de descomponer los nombres en nombre y apellido.

El objeto Torneo

Tim luego presenta el objeto más importante: Torneo.

Explica que el torneo es el centro de datos principal, ya que esta aplicación es un rastreador de torneos.

Claves Naturales y Datos Faltantes

Tim advierte que durante la planificación se perderán algunos datos. Habla sobre las Claves Naturales y cómo algunos desarrolladores las usan como identificadores. Por ejemplo, un nombre de torneo podría ser único y actuar como un identificador.

Sin embargo, Tim prefiere usar una propiedad de ID personalizada:

"Me gusta crear mi propio y llamarlo ID."

Dice que es más fácil para la indexación y la gestión.

También nos recuerda:

"Está bien perder cosas."

Nos anima a investigar y ver ejemplos como el registro en Amazon o los contactos telefónicos para ver qué información se suele recopilar para una persona.

Pero advierte no pensar demasiado: cometerá errores y se pueden corregir más tarde.

No planifique en exceso

Tim enfatiza un equilibrio crucial:

"Una aplicación bien planificada que todavía está en tu cuaderno legal es inútil."

Explica que la planificación es necesaria, pero pasar demasiado tiempo planificando puede impedir que construya la aplicación. Él nos anima a seguir adelante y aceptar que el diseño evolucionará.

Objeto Premio

Tim presenta el objeto Premio y sus propiedades:

1. Número de Lugar (int) Ejemplo: 1 para primer lugar, 2 para segundo.

2. Nombre del Lugar (cadena) Ejemplo: "Campeón", "Subcampeón".

3. Cantidad del Premio (decimal) Monto de dinero para ese lugar.

4. Porcentaje del Premio (doble) Ejemplo: 0.5 para 50%

Él explica cómo el sistema decidirá si usar cantidad o porcentaje según cuál de ellos no sea cero.

Objeto Emparejamiento

Tim luego presenta el objeto Emparejamiento:

• Entradas: Lista de EntradasEmparejamiento

• Ganador: Equipo

• Número de Ronda: int

Él explica que una entrada de enfrentamiento representa a un equipo en un enfrentamiento.

Objeto de Entrada de Enfrentamiento

Tim describe las propiedades de MatchupEntry:

• Equipo

• Puntuación

• Enfrentamiento Principal

Él explica por qué eligió una lista de entradas en lugar de propiedades de equipos separadas. Esto permite flexibilidad, como ordenar las entradas por puntuación.

También explica el propósito del Enfrentamiento Principal:\ Vincula al ganador de una ronda con la siguiente ronda.

Conclusión - Plan de Datos Completado

Tim concluye que estas seis clases (Team, Person, Tournament, Prize, Matchup, MatchupEntry) son la base de la aplicación. Nos recuerda que el plan de datos está completo y que la próxima lección se centrará en construir la interfaz de usuario.

Termina diciendo que aunque este diseño pueda parecer confuso, se volverá más claro una vez implementado en el código.

Siguiendo el enfoque de datos primero de Tim en el video, ahora tienes una comprensión clara de cómo estructurar los datos principales para una aplicación de seguimiento de torneos. El siguiente paso es construir la IU basada en estos datos, lo cual Tim cubre en la Lección Cuatro.