PROGRAMMIEREN II · KLAUSUR · 1:1
Vier bis fünf Sessions vor der Klausur. Wir gehen Vererbung, abstrakte Klassen und Interfaces durch, machen Generics greifbar und üben Rekursion, bis du sie selbst herleitest.
Dennis LIVE Senior Java Engineer · OOP-Profi antwortet ≤ 2 h , Profil ansehen Kostenloses Erstgespräch →
Schon entschieden? Direkt zur Session →
Live aus einer Programmieren-II-Session
// Welche Methode wird aufgerufen? Tier t = new Hund(); t.laut(); // Hund.laut(), nicht Tier.laut() // dynamische Bindung: der echte Typ zählt
Programmieren II baut auf den Grundlagen auf und dreht die Schwierigkeit Richtung OOP-Design. Typisch sind ein Vererbungs-Block, ein Generics- und Collections-Block sowie ein Rekursions-Block. Wir trainieren jeden an deinen Altklausuren.
Pro Session zahlen oder Klausur-Paket sichern. Erstgespräch kostenlos: wenn's nicht passt, hast du nichts verloren.
Der Klassiker in Programmieren II: dynamische Bindung. Wir trennen sauber, was der Compiler erlaubt und was zur Laufzeit passiert.
Welche Ausgabe erzeugt der folgende Code? Begründe, warum, mit Blick auf statischen und dynamischen Typ.
class Tier { String laut() { return "..."; } } class Hund extends Tier { String laut() { return "Wuff"; } } Tier t = new Hund(); System.out.println(t.laut());
Die Ausgabe ist Wuff: der statische Typ Tier erlaubt den Aufruf, der dynamische Typ Hund entscheidet, welche Methode läuft.
t hat den statischen Typ Tier. Der Compiler erlaubt nur Methoden, die Tier kennt. laut() existiert in Tier, also kompiliert es.
Zur Laufzeit zeigt t auf ein Hund-Objekt. Bei überschriebenen Methoden entscheidet der dynamische Typ, welche Implementierung läuft.
Hund überschreibt laut(), also wird Hund.laut() aufgerufen. Die Ausgabe ist Wuff. Das ist dynamische Bindung.
Der Compiler prüft den statischen Typ, die Laufzeit wählt die Methode über den dynamischen Typ. Bei Überschreibung gewinnt immer der dynamische Typ.
Genau das üben wir in deiner Session: statischen und dynamischen Typ sauber auseinanderhalten.
Wenn du jetzt anfängst und 4 bis 5 Sessions investierst, hast du gute Chancen. Weniger Zeit? Wir komprimieren. Mehr? Wir gehen tiefer, etwa in Design-Patterns oder funktionale Interfaces.
Du teilst Bildschirm, wir gehen deine letzte Übung und deinen Klausurstoff durch. Wir erkennen, wo du wirklich stehst, nicht wo du glaubst zu stehen.
Wir bauen Klassenhierarchien zusammen, klären abstrakte Klassen gegen Interfaces und üben dynamische Bindung am echten Beispiel deines Klausurstoffs.
Generische Methoden lesen und schreiben, die richtige Collection wählen und rekursive Aufgaben über den Aufrufbaum durchspielen. Du tippst, ich frage.
Du löst die Probeklausur deiner Uni unter Zeitdruck. Wir besprechen jede Aufgabe: was sitzt, wo du dich verzettelst und welche Aufgabentypen wahrscheinlich dran kommen.
Ich habe Study IT gebaut, weil ich selbst erlebt habe, wie IT-Lehre an der Hochschule auseinanderbricht.
Bei uns unterrichtet, wer Code aus echten Projekten kennt. Praxis entscheidet, nicht der Abschluss.
Direkt an mich: marcel.schmidtpeter@study-it.education
Vererbung, Interfaces, Generics und Rekursion aus echten Projekten statt Tutorials. Er macht typische Denkfehler sichtbar und zeigt, wie Prüfer:innen die Aufgaben bewerten.
„Programmieren versteht man, wenn man weiß, warum eine Lösung funktioniert. Mein Ziel: dass du Code nicht abschreibst, sondern selbst hinkriegst."
Wenn Programmieren II nicht der Engpass ist, passt vermutlich eine dieser Seiten besser.
Kostenloses Erstgespräch, 30 Minuten. Wir schauen auf deinen Stoff und sagen dir ehrlich, wie viele Sessions du brauchst.
