Was geht noch einfacher?

[Leonidas]

was bringt es die ganzen Methoden wie __len__ zu implementieren.

Wenn du ``__len__`` implementiest, kannst du ``len()`` auf eine Instanz deiner Klasse anwenden und bekommst somit ihre "Länge", d.h. die Anzahl der in ihr gespeicherten Adressen. Das ist insofern praktisch, dass der Anwender der Klasse nicht wissen muss ob man die anzahl der Einträge mit ``instanz.lenght()`` oder ``instanz.get_number_of_items()`` oder ``instanz.getItemNumber()`` aufrufen muss. Er kann einfach ``len(instanz)`` nutzen und das gibt ihm dann die Anzahl aus. Es ist eine Art, die API aller Klassen einheitlich zu halten.

[rolgal_reloaded]

was bringt es die ganzen Methoden wie __len__ zu implementieren.

Wenn du ``__len__`` implementiest, kannst du ``len()`` auf eine Instanz deiner Klasse anwenden und bekommst somit ihre "Länge", d.h. die Anzahl der in ihr gespeicherten Adressen. Das ist insofern praktisch, dass der Anwender der Klasse nicht wissen muss ob man die anzahl der Einträge mit ``instanz.lenght()`` oder ``instanz.get_number_of_items()`` oder ``instanz.getItemNumber()`` aufrufen muss. Er kann einfach ``len(instanz)`` nutzen und das gibt ihm dann die Anzahl aus. Es ist eine Art, die API aller Klassen einheitlich zu halten.

Das heisst, es geht darum jmd. der mit dieser Klasse etwas programmiert Methoden anzubieten, wie er sie auch von der Klasse List kennt?
Immerhin ist es ja eine Liste.

LG

rolgal_reloaded

[schlangenbeschwörer]

Wie intensiv man diese magischen Methoden für eine Klasse überläd hängt natürlich davon ab, es für eine Klasse ist und wer damit arbeitet. Wenn sie eh nur von einem Programm verwendet wird, in dem man diese Funktion nicht immer braucht, sind sie eher überflüssig, aber wenn man eine Klasse schreibt, die auch von anderen als Grundlage für verschiedenen Programme genutzt wird, hilft es schon. Zum einen ist es kürzer und zum anderen muss man den fremden Code nicht so verinnerlichen.

@Leonidas: Ehmm...wie schreibt man Unittests?
Und wie trennt man dann Daten und Darstellung, wenn man nicht nur auf die Klasse zugreift, sondern diese auch selbstständig bei bestimmten Gegebenheiten etwas darstellen will? Der __init__ entsprechende Methoden übergeben, die bestimmte Vorraussetzungen erfüllen? Also so, wie man stdout eine Instanz einer Klasse mit einer write-Methode übergibt? Oder alles mit return regeln, sodass man überprüfen muss, was zurückgegeben wird? Das denke ich, ist wohl besser, aber oft schwer zu machen...

Gruß, jj

[rolgal_reloaded]

Hallo nochmal,

also ich versuche immer gezeigtes einfließen zu lassen und dabei eigenes nicht gleich komplett zu verwerfen.
Weil einfach etwas zu 100% übernehmen = abschreiben nicht so das Ultimative ist, denke ich mal.

Ich habe jetzt bez. anzeigen() mal folgende Lösung probiert. Ein Mix BlackJack - Leonidas - rolgal_reloaded.....im Ernst gibts da grob was einzuwenden?

Code: Alles auswählen

    def __str__(self, ergebnis = None):
        if not ergebnis:
            ergebnis = self.eintraege
        ausgabe = ""
        for i, adresse in enumerate(ergebnis):
            ausgabe += str(i + 1) 
            for key in self.keys:
                ausgabe += " "
                ausgabe += adresse[key]
            ausgabe += "\n"
        return ausgabe

    def anzeigen(self):
        return self

    def suchen(self, suchbegriff):
        self.treffer = []
        for adresse in self.eintraege:
            if suchbegriff in adresse.itervalues():
                self.treffer.append(adresse)
        if self.treffer:
            return self.__str__(self.treffer)
        else:
            return 'Leider keinen Eintrag gefunden'

Jetzt kann man auf die Instanz print anwenden und __str__ innerhalb der Klasse wiederverwenden.
anzeigen() kann man wohl auch weglassen.

LG

rolgal_reloaded

[BlackJack]

