[0:01] Herzlich Willkommen zum Anwendungsentwickler-Podcast, dem Podcast rund um die Ausbildung zum Fachinformatiker für Anwendungsentwicklung.

[0:09] In dieser Episode gibt es eine Lernzielkontrolle rund um Algorithmen und Methoden. Viel Spaß dabei!

[0:20] Hallo und herzlich Willkommen zur 42. Episode des Anwendungsentwickler-Podcasts.

[0:26] Mein Name ist Stefan Macke und heute setze ich meine Reihe der Lernzielkontrollen fort, auf zahlreichen Wunsch.

[0:32] Ich wollte ja erst noch ein paar andere Themen einschieben, aber die Nachfrage nach den Lernzielkontrollen war dann doch so groß, dass ich gesagt habe,

[0:38] okay, ich mache nochmal zwei Episoden, so passend zu Weihnachten als kleines Vorabgeschenk, mache ich nochmal zwei Lernzielkontrollen rund um Java und Programmierung

[0:46] und danach gucken wir dann mal, wie es weitergeht.

[0:48] Es gibt wohl einige Azubis da draußen, die diesen Podcast hier nutzen, um ihren eigenen Lernerfolg so ein bisschen zu kontrollieren und zu gucken,

[0:54] was andere denn so lernen in der Zeit, in der sie sich auch in die Programmierung einarbeiten.

[0:57] Und von daher möchte ich euch gerne dabei unterstützen, keine Frage.

[1:00] Deswegen machen wir jetzt nochmal die nächsten Lernzielkontrollen, die nach denen auch wirklich anstehen würden, die ich beim letzten Mal aufgenommen habe.

[1:07] Und heute wären wir dann halt angekommen bei den Algorithmen und Methoden.

[1:11] Das passt, glaube ich, auch ganz gut zusammen, wie ich finde, denn Methoden sind ja letztlich nichts anderes als wiederverwendbare Algorithmen.

[1:17] Von daher fangen wir einfach mal mit dem Part über Algorithmen an und wechseln dann rüber zu den Methoden.

[1:22] Und dabei frage ich mal so ein paar Sachen ab, die man da vielleicht wissen sollte oder auch beschreiben können sollte.

[1:28] Gut, dann fangen wir gleich vorne an mit dem Algorithmus.

[1:31] Was ist denn überhaupt ein Algorithmus?

[1:33] Ich fange jetzt also nicht ganz vorne an, wie der Name zustande kam.

[1:36] Und da gab es ja diesen berühmten arabischen Forscher oder Mathematiker, der dem Algorithmus seinen Namen gab.

[1:42] Ich kann ihn selber nicht aussprechen, das ist ein ellenlanger Name.

[1:45] Das ist für mich jetzt auch ein bisschen irrelevant, sage ich mal.

[1:48] Wichtig ist, dass man beschreiben kann, was überhaupt ein Algorithmus ist und was das für uns als Programmierer bedeutet.

[1:53] Ein Algorithmus, den würde ich erklären als eine wiederholbare Beschreibung zur Lösung eines Problems.

[1:58] Und da ist auch noch nicht ein einziger IT-Begriff drin in dieser Definition, denn ein Algorithmus ist etwas, wofür man nicht unbedingt einen Computer braucht.

[2:05] Es ist einfach nur eine Lösungsbeschreibung, um irgendein Problem eben zu lösen.

[2:09] Und das kann auch etwas sein, was man auf dem Blatt Papier ausrechnet oder irgendwie in der realen Welt einfach umsetzt.

[2:14] Und genau so fange ich mit meinen Azubis eigentlich auch immer an, wenn sie Programmieren lernen.

[2:17] Die sollen mir die Sachen, die sie da programmieren sollen, erst mal so erklären, als wenn sie die selber lösen müssten.

[2:22] Zum Beispiel eben mit Zettel und Papier.

[2:24] Zettel und Papier ist doppelt, aber mit einem Stift.

[2:26] Und das dann wirklich auf Papier lösen.

[2:28] Also zum Beispiel, wie berechne ich denn die Wurzel einer Zahl?

[2:31] Das kann man ja mathematisch lösen.

[2:33] Und da muss ich erst mal beschreiben können, wie ich das grundsätzlich mache, bevor ich das einem Computer dann beibringen kann.

[2:38] Der Computer macht auch nichts anderes als das, was ich ihm sage.

[2:41] Und wenn ich selber gar nicht formulieren kann, wie ein Problem zu lösen ist, dann kann ich es auch nicht programmieren.

[2:46] Und ich finde, das ist auch immer ein ganz guter Trick.

[2:48] Wenn man mal etwas programmieren muss und man kommt einfach nicht weiter, man kommt nicht auf die Lösung,

[2:56] dann macht einfach mal den Bildschirm aus oder schiebt die Tastatur weg und versucht mal, das Ding auf dem Papier zu lösen.

[3:01] Mal dir mal ein bisschen was auf.

[3:03] Zeichne dir mal das Array auf, mit dem du gerade einen Sortieralgorithmus implementieren willst.

[3:08] Und versuch das mal auf dem Blatt Papier hin und her zu schieben.

[3:10] Das mache ich mit meinen Studenten in der FH auch immer so.

[3:13] Da wird das Ding dann mal an der Tafel gelöst.

[3:15] Wie soll man denn auch etwas einem Computer beibringen, was man selber nicht verstanden hat?

[3:18] Das geht nicht.

[3:19] Von daher muss man erst mal offline versuchen, diese Aufgabe zu lösen.

[3:23] Und das kann man wunderbar machen, indem man sich einfach mal ein Blatt Papier nimmt

[3:27] oder einfach irgendwas zu schreiben nimmt und das dann versucht zu lösen.

[3:30] Also Algorithmus, wiederholbare Beschreibungslösung eines Problems.

[3:33] Und jetzt ist die Frage, was sind denn die Bestandteile eines Algorithmus?

[3:37] Woraus besteht er denn jetzt?

[3:38] Und da gibt es eigentlich drei grundlegende Bestandteile.

[3:40] Das sind so ein bisschen die Bausteine von Algorithmen.

[3:43] Daraus kann ich mir meine Algorithmen zusammenbauen.

[3:45] Und wenn ich diese drei Bausteine habe, dann kann ich tatsächlich auch jedes lösbare Problem,

[3:50] sofern es denn wirklich lösbar ist, es gibt ja auch nicht lösbare Probleme,

[3:52] aber dann kann ich jedes lösbare Problem tatsächlich auch abbilden.

[3:55] Mehr brauche ich dafür nicht.

[3:56] Das meinen dann immer viele Prüflinge, dass man sagt,

[3:59] ich brauche unbedingt Objektorientierung und Funktionale und Vererbung und weißt gar nicht was.

[4:04] Brauchen wir im Prinzip eigentlich nicht.

[4:05] Es reichen drei grundsätzliche Bestandteile, um jegliches Problem lösen zu können.

[4:09] Und das sind die Sequenz, die Verzweigung und die Wiederholung.

[4:12] Oder auf Englisch Sequence, Branching und Repetition oder Loop oder wie auch immer.

[4:17] Und diese drei Teile gucken wir uns jetzt mal einmal im Detail an.

[4:20] Eine Sequenz ist eigentlich das einfachste von allen.

[4:22] Das bedeutet nämlich einfach nur eine Abfolge von Befehlen, die nacheinander ausgeführt werden.

[4:26] Also wenn ich sowas sage wie a gleich 1, b gleich 3, c gleich a plus b, meinetwegen,

[4:32] dann wären das drei Befehle hintereinander.

[4:34] Und das ergibt halt eben eine Sequenz.

[4:36] Dafür muss der Computer sorgen, dass die Teile, die ich da von oben nach unten eintippe,

[4:40] auch von oben nach unten ausgeführt werden.

[4:42] Dann habe ich eine Sequenz.

[4:43] Jetzt kommt das nächst komplexere.

[4:45] Das wäre dann die Verzweigung.

[4:46] Die Verzweigung ist nicht einfach nur ein Ablauf von oben nach unten,

[4:49] sondern hier geht es noch im Prinzip um eine Unterscheidung.

[4:51] Soll ich links oder rechts lang?

[4:52] Wenn ich mal so eine Straße langfahre zum Beispiel.

[4:54] Sequenz bedeutet, ich fahre einfach immer geradeaus.

[4:56] Und bei einer Verzweigung, da kann ich mich jetzt entscheiden, wo ich langfahre.

[4:59] Links oder rechts.

[5:00] Oder vielleicht gibt es sogar eine Kreuzung und ich habe drei Wege, die ich wählen kann.

[5:03] Und diese Verzweigung ist klassischerweise umgesetzt im Poemiersprachen mit dem beliebten If-Statement.

[5:08] Das ist dann auch gleich die Anschlussfrage, wie so ein If-Statement aussieht.

[5:12] Aber das vertiefen wir jetzt erstmal noch nicht.

[5:14] Und es gibt auch noch ein zweites, was es in vielen Poemiersprachen gibt.

[5:17] Das ist nämlich das Switchcase.

[5:18] Davon würde ich dann abraten, weil der Code dann teilweise sehr schwierig zu verstehen ist,

