[0:01] Hi, hier ist Stefan. In dieser Podcast-Episode geht es ums Fachgespräch.

[0:05] Wenn du noch mehr Informationen zum Fachgespräch von mir haben willst,

[0:08] dann schau doch mal auf meiner Website vorbei, dasperfektefachgespräch.de.

[0:14] Und jetzt wünsche ich dir viel Spaß mit der Podcast-Episode.

[0:19] Herzlich willkommen zum Anwendungsentwickler-Podcast,

[0:21] dem Podcast rund um die Ausbildung zum Fachinformatiker für Anwendungsentwicklung.

[0:25] In dieser Episode schließe ich meine häufigen Fragen im Fachgespräch rund um die Programmierung ab.

[0:31] Viel Spaß dabei!

[0:37] Hallo, zurück zu den häufigen Fragen im Fachgespräch.

[0:41] Ich hatte es in der letzten Episode ja nicht ganz geschafft, die Fragen zu Ende durchzugehen,

[0:45] denn ich habe noch einige auf der Liste stehen.

[0:48] Deswegen habe ich bei den Eigenschaften von Programmiersprachen aufgehört.

[0:52] Heute nehmen wir uns dann die letzten drei Punkte vor,

[0:55] die Objektorientierung, die Fehlerbehandlung und dann noch ein paar tiefer gehende Fragen.

[1:00] Schauen wir mal, wie lange das heute dauert.

[1:02] Ich hoffe, ich komme mit einer halben Stunde hin.

[1:04] Ich lege einfach mal los und setze nahtlos da an, wo wir beim letzten Mal aufgehört haben.

[1:09] Die Objektorientierung, da haben wir noch so ein paar Sachen vergessen.

[1:12] Vergessen nicht, aber die habe ich nicht so sinnvoll unterbringen können

[1:15] in den bisher behandelten Fragen rund um die Objektorientierung.

[1:20] Deswegen habe ich noch mal so ein paar Sachen zusammengeschrieben,

[1:23] die man im Rahmen der Objektorientierung noch fragen kann.

[1:26] Und das geht gleich los mit dem Schlüsselwort This.

[1:29] Was macht das This?

[1:31] This, das sollte man nicht meinen, das ist etwas,

[1:34] was man als Objektorientierter-Entwickler eigentlich fast täglich benutzt,

[1:37] aber viele können es trotzdem nicht erklären, was dahintersteckt.

[1:41] Und This ist eigentlich relativ einfach.

[1:43] Das ist ein Zeiger auf das aktuelle Objekt.

[1:46] Meinen Programmierlehrlingen bringe ich das immer wie folgt bei.

[1:50] Wenn ich ein Objekt instanziiere, dann gebe ich der Variablen,

[1:54] der ich dieses Objekt zuweise, ja einen Namen.

[1:57] Als Beispiel Auto, BMW gleich New Auto und dann gebe ich da die Parameter rein.

[2:04] Und über diesen Namen, BMW in diesem Fall, kann ich eben auf dieses Objekt zugreifen,

[2:08] kann dort Methoden aufrufen und Eigenschaften auslesen und so weiter.

[2:12] Aber was ist denn, wenn ich diese Klasse Auto jetzt programmiere

[2:16] und ich noch gar nicht weiß, wie die Variable später heißt,

[2:20] der ich zugewiesen werde als Klasse Auto?

[2:23] Das kann ich ja nicht wissen, das liegt ja beim Aufrufer.

[2:26] Da brauche ich aber jetzt ja irgendeine Möglichkeit, um auf mich selbst quasi zuzugreifen,

[2:32] ohne einen expliziten Namen dafür zu vergeben.

[2:34] Und für diesen Zeiger auf mich selbst, da muss ich irgendeinen Namen definieren

[2:39] und dieses ist eben This.

[2:41] Das heißt, das This zeigt einfach auf mich selbst,

[2:44] auf die aktuelle Instanz der Klasse, in der ich gerade programmiere.

[2:49] Das war es schon.

[2:51] Dann kommen wir zu einem weiteren Punkt, nämlich Static.

[2:55] Static ist noch ein Schlüsselwort, das ich mal am Rande erläutert habe,

[2:59] aber was man für sich alleine stehend auch nochmal gut nachfragen kann.

[3:02] Was bedeutet denn jetzt Static?

[3:04] Static, oder wenn ich es übersetzen würde, eben der statische Kontext,

[3:08] das kann ich vor Attribute oder Methoden oder auch Klassen schreiben,

[3:11] aber wir nehmen jetzt mal Attribute und Methoden,

[3:14] die können benutzt werden, ohne eine Instanz ihrer Klasse zu haben.

[3:19] Das heißt, wenn ich bei dem Beispiel Auto von eben bleibe,

[3:22] dann kann ich schlecht bei einem Auto Gas geben,

[3:25] wenn ich kein Objekt dieser Klasse Auto dann habe.

[3:28] Ich kann nicht einfach sagen, Auto, gib Gas,

[3:30] sondern ich brauche halt eben ein konkretes Auto, um da Gas zu geben.

[3:33] Es gibt aber auch Methoden oder Eigenschaften,

[3:35] die völlig unabhängig von einer Instanz sind, sondern die allgemeingültig sind.

[3:39] Wie zum Beispiel, angenommen wir würden das da ablegen wollen,

[3:42] die zulässige Höchstgeschwindigkeit auf deutschen Autobahnen.

[3:45] Angenommen die gäbe es und die läge bei 130 kmh,

[3:48] dann wäre es ja blöd, wenn ich die an einem Objekt hinterlege

[3:51] und jedes Mal ein konkretes Auto fragen muss, wie die Höchstgeschwindigkeit ist.

[3:55] Das wäre unsinnig.

[3:57] Stattdessen würde ich das an die Klasse Auto hängen

[3:59] und dann diesen Zugriff über die Klasse regeln.

[4:02] Damit das funktioniert, müssen eben diese Methoden oder Attribute static sein.

[4:07] Static oder der statische Kontext, das ist auch das, was ausgeführt wird,

[4:12] bevor das Programm wirklich gestartet wird, wenn man so will.

[4:15] Wenn ich mal an Java denke, da habe ich meine public static void main.