Warum `self.treffer` statt nur `treffer`?

[rolgal_reloaded]

Warum `self.treffer` statt nur `treffer`?

Das ist noch ein Überbleibsel, in irgendeinem Versuch habe ich es als Instanzattribut gebraucht , das gehört jetzt natürlich weg , danke für den Hinweis!

LG

rolgal_reloaded

[schlangenbeschwörer]

Könntest du vlt. nochmal deinen aktuellen Code im Ganzen posten, möglichst schon Daten und Darstellung getrennt? Dann würd ich mal sehn, was man noch ändern bzw. anpassen muss und versuchen, ein einfaches GUI zu schreiben, aber deine Klasse so zu lassen, das andere hier GUIs mit anderen Toolkits schreiben können.

[rolgal_reloaded]

Könntest du vlt. nochmal deinen aktuellen Code im Ganzen posten, möglichst schon Daten und Darstellung getrennt? Dann würd ich mal sehn, was man noch ändern bzw. anpassen muss und versuchen, ein einfaches GUI zu schreiben, aber deine Klasse so zu lassen, das andere hier GUIs mit anderen Toolkits schreiben können.

Meinst du mich
Nehme ich an wegen - nochmal deinen aktuellen usw.

Oder eine Version von Leonidas - nehme ich an, weil du mit ihm ein Projekt besprochen hast.

LG

rolgal_reloaded

[rolgal_reloaded]

mit folgendem:

Code: Alles auswählen

    def eintragen(self):
        adresse = {}
        anzahl = 0
        for key in self.keys:
            eintrag = raw_input("%s: " % key.capitalize())
            if eintrag:
                adresse[key] = eintrag
                anzahl += 1
            else:
                adresse[key] = ""

        if self.mindestanzahl:
            if anzahl < self.mindestanzahl:
                return "Es müssen mindestens\
 %s Einträge gemacht werden!" % self.mindestanzahl
            else:
                self.eintraege.append(adresse)
                return "Eintrag hinzugefügt!"

Ich habe hiermal die Printanweisungen rausgenommen.
Das bedeutet für den Aufruf:
eintrag = adressbuch.eintragen()
print eintrag

oder nur adressbuch.eintragen()

Dann wird die Rückgabe aber wohl zu einem anonymen Objekt oder?
Sollte man sowas irgendwie unterbinden, weil es schlechter Stil ist.
Oder ist es einfach dem Benutzer seine Sache wie er den Aufruf macht?

LG

rolgal_reloaded

[schlangenbeschwörer]

Meinst du mich

ja

Zu deiner letzten Frage: Es geht ja grade darum, das die Klasse nicth für den "Endverbraucher" sein soll, sondern für Leute wie mich grade, die die Klasse dann dem "Endverbraucher", der nix von Pyhton versteht bzw. verstehen muss, nutzbar machen. Du kannst auch eine Konsolenanwendung schreiben. Das machst du dann in einer neuen Klasse oder Funktion, wo du mit einer Instanz deiner Grundklasse arbeitest und die Eingaben in Methodenaufrufe umwandelst und umgekehrt die zurückgegebenen Werte entsprechend dem Benutzer ausgibst.

[rolgal_reloaded]

Meinst du mich

ja

Zu deiner letzten Frage: Es geht ja grade darum, das die Klasse nicth für den "Endverbraucher" sein soll, sondern für Leute wie mich grade, die die Klasse dann dem "Endverbraucher", der nix von Pyhton versteht bzw. verstehen muss, nutzbar machen. Du kannst auch eine Konsolenanwendung schreiben. Das machst du dann in einer neuen Klasse oder Funktion, wo du mit einer Instanz deiner Grundklasse arbeitest und die Eingaben in Methodenaufrufe umwandelst und umgekehrt die zurückgegebenen Werte entsprechend dem Benutzer ausgibst.

Ich versteh schon was du meinst, ob meine Frage damit beantwortet ist weiss ich dennoch nicht:-)

Der Code ist im ganzen vielleicht etwas lang, wie und wo kann ich das jetzt außerhalb des Forums posten?

@edit:

Ich habs wieder denke ich:

http://paste.pocoo.org/show/1527/

LG

r_r

[Leonidas]

@Leonidas: Ehmm...wie schreibt man Unittests?