[5:23] wenn ich mehrere verschiedene Verzweigungen habe.

[5:25] Ifs und geschachtelte Ifs reichen meist schon aus, um den Code komplex genug zu machen.

[5:29] Von daher würde ich persönlich auf ein Switchstatement verzichten.

[5:32] Ich habe das in meinem JavaScript-Tutorial noch nicht mal eingebaut,

[5:34] weil ich das so unsinnig oder unpraktikabel finde, weil der Code nachher einfach schwer zu verstehen ist.

[5:40] Und man muss ihn sehr oft anpassen, denn was hat man in so einem Switchcase häufig?

[5:43] Irgendeine Fallunterscheidung.

[5:44] Und wenn dann ein weiterer Fall hinzukommt, darf ich alle die Stellen im Code anpassen,

[5:48] wo eben diese Fallunterscheidung auftaucht.

[5:50] Und wenn ich damit einmal anfange, dann ist es ganz häufig so, dass sich das wild durch den Code verteilt.

[5:54] Und da muss ich an mehreren Stellen rumhantieren oder rumändern, nur weil ein neuer Fall hinzukommt.

[5:59] Das würde ich in einer objektorientierten Programmiersprache heutzutage Polymorph lösen.

[6:04] Polymorphie, da kommen wir doch in einer der nächsten DLC-Kontrollen dann drauf.

[6:07] Also das Switchcase-Statement wäre für mich ein Statement, das ich gar nicht benutzen würde.

[6:12] Da gibt es bessere Möglichkeiten, sowas zu lösen.

[6:14] Und der letzte Teil der Algorithmen-Bausteine, das wäre dann die Wiederholung,

[6:18] also die allseits bekannten Schleifen, die dann in der Programmiersprache diese Wiederholung umsetzen.

[6:24] Und da gibt es verschiedene Schleifen, die gucken wir uns auch gleich nochmal im Detail an.

[6:27] Aber wir gehen mal der Reihe nach, denn wir hatten gerade gesagt, die Verzweigung,

[6:30] das ist ein ganz wichtiges Statement, nämlich das IF-Statement.

[6:33] Und das sollte man auch kurz beschreiben können, wie das aussieht.

[6:35] Ist im Prinzip recht einfach. Wer schon mal programmiert hat, hat das wahrscheinlich auch schon mal gesehen.

[6:39] Es ist einfach das Statement IF.

[6:41] Oder Statement, es kommt jetzt ganz darauf an, was für eine Programmiersprache ich habe.

[6:46] Es kann teilweise auch ein Ausdruck sein, der einen Wert zurückgibt.

[6:49] In vernünftigen Programmiersprachen ist das z.B. so.

[6:52] Aber in Java z.B. ist es tatsächlich ein Statement, d.h. es gibt keinen Wert zurück.

[6:56] Aber der Aufbau ist eigentlich immer gleich in allen Programmiersprachen.

[6:59] Und dann habe ich eine Prüfung.

[7:01] Und je nachdem, ob die Prüfung wahr oder falsch ist, wird der nach der Prüfung kommende Ast durchlaufen.

[7:07] Das ist dann, wenn die Prüfung wahr ist.

[7:10] Und wenn die Prüfung falsch ist, wird der zweite Ast durchlaufen.

[7:13] Wobei ich in den meisten Programmiersprachen für den zweiten Ast noch ein ELS davor brauche.

[7:17] D.h. der Aufbau wäre IF, Prüfung, dann Block quasi.

[7:22] ELS, sonst Block.

[7:24] So wäre der Aufbau in Java zumindest.

[7:26] Blöcke werden ja mit geschweiften Klammern umschlossen.

[7:29] Das kennen wir schon.

[7:30] Und die Prüfung bei dem IF wird in normale Klammern eingefasst.

[7:33] Das war es zum Thema IF.

[7:35] Ach ja, ganz wichtig. So wichtig ist es auch nicht.

[7:38] Aber der ELS-Block ist optional.

[7:40] D.h. ich kann auch einfach nur eine IF-Abfrage haben mit einer Prüfung.

[7:43] Und dann wird im Wahrheitsfall true etwas ausgeführt.

[7:46] Und ansonsten passiert halt einfach nichts. Das geht auch.

[7:48] Also ich brauche keinen ELS-Zweig.

[7:51] Dann kommen wir zum etwas interessanteren Thema, nämlich den Schleifen.

[7:54] Da gibt es nämlich einfach ein paar mehr von, die man auch auseinanderhalten sollte.

[7:57] Deswegen fangen wir doch mal ganz vorne an mit der WHILE-Schleife.

[8:01] Die WHILE-Schleife ist eine sogenannte kopfgesteuerte Schleife oder auch eine abweisende Schleife.

[8:07] Das bedeutet, wenn ich die WHILE-Schleife programmiere und ich gebe die Bedingung an,

[8:11] wie lange diese Schleife durchlaufen werden soll.

[8:13] Das sagt schon das Wort WHILE.

[8:15] Solange die Prüfung, die diese Schleife im Kopf macht, wahr ist, wird irgendwas getan.

[8:20] D.h. wenn ich jetzt mir vorstelle im Code, ich schreibe irgendwo eine WHILE-Schleife,

[8:24] die, wie gesagt, irgendwas prüft, z.B. x kleiner 18 meinetwegen,

[8:27] dann kann es ja sein, dass das x schon größer 18 ist, bevor die Schleife überhaupt aufgerufen wird.

[8:33] D.h. sie wird niemals durchlaufen.

[8:36] Deswegen nennt man diese Schleife auch abweisend, weil sie potenziell auch einfach gar nicht ausgeführt werden kann,

[8:42] weil die Bedingung eben nicht zutrifft.

[8:43] Demgegenüber steht die sogenannte fußgesteuerte oder akzeptierende Schleife,

[8:48] das wäre in Java und vielen anderen Promi-Sprachen auch, die sogenannte DO-WHILE-Schleife.

[8:53] Da ist die Syntax dann ein bisschen anders.

[8:54] Dann mache ich ein DO, dann kommt der Block, der ausgeführt wird,

[8:57] und WHILE, die Prüfung, die kommt erst ganz am Ende.

[9:00] D.h. diese Schleife wird immer mindestens einmal durchlaufen.

[9:03] Es gibt also keinen Fall, wo diese Schleife gar nicht durchlaufen wird.

[9:06] Deswegen heißt sie auch akzeptierende oder eben fußgesteuerte Schleife,

[9:10] weil die Prüfung erst am Ende erfolgt.

[9:12] Das ist im Prinzip der zentrale Unterschied zwischen diesen Schleifen,

[9:15] kopf- und fußgesteuert,

[9:16] und alle anderen Schleifen, die dann eventuell noch angeboten werden in einer Programmiersprache,

[9:20] lassen sich auf diese beiden Schleifentypen zurückführen,

[9:22] nämlich die allseits beliebte VOR-Schleife z.B.

[9:25] Das ist auch nichts weiter als eine kopfgesteuerte Schleife,

[9:28] die einfach nur ein bisschen nette Syntax hat,

[9:30] weil ich z.B. bei einer WHILE-Schleife ganz häufig einen Zähler habe,

[9:33] und dann wird am Ende des Schleifendurchlaufs irgendwas hochgezählt,

[9:36] dann wird die Bedingung geprüft,

[9:37] und vorher muss ich noch eine Variable initialisieren,

[9:39] kann ich das Ganze auch ein bisschen kompakter machen,

[9:41] wenn ich es mit einer VOR-Schleife mache.

[9:43] Eine VOR-Schleife, und dann mache ich einfach VOR, Klammer auf,

[9:46] und dann kommen da die drei Komponenten mit Semikolon getrennt,

[9:49] nämlich einmal das, was durchgeführt wird, bevor die Schleife überhaupt losläuft,

[9:52] da kann ich z.B. eine Deklaration machen, eine Initialisierung.

[9:55] Als zweites kommt dann nämlich eben genau meine Prüfung,

[9:58] solange diese Bedingung wahr ist, wird irgendwas gemacht,

[10:01] und als letztes kommt in diesem Drei-Gespann, sage ich mal,

[10:05] die Aktion, die am Ende eines Schleifendurchlaufs ausgeführt wird,

[10:08] meistens wird da z.B. ein Zähler hochgezählt.

[10:11] Das muss aber nicht so sein,

[10:12] die VOR-Schleife kann auch einfach aus leeren Komponenten bestehen,

[10:15] also kann ich machen VOR, Klammer auf, Semikolon, Semikolon, Klammer zu,

[10:19] da steht dann einfach nichts drin,

[10:20] da habe ich dann nichts weiter programmiert als eine Endlosschleife.

[10:23] Es gibt keine Prüfung, d.h. sie läuft einfach ewig weiter im Prinzip.

[10:26] Das muss ich überhaupt bei all diesen Schleifen berücksichtigen,

[10:29] dass ich immer eine Endlosschleife programmieren kann,

[10:31] d.h. eine Schleife, die nie beendet wird.

[10:33] Und das bedeutet natürlich, wenn ich das Programm starte und es hört nie wieder auf,