[4:19] Diese main Methode kann nur deswegen aufgerufen werden, weil die static ist.

[4:23] Denn wenn sie nicht static wäre, müsste ich sie an einem Objekt aufrufen,

[4:26] aber zum Zeitpunkt des Programmstarts gibt es ja noch gar keine Objekte,

[4:30] denn das Programm läuft ja noch gar nicht.

[4:32] Also an welchem Objekt sollte ich diese Methode aufrufen?

[4:34] Da gibt es keins, das geht nicht.

[4:36] Deswegen muss die static sein.

[4:38] Also alles, was im statischen Kontext läuft, das führt die Laufzeit der Umgebung aus,

[4:42] bevor meine ersten Objekte instanziiert und ausgeführt werden.

[4:46] Deswegen sind die static.

[4:48] Jetzt haben diese static Methoden insbesondere leider einige Nachteile,

[4:53] aber auch einige Vorteile.

[4:54] Der große Vorteil ist, da sie nicht an einem Objekt hängen,

[4:57] sind sie auch nicht abhängig vom Zustand eines Objekts.

[4:59] Wie zum Beispiel beim Auto, wenn ich da Gas gebe,

[5:02] dann hängt natürlich die Änderung des Objekts davon ab,

[5:05] welche Geschwindigkeit das Auto denn aktuell hat.

[5:07] Wenn es schon mit Höchstgeschwindigkeit fährt,

[5:09] dann kann ich so viel Gas geben, wie ich will, es wird nicht mehr schneller.

[5:11] Wenn ich das jetzt zum Beispiel testen will, brauche ich aber auch ein Auto,

[5:15] was zum Beispiel im Stillstand ist, ein Auto, was normale Geschwindigkeit fährt,

[5:18] ein Auto, was Höchstgeschwindigkeit fährt und so weiter.

[5:20] Und jeder dieser Zustände sorgt dafür, dass sich die Methode unterschiedlich verhält,

[5:24] was wir auch wollen, was ja auch sinnvoll ist.

[5:26] Aber das macht das Testen etwas schwieriger.

[5:28] Wenn ich dagegen eine statische Methode habe,

[5:30] dann ist die von keinem Zustand irgendeines Objekts abhängig.

[5:33] Das heißt, ich kann die einfach aufrufen und kriege als Ergebnis etwas zurück.

[5:37] Das heißt, ich bin in meinem Setup für den Test deutlich einfacher.

[5:42] Ich brauche nämlich kein Setup.

[5:43] Ich kann die Methode einfach aufrufen und kriege etwas zurück und teste dagegen.

[5:46] Fertig.

[5:47] Bei einer Instanzmethode müsste ich erst ein Objekt erzeugen,

[5:50] das Objekt in einen gültigen Zustand versetzen,

[5:52] in einen bestimmten Zustand für den Test, den ich durchführen will,

[5:55] und dann kann ich die Methode erst aufrufen.

[5:57] Also, sehr umfangreich zu testen.

[5:59] Und das funktioniert bei statischen Methoden deutlich einfacher.

[6:02] Auf der anderen Seite haben sie auch einen Nachteil.

[6:04] Zum Beispiel kann ich sie nicht überschreiben.

[6:05] Wenn ich statische Methoden habe, dann sind die an der Klasse definiert

[6:08] und die sind nicht polymorph.

[6:10] Das heißt, wenn ich jetzt eine Vererbung habe,

[6:12] eine Klasse, die von meinem Auto zum Beispiel erbt,

[6:14] dann kann die diese statische Methode nicht überschreiben.

[6:17] Sondern es wird immer die Methode an der konkreten Klasse aufgerufen

[6:20] und ich kann sie nicht polymorphen mit einer anderen Implementierung versehen.

[6:24] Das geht dann leider nicht.

[6:27] Ja, dann kommen wir zu einer ganz anderen Frage,

[6:29] aber ungefähr auch in dem Bereich Methoden wenigstens.

[6:31] Nämlich, was ist ein Konstruktor?

[6:33] Ein Konstruktor ist eine ganz besondere Methode,

[6:36] die eine Objektinstanz erzeugt.

[6:38] Das heißt, die ist dafür zuständig, aus einer Klasse ein Objekt zu instanziieren.

[6:43] Und diese Methode, die ich da aufrufe,

[6:46] die hat zumindest in Java und auch in vielen anderen Polymer-Sprachen

[6:49] ein ganz bestimmtes Aussehen, eine ganz bestimmte Signatur.

[6:53] In Java ist das zum Beispiel so,

[6:55] dass der Konstruktor den Namen der Klasse 1 zu 1 übernehmen muss,

[6:59] also inklusive camelCase und so weiter,

[7:01] und keinen Rückgabewert hat.

[7:03] Das heißt, wenn ich mir eine übliche Methodendefinition angucke,

[7:06] dann habe ich eben Rückgabewert, Name, Parameter.

[7:08] Ein Konstruktor hat keinen Rückgabewert,

[7:11] hat denselben Namen wie die Klasse

[7:13] und hat dann ganz normal die Parameter.

[7:15] Daran erkenne ich quasi in Java einen Konstruktor.

[7:17] Das muss aber nicht so sein.

[7:19] In anderen Polymer-Sprachen ist das auch anders.

[7:21] Zum Beispiel in PHP,

[7:23] da hat der Konstruktor den definierten Namen

[7:25] unterstrich, unterstrich, initialize.

[7:27] Und damit wird dann zum Beispiel ein Objekt instanziiert.

[7:31] In Ruby heißt der Konstruktor einfach new,

[7:34] wie eine ganz normale Methode.

[7:36] Und wenn ich den Konstruktor in Polymer-Sprachen aufrufen will,

[7:38] dort ist es eigentlich fast überall identisch.

[7:40] Da mache ich es nämlich mit dem Schlüsselwort new.

[7:42] Das ruft eben diese besondere Methode auf, den Konstruktor.

[7:46] In den meisten Polymer-Sprachen, Java, C Sharp, PHP,

[7:49] wird das new vor den Klassennamen geschrieben.

[7:51] Also Auto A gleich new Auto.

[7:54] In anderen Polymer-Sprachen ist das anders,

[7:56] wie zum Beispiel in Ruby.