Dazu gibts ein ganzes Kapitel in "Dive into Python", danach komt gleich das Kapitel zu Test-First-Programming. Inzwischen müsste man aber überlegen, ob man das Modul ``unittest`` noch verwenden will oder sollte oder ob man nicht besser ``doctest``, ``py.test`` oder zumindest ``nose`` verwendet.

Und wie trennt man dann Daten und Darstellung, wenn man nicht nur auf die Klasse zugreift, sondern diese auch selbstständig bei bestimmten Gegebenheiten etwas darstellen will?

Die Klasse will aber nie bei bestimmten Gegebenheiten etwas darstellen. Daten sind passiv, auf sie wird zugegriffen. Wenn etwas dargestellt werden soll, muss man das auf höherer Ebene, in einer UI machen, die die Klasse anspricht. Nicht andersrum, sonst wird die Datenlogik mit der Darstellungslogik vermischt.

Der __init__ entsprechende Methoden übergeben, die bestimmte Vorraussetzungen erfüllen? Also so, wie man stdout eine Instanz einer Klasse mit einer write-Methode übergibt?

Würde zwar gehen, stellt dann aber unfassbar komplizierte Anforderungen an die GUI (zumindest wenn sie *etwas* größer sein soll), so dass du jedes Toolkit erstmal dazu bringen müsstest, die von deiner Klasse benötigte API zu haben.

Oder alles mit return regeln, sodass man überprüfen muss, was zurückgegeben wird? Das denke ich, ist wohl besser, aber oft schwer zu machen...

Warum sollte sowas schwer zu machen sein? Und Rückgabewerte überprüfen muss man nicht, wir sind nicht bei C - dafür gibt es Exceptions. Mit einer geeigneten Strukturierung von Exceptions lassen sich Fehler sehr gut behandeln.

[schlangenbeschwörer]

So, hier:
http://paste.pocoo.org/show/1528/
Hab mal so das geändert, was ich noch komisch fand. Ist jetzt leider ungetestet da untestbar, aber morgen liefer ich dazu ne GUI.
An einigen Stellen hab ich meine Änderungen kommentiert, aber halt nicht an allen...musste dir mal ansehen.

Ach, wozu sollte eigentlich

Code: Alles auswählen

def eingabe_eintragsnummer(nummer):
    try:
        return int(nummer)
    except ValueError:
        return None

gut sein? Das geht doch auch einfacher, oder? Und dann global über der klasse...naja.

edit @ Leonidas: Ich seh grad deinen Beitrag...hab grad nicht mehr so viel Zeit, kannst dir ja mal meine Version ansehen und es "testen".

Mit "selbstständig bei bestimmten Gegebenheiten etwas darstellen" meinte ich auch nicht direkt dieses Programm. ZB bei Spielen, für die man ein GUI schreibt, da kommt sowas häufiger vor. Klingt komisch, GUI für Spiele...

Gruß, jj

[rolgal_reloaded]

So, hier:
http://paste.pocoo.org/show/1528/
Hab mal so das geändert, was ich noch komisch fand. Ist jetzt leider ungetestet da untestbar, aber morgen liefer ich dazu ne GUI.
An einigen Stellen hab ich meine Änderungen kommentiert, aber halt nicht an allen...musste dir mal ansehen.

Ach, wozu sollte eigentlich

Code: Alles auswählen

def eingabe_eintragsnummer(nummer):
    try:
        return int(nummer)
    except ValueError:
        return None

gut sein? Das geht doch auch einfacher, oder? Und dann global über der klasse...naja.

edit @ Leonidas: Ich seh grad deinen Beitrag...hab grad nicht mehr so viel Zeit, kannst dir ja mal meine Version ansehen und es "testen".

Mit "selbstständig bei bestimmten Gegebenheiten etwas darstellen" meinte ich auch nicht direkt dieses Programm. ZB bei Spielen, für die man ein GUI schreibt, da kommt sowas häufiger vor. Klingt komisch, GUI für Spiele...

Gruß, jj

Kann man eigentlich seinen Code editieren, seh ich es wieder mal nicht oder gehts nicht???

Zur Funktion: die überprüft, ob eine Zahl eingegeben wurde - Auswahl löschen, bearbeiten - diese Funktion ist doch keine sinnvolle Methode der Klasse, denke ich, deshalb steht sie ausserhalb.
Ist doch nichts besonderes, oder?