[10:36] ja, das wäre doof für den Benutzer, der möchte das ja vielleicht mal beenden.

[10:39] Von daher muss ich immer sehr besonders darauf achten,

[10:41] dass meine Abbruchbedingungen oder mein Abbruchkriterium auf jeden Fall auch zutreffen kann

[10:46] und ich nicht etwas programmiere, was in der Bedingung z.B. niemals den Wert Falls ergibt,

[10:51] denn das bedeutet, dass die Schleife eben unendlich weiterläuft.

[10:53] Das wäre halt eben nicht so schön.

[10:55] Aber letztlich ist die Vorschleife nur eine Abkürzung, sage ich mal, für eine While-Schleife.

[10:59] Ich kann jede Vorschleife in eine While-Schleife umwandeln und übrigens auch umgekehrt.

[11:04] Aber ich kann z.B. nie eine While-Schleife in eine Do-While-Schleife umwandeln,

[11:08] weil die halt eben zwei völlig unterschiedliche Konzepte haben,

[11:10] nämlich eben Kopf bzw. Fuß gesteuert.

[11:13] Und es gibt in Java und in vielen anderen Promiesprachen auch noch eine schöne weitere Schleife,

[11:17] nämlich die For-Each-Schleife.

[11:19] Die wird in Java netterweise genauso geschrieben wie die Vorschleife.

[11:23] Es gibt also kein extra Schlüsselwort, das For-Each heißt.

[11:25] In C-Sharp heißt es z.B. For-Each.

[11:28] In Ruby heißt es, na gut, da ist es keine Schleife, da ist es eine Methode,

[11:31] aber die heißt Each auch dann tatsächlich.

[11:33] Und dieses For-Each bedeutet immer, dass ich über irgendeine Collection drüber laufe

[11:37] und mit jedem Element irgendetwas tue.

[11:39] Z.B. jedes Element eines Arrays durchlaufen und damit irgendwas machen.

[11:43] Und das könnte ich potenziell mit einer While- oder auch mit einer Vorschleife einfach programmieren.

[11:47] Mit einer Vorschleife, ich fange mit einem i z.B. an, mit Index 0,

[11:51] zähle das dann hoch und mache dann mit dem Element in meinem Array irgendwas.

[11:54] Das würde wunderbar funktionieren.

[11:56] Aber das ist ziemlich fehleranfällig.

[11:58] Ich muss einen Zähler initialisieren, ich muss wissen, dass der bei 0 anfängt.

[12:01] In einer anderen Programmiersprache fängt der vielleicht bei 1 an.

[12:03] Da muss ich immer dran denken.

[12:04] Dann muss ich den Zähler auch hochzählen.

[12:06] Dann muss ich die Abbruchbedingungen vernünftig setzen.

[12:08] Wenn ich das nicht tue, habe ich vielleicht eine Endplus-Schleife usw.

[12:11] Das ist also ziemlich viel Aufwand und ziemlich fehleranfällig,

[12:13] nur um so eine Standardaufgabe zu lösen, nämlich ein Array zu durchlaufen.

[12:16] Von daher würde ich in meinem echten Code immer nur eine For-Each-Schleife für sowas benutzen,

[12:20] denn die versteckt quasi vor mir diese Komplexität, die ich da programmieren muss.

[12:24] Das sage ich dann in Java z.B. einfach vor meinetwegen String s in Strings,

[12:30] in einem Array, wo Strings drinstehen, mache irgendwas.

[12:33] Und dann sorgt Java dafür, dass jedes Element durchgelaufen wird,

[12:36] in eine temporäre Variable gepackt wird, mit der ich dann arbeiten kann.

[12:39] D.h. ich muss mich nicht um irgendwelche Indizes hochzählen usw. alles kümmern.

[12:43] Das macht halt eben die Schleife für mich.

[12:45] Von daher, wenn ich im Code irgendwie sowas sehe wie eine Vorschleife,

[12:48] um durch ein Array zu laufen, da sage ich immer meiner Zobis,

[12:51] stell das Umruf nur für eine For-Each-Schleife.

[12:53] Die einzige Ausnahme ist, wenn ich zusätzlich zu dem Inhalt des Arrays auch noch den Index brauche.

[12:58] D.h. wenn ich mit diesem Index selber irgendwas tun will,

[13:01] weil ich z.B. den Index irgendwie brauche, um was auszugeben oder Zeilen durchzufärben

[13:07] oder ich weiß nicht, was man noch Tolles damit machen kann.

[13:09] Oder z.B. nehme ich den Index, um auf den nächsten, folgenden Index drauf zuzugreifen,

[13:14] um z.B. eins hochzurechnen usw.

[13:16] Dann brauche ich eine Vorschleife. Das geht dann nicht mehr mit einer For-Each-Schleife.

[13:19] Aber ich sage mal, für 99% meiner Anwendungsfälle,

[13:22] wenn ich einfach nur Collection durchlaufe und irgendwas mit den Elementen tue,

[13:26] reicht eine For-Each-Schleife völlig aus.

[13:29] Gut, dann haben wir noch zwei Statements, die ganz nett sind im Zusammenhang mit Schleifen.

[13:33] Die gibt es nicht in allen Promiesprachen, aber in den meisten mir Bekannten gibt es die.

[13:37] Und zwar heißen die Continue und Break.

[13:39] Was machen die?

[13:41] Continue, wenn ich das in eine Schleife packe, irgendwo in den Schleifenrumpf,

[13:45] bedeutet das, die Schleife wird mit dem nächsten Wert fortgesetzt.

[13:49] Wenn ich z.B. eine Vorschleife habe, die von 1 bis 3 zählt,

[13:52] und ich mache irgendwo mitten in meinem Schleifenrumpf ein Continue,

[13:55] dann würde der aktuelle Zähler einfach hochgesetzt und mit dem nächsten Element würde weitergemacht.

[14:00] Bedeutet aber auch, dass in dieser Zeile, wo das Continue steht,

[14:03] die Ausführung der Schleife tatsächlich abgebrochen wird quasi.

[14:06] Alles, was hinter dem Continue noch kommt in der Schleife,

[14:09] da könnte ja noch irgendwie ein bisschen Code drinstehen,

[14:11] der wird übersprungen und dann wird wirklich von vorne mit dem nächsten Wert in der Vorschleife weitergemacht.

[14:17] Break macht das Ganze im Prinzip genauso,

[14:20] nur dass da nicht mit dem nächsten Wert weitergemacht wird,

[14:22] sondern da wird die komplette Schleife verlassen.

[14:24] Das heißt, ich springe wirklich ans Ende der Schleife

[14:27] und dann wird der Code weiter ausgeführt, der hinter der Schleife kommt.

[14:30] Mit Continue springe ich also einfach zum nächsten Wert

[14:33] und die Schleife fängt quasi vorne wieder an mit diesem erhöhten Wert.

[14:36] Und bei Break springe ich komplett aus der Schleife raus

[14:38] und mache mit dem Code weiter, der dahinter steht.

[14:41] Das gibt es tatsächlich sogar auch in der Programmiersprache,

[14:44] die wir häufig benutzen, nämlich Natural.

[14:46] Da heißen die beiden Statements völlig anders,

[14:48] nämlich Escape Top und Escape Bottom.

[14:51] Das finde ich auch sehr schön sprechend.

[14:53] Das bedeutet nämlich einfach, dass man zum Top, also zum Kopf der Schleife,

[14:56] quasi zurückspringt und mit dem nächsten Wert weitermacht.

[14:59] Und Escape Bottom bedeutet halt eben, ich springe zum Ende der Schleife

[15:02] und die gesamte Schleife wird eben verlassen.

[15:04] Also diese beiden Statements sind auch häufig anzutreffen in der Praxis,

[15:08] wenn ich zum Beispiel, meinetwegen in einem Array, einen bestimmten Wert suche

[15:11] und es gibt da keine Funktion für,

[15:13] dann könnte ich ja zum Beispiel mit einer Vorschleife da durchlaufen

[15:15] und jeden Wert vergleichen.

[15:17] Und wenn ich jetzt den Wert gefunden habe, warum muss ich dann zum Beispiel

[15:19] noch die 1000 folgenden Elemente noch weiter durchlaufen?

[15:22] Das wäre ja Quatsch.

[15:23] Ich könnte also sagen, oh, Wert gefunden, Break.

[15:25] Und dann gehe ich halt ans Ende der Schleife

[15:27] und spare mir die restlichen Iterationen.

[15:31] Gut, und letzte Frage zum Thema Algorithmus.

[15:34] Da nämlich die große Frage der Vorschleife.

[15:37] Die wird halt auch häufig in Prüfungen abgefragt,

[15:39] gerne auch in Schriftlichen natürlich.

[15:41] Wie sieht jetzt so eine Vorschleife aus?

[15:43] Ich hatte es gerade schon mal kurz besprochen.

[15:45] Ich nehme das Schlüsselwort vor und dann kommt in Klammern einmal die Initialisierung,

[15:49] dann kommt ein Semikolon, dann kommt eine Prüfung,

[15:51] dann kommt noch ein Semikolon und dann kommt die Aktion,

