App-Daten gestalten (Lektion 03) — Ein tiefer Einblick mit Tim Corey

Warum Daten zuerst kommen

Tim beginnt die Lektion, indem er uns daran erinnert, dass wir bereits die Anforderungen und die Struktur für die Anwendung festgelegt haben. Jetzt ist es an der Zeit, die tatsächliche Datenstruktur zu erstellen. Er weist darauf hin, dass einige Entwickler es vorziehen, zuerst die Benutzeroberfläche zu gestalten, aber er glaubt, dass der größte Erfolg darin liegt, die Daten zuerst zu gestalten.

Tim erklärt seine Begründung:

"Ihre Anwendung ist ohne Daten nichts."\ Er stellt klar, dass eine App im Wesentlichen ein Vehikel ist, um Daten anzuzeigen, zu manipulieren, zu ändern und zu speichern.

Er gibt dann Beispiele, um seinen Standpunkt zu beweisen. Selbst ein Texteditor wie Microsoft Word ist um Daten herum aufgebaut — der Text selbst, Formatierung, Abstände, usw. Tim treibt dies noch weiter, indem er zeigt, dass selbst Spiele datenbasiert sind. Ein Schachspiel zum Beispiel ist nur eine Sammlung von Figuren, Positionen und Zügen — alles Daten. Ein Ego-Shooter-Spiel stützt sich auch stark auf Daten wie Charakterpositionen, Kugelgeschwindigkeit, Treffererkennung, Schadenswerte und Siegesbedingungen.

Sein Fazit ist klar:

"Alles dreht sich um Daten."

Deshalb beginnt er mit dem Datendesign, denn sobald Sie die Daten kennen, wird es einfacher, die Benutzeroberfläche zu erstellen. Andernfalls entwerfen Sie von einem leeren Blatt aus ohne Richtung. Dieser Ansatz hilft Entwicklern und Designern, die an Werkzeugen wie visuellen Suiten, Poster-Erstellern oder Logo-Erstellern arbeiten, weil auch diese Apps auf strukturierte Daten angewiesen sind, um Vorlagen, Schriftarten und Bildelemente zu erstellen.

Planen vor dem Codieren

Tim erklärt dann seine bevorzugte Planungsmethode:\ Er zeichnet alles auf Papier oder eine Tafel, weil es einfach zu ändern und anzupassen ist.

Er empfiehlt dringend, Visual Studio noch nicht zu öffnen und betont, dass die Planung außerhalb des Codes erfolgen sollte. Er sagt, dass die Planung in Notepad oder auf einem Blotter essentiell ist, weil Sie einfach Dinge durchstreichen und Änderungen vornehmen können, ohne im Code steckenzubleiben.

Tim zeigt die bereinigte Version seines Designs und geht es Schritt für Schritt durch. Seine erste Regel lautet:

"Schreiben Sie einfach etwas auf."

Er beginnt mit dem offensichtlichsten Objekt: Team.

Das Team-Objekt erstellen

Tim beginnt das Design, indem er aufschreibt, was ein Team benötigt. Er identifiziert zwei Haupteigenschaften:

Das Person-Objekt entwerfen

Als nächstes entwirft Tim die Person-Klasse. Er erklärt die Bedeutung davon, Namen in Vor- und Nachnamen zu unterteilen.

Das Tournament-Objekt

Tim stellt dann das wichtigste Objekt vor: Tournament.

Er erklärt, dass das Turnier das zentrale Daten-Drehkreuz ist, da diese Anwendung ein Tournament-Tracker ist.

Natürliche Schlüssel und fehlende Daten

Tim warnt, dass einige Daten im Planungsstadium fehlen werden. Er spricht über natürliche Schlüssel und wie einige Entwickler sie als Identifikatoren verwenden. Zum Beispiel könnte ein Turniername einzigartig sein und als Identifikator fungieren.

Tim zieht es jedoch vor, eine benutzerdefinierte ID-Eigenschaft zu verwenden:

"Ich mag es, meine eigene zu erstellen und nenne sie ID."

Er sagt, dass es für Indizierung und Management einfacher ist.

Er erinnert uns auch daran:

"Es ist in Ordnung, etwas zu übersehen."

Er ermutigt dazu, Recherchen durchzuführen und Beispiele wie Amazon-Anmeldungen oder Telefonkontakte anzusehen, um zu sehen, welche Informationen typischerweise für eine Person gesammelt werden.

Aber er warnt davor, es zu überdenken — Fehler passieren und können später behoben werden.

Nicht zu viel planen

Tim betont eine wesentliche Balance:

"Eine gut geplante Anwendung, die immer noch auf Ihrem Notizblock steht, ist nutzlos."

Er erklärt, dass Planung notwendig ist, aber zu viel Zeit in der Planung zu verbringen, kann Sie daran hindern, die Anwendung jemals zu bauen. Er ermutigt, voranzukommen und zu akzeptieren, dass sich das Design weiterentwickeln wird.

Preis-Objekt

Tim stellt das Preis-Objekt und seine Eigenschaften vor:

1. Platznummer (int)\ Beispiel: 1 für den ersten Platz, 2 für den zweiten.

2. Platzname (Zeichenkette)\ Beispiel: "Champion", "Erste/r Zweite/r".

3. Preissumme (Dezimalwert)\ Geldbetrag für diesen Platz.

4. Preisprozentsatz (Double)\ Beispiel: 0.5 für 50%

Er erklärt, wie das System entscheidet, ob der Betrag oder der Prozentsatz verwendet wird, basierend auf demjenigen, der ungleich null ist.

Matchup-Objekt

Tim stellt dann das Matchup-Objekt vor:

• Einträge: Liste von MatchupEntry

• Gewinner: Team

• Rundenzahl: int

Er erklärt, dass ein Matchup-Eintrag ein Team in einem Matchup repräsentiert.

Matchup Entry-Objekt

Tim beschreibt die Eigenschaften von MatchupEntry:

• Team

• Punktzahl

• Übergeordnetes Matchup

Er erklärt, warum er sich für eine Liste von Einträgen anstelle separat-angelegter Team-Eigenschaften entschieden hat. Dies ermöglicht Flexibilität, z. B. indem Einträge nach Punktzahl sortiert werden können.

Er erläutert auch den Zweck des übergeordneten Matchups:\ Es verknüpft den Gewinner einer Runde mit der nächsten Runde.

Fazit - Datenplan abgeschlossen

Tim kommt zu dem Schluss, dass diese sechs Klassen (Team, Person, Tournament, Prize, Matchup, MatchupEntry) die Grundlage der Anwendung bilden. Er erinnert uns daran, dass der Datenplan abgeschlossen ist und dass die nächste Lektion sich darauf konzentrieren wird, die Benutzeroberfläche zu erstellen.

Er schließt, indem er sagt, dass dieses Design zwar verwirrend erscheinen mag, es aber klarer wird, sobald es in Code umgesetzt ist.

Indem Sie Tims Daten-First-Ansatz im Video folgen, haben Sie jetzt ein klares Verständnis dafür, wie Sie die Kerndaten für eine Tournament-Tracker-Anwendung strukturieren. Der nächste Schritt ist es, das UI basierend auf diesen Daten zu erstellen, was Tim in Lektion Vier behandelt.