Die Keys könnte man natürlich schon holen, das probiere ich mal...
aber jetzt weiss ich wieder warum ich es nicht getan habe:

Wenn du die keys mit irgendwas.keys() ausliest bekommst du sie ja nicht in der Ordnung zurück wie du sie in der Anwendung brauchst.

Deine anderen Änderungen muss ich mir erst näher ansehen.

LG

r_r

[rolgal_reloaded]

So hier mal eine allgemeinere Fassung. Kurz auch drei Beispiele zur Verwendung dieser Klasse. Hauptprogramm fehlt natürlich.

Übrigens gefällt es mir einfach besser, wenn das konkrete Objekt mit dem Konstruktor geladen bzw. gespeichert wird. Diese Klasse ist in ihrer Art sehr nahe an einer fertigen Anwendung und daher empfinde ich es als Vorteil, wenn man sich nach der Instanzierung z. Bsp. nicht mehr um die Abspeicherung kümmern muss.
Laden sollte daher auch keine Methode sein. Geladen wird bei der Instanzierung und solange das Objekt existiert gibts wohl keinen Grund eine Methode laden() darauf anzuwenden.

Gerne diskutier ich über alle meine kühnen Aussagen:-)

Hier der Code:


http://paste.pocoo.org/show/1531/




Zu den vier Fassungen, unflexibel - alles global, alles mit Funktionen, Lösung mit Klasse, Klasse mit abstrahierter Namensgebung werde ich mir jetzt ein ordentliches didaktisches Konzept bauen.
Ich glaube, dass man damit viele Themen rund ums Programmieren effizient besprechen kann.
Bevor ich die ersten beiden Version poste, werde ich nochmal gründlich drüber gehen.

LG

rolgal_reloaded

[BlackJack]

Bei meinem Beispiel war das Laden eine statische Methode, also nichts was man auf einem fertigen Exemplar sondern nur auf der Klasse aufruft. Wenn das Laden aus einer Datei in der `__init__()` steckt, schränkt man sich IMHO unnötig ein. Zum Beispiel bei (automatischen) Tests, die dann nicht ohne Datei oder Zugriff auf ein Dateisystem funktionieren, oder dass man andere Möglichkeiten wie laden aus einer CSV-Datei, Mail-Programm-Adressbuch oder ähnliches als Alternative ausschliesst.

Ausserdem kann man in der `__init__()` nicht das gesamte Objekt laden sondern nur Teile/Attribute davon, weil das Objekt selbst zu dem Zeitpunkt schon besteht. Das man so ein Objekt nicht konstruieren kann ohne die Schlüssel zu kennen, ist eine unglückliche Trennung. Diese Information gehört IMHO mit in die Datei.

Das aktuelle Arbeitsverzeichnis zu dem Zeitpunkt als das Modul geladen wurde, als Ausgangspunkt für alle Lade- und Speichervorgänge zu benutzen ist sehr willkürlich und nicht das was man erwarten würde. Was ist denn der Sinn von dieser Aktion und auch der Fallunterscheidung zwischen 'Linux1' und 'win32' wenn eh in beiden Fällen das gleiche gemacht wird? Bei mir kommt bei `sys.platform` 'linux2' heraus, dass heisst das würde bei mir ziemlich auf die Nase fallen, weil der Dateiname nicht angehängt wird, und versucht wird das aktuelle Arbeitsverzeichnis als Datei zu öffnen.

`self.min_entries` kann man mit 0 initialisieren, dann braucht man einen Test weniger.

``del`` ist keine Funktion.

Irgendwie gefällt es mir nicht so gut, weil es als OOP-Beispiel furchtbar ist. Das würde man nie ernsthaft so entwerfen.

[rolgal_reloaded]

Bei meinem Beispiel war das Laden eine statische Methode, also nichts was man auf einem fertigen Exemplar sondern nur auf der Klasse aufruft. Wenn das Laden aus einer Datei in der `__init__()` steckt, schränkt man sich IMHO unnötig ein. Zum Beispiel bei (automatischen) Tests, die dann nicht ohne Datei oder Zugriff auf ein Dateisystem funktionieren, oder dass man andere Möglichkeiten wie laden aus einer CSV-Datei, Mail-Programm-Adressbuch oder ähnliches als Alternative ausschliesst.