[15:54] die am Ende jedes Schleifendurchlaufs durchlaufen wird.

[15:57] Klassischerweise sieht also eine Vorschleife so aus wie vor, Klammer auf, int i gleich 0.

[16:02] i nimmt man halt häufig als Variablename für den Iterator,

[16:06] für die Iterationsvariable.

[16:08] Dann kommt ein Semikolon, dann kommt die Prüfung,

[16:10] zum Beispiel i kleiner 10 meinetwegen.

[16:13] Ich möchte also von 0 bis 9 meinetwegen zählen.

[16:15] Und dann kommt noch ein Semikolon, dann kommt die Aktion,

[16:17] in diesem Fall meistens i++.

[16:19] Das heißt, Zähler wird hochgezählt.

[16:21] Und die Vorschleife wird jetzt so durchlaufen.

[16:24] Einmalig wird die Initialisierung durchgeführt,

[16:26] also die Deklaration von i in diesem Fall.

[16:28] Dann kommt als allererstes auch die Prüfung,

[16:30] denn die Vorschleife ist ja kopfgesteuert.

[16:32] Kann ja sein, dass der Wert von i direkt am Anfang schon so groß oder klein ist,

[16:36] dass die Schleife gar nicht mehr durchlaufen werden soll.

[16:38] Und dann kommt erstmal der Schleifenrumpf,

[16:41] also das, was in dem Block hinter der Vorschleife steht,

[16:43] wird komplett abgearbeitet.

[16:44] Ganz am Ende des Blocks kommt dann die Aktion,

[16:46] das heißt, i wird hochgezählt.

[16:48] Und dann kommen wir wieder zur Prüfung, Block, Aktion.

[16:51] Prüfung, Block, Aktion und so weiter,

[16:53] bis die Prüfung irgendwann mal falsch wird.

[16:55] So wird dann die gesamte Vorschleife abgearbeitet.

[16:58] So, dann haben wir jetzt quasi alles gelernt,

[17:00] um richtig programmieren zu können.

[17:02] Wir können eine Sequenz bilden,

[17:04] indem wir einfach Befehle untereinander schreiben.

[17:05] Wir können eine Verzweigung machen,

[17:07] indem wir ein if-Statement benutzen.

[17:08] Oder wir können eine Wiederholung machen,

[17:10] indem wir kopf- oder fußgesteuerte Schleifen programmieren.

[17:12] Mensch, super.

[17:13] Damit können wir jetzt also jedes berechenbare Problem im Prinzip lösen,

[17:16] mit diesen drei Grundbausteinen.

[17:18] Und jetzt kommt als nächstes unser Bereich der Methoden,

[17:21] denn wenn wir jetzt was Tolles programmiert haben,

[17:23] dann sollten wir auch eine ganz wichtige Grundregel bei der Programmierung beherzigen,

[17:28] nämlich Code nur einmal schreiben und wiederverwenden

[17:31] und nicht copy-paste und alles doppelt und dreifach programmieren.

[17:33] Und das können wir in den meisten Programmiersprachen in irgendeiner Form tun.

[17:37] Wir können nämlich den Code, den wir programmiert haben,

[17:39] in irgend so ein Ding reinquetschen,

[17:41] das ich dann einfach nur noch aufrufen muss.

[17:43] Und das wären dann in Java oder in anderen objektorientierten Programmiersprachen

[17:46] auch die sogenannten Methoden.

[17:48] Man kann sie aber auch Funktionen oder Prozeduren nennen.

[17:51] Vielleicht einmal vorweg.

[17:53] In Prozeduralen Programmiersprachen gibt es zwei Begriffe für solche aufrufbaren Codeteile.

[18:00] Und zwar einmal die Funktion und einmal die Prozedur.

[18:03] Eine Prozedur hat einfach keinen Rückgabewert und eine Funktion hat einen Rückgabewert.

[18:08] Das ist eigentlich der zentrale Unterschied zwischen beiden.

[18:11] Und beides, sowohl Funktion als auch Prozedur, ist einfach nur ein benannter Code-Bereich im Prinzip.

[18:16] Dem kann ich einen Namen geben und dann rufe ich den auf.

[18:18] Und das ist im Prinzip eine Möglichkeit, diesen Code wiederzuverwenden.

[18:21] Ich kann also, wenn ich einen tollen Algorithmus programmiert habe,

[18:23] meinetwegen um das Alter einer Person zu berechnen,

[18:26] dann kann ich diesem Algorithmus einen schönen Namen geben,

[18:28] zum Beispiel berechne Alter.

[18:30] Und dem kann ich auch Parameter reingeben,

[18:32] wie zum Beispiel Geburtstag und aktuelles Datum zum Beispiel.

[18:35] Und dann gibt er mir irgendwas zurück, nämlich zum Beispiel das Alter der Person.

[18:38] Und diese Dinge kann ich also wunderbar wiederverwenden.

[18:42] Ich kann mich dann irgendwo in meinem Code einfach sagen,

[18:44] anstatt diesen ganzen Code runterzuprogrammieren mit Schleife und Vergleich und hin und her,

[18:47] sage ich einfach, berechne Alter, Datum 1, Datum 2.

[18:50] Und dann habe ich sofort das Alter und muss diesen Code nicht doppelt und dreifach schreiben.

[18:54] Kommt einem so vor wie, ja, das ist doch logisch, mache ich da ja schon immer so.

[18:58] Aber das war halt nicht immer so.

[19:00] Es gab auch früher Programmiersprachen, als es noch ganz in den Anfängen war, der Informatik,

[19:04] da ging das eben nicht.

[19:06] Da musste ich halt tatsächlich meinen Code doppelt und dreifach schreiben,

[19:08] weil ich eben solche benannten Funktionen oder Prozeduren nicht erzeugen konnte.

[19:12] Aber in heutigen Programmiersprachen ist das sicher anders.

[19:14] Und da sollten wir auf jeden Fall auch Gebrauch davon machen,

[19:16] nämlich um diese Redundanzen in unserem Code zu vermeiden.

[19:19] Redundanzen sind nämlich so das Schlimmste, was man tun kann in seinem Code.

[19:23] Denn das bedeutet, wenn ich Änderungen habe, muss ich an mehreren Stellen irgendwas anpassen.

[19:27] Und dabei vergesse ich ganz häufig irgendwie eine Stelle

[19:30] und dann habe ich komische Inkonsistenzen in meinem Code und Fehler im Programm,

[19:33] die sehr schwer zu finden sind.

[19:35] Also, wir machen am besten alles nur einmal.

[19:37] Das ist genau die Frage, warum schreibt man Methoden, um Code wiederverwenden zu können

[19:42] oder eben um Algorithmen wiederverwenden zu können.

[19:45] Ich würde mir ganz einfach als Daumenregel mitnehmen,

[19:50] immer wenn ich einen Code mehr als einmal benutze, mache ich auf jeden Fall eine Methode draus.

[19:54] Das heißt, ich extrahiere das dann zum Beispiel, wenn ich in Java entwickle mit Eclipse,

[19:58] kann ich einen Rechtsklick auf den Code machen und dann mache ich RefactorExtractMethod.

[20:02] Das ist ein ganz häufig verwendetes Pad, Refactoring.

[20:05] Und dann baut der mir von alleine eine Methode draus.

[20:07] Erzeugt mir auch die Parameter, Rückgabewert und so alles automatisch.

[20:10] Und ich muss eigentlich fast gar nichts mehr tun.

[20:12] Und dann kann ich sofort diese Methode natürlich an anderer Stelle aufrufen.

[20:15] Also perfekt, um Dinge wiederzuverwenden.

[20:18] So, dann schauen wir uns aber mal den Aufbau so einer Methode an.

[20:22] Hatte ich noch gar nicht gesagt, wie der Name zustande kommt.

[20:24] Also ich habe gerade gesagt, es gibt Funktionen und Prozeduren in anderen Programmiersprachen

[20:28] und in Java und anderen objektorientierten Sprachen haben diese Funktionen an den Objekten den Namen Methode.

[20:35] Das ist einfach nur Namenskonvention, die heißen einfach so.

[20:38] Daran kann man auch nicht ablesen, ob es eine Funktion oder eine Prozedur ist.

[20:40] Es haben also beide Dinge, sowohl mit Rückgabewert als auch ohne, den Namen Methode.

[20:47] Gut, dann gucken wir uns aber mal den Aufbau so einer Methode an.

[20:50] Und fangen gleich mit einem wichtigen Fachbegriff an, nämlich mit der Signatur einer Methode.

[20:55] Was ist diese Signatur und was gehört dazu?

[20:58] Wenn wir uns den Aufbau einer Methode anschauen, dann sehen wir meist in den meisten Programmiersprachen,

[21:02] insbesondere Java, C Sharp und so weiter.

[21:04] Wenn wir von links nach rechts die Methode uns anschauen, dann fängt die immer an mit dem Rückgabewert.

[21:09] Dann kommt der Name der Methode und hinter dem Namen steht dann meist in Klammern die Parameter der Methode.

[21:16] Also Rückgabewert, Name, Parameter.

