Ach, glaub mir man ist nicht zu dumm.
Mache nebenbei bemerkt meinem Namen alle Ehre, aber lasse ich hier mal nicht zu sehr raushängen. Was man weiß ist halt immer relativ wenig im Verhältnis zu all dem was man nicht weiß. Aber egal, wollen ja hier nicht philosophieren.
Wenn du etwas nicht verstehst, einfach nachfragen. Ich hab ehrlich gesagt auch ein Weilchen gebraucht um mal den Sinn von Interfaces und natürlich auch abstrakten Klassen zu verstehen. Hatte halt mal ohne Objekt Orientierung angefangen (die guten alten Zeiten) und lange deren Vorteile nicht gesehen. Klar, keine Art von Programmierung ist perfekt, aber Objekt Orientierte Programmierung (
OOP) ist eigentlich sehr einsteiger freundlich.
Einer der wichtigsten Grundsätze in der
OOP besteht halt darin, nur zu zeigen was wirklich wichtig ist (siehe private, protected, public und published). Man versteckt einfach Implementierungsdetails. Genau genommen versucht die
OOP das reale Leben auf dem Rechner nachzubilden. Und wenn Menschen etwas recht gut können, dann abstrahieren. Klingt immer alles super kompliziert, ist es aber gar nicht.
Wenn ich mit dir über eine Liste rede, dann kannst du dir doch was drunter vorstellen? Du kennst wahrscheinlich ne Menge Arten von Listen. Mir würden jetzt Listen in Delphi (TStringList, THashedStringList), Listen im realen Leben z.B. Einkaufsliste, Anwesenheitsliste und und und einfallen (gelogen, jetzt müsste ich anfangen zu grübeln).
Nun gut, eine Einkaufsliste ist sicher was anderes als eine Anwesenheitsliste. Doch du kannst beides nicht nur unterscheiden, du kannst auch Gemeinsamkeiten feststellen. So "listen" beide etwas auf, man könnte auch sagen, sie "zählen" etwas auf (auflisten ist für die Definition einer Liste wohl schlecht gewählt). Aber da siehst du es, wir Menschen können sehr intuitiv abstrahieren, der Rechner halt nicht.
Dem musst du schon sagen, was (z.B. Listen) Dinge gemeinsam haben. Da gibt es mehrere Wege. Während die Einkaufsliste nun ja, Artikel speichert, wird die Anwesenheitsliste Anwesenheiten speichern (wie überraschend!). Aber hey, beide speichern etwas. Und beide sind am Anfang leer. Also muss es eine Möglichkeit geben, wie du etwas einträgst. Und es sollte eine Möglichkeit geben, dass du auch wieder liest was drauf steht.
Sagen wir mal Artikel ist eine Klasse (besteht aus Beschreibung und Anzahl) und Anwesenheit ist ne ganz andere Klasse (besteht aus der Person, Name + Vorname).
Ein Interface würde jetzt sowas wie eine Klasse sein, dass ein Methode "füge hinzu" und eine Methode "lese nächsten Eintrag" (z.B.) hat. Das heißt, du sagst : "Wenn es eine Liste ist, dann kann man mit füge hinzu ein Element hinzufügen. Und mit lese nächsten Eintrag einen Eintrag lesen (nil wenn kein weiterer vorhanden)".
Das ist es auch schon. Deine Konkrete Einkaufsliste besteht vielleicht aus einem Array von Artikeln oder einer verketteten oder doppelt verketteten Liste, vollkommen egal (vielleicht ja auch nur zettel und stift), aber sie instanziert (im weitesten Sinne erbt) von Liste. Damit muss sie die Funktionen "füge hinzu" udn "lese nächsten Eintrag" haben und auf ihre Weise implementieren.
Das gleiche gilt für analog für Anwesenheitsliste. Analog heißt hier also, dass z.B. Einkaufsliste alle Artikel in einer doppelt Verketteten Liste von Artikeln speichert. Anwesenheitsliste hingegen alle personen in einem Array[0..100] von Personen. Was die dann machen wenn "füge hinzu" aufgerufen wird, kann wieder ganz verschieden sein. Aber weil sie vom Interface Liste erben, haben sie diese Funktionen und egal was du für eine Liste hast, du kannst diese Funktionen aufrufen.
Die Vorteile kommen dann halt wirklich bei etwas komplizierteren Dingen zu tragen, aber ich hoffe es ist grob klarer geworden?