Das Telefonbuch: Abstraktion
Lösung geprüft
Die Aufgabe der heutigen Stunde ist das Telefonbuch! Wir bauen über die nächsten Stunden das Telefonbuch eines Handys nach. Der Anfang ist aber kein Code, sondern Nachdenken: aus einem Screenshot der App herausfinden, was für die Programmierung überhaupt wichtig ist.
Genau das heißt Abstrahieren. Auf dem Screenshot ist eine Menge zu sehen – Farben, ein Häkchen-Symbol, drei Punkte oben rechts. Davon interessiert uns fast nichts. Uns interessiert, welche Daten die App speichert und was man damit machen kann.
Das Telefonbuch eines Handys soll objektorientiert nachgebildet
werden. Dazu werden einige Klassen benötigt, zum Beispiel eine Klasse
Termin.
Aufgabe: Abstrahieren. Beschreiben Sie die für die Programmierung relevanten Informationen aus dem Screenshot. Orientieren Sie sich an der Frage: „Wie wird diese APP funktionieren?"
Was auf dem Screenshot zu sehen ist
Die Eingabemaske für einen neuen Kontakt hat diese Felder: Name, Unternehmen hinzufügen, und dann fünf Blöcke mit Überschriften: TELEFON, E-MAIL, ADRESSE, TERMINE und GRUPPEN.
Meine Beschreibung
Die App verwaltet Kontakte. Ein Kontakt ist das, was die App zusammenhält – alles andere hängt an ihm dran. Ein Kontakt hat einen Namen, und der Name ist das Einzige, was jeder Kontakt auf jeden Fall hat. Alles andere kann fehlen.
Auffällig ist, dass rechts neben fast jedem Feld noch ein zweites kleines Feld steht: neben der Telefonnummer steht MOBIL, neben der E-Mail und der Adresse jeweils PRIVAT, neben dem Datum GEBU…TAG. Das sind Auswahlfelder, keine Texteingaben – man tippt da nichts hin, sondern klappt sie auf und wählt aus. Für die Programmierung heißt das: es gibt eine feste, begrenzte Auswahl.
Und das wiederum heißt: eine Telefonnummer ist nicht einfach ein Text.
Sie ist ein Paar aus Nummer und Typ. Dasselbe gilt für
E-Mail und Adresse. Deshalb reicht es nicht, im Kontakt einen
String telefon zu haben – wir brauchen für diese Dinge
jeweils eine eigene Klasse.
Die kleinen Dreiecke in der Ecke der Felder bedeuten übrigens, dass man weitere hinzufügen kann. Ein Kontakt kann also mehrere Telefonnummern haben, mehrere Termine und mehrere Gruppen. Für die Programmierung heißt das: da brauchen wir Listen, keine einzelnen Attribute.
Welche Klassen wir daraus ableiten
| Klasse | Wofür sie da ist | Beziehung zum Kontakt |
|---|---|---|
Kontakt | Der Eintrag selbst, mit Name | – |
Telefon | Nummer + Typ (mobil / Festnetz) | Kontakt hat eine |
Email | Adresse + Typ (privat / geschäftlich) | Kontakt hat eine |
Adresse | Straße, Hausnummer, PLZ, Ort, Land + Typ | Kontakt hat eine |
Termin | Datum, Uhrzeit + Art (Geburtstag, …) | Kontakt hat mehrere |
Gruppe | Ein Gruppenname | Kontakt ist in mehreren |
Warum nicht alles in eine Klasse?
Man könnte ja auf die Idee kommen, alles in Kontakt zu
stopfen: String strasse, String plz,
String telefonnummer und so weiter. Geht – nur wird es
sofort unhandlich, sobald jemand zwei Telefonnummern hat. Dann bräuchte
man telefonnummer1, telefonnummer2 … und beim
dritten Anruf ist Schluss.
Mit einer eigenen Klasse Telefon ist das kein Problem:
dann liegt eine Liste davon im Kontakt und es können beliebig viele
sein. Das ist der eigentliche Gewinn der Abstraktion – nicht die
schöneren Namen, sondern dass Änderungen später nicht wehtun.
Was wir bewusst weglassen
Abstrahieren heißt auch, Sachen nicht zu modellieren. Der Screenshot zeigt ein Profilbild, einen „FERTIG"-Knopf und ein Drei-Punkte-Menü. Das ist alles Oberfläche. Ein Profilbild wäre zwar ein denkbares Attribut, aber für unser Programm, das auf der Konsole läuft, bringt es nichts. Der FERTIG-Knopf ist gar kein Datum, sondern eine Bedienung – der würde später in der GUI landen, nicht in der Klasse.
Die Faustregel, die dabei hilft: modelliere, was die App speichern muss, nicht was sie anzeigt.