[21:19] Diese drei Dinge, die hat eine Methode, beziehungsweise darüber definiert man eine Methode.

[21:23] Jetzt ist die zentrale Frage, was ist jetzt diese Signatur?

[21:26] Je nach Definition könnte man jetzt sagen, diese drei Bestandteile gehören zur Signatur.

[21:31] In Java ist das allerdings nicht so, der Rückgabewert gehört nämlich nicht dazu.

[21:35] Warum, da kommen wir gleich noch zu.

[21:37] Im engeren Sinne ist die Signatur der Name und die Anzahl und der Datentyp der Parameter.

[21:43] Was das genau bedeutet, da kommen wir gleich noch mal drauf.

[21:46] Die Signatur einer Methode muss eindeutig sein.

[21:49] Das heißt, ich kann nicht einfach eine Methode anlegen mit dem gleichen Namen und den gleichen Parametern.

[21:53] Denn, ganz einfach gesagt, die Programmiersprache kann dann nicht entscheiden, welche ich denn jetzt aufrufen will.

[21:57] Wenn der Name gleich ist und die Parameter auch.

[21:59] Und ich habe zweimal eine Methode, die so definiert ist.

[22:02] Woher soll jetzt zum Beispiel Java wissen, welche Methode er aufrufen soll?

[22:05] Kann er nicht, denn die unterscheiden sich ja nicht.

[22:07] Und deswegen muss die Signatur einer Methode eben eindeutig sein.

[22:10] Und jetzt erklären wir vielleicht auch, warum der Rückgabewert dann nicht zur Signatur gehört.

[22:14] Denn angenommen, ich hätte eine Methode mit zwei unterschiedlichen Return-Werten,

[22:17] aber dem gleichen Namen und den gleichen Parametern.

[22:20] Woher soll Java jetzt wissen, welche Methode aufgerufen wird?

[22:24] Denn ich schreibe ja hin bei meinem Methodenaufruf später, meinetwegen alter a gleich berechneAlter Tag Tag2.

[22:32] Ich gebe ja nur ein berechneAlter Tag und Tag2.

[22:35] Aber ich kann in keiner Weise vorgeben, welchen Rückgabewert ich denn jetzt gerne hätte.

[22:39] Ich kann also jetzt nicht sagen, von der Methode hätte ich aber jetzt gerne einen anderen Rückgabewert.

[22:43] Das ist einfach syntaktisch nicht möglich in Java.

[22:45] Und deswegen gehört der Rückgabetyp auch nicht zur Signatur dazu.

[22:49] Der Name dürfte relativ eindeutig sein.

[22:52] Wenn ich zwei Methoden anlege mit unterschiedlichem Namen, dann unterscheiden die sich logischerweise.

[22:55] Das ist kein Problem für Java.

[22:57] Was wir uns im Detail einmal anschauen sollten, wäre jetzt der Datentyp und die Anzahl der Parameter.

[23:03] Ich habe bewusst nicht den Namen der Parameter erwähnt, denn der Name ist völlig irrelevant für Java oder auch andere Programmiersprachen.

[23:10] Es wird sich nur interessiert für wirklich die Anzahl der Parameter und welchen Datentyp sie haben.

[23:15] Als Beispiel, wenn wir eine Add-Methode anlegen, um zum Beispiel zwei Zahlen zu addieren,

[23:20] und wir definieren die als add, Klammer auf, int a, Komma, int b, Klammer zu.

[23:25] Dann bekommt sie zwei Integer-Parameter rein.

[23:28] Wenn ich jetzt eine zweite Methode anlege mit dem Namen add und ich schreibe in Klammern int b, Komma, int c, Klammer zu,

[23:36] dann heißen die Parameter zwar unterschiedlich, nämlich a und b, beziehungsweise b und c, aber die Datentypen sind halt identisch.

[23:42] Und das würde eine Programmiersprache nicht erlauben.

[23:45] Denn hier ist wieder das Problem beim Aufruf der Methode. Wie soll die Programmiersprache entscheiden, welche Methode aufrufen wird?

[23:50] Ich gebe ja beim Aufrufen nicht die Namen der Parameter mit, sondern ich gebe nur die Werte mit.

[23:55] Das heißt, die Methode würde ich aufrufen mit add, 2, 3, um zum Beispiel 2 und 3 zu addieren.

[24:01] Da schreibe ich aber nicht rein, 2 und 3 sind a und b, beziehungsweise b und c, sondern ich gebe nur die Werte rein.

[24:06] Also wie soll die Programmiersprache dann diese Werte, den Namen zuordnen? Das ist nicht möglich.

[24:11] Und genau deswegen ist es auch nicht möglich, zwei Methoden anzulegen mit dem gleichen Namen und der gleichen Anzahl und den gleichen Datentypen an Parametern,

[24:19] die unterschiedliche Namen haben. Das reicht nicht aus, sondern die Datentypen müssen wirklich unterschiedlich sein.

[24:24] Was ich also durchaus machen könnte, wäre sowas wie eine zweite add-Methode mit double a, Komma, double b anzulegen.

[24:32] Das wäre in Ordnung, denn int und double sind zwei unterschiedliche Datentypen und dann kann die Programmiersprache sehr wohl entscheiden,

[24:38] wenn ich was aufrufe, add, 2, 3 oder add, 2, 0, 3, 0, dann kann natürlich die Programmiersprache entscheiden,

[24:47] ah, das erste sind Integers, also nehme ich die eine Methode und das zweite sind Doubles, also nehme ich die andere Methode.

[24:52] Das reicht dann aus, um die Methode eindeutig zu identifizieren.

[24:56] Eine schöne Besonderheit übrigens noch in Java, da gibt es noch so tolle Dinger, die Checked Exceptions heißen.

[25:01] Haben wir uns noch nicht im Detail angeguckt, aber es sind ja Exceptions, die ich hinter die Methode schreibe mit dem Schlüsselwort throws

[25:07] und dann wird ausgesagt, dass diese Methode eine gewisse Exception werfen kann.

[25:11] Und das bedeutet, der Aufrufer muss den auch behandeln, also z.B. einen Try-Catch drum machen.

[25:16] Und dieses Throws und die Exceptions, die da geworfen werden können, gehören auch mit zur Methodensignatur in Java.

[25:22] Es wird also relevant, wenn ich entscheide, welche Methode aufgerufen werden soll.

[25:26] Aber für so eine Prüfungssituation, nochmal vielleicht ganz konkret der Tipp, in der Prüfung werde ich nicht auf eine konkrete Programmiersprache geprüft,

[25:34] außer ich habe sie selber verwendet, z.B. in meinem Abschlussprojekt.

[25:36] Aber ich würde wahrscheinlich keinen Prüfling nach der konkreten Implementierung in Java fragen,

[25:42] weil einfach nicht jeder Prüfling in seiner Ausbildung irgendwann mal Java gemacht hat.

[25:45] Das kann man nicht voraussetzen.

[25:47] Und von daher sollte man eher allgemein antworten und vielleicht Beispiele aus seiner Lieblingsprogrammiersprache bringen,

[25:53] aber immer versuchen, die Fragen der Prüfer möglichst allgemein zu beantworten.

[25:57] Deswegen würde ich sagen, zur Signatur einer Methode gehören der Name und die Anzahl und die Datentypen der Parameter.

[26:04] Den Rückgabewert lasse ich weg und auch diese Exception-Geschichte aus Java lasse ich weg.

[26:08] Und wenn dann noch eine konkrete Nachfrage kommt, sowas wie, ja, aber Sie kennen doch vielleicht Java, wie ist es denn da und da?

[26:13] Okay, dann kann man natürlich darauf antworten, aber erstmal versuchen, möglichst allgemeingültig für so viele Programmiersprachen wie möglich,

[26:19] sage ich mal, eine korrekte Antwort zu liefern.

[26:23] So, jetzt haben wir also kennengelernt, wenn wir eine Methode definieren, dann sagen wir Rückgabewert, Name und dann die Parameter dahinter.

[26:30] Jetzt gibt es aber noch eine tolle Funktion in vielen Programmiersprachen, die Überladen heißt.

[26:35] Was ist das jetzt? Das kann man jetzt relativ einfach erklären.

[26:38] Wenn wir jetzt nämlich wissen, was die Signatur einer Methode ist, dann können wir einfach sagen,

[26:42] das Überladen von Methoden ist, eine Methode anzulegen mit dem gleichen Namen wie dem einer Methode, die es schon gibt,

[26:50] aber mit unterschiedlichen Parametern.

[26:52] Wir könnten also, wie ich es gerade erklärt habe, mit meiner Add-Funktion, könnte ich eine zweite Add-Funktion anlegen,

[26:57] die genauso heißt wie die erste, aber eben andere Parameter bekommt.

[27:00] Und genau das heißt Überladen.

[27:02] Das heißt, ich habe, wenn ich die Methoden aufrufe und anschaue, ich gebe ein Add, Klammer auf,

[27:07] und dann habe ich halt die Möglichkeit, zwischen verschiedenen Implementierungen dieser Add-Funktion, äh, Methode zu wählen.

[27:14] Und genau das ist das Überladen von Methoden.

