Kommen wir nun zur Vererbung in der UML. Wir hatten
uns bisher mit der Beziehung Assoziation beschäftigt, bei der Assoziation,
sagen wir, es ist eine sogenannte, hat eine Beziehung.
Wir haben gesagt, eine Artikelgruppe hat Artikel, ein Hersteller hat eine Artikelliste.
Bei der Vererbung oder bei der Generalisierung und Spezialisierung
sagen wir, es ist eine, ist eine Beziehung.
Wir sagen, Der Student ist eine Person oder der Mitarbeiter
ist eine Person. Das ist erst mal etwas,
was etwas Unterschiedliches darstellt und ich will gleich noch einmal zeigen,
was sich daraus ergibt, die Vererbung bedeutet halt,
dass wir eine Basisklasse definieren, die Basisklasse wäre hier die Klasse Person.
Und von dieser Basisklasse gibt es sogenannte Subklassen.
Wir sagen die Subklasse, erbt von der Basisklasse.
Oder die Klasse, die Subklasse, die klassische Student,
Es ist eine Spezialisierung der Basisklasse Person.
Bei der Vererbung geht es darum, dass eben alles,
was die Personen ist, auch eben in dem Studenten vorhanden ist.
Aber der Student noch spezielle Attribute oder Methoden besetzt.
Also der Student erbt einmal Nachname und Vornamen und Geburtsdatum von Personen
und erweitert die Basisklasse um die Matrikelnummer Studienfachfachsemester.
Es gibt daher auch eben verschiedene Begriffe
Wie gesagt, der Student erbt von der Klasse Person,
Student ist eine Subklasse der Klasse Person oder die klasse Student erweitert die klasse Person.
Und es wäre dann eben die spezielle Klasse Person,
ist die generelle Klasse, wenn wir nämlich sagen,
wir haben verschiedene Arten von Personen in unserem Programm,
wir bilden einmal Student ab und einmal Mitarbeiter ab,
dann würden wir sagen, okay,
Mitarbeiter ist auch eine Person,
Mitarbeiter besitzt eben auch Nachname, Vorname Geburtsdatum,
Mitarbeiter soll eben Nachname,
Vorname Geburtsdatum von der Klasse Person erben
Sollte die Klasse aber dann um Personalnummergehalt und Raumnummer erweitern.
Eben die speziellen Attribute der Klasse, Mitarbeiter. Die verschiedenen Subklassen,
Student und Mitarbeiter haben hier eben unterschiedliche spezielle Attribute,
kann eben auch unterschiedliche spezielle Methoden haben.
Und das bezeichnen wir eben dann als Generalisierung Spezialisierung oder eben als Vererbung.
Wenn wir ja dieses Konstrukt haben, gibt es so
ein paar Auswirkungen, die wir jetzt auch behandeln wollen.
Zum einen Für die Attribute können wir sagen,
wir haben generelle Attribute, das hat einmal den Vorteil natürlich,
dass wir sie nicht jetzt doppelt definieren müssen.
Aber gut, man könnte natürlich auch sagen,
ich mache zwei Klassen, die eine Klasse ist Student,
besitzt halt eben Nachname, Vormannahme, Geburtsdatum und die weiteren Attribute.
Und ich habe eine Klasse Mitarbeiter besitzt auf Vorname, Nachname,
Geburtsdatum und so weiter. Von der Schreibarbeit wäre das vielleicht
vertretbar. Und wir würden dann eben sagen, okay,
es gibt dann eben zwei verschiedene Klassen, wir könnten auf die Basisklasse eigentlich verzichten.
Die Vererbung machen wir aber nicht, nur deshalb, weil wir irgendwie schreibfaul sind.
Zum einen ist es so, diese Wiederverwendbarkeit, die wir haben. Wenn wir eben sagen,
wir haben eben allgemeine Eigenschaften, die sich auf alle Personen beziehen,
dann wollen wir die eben auch allgemein definieren und wenn wir Änderungen in der allgemeinen Klasse machen,
dann wollen wir eben auch,
dass die sich auswirken auf alle Subklassen,
weil sie die ja erben.
Das birgt natürlich auch wieder eine Gefahr in sich.
Wenn man ein komplexes Programm hat und viele Klassen vielleicht von vielen anderen Klassen erben,
dann werden Änderungen in den Basisklassen große Auswirkungen haben.
Das bedeutet im Prinzip, dass man solche Auswirkungen auch immer testen muss.
Und deswegen muss man sich sehr genau überlegen,
an welcher Stelle setzt man die Vererbung sinnvollerweise ein
Bringt sie einem etwas. Und wann ist es vielleicht eben
nicht notwendig? Da gibt es eben zwei Aspekte.
Gibt es erstmal viele Attribute, die man generalisieren kann?
Es ist eben wert, eine Basisklasse zu definieren.
Eine generelle Klasse. Oder sagt man, okay,
diese Klassen sind zwar, haben zwar vielleicht ein paar Attribute,
die ähnlich sind oder gleich sind,
aber wir können auch eben doch zwei verschiedene Klassen definieren und lassen das mit der Basisklasse.
Auf der anderen Seite muss man sich eben überlegen, was vielleicht noch wichtiger ist,
gibt es eben hinreichend viele spezielle Tribute und spezielle Methoden,
die wir abbilden wollen. Wenn wir jetzt eben sagen,
wir haben hier die klasse Person und nehmen wir mal an,
wir hätten jetzt bei Student nur die Matrikel-Nummer und bei Mitarbeiter die Personalnummer als einziges,
was speziell wäre, dann muss man sich eben fragen,
wollen wir nicht eher sagen, es gibt eine Klasse,
die heißt Person.
In der Klasse kann ich entweder Matrikel-Nummer oder Personalnummer speichern,
habe da vielleicht zwei Attribute und mache dann vielleicht ein Kennzeichen und sage,
okay, diese Person ist ein Student und diese Person ist ein Mitarbeiter.
Dann habe ich die Unterscheidung auch, dann habe ich sie
nicht über eine Vererbungshierarchie Aber ich spare mir immerhin zwei Klassen.
Wenn es eben zu wenige spezielle Eigenschaften, Attribute, Methoden gibt,
dann würde man auch oft auf die Vererbung verzichten und eher eine generelle Klasse bilden.
Und wenn es sowas gibt wie, dass es eben bestimmte Kennzeichnungen geben soll,
dann kann man eben ein Kennzeichen definieren.
Das ist dann ein Attribut mehr, was man hat,
aber eben nicht diese Klassen mehr.
Und mit der Vererbung muss man halt eben in der Programmierung
und der Softwareentwicklung immer so umgehen, dass man sagt,
okay, wenn es notwendig ist,
wenn es sinnvoll ist,
dann mache ich die Vererbung
Ich muss es aber immer irgendwie begründen können. Ich mache nicht die Vererbung um des Vererbenswillens. In unseren Übungsaufgaben ist es natürlich so ein bisschen so,
dass ich dann manchmal darauf hindeute, wenn ich den Sachverhalt beschreibe,
hier sollen jetzt eine Vererbung gemacht werden,
weil ich sage, es gibt irgendwie spezielle Attribute,
da wäre aber eh nicht zig Attribute aufschreiben wollen,
ist es natürlich bei uns oft so,
dass wir vielleicht nur zwei,
drei spezielle Attribute haben und deswegen eine Vererbung machen,
weil wir halt eben in unseren Beispielen da auch vieles verzichten,
da müssen wir dann eben sehen, macht es hier Sinn,
irgendwo spezielle Attribute oder spezielle Klassen zu definieren,
weil wir davon ausgehen,
dass es vielleicht auch
noch mehr spezielle Attribute gibt
Aber das werde ich hier in den Übungsaufgaben praktisch auch so formulieren,
dass sie grundsätzlich erkennen können,
ob man jetzt eine Vererbungshierarchie macht oder halt eben weglässt.
Aber diese Frage lässt sich so und so nicht immer endgültig beantworten.
Es ist, wie oft in der Modellierung oder in der Softwareentwicklung,
man kann es auf die eine Weise machen oder auf die andere Weise.
Für beide Varianten gibt es vielleicht Argumente und man erkennt nicht
unbedingt sofort, schon gar nicht bei der Modellierung unbedingt,
was die bessere Variante ist.
Es gibt vielleicht auch gar keine bessere Variante und
dementsprechend gibt es auch manchmal mehrere gute Lösungen
Was halt eben immer wichtig ist,
und manchmal stelle ich auch solche Fragen dann in der Klausur,
warum haben sie die Vererbung an der Stelle gemacht?
Oder warum haben sie die nicht gemacht,
dass sie halt eben begründen, wie sie etwas abbilden?
Und dazu sollten sie halt eben dann fähig sein,
dass sie sagen, aus dem und dem Grund habe ich
jetzt hier eine Vererbungshierarchie aufgebaut, oder es halt eben gelassen.
Dazu werden wir auch Übungsaufgaben haben,
in den Übungen ist ja kein Problem,
da können wir ja mal diskutieren,
bei Klausur oder so muss man natürlich dann schon seine Lösung hinschreiben,
sich festlegen, für sich sich festlegen und dann eben vielleicht auch seine Gründe haben.
Und das ist halt eben etwas, ja,
wir uns weitgehend in den Übungen
dann auch beschäftigen
So, jetzt habe ich ja bisher nur die Attribute.
Wir haben halt eben auch Methoden, Methoden,
die wir in der Basisklasse definieren.
Wenn wir eine Methode in der Basisklasse definieren,
dann können wir sie auf ein Objekt der Klasse Person anwenden hier.
Auf ein Objekt der Klasse Student und auf ein Objekt der Klasse Mitarbeiter.
Also auch die Methoden werden geerbt und diese Methoden können halt
eben in jedem Objekt einer beliebigen Klasse dann eben angewendet werden,
wenn sie in der Basisklasse definiert sind.
So, es gibt dann ja auch noch diese Sichtbarkeiten,
die gelten ja
auch für Attribute
Für Methoden. Die hatten wir ja mit diesem Plus und Minus
und ich habe jetzt hier dieses Hashtag eingezeichnet, bezeichnet.
Ich habe ja gesagt, diese Sichtbarkeiten,
diese Gültigkeitsbereiche sind für uns nicht so relevant,
aber vielleicht dann eben zur Erklärung, wenn wir erben,
dann erben wir alle Attributor-Methoden.
Habe ich auch gesagt, das stimmt soweit.
Wenn die Sichtbarkeit aber sozusagen auf Private ist und ich
nur innerhalb einer Klasse auf ein Attribut zugreifen kann,
was ich nur kann, wenn ich das mit Minus hier definiere,
dann kann ich auch nicht aus der Subklasse drauf zugreifen.
Deswegen gibt es hier dieses Hashtag,
das ist diese sogenannte Sichtbarkeit Protected und diese Protected,
Sichtbarkeit bedeutet, dass ich eben innerhalb der Klasse,
also innerhalb jeder Methode der Klasse Person,
auf diese Attribute zugreifen kann, aber auch aus den Subklassen.
Also die werden ja geerbt und dementsprechend sind die hier drin vorhanden.
Wenn ich das sozusagen private definiere, werden sie auch geerbt,
nur ich kann sie da nicht direkt ansprechen,
dazu bräuchte da Methoden. Das ist aber etwas wieder,
was für die Programmierung viel wichtiger ist,
für diese Vorlesung, weil die es einmal erklärt haben,
was dieses Hashtag jetzt hier soll und auch was diese Sichtbarkeit protected bedeutet.
Aber ich habe ja auch schon gesagt, für Attribute ist es
für uns nicht so relevant, die Sichtbarkeit und die Methoden
Die definieren wir eh immer public mit Plus.
Dementsprechend hat das dann auch keine Auswirkungen, wenn wir
hier etwas mit Plus definieren, dann gilt das Gleiche.
Dann würden wir in den Subklassen darauf zugreifen können,
dann könnten wir auch von außen drauf zugreifen,
was immer das dann auch bedeutet.
Aber man könnte sich auch mit Plus definieren, hier die Attribute.
Aber wie gesagt, dieser Sichtbarkeitsbereich protected ist extra für
die Vererbung definiert. Machen wir ein zweites Beispiel,
wo man sich vielleicht auch die Vererbung dann klar machen kann.
Wir haben jetzt hier ein Programm,
dieses Programm soll in irgendeiner Form geometrische Figuren verarbeiten.
Diese geometrischen Figuren sollen eben gemalt werden können auf irgendeiner grafischen Benutzeroberfläche.
Und dazu gibt es eben eine Positionsangabe,
die sei X und Y, es gibt eine Farbe.
Man kann sie halt eben einblenden, die Figur,
dann wird sie angezeigt oder ausblenden.
Und man kann meinetwegen auch noch die Farbe verändern und setzen.
Das sind sozusagen Methoden, die kann ich auf alle geometrische Figuren anwenden.
So, und dann gibt es bestimmte geometrische Figuren.
Ein Kreis ist eine geometrische Figur. Ein Kreis soll halt eben
auch die Positionsangaben haben, die Farbe haben und diese Methoden Blenden ausblenden,
Setfarbe. Aber ein Kreis hat natürlich eine spezielle Eigenschaft,
das ist nämlich der Radius. So, der Radius,
der soll vom Typ Double sein, also die Zimalzahl.
Und wir sagen hier noch eine Zusicherung, Radius ist größer,
null. So, und jetzt haben wir hier noch,
Get Fläche, Get Umfang, für den Kreis.
So, dann haben wir eben Rechteck,
Rechteck besteht eben aus zwei Linien sozusagen, A und B.
Die sollen beide eine Länge größer Null haben und wird eben
auch an eine Position gesetzt.
Auch hier können wir dann eben die Fläche und den Umfang
Und dann haben wir ein Dreieck, ein Dreieck besteht aus Dreilinien,
ABC und da gibt es auch Geldfläche, keine Umfang.
So, was hier auffällt, ist natürlich,
dass wir in allen drei Klassen Getfläche und Get Umfang haben.
Die meisten von ihnen werden ja auch wahrscheinlich schon verstehen,
warum, weil wir, zwar hier immer dieselbe Methode benennen,
die Signatur, also der Methodenkopf ist immer der gleiche,
aber wir wissen ja, die Implementierung ist unterschiedlich,
wenn wir die Fläche für einen Kreis berechnen,
müssen wir hier eine andere Implementierung in diese Klasse schreiben,
als wenn wir die Fläche für ein Rechteck oder für ein Dreieck berechnen.
Und dementsprechend wurden diese Methoden eben in die Subklassen reingeschrieben,
weil nicht der Methodenkopf spezifisches oder speziell ist, aber die Implementierung.
Und von der Logik her gehören sie dann eben in die Subklassen.
Wir können jetzt auch jeweils sagen, der Kreis ist eine geometrische Figur,
das Rechtergessene, geometrische Figur und das Dreiergessene geometrische Figur.
Wir haben halt eben hier in sinnvoller Weise so eine Vererbung gemacht.
Wenn wir eine Vererbung hier machen,
das fällt hier auch nochmal auf, gibt es keine Wertigkeit,
die wir dran schreiben.
Bei den Assoziationen haben wir ja mal irgendwelche Zahlen drangeschrieben.
Die Vererbung erfolgt ja auf der Klassenebene
Und wir sagen eben, der Kreis ist eine geometrische Figur.
Also er ererbt die Sachen, dieses Objekt,
was wir erzeugen, referenziert nicht irgendwie ein anderes Objekt.
Also Kreis referenziert kein geometrisches Figurobjekt, sondern es wird zu
einem einer Klasse sozusagen verschmelzen, Kreis und geometrische Figur.
Es wird alles geerbt und es wird ein Objekt erzeugt vom Typkreis.
Und da sind halt eben XY-Farbe drin enthalten,
Speicherbereiche dafür enthalten, sodass man direkt darauf zugreifen kann.
Da gibt es keine Wertigkeit der Beziehung. Und jeder,
der dann eben an eine Vererbungshierarchie irgendwelche Zahlen dran schreibt,
zeigt damit, dass sie da irgendwas grundlegend nicht richtig gelernt oder verstanden haben,
weil aus der Logik heraus dürfen die ja gar keine Zahlen dran und werden wir auch nicht machen.
Dementsprechend, auch wenn das hier ein bisschen unsauber im PowerPoint verrutscht ist,
grundsätzlich können wir aber dann eben mehrere Linien zusammenführen.
Mann, das soll jetzt hier eine Linie sein,
die zusammenführen und dann eben auf ein Dreieck bringen,
also auf dieses Symbol bringen, was die Vererbung andeutet.
Wir können aber natürlich auch das dreimal einzeln machen,
dass wir sagen, okay, dieses Dreieck oder diese Pfeil,
diesen Pfeil machen wir von Kreis aus vom Rechteck und von Dreieck.
Aber wir können das, wie gesagt,
auch hier zusammenführen
So, jetzt haben wir halt eben diese Klassen,
vier Klassen, das mit der Spezialisierung, ist,
glaube ich, hier gut nachvollziehbar.
Man kann sich noch vorstellen, dass das alles noch viel,
viel weitergehen würde, für wahrscheinlich viel mehr Attribute noch haben,
wenn wir das wirklich dann zeichnen wollen und so weiter.
Aber also als Beispiel, Marc, das erstmal reichen.
Jetzt kann man sich aber zwei Sachen fragen.
Zum einen kann man sich fragen, gibt es eigentlich Objekte
der Klasse,
geometrische Figur oder Georg-Figur
Gibt es sozusagen eine geometrische Figur als geometrische Figur?
Jetzt könnte man sich vorstellen, ja, das könnte ja so
ein Polygon sein, irgend so ein Vieleck oder sonst was.
Ja, aber kann es hier nicht sein,
weil ich ja hier überhaupt keine Daten dazu habe,
wenn es irgendwie ein anderes Vieleck wäre oder so etwas,
dann müsste ich ja die Daten dazu haben.
Das habe ich ja mal erst in den speziellen Klassen.
Also wenn ich noch ein Fünfeck und ein Sechseck oder so
abbilden möchte oder allgemein ein Vieleck oder ein Polygon abbilden möchte,
dann müsste ich das halt eben anders tun.
Also so wie die Klasse hier definiert ist,
Inhalt hält sie ja nicht genug Inhalte,
um wirklich eine konkrete geometrische Figur zu zeichnen.
Also können wir dann eben auch sagen,
in unserem Programm macht es eigentlich gar keinen Sinn,
ein Objekt der Klasse geometrische Figur zu definieren.
Und das können wir machen. Wir können Klassen definieren,
so, dass sie sozusagen nur als Basisklasse fungieren,
dass sozusagen die generellen Attribute Methoden eben in ihr
zwar als Generalisierung definiert werden,
aber von dieser Klasse selber gar kein Objekt
erzeugt werden kann
Und wenn wir das halt haben wollen, dann bezeichnen wir diese Basisklasse als sogenannte abstrakte Klasse,
diese abstrakte Klasse, ist halt eben so definiert,
dass wir von ihr nur erben können, aber eben keine Objekte instanzieren können.
Das ist manchmal ganz gut für die Übersichtlichkeit und es hat nachher noch einen weiteren Vorteil,
aber das ist schon mal erst mal gut,
dass man sagt, okay,
ich gebe euch eine abstrakte Klasse und dann kommt keiner auf die Idee,
davon ein Objekt zu erzeugen und wenn das täte,
dann würde auch das sein Syntagsfehler,
also ein Fehler im Programm geben,
weil man,
das ist die Regel,
das nicht machen darf
Gut, wenn man jetzt diese abstrakten Klassen haben,
dann nehmen wir mal an, jometrische Figur, definieren wir jetzt abstrakt.
Jetzt können wir noch eine zweite Sache machen. Und zwar,
das, was wir hier haben mit Get Fläche,
Get Umfang in der Definition, könnten wir vielleicht auch noch vereinfachen.
Also ich hatte ja gesagt, Get Fläche,
Get Umfang ist natürlich speziell für jede Subklasse.
Definiert werden muss sie nachher bei der Programmierung dort.
Das ist auch vollkommen in Ordnung. Aber wir sehen ja
in dem UML-Klassendiagramm sonst auch nur den Methodenkopf.
Wir sehen ja nur die Signatur, wir sehen ja nicht
die Implementierung, also das, was dahinter programmiert wird.
Also könnte man doch irgendwie sagen,
ich möchte diese Methoden hier oben definieren, so definieren,
dass sie sozusagen in Kreis, Rechteck und Dreieck automatisch auch mit aufgenommen werden.
Und dieses Konstrukt gibt es auch eben in der Programmierung.
Man bezeichnet dies dann eben als abstrakte Methoden. Wir können in der abstrakten Klasse,
die wir jetzt meinetwegen als abstrakt definieren, die geometrische Figur,
zwei abstrakte Methoden definieren, Get Fläche und Get Umfang,
wenn wir sie dort abstrakt definieren in der Basisklasse,
dann heißt es,
wir müssen sie in den Subklassen nochmal definieren und dort implementieren.
Also dort die Programmierung reinschreiben
Eine abstrakte Methode ist eine Methode, die nur etwas definiert.
Also wir schreiben nur den Methodenkopf hin, aber keine Implementierung.
Also es gibt keine Programmierung. Und wir sagen dann,
wir überschreiben dann, das ist ein Konzept der Objektorientierung für die Vererbung.
Wir überschreiben die Methode, Get Fläche, Get Umfang in der Klasse Kreis,
in der Klasse Rechtdeck, in der Klasse Dreieck.
Und wenn wir sie eben als abstrakt in der Basisklasse definieren,
dann müssen wir das auch tun. Jede Klasse,
die dann eben von geometrischer Figur oder geomem Figur erbt,
muss dann die Methoden, die als abstrakt definiert werden, überschreiben.
Das heißt eben, es muss eine Implementierung erfolgen in den Subklasten.
Und das ist etwas, was auch sehr schwer ist,
nachzuvollziehen, aber das ist halt eben eine Sache,
die wichtig ist für die Objektorientierung. Dadurch können wir eben gewährleisten,
dass sich Programmierer an gewisse Richtlinien halten und wir sozusagen mit abstrakten Klassen,
mit Basisklassen Vorgaben machen, auf die wir uns verlassen können,
dies im Programm immer gibt.
Wir können mir dann sogar so weit gehen und sagen,
wir können hier in der Basisklasse Methoden definieren,
die auf die Methoden der Subklassen zugreifen.
Wenn wir sie nämlich abstrakt definiert haben, können wir uns sicher sein,
dass es eben immer eine Methode geht, Fläche,
Geld, Umfang gibt in jeder der Subklassen. Das bedeutet,
dass ich hier sogar in der Basisklasse die benutzen kann,
weil wenn ich ein Objekt erzeuge,
dann erzeuge ich ein Objekt der Subklasse und ich kann mir sicher sein,
die Subklasse hat diese Methode implementiert,
dann würde das eben bedeuten,
dass ich halt
die auch aufrufen kann
Auch das ist wieder nachher in der Programmierung wichtig und kann man da ausprobieren.
Auch das werden wir hier in der Vorlesung nicht machen.
Ich wollte nur dieses Konzept der abstrakten Klassen und Methoden auf jeden Fall nicht verschwiegen haben.
Dem Begriff kann man oder sollte man schon mal gehört haben,
so richtig verstehen,
was das bedeutet und wie man das vor allen Dingen sinnvoll einsetzen kann,
kann man sicherlich erst,
wenn man das mal programmiert hat und das ist auch in der Regel erst,
wenn man mal größere Projekte gemacht hat,
weil diese abstrakten Klassen und Methoden werden eh erst dann relevant,
wenn man natürlich sehr komplexe Strukturen hat,
auch gerade so Vorgaben machen will oder vielleicht sogar machen muss.
Und dementsprechend ist das etwas, was er für fortgeschrittene Programmierer nachher sinnvoll ist,
aber es gehört nun mal zu dem Konzept der Vererbung
dazu und deswegen wollte ich es zumindest einmal erwähnt haben.
Also wenn wir hier so abstrakte Klassen haben,
dann würden wir halt eben sagen,
wir nehmen hier das Schlüsselwort Apps Fact oder diesen Stereo Type oder Stereotypen
Abstract mit auf und könnten dann eben abstrakte Methoden hier hinschreiben,
abstrakte Methoden werden sozusagen in der Basisklasse dann definiert und in den Subklassen überschrieben.
Da müssen wir sie dann nicht nochmal im Modell wiederholen.
Abstrakte Methoden schreibt man in der UML übrigens offiziell kursiv,
da sie ihre Modelle nachher eh handschriftlich machen, verlange ich von ihnen nicht,
dass sie da dann irgendwie kursiv und nicht kursiv unterscheiden.
Für uns haben diese abstrakten Methoden jetzt auch nicht so einen Stellenwert.
Wie gesagt, das würde man eher in der Programmierung machen.
Aber so von der, von der Modellierung her wäre das
die Variante
So, und dann gibt es noch etwas, auch in jeder objektorientierten Programmiersprache.
Das sind eben Interfaces, diese Interfaces beinhalten ausschließlich abstrakte Methoden.
Also ein Interface beschließt, beinhaltet ausschließlich eben die Methodenköpfe.
Wenn wir an unsere Anbildung da ganz am Anfang denken,
wo ich diesen Kreis gemalt habe, wo innen der Datenwürfel war,
dann diese vierzackigen Sterne und dann auf dieser,
auf dem Rand des Kreises waren eben diese Rauten gemalt.
Da hatte ich ja auch schon gesagt, das ist das Interface.
Das ist sozusagen die Information, wie wir eine Methode aufrufen.
Dann können wir eben sowas in der Programmierung auch separat erstmal
definieren und sagen, das ist das Interface dieser Klasse.
Und es besteht nur aus diesen Methodensignaturen oder Methodenköpfen. Und
wenn ich die dann eben zusammenfasse, dann würden das sein,
das könnte ich in einem Interface, in einer Interface-Datei sozusagen zusammenfassen.
Und das wäre dann eben eine Sammlung von abstrakten Methoden nach
der Sprache. In dem Fall schreiben wir dann eben,
müssen wir sie gar nicht als abstrakt definieren,
weil im Interface klar ist,
dass nur die Methodenköpfe da drin enthalten sind
Interfaces, wenn man so möchte, eine spezielle abstrakte Klasse,
nämlich eine abstrakte Klasse, die ausschließlich aus abstrakten Methoden besteht,
wohingegen abstrakte Klassen übrigens auch nicht abstrakte Methoden enthalten kann und halt eben andere Kretboote.
Und das kann halt ein Interface nicht. Damit ist ein Interface etwas sehr Spezielles,
was man in der Programmierung auch braucht,
in der Modellierung werden wir das Interface jetzt auch nicht
so oft verwenden für unsere Zusammenhänge oder für unsere Übungsaufgaben,
hat das dann auch wieder nicht die Bedeutung.
Aber auch da wollte ich einmal zeigen,
wie das funktioniert
Hier praktisch eine ähnliche Notation auch wie bei der Vererbung. Wir haben zwar eine gestrichelte Linie,
weil es ein Interface ist, aber wäre es hier eine abstrakte Klasse,
dann würden wir hier die Linie durchziehen und die gleiche Symbolik verwenden,
dieses Dreieck oder diesen Pfeil,
sodass wir halt eben sowas ähnliches machen wie Erben.
Wir sagen nur, beim Internet-Face, wir implementieren das Interface
in eine Klasse und wir sagen jetzt nicht die Klasse,
erbt von dem Interface, aber das ist eigentlich auch erstmal nur ein sprachlicher,
kleiner Unterschied.
Auf jeden Fall müssen dann in der Klasse die das Interface implementiert,
alle abstrakten Methoden, also alle Methoden, die im Interface definiert sind,
müssen dann eben hier in der Klasse implementiert werden.
Wie gesagt, auch das gehört mit zur UML-Notation,
aber inhaltlich durchdringen kann man das wahrscheinlich nur,
wenn man die Programmierung macht.
Gut,
das war es dann erstmal zu der Vererbung