Du bist ein Opfer der wissenschaftlichen Korrektheit. Gleiche Problem wie in Mathe.
Überall werden Formeln und Beispiele hingeschmiert, mit der Meinung ein Anfänger lernt so am Besten.
Trotz ewiger extrem hoher Durchfallquoten macht sich keiner die Mühe die bisherigen Methoden anzuzweifeln.
Was ich damit sagen will, vergiss den Code, leg das Zeug erst mal zur Seite und lerne wie man lernt.
Überlege dir das Konzept und stelle es dir vor.
Was sind Objekte? In Java ist ein Objekt nix anderes als die "Kopie" einer Klasse, samt deren Feldern und Methoden.
Bei jedem new... wird einfach so eine "Kopie" einer Klasse in eine Variable gesteckt, über die man dann an deren Inhalt kommt.
Denke in Kisten, nicht in Code :>
In der Java API Doku rumschnüffeln ist besser als Anfänger Programmier Bücher zu büffeln. Wenn du genau hinschaust, siehst du wie Java strukturiert ist. Alles besteht aus Klassen (Objekten) die "kopiert" werden, oder per Vererbung erweitert werden. Erbt eine Klasse von einer anderen, so hat sie ihre eigenen Methoden und die der Oberklasse.
Und in Java gibt es keine wirklichen Funktionen, man simuliert sie nur indem man den Methoden ein static davor schreibt.
Was heißt das? Erstellt man von einer Klasse ein Objekt, also mit new..., dann ist es eine Kopie die unabhängig von den anderen Kopien ist, will heißen man kann in jedem Objekt Daten ändern ohne dass sie sich gegenseitig beinflussen können. Setzt man ein static davor, macht man diese Unabhängigkeit kaputt - man verlässt die Objektorientierung. Alle Änderungen an den Variablen sind dann in einer Box, alle Zugriffe darauf ändern direkt den Wert - egal von wo. Stell dir ein Logfenster vor. Will man aus allen Objekten in das gleiche Fenster schreiben, so wird das Fenster mit static programmiert. Kontrollmittel ob und wie sich etwas verhält hat man in Java mit "final" und "static".
Und das ist bei langem Code sehr übel, deswegen Objekte. Wenn da etwas nicht funktioniert, dann nur innerhalb eines kleinen Umfeldes. Ohne Objektorientierung kann alles mögliche an jeder Stelle alles mögliche verändern. Z.b. man hat 10.000 Funktionen die alle in das Logfenster schreiben. Dann taucht ein Fehler in der Log auf - tja, welche Funktion hat nun Mist gebaut? Mit Objekten peilt der Compiler das das sofort, dann müsste man keine 10.000 Funktionen durchgehen, sondern nur die 10 Methoden in dem Objekt.
Und weiter gehts. Abstrakte Klassen...tja was ist das wieder. In Java gibt es zwei "Platzhalter" für Methoden, wo man zum Zeitpunkt der Programmierung nicht weiß was es tun soll. Das sind Interfaces und die abstract Methoden/Klassen. Ist eine Methode abstract, dann auch die Klasse - dies verhindert dass man von unfertigen "Methoden" Objekte erzeugt. Methoden die abstract sind haben nur einen Kopf also "int test();"
Wozu ist das gut? Man will Eine Methode für einen PKW Hersteller schreiben, die Kosten für einen Wagen berechnet der in 1 Jahr gebaut wird. Man hat keine Ahnung was es kosten soll, kann aber schon mal die Struktur festlegen und das einbauen was man weiß. In 1 Jahr programmiert man das in einer Klasse aus, von der man dann wieder Objekte erzeugen kann. Man muss also gar nicht wissen was die 1 Jahr alte Klasse genau tut, man muss nur wissen was noch zu tuen ist
Wenn man dann von dieser Klasse erbt, also mit "extends" <abstrakte Klasse>, dann muss man den Kram der abstract ist implementieren, oder es erneut als abstract definieren und so das Problem weiter schieben :>
Interfaces bestehen nur aus solchen unfertigen Methoden, ist also ein Strukturierungsmittel. Abstrakte Klassen sind also eine Mischung aus "vollständigen" Methoden und Methoden Platzhaltern.
Dann weiter zur Rekursion. Man stelle sich vor bei jedem Aufruf der gleichen Methode wird eine neue "box" mit dem gleichen Code daneben gepackt. Der Code läuft von oben nach unten ab, was einmal abgearbeitet wurde, wird nicht erneut aufgerufen. Die Boxen werden so lange aneinander gereiht bis nicht ein Abbruchkriterum kommt, dass den erneuten Aufruf verhindert. Wenn dies passiert, kommt der JoJo Effekt. Die lezte Box überspringt also den Methoden Aufruf, und arbeitet den Code "unter" diesem Aufruf ab bis es zu einem return etc. kommt. Das return gibt einen Wert an die Box links daneben. In dieser Box läuft der Code auch weiter wo er aufhörte, d.h. unter dem Rekursionsaufruf. Das rollt dann rückwärts bis zu ersten Box. Wenn einem dies Klar ist, kann man z.b. eine Zahlenfolge vorwärts oder rückwärts ausgeben. Z.b. wird bei jedem Aufruf eine Variable inkrementiert. Ist der Output vor dem Rekursionsaufruf, wird er sofort ausgegeben. Ist er danach, wird erst die Variable der letzten Box ausgegeben, dann der vorlezten usw. Dieses Prinzip hat später große Bedeutung für Listen, Bäume und sonstigen schwierigeren Kram (PreOrder, PostOrder, InOrder...).
Hoffe du verstehst was ich sagen will. Lerne wie Dinge funktionieren, nicht wie man sie programmiert. Das programmieren ist die einfache Geschichte und dauert nicht lange wenn das Konzept klar ist. Besonders bei der Rekursion wird das klar. Ein Methodenaufruf und paar Variablen knocken im Studium reihenweise Leute aus.
Würden die Proffs auf wissenschaftliche Korrektheit pfeifen und mit Schuhkartons Beispiele bringen, würde kaum wer durchfallen. Wenn das Prinzip dann klar ist, dann man es immer noch wissenschaftlich definieren - aber nicht vorher.