[7:57] Da mache ich Klassenname Punkt new.

[8:00] Das heißt, da sieht der Methodenaufruf des Konstruktors

[8:03] genauso aus wie bei allen anderen Methoden.

[8:05] Das unterstreiche nochmal,

[8:06] dass der Konstruktor tatsächlich nichts anderes ist

[8:08] als eine besondere Methode.

[8:10] Also warum soll die anders aufgerufen werden?

[8:12] Warum soll ich dafür new benutzen,

[8:13] wenn ich auch einfach die Syntax benutzen kann

[8:15] wie für alle anderen Methoden?

[8:17] Da haben sie sich bei Ruby ein bisschen Gedanken gemacht

[8:19] und das ein bisschen optimiert, wie ich finde.

[8:22] Ja, jetzt ist die Frage,

[8:23] was packe ich denn in so einen Konstruktor rein?

[8:25] Welche Parameter sollte ein Konstruktor bekommen?

[8:28] Da sage ich immer,

[8:29] ein Konstruktor sollte all die Parameter bekommen,

[8:32] die nötig sind, um das zu erzeugende Objekt

[8:35] in einem gültigen Zustand zu hinterlassen.

[8:38] Der Konstruktor hat eine zentrale Aufgabe,

[8:40] nämlich, dass man keine Objekte erzeugen kann,

[8:42] die ungültig sind.

[8:43] Wenn ich also zum Beispiel ein Auto habe

[8:45] und es ist ganz wichtig, dass es einen Kilometerstand hat,

[8:48] dann muss der Konstruktor diesen Kilometerstand

[8:50] in einem gültigen Zustand hinterlassen

[8:52] und nicht einfach so etwas sagen wie

[8:54] Kilometerstand gleich minus 1,

[8:56] sondern der muss dafür sorgen,

[8:57] dass der Kilometerstand zum Beispiel mindestens 0 ist,

[8:59] dass er also nicht negativ sein kann.

[9:02] Das ist ganz wichtig,

[9:03] damit ich eben nicht Objekte einfach wahllos erzeugen kann

[9:06] und dann arbeite ich damit

[9:07] und irgendwo später,

[9:08] wenn ich das Objekt dreimal irgendwo durchgereicht habe,

[9:11] tritt auf einmal ein Fehler auf,

[9:12] weil irgendein Attribut in einem ungültigen Zustand ist,

[9:14] zum Beispiel, weil der Wert 0 ist

[9:15] oder weil der Wert negativ ist oder was auch immer.

[9:17] Dafür sollte ein Konstruktor Sorge tragen.

[9:20] Der sollte alle die Parameter reinbekommen,

[9:22] die absolut notwendig sind,

[9:24] um das Objekt korrekt zu erzeugen.

[9:27] Ganz oft gibt es auch Attribute,

[9:29] die ich nicht zwingend setzen muss,

[9:31] die einfach auf den Standardwert gesetzt werden können.

[9:34] Dafür sollte auch der Konstruktor dann Sorge tragen.

[9:36] Dafür überlädt man den Konstruktor dann sehr häufig.

[9:39] Wenn ich also sage,

[9:40] es gibt einen Konstruktor,

[9:41] der alle Werte, die notwendig sind, reinbekommt,

[9:43] aber es gibt auch andere Konstruktoren,

[9:45] die den ersten überladen

[9:46] und dann bestimmte Werte einfach auf Default-Werte setzen,

[9:49] wie zum Beispiel Kilometerstand auf 0,

[9:51] aber eben nicht auf Null oder auf Minus 1

[9:54] oder sonst irgendwas,

[9:55] sondern in einem gültigen Zustand.

[9:57] Das ist die Hauptaufgabe des Konstruktors.

[10:01] Dann haben wir noch zwei völlig andere Fragen,

[10:03] die damit erstmal wenig zu tun haben,

[10:04] nämlich einmal, was sind Enumerations?

[10:07] Enumerations, das sind Datentypen

[10:08] mit einer endlichen Menge an erlaubten Werten.

[10:12] Der Klassiker ist sowas wie Wochentag.

[10:14] Wochentage gibt es genau sieben Stück,

[10:15] das werden nicht mehr und auch nicht weniger

[10:17] und die haben einen definierten Namen.

[10:19] Und da will ich mir nicht jedes Mal merken,

[10:20] wenn ich programmiere,

[10:21] war jetzt Null Sonntag oder Montag?

[10:23] Ich weiß es nicht mehr.

[10:24] Stattdessen lege ich mir eine Enumeration an,

[10:26] wo halt alle erlaubten Werte drinstehen,

[10:28] also Montag, Dienstag, Sonntag bis Sonntag

[10:30] und dann habe ich den Vorteil,

[10:31] dass ich zum einen sprechende Namen benutzen kann

[10:33] und nicht irgendwelche Int-Werte zum Beispiel,

[10:35] die den Datentyp repräsentieren

[10:37] und ich habe den Vorteil,

[10:38] dass ich auch keine anderen

[10:39] als die erlaubten Werte benutzen kann.

[10:41] Ich kann dann nicht einfach,

[10:42] wenn ich zum Beispiel Int als Wochentag benutze,

[10:44] auf einmal eine Acht reingeben.

[10:46] Den achten Wochentag gibt es nicht.

[10:48] Das ist mit Enumerations ausgeschlossen,

[10:50] weil ich eben nur eine Liste der erlaubten Werte definiere

[10:53] und gar nichts anderes reingeben kann,

[10:55] als in dieser Liste steht.

[10:57] Und dann die letzte Frage,

[10:58] welche Vorteile bieten Listen gegenüber Arrays?

[11:02] Auch das eine recht allgemeine Frage.

[11:04] Wenn wir jetzt an Listen denken,

[11:05] an die generischen Klassen,

[11:06] eine List of T zum Beispiel,

[11:08] was hat das den Vorteil gegenüber Arrays?

[11:10] Der zentrale Vorteil ist eigentlich,

[11:11] dass sie redimensionierbar sind.

[11:13] Arrays sind ja in ihrer Länge fix.

[11:16] Wenn ich sie deklariere,

[11:18] muss ich gleich sagen,

[11:19] wie lang dieses Array ist.

[11:20] Also zum Beispiel String 5,