Ausserdem kann man in der `__init__()` nicht das gesamte Objekt laden sondern nur Teile/Attribute davon, weil das Objekt selbst zu dem Zeitpunkt schon besteht. Das man so ein Objekt nicht konstruieren kann ohne die Schlüssel zu kennen, ist eine unglückliche Trennung. Diese Information gehört IMHO mit in die Datei.

Das aktuelle Arbeitsverzeichnis zu dem Zeitpunkt als das Modul geladen wurde, als Ausgangspunkt für alle Lade- und Speichervorgänge zu benutzen ist sehr willkürlich und nicht das was man erwarten würde. Was ist denn der Sinn von dieser Aktion und auch der Fallunterscheidung zwischen 'Linux1' und 'win32' wenn eh in beiden Fällen das gleiche gemacht wird? Bei mir kommt bei `sys.platform` 'linux2' heraus, dass heisst das würde bei mir ziemlich auf die Nase fallen, weil der Dateiname nicht angehängt wird, und versucht wird das aktuelle Arbeitsverzeichnis als Datei zu öffnen.

`self.min_entries` kann man mit 0 initialisieren, dann braucht man einen Test weniger.

``del`` ist keine Funktion.

Irgendwie gefällt es mir nicht so gut, weil es als OOP-Beispiel furchtbar ist. Das würde man nie ernsthaft so entwerfen.

Zunächst mal zu "Linux 1" usw. Das hat nur was mit unserer Schule zu tun.

@edit
Aber es dämmert mir grad was....das ist gar nicht mehr nötig. Zu 99,9% hast du Recht ich brauch die Fallunterscheidung hier nicht......den Werdegang dieses Denkfehlers von mir erspar ich dir, ggg

Alles zum Thema laden() (automatische Tests usw.) war hier nicht vorgesehen. Nochmal: Beschränkung bedeutet oft leichteres Verständnis. Beim Programmieren der 4 Ansätze und ersten Tests habe ich gesehen, dass der 4. Ansatz oder vielleicht noch ein höher entwickelter wie deiner (Implementierung von __len__ usw.) zum Anfangen mit SchülerInnen zum Scheitern verurteilt ist. Warum denkst du sind in fast allen Schulen - ich rede nicht von HTLs udgl. - der Einsatz von Java im Unterricht zu einer Katastrophe geführt hat?

Ich finde es als OOPbeispiel gar nicht furchtbar, muss ich dir glatt widersprechen.
Es hat alle Aspekte, das ein OOPP haben sollten, dass man vieles besser machen kann ist ja eh klar.
Es ist dennoch vielseitig einsetzbar, nicht abstrakt und nicht falsch.

Die Sache mit dem Verzeichnis, dass man das nur so festlegen sollten, wenn kein Pfad angegeben wird, habe ich mir auch schon mal gedacht.

Die Idee mit min_entries klingt auch gut, sehe ich mir an.

Warum ist del keine Funktion, anders gefragt, wie sollte ich es ändern in meinem furchtbaren Code:-)

LG

rolgal_reloaded

[EyDu]

@rolgal_reloaded:
Lass doch bitte die full-quotes, die tragen nicht unbeding zur Übersicht bei

Es hat alle Aspekte, das ein OOPP haben sollten, dass man vieles besser machen kann ist ja eh klar.

Wie sieht das mit Polymorphie aus? Daran kann ich mich nämlich in dem Beispiel nicht erinnern, nachschauen konnte ich leider nicht, da der Server nicht erreichbar war.

Warum ist del keine Funktion, anders gefragt, wie sollte ich es ändern in meinem furchtbaren Code:-)

"del" ist ein Statement.

[BlackJack]

@rolgal_reloaded: Ich bin davon ausgegangen, dass die OOP-Variante nicht der Anfang ist, sondern das was am Ende präsentiert/gelernt wird, d.h. die meisten Methoden dürften zu dem Zeitpunkt schon als Funktionen in sehr ähnlicher Form aus früheren Versionen bekannt sein. Da kann man dann IMHO schon so etwas wie `__len__()` neu einführen. Der Übergang könnte so aussehen: Vorher hatten wir eine Liste, da konnte man mit `len()` Abfragen wieviele Datensätze vorhanden sind, jetzt haben wir eine eigene Klasse und so (`__len__()`) kann man dafür sorgen, dass man immer noch mit `len()` an diese Anzahl kommt.