[27:16] Also im Prinzip, kurze Antwort, gleicher Name, andere Parameter.

[27:20] Und der Rückgabewert, wie gesagt, ist dabei irrelevant.

[27:23] Das heißt, ich kann eben gerade nicht eine Funktion angeben, die den gleichen Namen, die gleichen Parameter,

[27:27] aber einen unterschiedlichen Rückgabewert hat. Das ist nicht möglich.

[27:30] So, wenn wir jetzt schon beim Rückgabewert gerade mal waren, wie geben wir denn überhaupt etwas zurück aus einer Methode?

[27:36] Also wie geben wir einen zum Beispiel berechneten Wert zurück an den Aufrufer?

[27:40] Dafür gibt es in den meisten Poemiersprachen das Schlüsselwort return.

[27:43] Einige coolere Poemiersprachen verzichten auch zum Beispiel auf das Schlüsselwort return.

[27:47] Da wird einfach der zuletzt in der Methode aufgerufene Wert zurückgegeben.

[27:51] Also könnte ich zum Beispiel einfach alter da hinschreiben, und dann wird halt der Inhalt der Variable in alter zurückgegeben.

[27:56] Aber in vielen, sag ich mal, Mainstream-Poemiersprachen, Java, C Sharp und so weiter,

[28:01] wird das return-Schlüsselwort benutzt, um etwas zurückzugeben.

[28:04] Und das, was hinter dem return dann steht, zum Beispiel return alter, das wird dann zurückgegeben an den Aufrufer.

[28:10] Es gibt allerdings auch Methoden, die gar nichts zurückgeben.

[28:13] Das wäre dann quasi die Analogie zu unseren Prozeduren.

[28:16] Das heißt, ich habe eine Methode, die hat keinen Rückgabewert.

[28:19] Die hat einen Namen und Parameter, wunderbar, aber die gibt nichts zurück.

[28:21] Aber ich muss halt, wenn ich die Methode definiere, einen Rückgabewert definieren.

[28:25] Der steht da, und der muss da auch stehen.

[28:27] Jetzt ist die Frage, was schreibe ich denn da hin, wenn gar kein Rückgabewert da ist?

[28:31] Dafür gibt es ein weiteres Schlüsselwort, und das heißt void.

[28:34] Kommt aus dem Englischen, heißt sowas wie leere, also zum Beispiel die Leere im Weltraum.

[28:38] Und dieses void schreibe ich da hin, wenn ich keinen expliziten Rückgabewert habe.

[28:42] Also zum Beispiel string oder int oder partner oder was auch immer ich da zurückgebe.

[28:46] Das heißt, der Aufbau einer Methode ist wirklich immer gleich Rückgabewert, Name, Parameter.

[28:51] Und wenn es eben keinen Rückgabewert tatsächlich gibt, muss ich eben das Schlüsselwort void benutzen, um das deutlich zu machen.

[28:57] Und das wäre dann eben eine Methode ohne Rückgabewert, also quasi eine Prozedur.

[29:02] So, eine ganz wichtige Sache bei den Methoden, das sehe ich auch immer ganz häufig, gerade bei Premiere-Anfängern,

[29:06] dass das irgendwie nicht so richtig verstanden wird, ist, wie die Parameter, die ich da so reingebe, sich verhalten.

[29:12] Und zwar insbesondere beim Aufrufer.

[29:14] Viele Leute sind nämlich der Meinung, ich mache dann sowas wie berechne Alter,

[29:18] und die Sachen, die ich dann da reingebe, die werden irgendwie geändert,

[29:20] und dann sind die nachher bei meinem Aufrufer auch geändert.

[29:23] Aber das ist gerade eben nicht der Fall.

[29:25] Und hier müssen wir uns zwei Sachen einmal angucken, die man beim Methodenaufruf unterscheiden muss.

[29:29] Und zwar die Parameter, die man da reingibt.

[29:32] Die können entweder, wie man das auf Englisch sagt, by value übergeben werden oder by reference.

[29:38] Und die beiden Sachen sind grundsätzlich unterschiedlich, und das muss man auch einmal verstanden haben.

[29:42] Der Standard in fast allen Premiere-Sprachen, die ich kenne, ist immer by value.

[29:47] Das heißt, es wird, wie der Name sagt, der Wert der Parameter übergeben.

[29:51] Kann man sich so vorstellen, ich habe meinetwegen eine Variable, die nenne ich meinetwegen int i,

[29:56] und die hat irgendeinen Wert, sagen wir mal 5.

[29:58] Und ich rufe dann eine Methode auf, der ich das i übergebe.

[30:01] Also meinetwegen berechne irgendwas in Klammern i.

[30:04] Dann wird die Programmiersprache dafür sorgen, dass der Wert, den i zum Zeitpunkt des Methodenaufrufs hat,

[30:10] an diese Methode übergeben wird.

[30:12] Und wenn jetzt in dieser Methodendefinition sowas steht wie, was hatte ich gerade gesagt, berechne, glaube ich,

[30:17] berechne und dann Klammer auf meinetwegen int a,

[30:20] dann wird der Wert, den i beim Aufruf hat, in den Parameter a übergeben,

[30:25] aber nur der Wert wird einmalig da rein kopiert, quasi, wenn man so will.

[30:30] Und innerhalb dieser Methode ist er dann in der Variablen mit dem Namen des Parameters verfügbar,

[30:35] also meinetwegen a.

[30:36] Dann kann ich mit a natürlich auch alle Dinge machen, die ich sonst mit Variablen auch tun kann.

[30:39] Ich kann da neue Werte zuweisen oder was hochrechnen, runterrechnen, keine Ahnung.

[30:42] Alles mögliche kann ich damit tun.

[30:44] Allerdings hat das keinerlei Auswirkungen auf den Aufrufer, also das i in meinem aufrufenden Code.

[30:49] Wenn ich das berechne aufgerufen habe, hat das i immer noch den gleichen Wert wie vorher.

[30:54] Der ist unverändert, denn nur der Wert, den i hatte, wird eben kopiert und an die Methode übergeben.

[31:00] Aber das ist halt eben eine Kopie.

[31:02] Das heißt, wenn sich diese Kopie ändert, hat das keinerlei Auswirkungen auf den originalen Wert und die originale Variable.

[31:08] Demgegenüber steht der Call bei Reference.

[31:12] Das bedeutet nämlich, ich gebe nicht den Wert an die Methode,

[31:15] sondern eben eine Referenz auf eine Variable im Prinzip.

[31:19] Das heißt, ich sage dann nicht der Methode, hier hast du den Wert 5,

[31:22] sondern ich sage der Methode hier, hier hast du die Variable im Speicher,

[31:26] da steht die 5 drin und mit dieser Variablen kannst du jetzt irgendwas tun.

[31:30] Und wenn die Methode das dann tatsächlich auch tut und zum Beispiel diese Variable verändert und der einen neuen Wert gibt,

[31:35] dann hat das auch eine Auswirkung auf den Aufrufer.

[31:38] Das heißt, in unserem Beispiel wäre das i nachher verändert, nachdem die Methode aufgerufen wurde.

[31:43] Aber wie gesagt, die meisten Programmiersprachen machen das bei Value zum Standard.

[31:48] Das heißt, es wird immer eine Kopie übergeben und nie die Originalvariable verändert.

[31:53] Wenn ich das anders haben will, dann bieten einige Programmiersprachen das durchaus an.

[31:57] Zum Beispiel in C-Sharp, da gibt es das Schlüsselwort ref.

[32:00] Das kann ich vor meine Variable beim Parameter, beim Methodenaufruf hinschreiben.

[32:05] Muss ich aber auch in der Methodensignatur machen.

[32:07] Also hätte ich sowas wie brechne ref int i.

[32:11] Das bedeutet dann, ich gebe wirklich eine Referenz da rein

[32:14] und wenn die Methode diesen Wert dann ändert, dann gilt es auch beim Aufrufer.

[32:18] Da gibt es noch eine wichtige Sache, die man wissen muss.

[32:21] Und zwar, wenn ich jetzt Objekte übergebe an eine Methode,

[32:24] dann ist das grundsätzlich auch immer bei Value.

[32:27] Das bedeutet aber nicht, dass die Werte, die das Objekt hat,

[32:31] zum Beispiel in seinen Attributen, dass die festgeschrieben und kopiert werden,

[32:35] sondern nur die Referenz auf das Objekt.

[32:38] Die kann sich nicht ändern, aber das Objekt kann sich sehr wohl ändern.

[32:42] Der Inhalt des Objekts ist nämlich weiteränderbar

[32:45] und das hat auch eine Auswirkung dann auf den Aufrufer.

[32:48] Kleines Beispiel, mein Aufrufer hat irgendwie eine Person erzeugt,

[32:52] ein Objekt vom Typ Person und diese Person hat einen Namen.

[32:55] Wenn ich jetzt meinetwegen beim Aufruf der Methode Druckepartner oder sowas

[33:01] diese Person da rein gebe und dieses Druckepartner verändert jetzt den Namen der Person,

[33:06] dann hat die Zugriff auf den gleichen Speicherbereich,

[33:10] den auch der Aufrufer benutzt hat.