[11:22] dass also genau 5 String-Elemente dort drinstehen können

[11:26] und ich kann den auch nicht verlängern

[11:28] oder verkürzen oder sonst was.

[11:29] Er bleibt fix.

[11:30] Und bei Arrays ist es jetzt so,

[11:32] dass sie im Speicher wirklich hintereinander angelegt werden.

[11:35] Wenn ich also sage,

[11:36] new String 5,

[11:37] dann werden dort 5 String-Elemente im Speicher platziert

[11:40] und zwar direkt aufeinanderfolgend im Speicher.

[11:42] Das heißt,

[11:43] die sind wirklich als ein Block im Speicher abgelegt.

[11:46] Und da habe ich bei Listen den Vorteil,

[11:48] die liegen nicht als ein Block da,

[11:49] sondern die sind redimensionierbar.

[11:51] Wie funktioniert das?

[11:52] Jedes Element der Liste zeigt im Prinzip

[11:54] auf seinen Vorgänger oder Nachfolger,

[11:56] je nachdem, was man braucht.

[11:57] Meistens auf beide.

[11:59] Das heißt, ich habe eine doppelt verkettete Liste zum Beispiel,

[12:02] in die Datenstruktur abtauchen wollen.

[12:05] Und das funktioniert dann so,

[12:07] dass ich das eine Listen-Element einfach irgendwo im Speicher ablege

[12:10] und das hat dann halt einen kleinen Zeiger auf das nächste Objekt.

[12:13] Und dieses Objekt kann irgendwo anders im Speicher liegen,

[12:16] ist ganz egal,

[12:17] denn der Vorgänger weiß ja, wo es liegt.

[12:19] Das heißt, ich kann auch einfach die Liste erweitern

[12:21] oder ich kann Elemente wieder rausnehmen

[12:23] oder umsortieren oder was auch immer.

[12:25] Das kann ich mit einer Liste verhältnismäßig einfach.

[12:27] Im Array ist es halt so,

[12:28] ein Block im Speicher und der ist dann da.

[12:30] Und wenn ich den größer machen will,

[12:32] dann geht das halt nicht.

[12:33] Bei Listen geht das, weil sie redimensionierbar sind.

[12:36] Eventuell sind sie sogar ein bisschen schneller als Arrays,

[12:39] aber das kommt dann wieder auf die Promiersprache

[12:41] und die Implementierung an,

[12:42] welche Liste man nimmt,

[12:43] ob es zum Beispiel eine Linked-List ist

[12:45] oder eine Array-List,

[12:46] die im Prinzip nichts anderes ist als ein Array,

[12:48] bloß mit Listen-Funktionen.

[12:49] Also da gehen wir jetzt ins Detail,

[12:51] das interessiert dann tatsächlich in der Prüfung auch niemanden mehr.

[12:53] Aber der zentrale Vorteil ist,

[12:55] dass Listen eben redimensionierbar sind

[12:57] und Arrays eben nicht.

[13:00] Ja, das waren so ein paar Fragen zur Backgroundierung,

[13:02] die mir nochmal so eingefallen sind,

[13:03] die ich nochmal klären wollte.

[13:04] Dann kommen wir nun zum nächsten großen Punkt,

[13:06] nämlich der Fehlerbehandlung.

[13:08] Und da steigen wir direkt ein mit dem allseits beliebten Thema,

[13:11] was sind Exceptions?

[13:13] Exceptions sind in vielen Promiersprachen heute Standard

[13:16] für die Fehlerbehandlung.

[13:17] Deswegen sollte man das durchaus erklären können,

[13:19] was dahinter steckt.

[13:20] Eine Exception beschreibt im Prinzip

[13:22] eine Fehlersituation in einem Programm.

[13:24] Und diese Fehlersituation, die kann herumgereicht werden.

[13:28] Das heißt, ich muss diese Fehlersituation nicht dort behandeln,

[13:31] wo sie auftritt,

[13:32] sondern sie wird einfach immer weitergereicht

[13:34] durch alle Aufrufer zurück,

[13:35] bis sie irgendwo dann mal behandelt wird.

[13:38] Und in dieser Fehlersituation stehen dann Informationen drin,

[13:41] wie in welcher Zeile, in welcher Klasse

[13:44] und wo auch immer dieser Fehler aufgetreten ist.

[13:46] Das heißt, der gesamte Stack Trace steht da drin,

[13:48] aber auch welcher Fehler genau es ist.

[13:50] Und auch die Schwere teilweise lässt sich aus der Exception ablesen.

[13:54] Also ob es ein, wie soll man sagen,

[13:56] ein ganz schlimmer Fehler ist oder nicht ganz so schlimm.

[13:59] Wichtig ist auf jeden Fall, dass sich diese Exception im Prinzip…

[14:02] Also eine Exception ist einfach ein Objekt einer bestimmten Klasse

[14:05] oder einer Klassenhierarchie.

[14:07] In Java haben wir zum Beispiel wirklich die Klasse Exception,

[14:10] von der ich erben kann.

[14:11] Es gibt aber auch noch eine andere Klasse, Error zum Beispiel.

[14:15] Und es gibt auch noch so ein Ding dazwischen,

[14:17] das ist das Throwable und beide erben davon, von Throwable.

[14:21] Also die Error-Klasse und die Exception-Klasse.

[14:25] Ich weiß jetzt ehrlich gesagt nicht, ob Throwable ein Interface ist oder eine Klasse.

[14:28] Auf jeden Fall hängen die in einer Hierarchie zusammen.

[14:32] Und diese Exceptions, die kann ich jetzt mit einigen Schlüsselwörtern in der Promiesprache…

[14:36] Ja, man hat dann so ein bisschen die Analogie wie so einen Ball,

[14:39] den ich werfe und auffangen kann.

[14:41] Und rund um diese Analogie drehen sich auch die ganzen Schlüsselwörter.

[14:45] Und zwar gibt es dort die bekannten Schlüsselwörter try, catch, throw

[14:48] und in Java noch die Besonderheit throws.

[14:50] Und die gucken wir uns jetzt mal an.

[14:52] Das try, catch, das umschließt einen potenziell fehlerhaften Code in meiner Promiesprache.