Zum Thema `laden()`: Der Lehrer darf IMHO schon weiterdenken und sollte Beispiele geben, die erweiterbar sind, auch wenn das im Unterricht nicht getan wird. Und gerade beim Lernen ist der interaktive Interpreter eine sehr nützliche Sache, deshalb sollte man auf "Testbarkeit" Wert legen, auch wenn man keine automatischen Tests durchführt. Wenn man die meisten Funktionen/Methoden "live" aufrufen und die Auswirkungen inspizieren kann, bekommt man ein besseres Gefühl für die Wirkungsweisen und Zusammenhänge, als wenn man nur den Quelltext und einen kompletten, grossen Programmablauf "von aussen" beobachten kann.

Und gerade bei Python sind automatische Tests zum Beispiel als "doctests" sehr einfach. Das kann man den Schülern zumindest mal zeigen. Oder zu Aufgaben einen passenden Doctest mitgeben, den der selbstgeschriebene Code bestehen muss.

Bei uns im Informatik-Unterricht und in der Uni wurde immer Wert darauf gelegt, dass zu den Hausaufgaben nicht nur eine Funktion oder ein Progrämmchen geschrieben wurde, sondern auch ein dokumentierter, teilweise interaktiver Testlauf, abgeliefert wurde. Nur so lernt man zu testen und Fehler selber zu finden und bekommt ein "Gefühl" für den Code.

Wir scheinen und einig zu sein, dass wir uns uneinig sind was das OOP-Beispiel angeht.

Es geht nicht darum dass hier Klassen und Methoden angewendet werden, sondern dass der Entwurf IMHO schlecht ist. Schon ganz grundsätzlich. Ich habe sogar die Befürchtung, dass das nicht einmal etwas mit OOP zu tun hat und in den anderen 3 Varianten genauso ist. Das könnte teilweise daran liegen, dass es kein klares Ziel gab (gibt?) ─ die Anforderungen scheinen sich jedenfalls im Laufe der Zeit und während des Programmierens geändert zu haben. Wie hast Du denn vor dieses Programm zu motivieren und wie gehst Du beim Entwurf vor?

[rolgal_reloaded]

Grundsätzlich hast du mit vielem recht. Auch an deinen Ideen was man im Unterricht machen könnte - könnte!, gibts eigentlich nichts zu rütteln.

Aber zu der Sache mit OOP. Das war sogar deine Idee, als ich zum Spaß auch mal ein Adressbuch gebastelt habe, dabei mich ganz auf das Wesentlichste reduziert habe, um Dinge wie Zugriff auf ein Dict., Listen usw. zu zeigen.

Schließlich, auch durch dich, entstand die Idee, das Programm auch an sich zu verbessern. So ging es dann Schritt für Schritt weiter.

Der Entwurf ist schlecht. Was ist denn genau schlecht?
Eine Klasse, die es mir ermöglicht viele ähnliche Anwendungen zu machen, es ist kompakt übersichtlich, funktioniert, was soll daran schlecht, schlecht im engeren Sinne, nicht vor dem Hintergrund deines Genies sein ???
Und natürlich hat es was mit OOP zu tun.
Es wurde ein Datentyp definiert, die aufgenommen Daten der davon abgeleiteten einzelnen Objekte können manipuliert werden usw.

Jetzt sind die vier Versionen mal lauffähig, die will ich wo es geht selbst noch etwas tunen. Dann werden wir diskutieren ab welcher Klasse das machbar wäre und wie man das am besten aufbauen zu hat.
Grundsätzlich versucht man Motivation zu schaffen, in dem besprochene Themen unmittelbar erfahrbar werden. Häufig ist das im Unterricht nicht der Fall, ein ganz großes Problem auch des Instrumentalunterrichts übrigens. Gruhn - Der Musikverstand, ein super Buch zu diesem Thema.

Zum Entwurf kann ich daher mal zunächst nur sagen, dass ich versuchen werde, mit den SchülerInnen, nach Etstellung der anderen Versionen, ein Adressbuch abstrakter zu sehen, zu beschreiben, usw. Dadurch Parallelen zu anderen Objekten wie Telefonbuch usw. zu erkennen.

Eine Klasse von der man Objekte ableiten kann, die schon eine Anwendung ansich definieren legt nahe, dass man Mechanismen beim Instanzieren integriert, die man bei der Programmierung dieser einzelnen Anwendungen sowieso braucht und einbauen würde.
Stichwort laden() und speichern().

LG

rolgal_reloaded