[33:12] Das heißt, wenn die Person dann quasi zurückkommt aus der Methode,

[33:16] dann ist die auch für den Aufrufer verändert.

[33:19] Was ich bei diesem CallByValue bei Objekten nicht tun könnte,

[33:22] wäre innerhalb meiner Methode der Variablen eine ganz neue Person zuzuweisen.

[33:28] Wenn ich jetzt also zum Beispiel sage, in meiner Druckepartner-Methode

[33:32] greife ich auf meinen Parameter zu und sage zum Beispiel

[33:35] Parameter gleich new Person mit irgendwas,

[33:38] dann würde ich ja wirklich das komplette Objekt ersetzen.

[33:41] Und das führt dann dazu, dass beim Aufrufer nichts verändert wird,

[33:45] weil diese Referenz auf das Objekt tatsächlich nur innerhalb der Methode dann gültig war

[33:49] und sich nicht auf den Aufrufer durchschlägt.

[33:52] Aber wenn ich das Objekt so übernehme, wie ich es bekomme

[33:54] und an dem Objekt herum manipuliere, zum Beispiel mit Gettern und Zettern usw.,

[33:58] dann hat das sehr wohl eine Auswirkung auf den Aufrufer.

[34:02] Von daher könnte man meinen, dass der Aufruf mit Objekten als Parametern

[34:08] ein CallByReference ist, ist er aber nicht.

[34:10] Es ist auch ein CallByValue, aber ich kann halt eben die referenzierten Objekte ändern

[34:16] und das hat dann auch eine Auswirkung auf den Aufrufer.

[34:19] Ich merke gerade, dass das, glaube ich, ziemlich schwierig erklärt war,

[34:22] was ich jetzt hier gerade erzählt habe.

[34:24] Also wenn es dazu noch Fragen gibt, dann meldet euch gerne,

[34:27] schreibt mir gerne einen Kommentar zur Episode,

[34:29] dann versuche ich nochmal etwas Schönes rauszusuchen

[34:31] oder erkläre das nochmal einmal mit anderen Worten vielleicht.

[34:34] Aber ganz wichtig, merken, CallByValue ist Standard,

[34:37] das heißt, es werden nicht die Variablen übergeben, sondern tatsächlich die Werte.

[34:41] Und wenn ich die Werte verändere, dann interessiert das den Aufrufer hässlich wenig.

[34:44] Das Einzige, was ich tun kann, um den Aufrufer einen Wert zurückzugeben,

[34:49] ist eben ein Return zu machen, also wirklich einen Rückgabewert zurückzugeben.

[34:53] Wenn ich die Parameter ändere, dann interessiert den Aufrufer eigentlich null.

[34:56] Der kriegt davon gar nichts mit.

[34:58] Und wenn ich halt ein ByReference mache, dann ist das sehr wohl der Fall,

[35:01] dann kriegt er die Änderung mit, aber das ist nicht umsonst so.

[35:04] Das Programmiersprachen darf das eigentlich von Haus aus heute nicht mehr machen.

[35:07] Sagt sogar Microsoft zu C Sharp, wo das zum Beispiel möglich ist mit dem Ref,

[35:10] bitte nicht benutzen, weil das dazu führt, dass es ganz schwierig wird,

[35:14] nachzuvollziehen, wo denn irgendwelche Werte herkommen.

[35:16] Denn ich habe einen Methodenaufruf, da gebe ich eine Variable rein

[35:18] und ich kann da ja nicht reingucken manchmal in die Methoden

[35:20] und dann weiß ich gar nicht, wieso jetzt auf einmal ein Wert verändert ist.

[35:22] Und dann frage ich mich, wie kommt es jetzt zum Fehler in meinem Programm

[35:25] und dann suche ich stundenlang nach dem Fehler.

[35:27] Das wollen wir also eigentlich nicht.

[35:28] Schöner ist es, wenn wir nur mit den Return-Werten arbeiten

[35:31] und so Reference-Aufrufe uns am besten komplett sparen.

[35:35] So, da habe ich noch eine ganz triviale Frage,

[35:37] aber da denkt man vielleicht nicht unbedingt so dran.

[35:40] Wenn ich jetzt eine Methode aufrufen möchte, wie mache ich denn das überhaupt?

[35:43] Und da müsste man vielleicht einmal unterscheiden.

[35:45] Es gibt eigentlich zwei Arten von Methoden in der Objektdenotierung,

[35:47] nämlich einmal die sogenannten Instanzmethoden oder Objektmethoden

[35:51] oder auch die statischen oder Klassenmethoden.

[35:54] Und beide werden in Java zumindest mit dem gleichen Operator aufgerufen,

[35:57] nämlich mit dem Punkt.

[35:58] Wenn ich also ein Objekt habe, meinetwegen diese Person von eben,

[36:01] die hat meinetwegen auch den Namen Person,

[36:03] dann mache ich Person, Punkt und dann gib Person aus oder sowas.

[36:07] Über den Punkt greife ich auf diese Methode zu.

[36:10] Wenn ich stattdessen eine statische oder eine Klassenmethode habe,

[36:12] dann mache ich das genauso, nämlich auch mit dem Punkt,

[36:14] aber das rufe ich nicht an einem Objekt auf, sondern an der Klasse selber.

[36:18] Da würde ich jetzt also sowas machen wie,

[36:20] Person ist jetzt ein doofes Beispiel, weil die Klasse auch vielleicht Person heißt,

[36:23] aber dann würde ich halt eben Person mit einem großen P schreiben

[36:26] für die Klasse Person und dann Punkt gib Person aus.

[36:30] Das heißt also, der Aufruf ist in beiden Fällen gleich,

[36:32] nämlich der Punktoperator und dahinter dann der Name der Methode.

[36:35] Aber bei Instanzmethoden steht ein Objekt vor dem Punkt

[36:38] und bei Klassenmethoden steht der Klassenname vor dem Punkt.

[36:42] So, dann ist gleich die nächste Frage, was ist denn jetzt der Unterschied zwischen beiden?

[36:46] Instanzmethoden, wie der Name sagt, kann ich nur an einer Instanz aufrufen.

[36:49] Das heißt, ich brauche auch eine Instanz.

[36:51] Ich kann also zum Beispiel nicht an der Klasse Person sowas wie SetName aufrufen,

[36:56] denn ein Name ist für eine konkrete Person individuell

[37:00] und das ist also nicht für alle Personen auf der ganzen Welt identisch.

[37:04] Und genau daran würde ich auch die Unterscheidung machen,

[37:06] nämlich alles, was individuell für ein Objekt gültig ist,

[37:09] ist über eine Instanzmethode aufzurufen

[37:11] und alles, was zum Beispiel für alle Objekte dieser Klasse gleich sein muss,

[37:17] kann man dann über eine Klassenmethode machen, also über eine statische Methode.

[37:21] Und wie man jetzt so eine statische Methode definiert, ist eigentlich relativ simpel.

[37:25] Ich nutze das Schlüsselwort Static

[37:27] und Static schreibe ich einfach irgendwo vor die Methodensignatur,

[37:30] also zum Beispiel sowas wie Public, Static, Void und so weiter.

[37:33] Ja, dann geht's los.

[37:34] Und das bedeutet dann, dass ich eben diese Methode auch aufrufen kann,

[37:37] ohne mir ein Objekt zu erzeugen.

[37:40] Sonst müsste ich halt in meinem Code sowas machen wie

[37:42] new Person, also zum Beispiel Person p gleich new Person

[37:47] und dann kann ich machen p Punkt gibt aus.

[37:50] Wenn ich jetzt aber was aufrufe, was an der Klasse definiert ist,

[37:53] brauche ich halt dieses ganze new Gedöns da nicht,

[37:55] sondern ich kann einfach machen Person mit großem p Punkt

[37:58] und dann irgendwas, was für alle Personen gleich ist,

[38:00] wie zum Beispiel, ja, da fällt mir jetzt natürlich wieder nichts ein,

[38:04] aber irgendetwas, was für alle Personen weltweit gleich wäre

[38:07] und wo ich auch zum Beispiel gar nicht auf die Attribute einer konkreten Person zugreifen müsste,

[38:11] das würde ich halt eben als statische Methode modellieren.

[38:14] Und jetzt habe ich auch schon gleich wieder ein weiteres Schlüsselwort benutzt,

[38:17] was wir in diesem Kontext brauchen, um das aufrufen zu können, ohne das zu erklären,

[38:20] und zwar das Schlüsselwort new.

[38:22] Was macht new?

[38:23] New erzeugt einfach ein neues Objekt einer Klasse oder instanziiert eine Klasse.

[38:27] Das sagt man auch dazu.

[38:29] Genau wie ich es gerade im Beispiel gemacht habe,

[38:31] Person p deklariert die Variable als Typ Person gleich new Person

[38:36] und new, da wird halt eben dann ein neues Objekt der Klasse Person erzeugt.

[38:40] Das werden wir in den nächsten Lernsekretoren sicherlich nochmal vertiefen,

[38:43] wenn es um die Objektorientierung geht.

[38:45] Für jetzt merken wir uns erstmal den Unterschied.