[14:58] Ich könnte also sagen try und dann mache ich was, was eventuell fehlerhaft sein könnte,

[15:02] wie z.B. connect-to-database.

[15:04] Und bei diesem connect-to-database kann einiges schief gehen,

[15:07] wie z.B. benutze mein Passwort falsch oder die Datenbank ist nicht erreichbar.

[15:11] Und wenn das auftritt, dann wirft dieser Code, der diesen Fehler produziert, eben eine Exception.

[15:17] Die wird dort geworfen und die kann ich dann in meinem catch-Block entsprechend auffangen.

[15:22] Ich sage dann also, catch mal die, was auch immer, database-not-found-Exception

[15:27] und dann kann ich darauf reagieren und diesen Fehler eben behandeln.

[15:32] Wenn ich dann in dem aufgerufenen Code, der den Fehler produziert,

[15:35] tatsächlich manuell eine Exception werfen möchte, dann ist das Schlüsselwort dafür throw.

[15:40] Also wir reden hier die ganze Zeit von Java, aber in anderen Promiesprachen ist das sehr ähnlich,

[15:43] in C Sharp z.B.

[15:45] In Ruby heißen die anders, da heißen die z.B. race, um eine Exception zu werfen,

[15:50] aber in den meisten gängigen Promiesprachen heißt es throw.

[15:53] Und in Java kommt noch eine Besonderheit dazu, da gibt es nämlich die sogenannten checked Exceptions.

[15:58] Dort kann ich Methoden kennzeichnen, als potenziell fehleranfällig

[16:02] und das bedeutet, ich muss die Fehlerbehandlung beim Aufruf einbauen.

[16:06] Ich kann diese Methode nicht einfach aufrufen, ohne ein try-catch drumherum

[16:11] oder selber die Exception weiter zu werfen,

[16:14] indem ich an meine eigene Methode nochmal wieder das throw dran schreibe.

[16:17] Dieses Konzept der checked Exceptions, das ist Grundlage für viele tiefe Diskussionen,

[16:24] ob das gut ist oder schlecht.

[16:25] Man müsste wissen, dass es in Java eben so ist.

[16:27] Ich kenne keine andere Promiesprache, wo es so umgesetzt ist,

[16:29] aber Java hat das nun mal durchgezogen.

[16:31] Das bedeutet, diese checked Exception ist etwas, was ich auffangen muss,

[16:37] während die unchecked Exceptions eben solche sind, die auftreten können,

[16:40] die ich aber nicht unbedingt auffangen muss.

[16:42] Also zum Beispiel Laufzeitfehler, die ich auch gar nicht erwarten kann,

[16:45] wie zum Beispiel die Festplatte ist voll oder der Speicher ist voll.

[16:48] Das sind Dinge, die kommen so unregelmäßig vor,

[16:51] auf die kann ich jetzt nicht bei jedem Fitzel-Methodenaufruf reagieren.

[16:54] Wenn das auftritt, dann habe ich Pech gehabt,

[16:56] dann kann ich vielleicht in irgendeinem globalen try-catch solche Sachen behandeln,

[17:00] aber ich kann auch eigentlich nichts machen, wenn das auftritt.

[17:02] Wenn die Festplatte voll ist, ja, was kann ich dann tun?

[17:04] Weiß ich nicht.

[17:05] Deswegen gibt es diese Unterscheidung in Java, einmal checked und unchecked.

[17:09] Das wäre dann auch gleich die nächste Frage, die man da stellen könnte.

[17:13] Also, was gibt es für Exceptions in Java?

[17:15] Ich habe es gerade gesagt, checked und unchecked.

[17:17] Und der Unterschied ist, dass die checked Exceptions gefangen werden müssen

[17:20] und die unchecked Exceptions nicht.

[17:24] Das wäre es dann auch schon zum Bereich Fehlerbehandlung.

[17:27] Dann kommen wir jetzt zum letzten Punkt, nämlich zu den tiefergehenden Fragen.

[17:32] Da habe ich auch noch mal einige Sachen zusammengestellt,

[17:34] die ich nirgendswo anders unterbringen konnte, sage ich mal,

[17:37] und die ich auch nicht um jeden Prüfling stellen würde.

[17:40] Oder anders gesagt, wovon ich nicht ausgehen würde, dass jeder Prüfling sie beantworten könnte.

[17:45] Das sind eher Fragen, die ich so einem Einser-Kandidat vielleicht stellen würde.

[17:49] Und das geht dann los mit einer meiner Meinung nach noch ziemlich einfachen Frage,

[17:54] aber trotzdem kann man das nicht voraussetzen, dass ihr das kennt.

[17:57] Was ist Refactoring?

[17:59] Refactoring, dafür habe ich mal eine ganz tolle Definition irgendwo gelesen.

[18:02] Ich weiß leider nicht mehr wo.

[18:04] Auf Deutsch die semantikinvariante Modifikation von Quelltext.

[18:09] Das ist Refactoring.

[18:11] Wenn man sich das mal auf der Zunge zergehen lässt.

[18:13] Ja, semantikinvariant.

[18:15] Semantik und Syntax hatten wir schon mal in einer früheren Podcast-Episode auseinandergenommen.

[18:20] Semantik ist ja die Bedeutung meines Codes.

[18:23] Und wenn etwas invariant ist, dann bedeutet das, dass sich das nicht ändert.

[18:27] Das heißt, die Bedeutung ändert sich nicht.

[18:29] Modifikation heißt ja bearbeiten.

[18:32] Und Quelltext ist klar.

[18:34] Das heißt, ich verändere den Quelltext, ohne die Bedeutung zu verändern.

[18:38] Das ist Refactoring.

[18:40] Und das ist auch eine schöne Definition, wenn man das mal ein bisschen anders formuliert.

[18:43] Ich verändere den Quelltext, ohne das nach außen sichtbare Verhalten zu ändern.

[18:48] Was bedeutet das?

[18:49] Ich mache den Code schöner, aber ich ändere eben nicht, was er macht.

[18:53] Zum Beispiel habe ich einen ganz tollen Algorithmus programmiert, der aber leider total langsam ist.

[18:57] Und es ist meinetwegen ein Suchalgorithmus.

[19:00] Dann, wenn ich den jetzt refaktorisiere oder refaktore, oder wie auch immer ich das nennen will,

