Gestaltungsorientierte Informatik

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige ÜberarbeitungVorherige Überarbeitung
Nächste Überarbeitung
Vorherige Überarbeitung
textadventure:wiederhole_dich_nicht [2026/05/20 22:41] – celandirtextadventure:wiederhole_dich_nicht [2026/05/28 09:04] (aktuell) – celandir
Zeile 51: Zeile 51:
 waldlichtung() waldlichtung()
 </file> </file>
 +
 +<div todo>
 +Führe das Programm mit Thonny mehrmals aus und mache unterschiedliche Eingaben. Fasse zusammen, was Du beobachtest.
 +</div>
 +
 +Möglicherweise ist dir aufgefallen, dass die Programmausführung nun nicht mehr endet, weil man immer zwischen den drei bzw. vier Orten hin- und herläuft, aber dazu später. Erstmal ist wichtig, dass das Programm nun anders strukturiert ist. Es gibt für jeden Ort eine eigene **Funktion**. Diese wird mit dem „Schlüsselwort“ ''def'' eingeleitet, dann folgt der Name der Funktion und schließlich Klammern und ein Doppelpunkt. Die Klammern, das weißt du schon, stehen für die Parameter. Unsere Funktionen haben aktuell keine Parameter, also sind die Klammern leer – sie dürfen aber nicht fehlen. Der Doppelpunkt schließt den „Funktionskopf“ ab. Der folgende, eingerückte Block von Anweisungen bildet den „Funktionsrumpf“. Er wird immer ausgeführt, wenn irgendwo im Programm diese Funktion aufgerufen wird. 
 +
 +Der Funktionsaufruf in Zeile 44 ist notwendig, damit das Programm irgendwo startet. Solange eine Funktionsdefinition nur so im Programmtext steht, passiert gar nichts. Der Interpreter würde dann feststellen „Aha, es gibt also die Funktion …“, aber ausgeführt wird sie erst, wenn irgendwo ein **Funktionsaufruf** steht. Dass der Funktionsaufruf am Ende des Programmes steht, liegt daran, dass vorher die Funktionen noch nicht bekannt sind. Der Interpreter arbeitet immer von oben nach unten. Die Funktionsdefinitionen werden also erst „zur Kenntnis genommen“, danach kann man sie aufrufen. Der Python-Interpreter prüft dabei erst **zur Laufzeit**, also wenn eine Anweisung konkret ausgeführt wird, ob es die Funktion auch wirklich gibt. Deshalb kann die Funktion ''flussufer()'' in der Funktion ''waldlichtung()'' aufgerufen werden, obwohl ''waldlichtung()'' vor ''flussufer()'' im Programmtext steht. Zu dem Zeitpunkt, wo ''flussufer()'' aufgerufen wird, hat der Interpreter die Funktionsdefinition schon einmal eingelesen.
 +
 +<div todo>
 +Ändere das Programm so, dass der Funktionsaufruf von ''waldlichtung()'' nicht am Ende des Programmtextes steht, sondern hinter der Definition von ''flussufer()'' und vor der Definition von ''dunlerWald()'' (Zeile 28). Starte das Programm, bewege dich ein wenig durch die Landschaft und beobachte, was passiert. Erkläre die Beobachtung.
 +</div>
 +
 +In jedem der drei „richtigen“ Orte gibt es nun eine Ortsbeschreibung und dann eine anpasste Eingabe nach dem bekannten Muster. Dabei wird jetzt aber in den Zweigen der Fallunterscheidung nur mehr die jeweils passende Funktion aufgerufen. Damit kannst du jetzt auch ein komplexeres „Dungeon“ aufbauen. 
 +
 +<div todo>
 +Ändere die Programmierung so, dass man das Programm an irgendeinem Ort beenden kann. 
 +</div>
 +
 +<div todo>
 +Schreibe nun dein Textadventure so um, dass du Funktionen verwendest.
 +</div>
 +
 +Vielleicht ist Dir aufgefallen, dass es eine weitere „Chance“ gibt, wiederkehrende Programmierung  in einer eigenen Funktion auszulagern? Gemeint ist die Eingabe, die auch immer zumindest ähnlich ist. Wenn du magst, kannst du gerne jetzt schon versuchen, eine eigene „Eingabe-Funktion“ zu definieren. Wir kommen sonst später darauf zurück.
 +
 +Link zum Python-Handbuch: [[https://openbook.rheinwerk-verlag.de/python/19_001.html#u19.1]]
 +
 +Nächste Lektion: [[inventar|Ich packe in meinen Rucksack]]
textadventure/wiederhole_dich_nicht.1779309672.txt.gz · Zuletzt geändert: von celandir