[38:47] Es gibt eine Instanzmethode.

[38:49] Dafür brauche ich ein Objekt und das erzeuge ich mit new.

[38:52] Und es gibt statische Methoden.

[38:54] Da nehme ich einfach direkt den Klassennamen.

[38:56] Da muss ich überhaupt nichts instanziieren.

[38:58] So, damit wäre ich jetzt mit meinen Themen für heute durch.

[39:01] Ich hoffe, es war ein bisschen was Interessantes dabei.

[39:03] Wenn ich noch was Wichtiges vergessen habe, was du unbedingt ergänzen würdest,

[39:07] dann schreib mich doch einfach an.

[39:09] Oder am besten schreib einen Kommentar zur Episode.

[39:11] Dann sehen auch andere Leute das.

[39:13] Das kannst du wie immer tun unter anwendungsentwicklerpodcast.de

[39:16] slash 42, also die Zahl 4 2, für die heutige 42. Episode.

[39:21] Da findest du die Shownotes zu der heutigen Episode mit einigen Links noch.

[39:26] Zu weit dafür in der Literatur.

[39:28] Unter anderem habe ich heute wieder mal verlinkt das allseits bekannte Buch

[39:31] die Java-Insel oder auch die Java-Einführung.

[39:34] Beide aus dem Rheinwerk-Verlag.

[39:36] Das sind tolle Bücher, um mit Java loszulegen.

[39:39] Wie gesagt, ich mache meine Letzigertreuen ja recht fokussiert auf Java,

[39:42] weil ich das immer anhand von Java mache.

[39:44] Aber grundsätzlich gilt das, was ich heute erzählt habe,

[39:46] eigentlich auch in vielen anderen Programmiersprachen.

[39:48] In C-Sharp kann man quasi sogar die Syntax fast 1 zu 1 übernehmen.

[39:51] In der anderen Programmiersprache, meinetwegen in Ruby,

[39:53] ist vielleicht dann nicht das New vor der Klasse, sondern hinter der Klasse.

[39:56] Aber im Prinzip sind die Konzepte überall dieselben.

[39:59] Nur die Syntax unterscheidet sich dann halt vielleicht mal ein bisschen.

[40:02] Also grundsätzlich habe ich eigentlich bei allen meinen Letzigertreuen immer drunter geschrieben,

[40:05] die Java-Insel ist eigentlich das perfekte Buch, um irgendwas mit Java zu lernen.

[40:09] Über 1000 Seiten dick und da wird natürlich auch alles im Detail vorgestellt,

[40:12] was ich heute erzählt habe.

[40:13] Ich habe die wichtigsten Inhalte auch nochmal konkret auf das Openbook verlinkt.

[40:17] Die Java-Insel ist ja glücklicherweise kostenfrei im Internet verfügbar,

[40:20] in einer etwas älteren Version.

[40:22] Und da habe ich genau die Sachen zur heutigen Episode,

[40:24] nämlich Datenstrukturen, Algorithmen und auch Methoden einer Klasse verlinkt.

[40:28] Da kannst du gerne mal reinschauen.

[40:30] Auch das Java-Tutorial direkt von Oracle kann ich absolut empfehlen.

[40:33] Kannst du auch mal reingucken, ist auch sehr gut geschrieben,

[40:35] allerdings dann halt auf Englisch.

[40:36] Das erklärt die ganzen Sachen, die ich heute hier erzählt habe,

[40:39] natürlich auch nochmal einmal im Detail.

[40:42] So, wenn du schon auf der Website bist und mir einen Kommentar gerade schreiben möchtest, dann

[40:46] guck doch mal in den Blog. Da habe ich letzte Woche auch noch mal zwei ganz nette Sachen

[40:50] veröffentlicht. Mein Link der Woche ging darüber, wie man jeden Code in jedem System testbar macht.

[40:56] Wir haben ja noch nicht so viel über Unit-Tests gesprochen, aber es ist eines meiner Lieblingsthemen.

[41:00] Da werde ich sicherlich auch noch mal in Zukunft eine Episode dazu machen. Und ich habe einen ganz

[41:04] interessanten Artikel da verlinkt und auch ein super Buch, nämlich Working Effectively with

[41:09] Legacy Code von Michael Feathers kann ich nur empfehlen, wenn man mit Alt-Software arbeiten

[41:14] muss. Und der Artikel, den ich verlinkt habe, ist quasi so eine Kurzform, wie man auch, ich sage

[41:18] mal, uralt Code, für den man noch keine Unit-Tests hat, testbar machen kann. Und zwar auch gefahrlos,

[41:23] ohne in dem Prozess etwas kaputt zu machen. Und als Blog-Artikel habe ich letzte Woche etwas

[41:28] umfangreich geschrieben zum Thema Verwendung von fremden Vorlagen in der Projektdokumentation.

[41:32] Meine beliebteste Seite auf dem Blog ist ganz klar die Vorlage für die Projektdokumentation,

[41:37] meine LaTeX-Vorlage. Und häufig erreichen mich dann auch Fragen von Prüflingen, darf ich das

[41:41] überhaupt benutzen? Wie muss ich denn die Vorlage zitieren zum Beispiel? Oder gibt es vielleicht

[41:45] Punktabzuche, wenn ich irgendwelche Sachen aus dem Internet benutze? Und meine Antwort dazu findest

[41:49] du auf jeden Fall in einem ausführlichen Artikel auch auf der Website. Wenn du selber noch Empfehlungen

[41:55] hast, vielleicht für coole Links, die du gelesen hast, dann immer her damit. Schick mir das gerne

[41:59] rüber. Ich teile die Sachen gerne auch mit meinen Zuhörern und Lesern. Und natürlich erwähne ich

[42:04] gerne auch deinen Namen und verlinke dich, wenn du irgendeinen Blog hast oder sowas. Also immer

[42:07] her mit dem Content. Und ich freue mich auch über jegliches Feedback. Also wenn du mir eine Mail

[42:11] schreiben willst oder mich am besten noch weiterempfehlen willst, mach das gerne unter

[42:15] mail.anwendungsentwicklerpodcast.de kannst du mich jederzeit erreichen. Oder eben noch besser, schreib

[42:20] einen Kommentar zu der Episode hier. Du kannst mich auch jederzeit anschreiben, wenn du irgendwelche

[42:25] Fragen hast rund um die Ausbildung. Das nutze ich auch immer gerne, um zum Beispiel auf neue

[42:29] Themenideen für die Episoden zu kommen. Also schreib mich da gerne an, wenn du möchtest. Und

[42:33] ich empfehle natürlich auch noch, den Podcast zu abonnieren. Dann verpasst du keine neue Episode.

[42:37] Du kannst direkt auf die Shownotes gehen und da findest du auch wie immer unter jeder Episode den

[42:41] Link zum ESS-Feed, wo du den Podcast abonnieren kannst. Ansonsten, wenn du irgendwie mit mir in

[42:46] Kontakt treten willst, ich fasse das Ganze jetzt mal kurz zusammen. Es geht wie immer unter

[42:50] anwendungsentwicklerpodcast.de und dann ein entsprechendes Wort für das Social Network, wo

[42:56] du mich dann erreichen kannst. Zum Beispiel iTunes, Stitcher, Facebook, Twitter, Xing. Die fünf Links

[43:01] gibt es schon. Einfach hinter anwendungsentwicklerpodcast.de schreiben und dann landest du automatisch auf der Seite,

[43:06] wo du mit mir in Kontakt treten kannst, wenn du das möchtest. Und wie immer gibt es auch zuletzt den

[43:10] Hinweis auf mein Newsletter. Wenn du möchtest, trage dich gerne ein unter anwendungsentwicklerpodcast.de

[43:15] slash Newsletter. Als kleines Dankeschön bekommst du gleich Zugriff auf meine Checklisten rund um

[43:20] die Projektarbeit und du bekommst auch immer von mir regelmäßig Informationen rund um die

[43:25] Neuigkeiten auf der Webseite. So verpasst du dann auch keine neuen Inhalte. Nächste Woche ist

[43:30] die letzte Episode vor Weihnachten 2015 und da mache ich dann tatsächlich mal ganz langweilig

[43:36] eine weitere Lernzielkontrolle. Und dann steigen wir, glaube ich, schon mal ein in die

[43:39] Objektorientierung. Da wird es dann also durchaus etwas interessanter. Und dann überlege ich mir mal,

[43:44] was ich für die Episode nach Weihnachten mir dann Tolles ausdenke. Da würde ich sagen,

[43:49] machen wir mal wieder eine kleine Pause von den Lernzielkontrollen. Ansonsten,

[43:52] wenn dir die Lernzielkontrollen was bringen oder wenn du noch weitere Inhalte hören willst oder

[43:57] oder oder, dann melde dich einfach bei mir. Ich freue mich über jegliches Feedback und ich versuche

[44:00] immer möglichst schnell auf alle möglichen Kontaktanfragen zu antworten. Also kontaktiere

[44:04] mich gerne. Würde mich freuen. Ansonsten sage ich vielen, vielen Dank fürs Zuhören und bis zum

[44:10] nächsten Mal. Tschüss.