[19:05] dann verändere ich eben die interne Struktur dieses Codes.

[19:08] Ich benenne vielleicht Variablen um.

[19:10] Oder ich nutze einen anderen Algorithmus.

[19:12] Oder weiß der Geier, ich extrahiere Methoden, um den Code lesbarer zu machen.

[19:16] Solche Dinge.

[19:17] Aber das führt nicht dazu, dass die Methode sich nachher unterschiedlich verhält,

[19:22] nachdem ich dieses Refactoring gemacht habe.

[19:24] Das heißt, genau wie vorher, wenn es ein Suchalgorithmus war,

[19:27] wird es das Element in einem Array meinetwegen finden.

[19:30] Genau wie vorher.

[19:31] Egal, ob ich ein Refactoring mache oder nicht.

[19:33] Das Verhalten ist unverändert.

[19:34] Nur der Code selber, die interne Struktur wird verändert.

[19:38] Meistens mit dem Ziel, um den Code besser lesbar zu machen für den Menschen.

[19:42] Denn im Computer ist es eigentlich völlig wurscht, wie die Variablen heißen.

[19:45] Aber der Programmierer, der den Code liest, der sollte ihn auch gut verstehen können.

[19:48] Und dafür sind viele der Refactoring-Maßnahmen, die es so gibt,

[19:52] ein paar hatte ich schon erwähnt, wie zum Beispiel Variablen,

[19:54] unbenennen, Methoden extrahieren,

[19:55] die sind eigentlich dazu da, um dem Programmierer, dem Leser des Codes,

[19:58] das Leben einfacher zu machen.

[20:01] Wichtig ist beim Refactoring, dass ich das nicht einfach so machen kann, sondern dass

[20:05] ich normalerweise dafür Tests brauche. Automatische Tests, Unit Tests, um meinen

[20:10] Code abzusichern. Ich will ja sicherstellen, dass die

[20:13] Bedeutung sich nicht verändert. Das heißt, das nach außen sichtbare Verhalten

[20:15] muss vorher und nachher gleich sein. Aber wie kann ich das sicherstellen? Nur durch

[20:19] Tests. Nur indem ich ausprobiere, ob sich was verändert hat. Und dafür brauche ich

[20:23] Unit Tests. Das heißt, Nummer eins, die Voraussetzung, um ein Refactoring

[20:28] durchführen zu können, ist, ich muss automatische Tests haben. Denn wenn ich

[20:32] die Struktur meines Codes verändere und mach dabei aus Versehen was kaputt,

[20:36] das wäre schlecht. Das darf ja auf keinen Fall passieren. Und das kann ich nur

[20:39] quasi beweisen, indem ich Tests habe, die ich vorher und nachher laufen lasse und die

[20:44] sicherstellen, dass sich wirklich nichts verändert hat. Dann kommen wir zu einem

[20:49] weiteren Stichwort, was man meiner Meinung nach heute durchaus erläutern

[20:53] können müsste. Aber nicht jede Sprache kann das, deswegen würde ich es nicht

[20:56] allgemein voraussetzen. Aber wenn ich zum Beispiel mit C-Sharp arbeite, dann ist

[21:01] das Schlüsselwort Typ-Inferenz für mich schon eigentlich Voraussetzung, dass man

[21:06] das erkennen, aber auch erklären können muss. Also was ist Typ-Inferenz?

[21:11] Typ-Inferenz bedeutet, dass der Compiler den Datentyp einer Variable

[21:16] automatisch ableiten kann, ohne dass ich ihn explizit angeben muss. Aber der

[21:22] Datentyp ist nachher dann auch wirklich fix. Das hat also nichts mit dynamischer

[21:26] Typisierung zu tun, sondern ich lasse den Datentyp einfach weg, aber meine

[21:30] statisch typisierte Poemiersprache erkennt von alleine, welchen Datentyp es

[21:35] denn dort eigentlich geben müsste. Und ab diesem Zeitpunkt ist das dann auch

[21:40] der Datentyp. Als Beispiel. In C-Sharp haben wir das Schlüsselwort

[21:44] War. Damit kann ich eben Variablen definieren, ohne den Typ anzugeben. Ich

[21:48] kann also sowas machen wie War Test gleich in Anführungszeichen Hallo Welt.

[21:53] Damit habe ich eine Variable Test definiert. Die Frage ist, welchen

[21:57] Datentyp hat denn jetzt diese Variable? Der Compiler schaut jetzt einfach auf die

[22:00] rechte Seite der Zuweisung und sieht, ah, Hallo Welt, ein String. Das heißt, diese

[22:04] Variable muss wohl den Datentyp String haben und das erkennt der Compiler jetzt,

[22:11] das inferiert er, das leitet er ab aus dem Wert, den ich da reinschiebe. Und ab

[22:15] diesem Zeitpunkt hat die Variable jetzt auch wirklich den Datentyp String. Da kann

[22:20] ich jetzt also nicht in der nächsten Zeile dann machen, ach, Test gleich 1. Das geht

[22:23] nicht, denn Int und String passen nicht zusammen. Also ganz, ganz wichtig. Bedeutet

[22:28] nicht, dass die Sprache dynamisch ist. Im Gegenteil, die ist immer noch sehr, sehr

[22:32] statisch typisiert. Es macht mir bloß das Leben einfacher, weil ich eben nicht

[22:36] diese Klassik habe wie in Java, wo ich immer links und rechts meine Variablen,

[22:41] Entschuldigung, meine Datentypen anführen muss. Wie in der letzten Episode schon. Auto, BMW

[22:46] gleich New Auto. Warum muss ich das Auto zweimal schreiben? Das ist total

[22:50] überflüssig. Wenn ich sage, war BMW gleich New Auto, dann könnte der Compiler

[22:53] eigentlich auch selber so intelligent sein, um zu sehen, ah, New Auto, ja, dann wird der

[22:57] BMW wohl ein Auto sein und nicht auf einmal ein Baum oder sowas. Und das kann

[23:01] eben der Compiler in vernünftigen Sprachen inferieren und das spart mir als

[23:05] Entwickler einiges an Arbeit, denn ich muss eben meine ganzen Datentypen nicht

[23:09] 73 mal hinschreiben. Ja, dann noch eine weitere nette Frage, die ich durchaus

[23:14] vielen Leuten stelle, weil fast jeder die eigentlich in seinem Code benutzt,

[23:18] nämlich generische Klassen. Was sind das eigentlich? Und das Schöne ist, das können

[23:22] die wenigsten erklären, obwohl man es tagtäglich benutzt. Dabei ist es eigentlich

[23:26] recht einfach. Generische Klassen oder auch Generics, werden sie in Java genannt,

[23:30] die stellen allgemeingültige Algorithmen zur Verfügung und zwar für

[23:34] unterschiedliche Datentypen. Was bedeutet das jetzt? Klassisches Beispiel ist die

[23:39] Liste, List of T in Java oder auch in C-Sharp. Das ist eine Klasse, die eine

[23:44] ganz allgemeine Funktionalität bereitsteht, nämlich Listenverwaltung.

[23:47] Also Elemente der Liste hinzufügen, löschen, sortieren, was auch immer die so

[23:51] kann. Aber das Problem mit diesen Sprachen ist ja, dass sie statisch

[23:55] typisiert sind. Das heißt, wenn ich jetzt eine Liste von

[23:58] Strings haben will oder eine Liste von Integern oder eine Liste von Double, dann

[24:02] muss ich die Klasse dreimal programmieren. Die eine arbeitet mit Int, die eine mit

[24:05] Double, die eine mit String. Und das ist natürlich super aufwendig, obwohl die

[24:09] Implementierung für alle diese Datentypen eigentlich identisch ist.

[24:12] Der Liste ist dann völlig egal, ob ich eine Zahl speichere oder ein String. Solange

[24:17] ich die zum Beispiel miteinander vergleichen kann, kann ich die Liste

[24:19] sortieren. Und genau das ist der Sinn dieser generischen Liste. Ich stelle

[24:23] diese Implementierung einmal bereit, völlig unabhängig vom konkreten

[24:27] Datentyp, der in dieser Liste gespeichert wird. Aber ich muss eben in meinen

[24:32] statischen Programmier-Sprachen dafür sorgen, dass die Liste typsicher ist, dass sie

[24:36] statisch typisiert ist. Das heißt, ich muss jetzt sagen, wenn ich eine Liste erzeuge,

[24:40] das ist eine List of String, damit ich eben nicht irgendwas anderes in die

[24:44] Liste reinschieben kann als ein String. Das geht zwar, ich kann die Liste auch

[24:48] einfach als List definieren und dann kann ich alles Mögliche da reinschieben, aber

[24:51] in den meisten Fällen ist das nicht das, was ich will.

[24:53] Denn dann muss ich ja beim Rausholen aus der Liste immer wieder ein Cast machen.

[24:57] Und das wollen wir eigentlich nicht. Wir wollen eigentlich die Typsicherheit

[25:00] haben, dafür nutzen wir diese Programmier-Sprachen. Und deswegen würde ich sowas

[25:04] definieren wie List of String und weiß dann, da sind immer Strings drin. Und wenn

[25:08] ich dann Int reinschiebe, dann gibt der Compiler mir den Fehler und sagt,

[25:11] Moment mal, das geht nicht. Und damit habe ich eine bestimmte Art von Fehlern

[25:15] ausgeschlossen, die ich sonst eventuell machen würde.

[25:19] Also, wir stellen allgemeingültige Algorithmen dar und ich brauche diese

[25:24] Generics aber nur in statisch typisierten Sprachen. Denn nur da kommt es auf diese

[25:28] Typisierung an. Wenn ich in Ruby eine Liste programmiere, dann muss ich gar

[25:32] nicht angeben, was für ein Datentyp da drin ist. Das kann die einfach selber die

[25:36] Sprache, weil sie halt dynamisch ist. Wenn ich also mit diesen Elementen in der Liste

[25:39] irgendwas machen will, dann wird halt zur Laufzeit geprüft, ob die alle Methoden

[25:42] bereitstellen, die benötigt werden, um irgendwas damit zu tun. Und wenn es halt

[25:45] nicht ist, dann gibt es einen Fehler. Aber es gibt eben nicht den Compiler, der

[25:48] zur Compile-Zeit schon prüft, ob das der Fall ist.

[25:51] Das heißt, generische Klassen, wichtiger Bestandteil statisch typisierter

[25:56] Programmiersprachen, die stellen allgemeingültige Algorithmen bereit, und

[25:59] zwar für unterschiedliche Datentypen. Das ist der zentrale Ansatz dabei.

[26:04] Und in diesem Zusammenhang, gerade mit den Listen, kann man noch ein weiteres

[26:09] schönes Thema ansprechen, nämlich die Co- und Contra-Varianz. Ich fange vielleicht

[26:14] mit dem Beispiel an. In Java haben wir eine List of String und eine List of

[26:18] Object. Jetzt denken sehr, sehr viele Entwickler, und ich gebe zu, ich gehörte

[26:23] auch lange Zeit dazu, dass die List of String ja wohl von List of Object erben

[26:29] wird. Denn String erbt ja auch von Object. Also warum sollte List of String nicht

[26:33] von List of Object erben? Es ist ja eigentlich sinnvoll, dass das so ist.

[26:36] Aber das ist nicht der Fall. List of String und List of Object stehen in

[26:41] keiner Beziehung zueinander, insbesondere nicht in einer

[26:43] Vererbungsbeziehung. Das ist nicht so, sondern es sind gleichrangige Klassen,

[26:47] die sich nicht substituieren lassen. Das heißt, ich kann nicht einfach sagen, eine

[26:51] List of Object gleich List of String. Das funktioniert nicht. Und das bedeutet,

[26:56] dass diese beiden Listen nicht Co-Variant sind. Das ist jetzt genau die Frage, die

[27:01] als letztes kommt, nämlich was ist Co- und Contra-Varianz? Und das ist etwas

[27:08] tiefergehendes, das würde ich wirklich nicht unbedingt jeden Azubi fragen. Und

[27:12] wer das beantworten kann, der hat ja quasi schon seine Eins sicher, so in der Art

[27:17] und Weise. Aber wenn ich mir mal anschaue, List of String und List of Object, die

[27:21] sind eben nicht Co-Variant. Das bedeutet, List of String erbt nicht von List of

[27:26] Object. Und diese Co- und Contra-Varianz kann man erklären anhand von zwei

[27:30] Beispielen. Das erste ist jetzt eben diese parametrische Polymorphie, das

[27:35] heißt meine Generics, wo eben der Parameter-Datentyp, String oder Object,

[27:41] in einer Vererbungsbeziehung steht, aber der Container drumherum, die Liste, eben

[27:46] nicht in einer Vererbungsbeziehung steht. Wäre das der Fall, würde List of String

[27:51] von List of Object erben, dann wären sie Co-Variant, weil die Vererbungsbeziehung

[27:57] String Object die gleiche wäre wie List String List Object. Es geht also in die

[28:03] gleiche Richtung. Wenn ich den umgekehrten Weg hätte, angenommen, List of

[28:08] String und List of Object hätte ich, aber List of Object könnte ich für List of

[28:13] String benutzen. Object und String stehen in einer Vererbungsbeziehung, aber die

[28:19] Vererbungsbeziehung der beiden Listen stünde in genau der umgekehrten

[28:22] Richtung. Also so nach dem Motto List of Object erbt von List of String, obwohl

[28:28] String von Object erbt, also genau umgekehrt wie beim Typ, dann hätten wir

[28:32] eine Contra-Varianz. Aber auch das ist nicht gegeben bei den Listen. Und

[28:37] vielleicht an einem noch etwas einfacheren Beispiel, wie man das

[28:40] erklären kann, das geht auch bei Methoden. Wenn ich eine Vererbungsbeziehung

[28:43] habe und eine Methode in einer Subklasse überschreibe und diese Subklasse hat

[28:48] oder diese Methode hat einen Parameter und dieser Parameter wird in der

[28:53] Subklasse auf einen Datentyp verändert, der von dem Datentyp in der

[28:59] Basisklasse erbt. Also als Beispiel, ich habe in meiner Basisklasse eine Methode

[29:04] Fahre und die bekommt ein Auto und ich habe in meiner Subklasse eine Methode

[29:09] Fahre, die bekommt kein Auto, sondern ein BMW und dieser BMW, der erbt von Auto. Wenn

[29:16] das so wäre, dann habe ich eine Ko-Varianz. Wenn es umgekehrt wäre, in

[29:20] meiner Basisklasse definiere ich eine Methode Fahre, die bekommt ein BMW und in

[29:24] meiner abgeleiteten Klasse habe ich eine Methode Fahre, die bekommt ein Auto, dann

[29:27] wäre ja die Vererbungsbeziehung genau umgekehrt, dann würde ich wieder von

[29:31] Contra-Varianz sprechen. Es gibt auch noch das Dritte, nämlich die In-Varianz. Das

[29:37] bedeutet, ich kann das gar nicht verändern. Das heißt, wenn ich oben Fahre-Auto

[29:40] habe, dann habe ich meiner Subklasse auch Fahre-Auto und ich kann diesen

[29:44] Parameter gar nicht verändern. Dann würde ich von In-Varianz sprechen.

[29:49] Ja, das war noch mal das Highlight zum Schluss. Also ich erwarte nicht, dass

[29:53] jeder das so im Detail erklären kann. Es ist schon ein sehr tiefer gehendes Thema,

[29:57] aber wenn man sich so von anderen abgrenzen will und eine sehr gute Note

[30:00] erreichen will, spricht nichts dagegen, wenn man das auch mal erklären kann, die

[30:03] Ko- und Contra-Varianz. Okay, damit schließe ich jetzt aber nun meine Liste der

[30:08] häufigen Fragen rund um die Programmierung in diesem Fall ab und

[30:14] weise wie gewohnt zum Ende der Episode auf die Shownotes hin, die ihr wie immer

[30:18] findet unter www.anwöchns-entwickler-podcast.de

[30:22] für die 13. Episode. Ich würde mich wie immer über euer Feedback freuen, egal ob

[30:29] positiv oder negativ. Schreibt mir einfach alles, was ihr mir zu sagen habt.

[30:34] Gerne per Mail an mail.anwöchns-entwickler-podcast.de oder über das Kontaktformular auf der

[30:40] Website. Ich würde mich auch sehr freuen, wenn ihr mich weiter empfehlt und ganz

[30:44] besonders würde ich mich freuen über ein iTunes-Review. Könnt ihr einfach unter

[30:48] www.anwöchns-entwickler-podcast.de erreichen die Seite und wenn ihr mir dort

[30:53] ein ehrliches Feedback gebt, das würde mich sehr freuen, würde dazu beitragen,

[30:57] dass dieser Podcast noch ein bisschen bekannter wird und ich noch mehr Azubis

[31:01] bei ihrem Weg zum Fachinformatiker helfen kann. Wenn ihr wissen wollt, was bei

[31:08] mir so passiert im Blog und auch im Podcast, könnt ihr euch gerne auch für

[31:12] den Newsletter anmelden unter www.anwöchns-entwickler-podcast.de

[31:15] slash Newsletter. Da bekommt ihr als kleines Dankeschön auch direkt eine

[31:20] Liste für die häufigen Probleme, die es in der Projektdokumentation gibt mit

[31:26] über 100 Punkten, die ihr mal durchgehen könnt, bevor ihr eure Projektdokumentation

[31:29] abgibt und wird in Zukunft auch noch eine weitere Liste hinzukommen für den

[31:33] Projektantrag und auch für die Projektpräsentation. Die bekommt ihr

[31:36] sofort zugesendet, wenn ihr euch angemeldet habt und außerdem bekommt

[31:41] ihr dann jede Woche von mir die neuen Infos, was auf der Website so passiert.

[31:44] Auch den Link der Woche, den ich immer freitags veröffentliche, den bekommt ihr

[31:48] dann schon vorab am Montag. So bleibt ihr einfach auf dem Laufenden, was

[31:52] ich so veröffentliche und hoffe, dass es euch dann so ein bisschen auch hilft bei

[31:57] eurer Prüfungsvorbereitung. Damit sage ich jetzt auch wirklich vielen, vielen

[32:02] Dank fürs Zuhören und bis zum nächsten Mal!