Instanzmethoden

Schreibe eine Klasse Jar mit einem int-Feld fill, einem Konstruktor Jar(int n), der fill = n; setzt, und einer Instanzmethode void bump(), die fill = fill + 1; ausführt. In Pine behalte Main und baue ein jar mit Jar j = new Jar(3);, rufe j.bump(); auf, dann schreibe j.fill. Halte beide Typen in derselben Lehrdatei, damit dotnet run einfach bleibt. Starte mit dotnet run. Der Bildschirm sollte eine Zeile zeigen: 4. Die Methode läuft auf diesem einen Objekt und ändert sein Feld. Eine Methode über die Objektvariable aufzurufen, ist das Lehrziel dieser Seite. Behalte den öffentlichen Startklassennamen Pine.

Eine Methode, die zum Objekt gehört

Auf den früheren Methodenseiten hast du einen Namen aus Main ohne Objekt davor aufgerufen. Hier sitzt die Methode an der Klasse, aber du erreichst sie über eine jar-Variable: j.bump(). Dieser Aufruf nutzt die Felder des jars, das j benennt. Ein zweites jar behält sein eigenes fill.
Öffne die Pine-Datei. Der Startklassenname bleibt Pine. Diese Seite benennt den Starter nicht um. Lösche jeden übrig gebliebenen Tin t = new Tin(7);, falls dieser this-Seiten-Aufruf noch alles ist, was in Main steht. Lösche jede übrig gebliebene Tin-Klasse. Lösche jede ReadLine-Zeile. Die Datei, die du behältst, wartet nicht auf Tippen.
Außerhalb der geschweiften Klammern von Pine — noch in derselben Datei — schreibe public class Jar. Innerhalb der Klammern deklariere int fill;. Schreibe den Konstruktor Jar(int n) { fill = n; } mit unterschiedlichen Namen, damit diese Seite kein this braucht. Dann schreibe die Instanzmethode: void bump() { fill = fill + 1; }. In Jar gibt es auf dieser Seite kein Main. Speichere die Datei vor dem Lauf.
Die Methodenkopfzeile braucht void, weil bump keinen Wert zum Schreiben zurückgibt. Der Konstruktor hat weiterhin kein void — halte diesen Unterschied klar.

Pine baut ein jar und ruft bump auf

Pine behält public static void Main(). Innerhalb von Main schreibe drei Zeilen der Reihe nach: Jar j = new Jar(3);, dann j.bump();, dann Console.WriteLine(j.fill);. Der Konstruktor speichert 3. Der Aufruf j.bump() addiert eins. Die Schreibzeile zeigt den neuen Wert. Auf dieser Seite schreibst du nicht Tin t = new Tin(7);. Das war die this-Lektion.

Lies die behaltene Datei von oben. using System; bereitet kurze Namen vor. public class Pine ist der Starter. public static void Main() ist der Einstieg der Laufzeit. Der Ausdruck new Jar(3) baut ein jar und speichert 3 in fill. Der Aufruf j.bump() betritt bump auf demselben Objekt. Der Körper schreibt fill = fill + 1, also wird fill zu 4. Dann schreibt Main j.fill und der Bildschirm zeigt 4.
Führe es mit dotnet run aus. Das Programm schreibt eine Zeile und stoppt. Es wartet nicht auf deine Eingabe. Wenn dotnet run wartet, steckt ReadLine noch in der Datei. Lösche diese Zeile und behalte in Pine new Jar(3), j.bump() und die Schreibzeile, mit bump in Jar. Der Bildschirm zeigt 4. Zeigt der Bildschirm 7, läuft noch eine übrig gebliebene Tin-Demo. Zeigt der Bildschirm 3, fehlt der bump-Aufruf möglicherweise oder er läuft nach der Schreibzeile.
Schreibst du bump(); ohne j. davor, lehnt der Build in dieser Form von Main ab. Die Instanzmethode braucht ein Objekt. Schreibst du Jar.bump(); als wäre es ein static-Aufruf, ist das die Idee der nächsten Lektion — nicht dieser Seite. Behalte j.bump();.

Vergleich mit this und einfacher Feldzuweisung

Auf der this-Seite hast du im Konstruktor mit passenden Namen ein Feld gespeichert. Das funktioniert weiterhin. Diese Seite fügt eine Methode hinzu, die du später aufrufen kannst, nachdem das Objekt schon existiert. Ein übrig gebliebenes Tin t = new Tin(7); mit this.size = size; ist eine andere Lektion. Für diese Seite behalte Jar und Pine und j.bump();.
Du könntest in Main immer noch j.fill = j.fill + 1; schreiben. Diese Lektion verschiebt diese Änderung nach bump, damit das Objekt die Aktion trägt. Console.WriteLine(j); allein zeigt kein sauberes 4. Schreibe Console.WriteLine(j.fill);, um die gespeicherte Zahl zu sehen.

Zwei bumps auf einem jar

Du kannst j.bump(); zweimal aufrufen, bevor du schreibst. Starte mit new Jar(3), bump einmal auf 4, bump erneut auf 5, dann schreibe. Dieser Check passt in eine kleine zweite Pine-Demo.

Führe erneut mit dotnet run aus. Der Bildschirm sollte 5 zeigen. Jeder Aufruf von bump lief auf demselben Objekt und addierte eins mehr. Jar k = j; baut kein zweites Objekt — nutze zwei new Jar(...)-Aufrufe, wenn du zwei getrennte fills willst. Für diese Seite reichen zwei bumps auf einem jar, um die Methode zweimal laufen zu sehen.
Zeigt der Bildschirm noch 3, fehlen die bump-Aufrufe möglicherweise oder Main schreibt noch vor dem Aufruf. Zeigt er 7 oder eine andere Restzahl, steckt möglicherweise noch eine alte Tin-Demo in der Datei. Behalte new Jar(3) und die bump-Aufrufe.

Was diese Seite für static lässt

Diese Seite ruft die Methode über ein Objekt auf: j.bump(). Eine spätere Seite — static — zeigt Methoden und Felder, die zum Klassennamen selbst gehören, ohne Objekt davor. Bleib hier beim Instanzaufruf. Erfinde auf dieser Seite kein static void bump(), es sei denn, du kennst es schon; das Lehrziel ist der Aufruf am Objekt.
Verschachtele Jar nicht in den geschweiften Klammern von Pine. Auf dieser Seite sitzen die beiden Klassen als Geschwister in der Datei. Wenn der Build Jar beim Kompilieren von Pine nicht findet, prüfe, dass public class Jar in derselben Datei steht. Zeigt der Bildschirm 0, fehlt dem Konstruktor möglicherweise die Speicherung, oder bump läuft nie — behalte Jar(int n) { fill = n; } und j.bump(); vor der Schreibzeile.

Du kannst int fill; deklarieren, Jar(int n) { fill = n; } und void bump() { fill = fill + 1; } schreiben und aus Pine.Main Jar j = new Jar(3);, j.bump();, dann j.fill schreiben. Starte mit dotnet run. Der Bildschirm zeigt 4. Die Instanzmethode lief auf diesem Objekt und änderte sein Feld. Denk an bump als eine Aktion, die das jar nach seiner Existenz ausführen kann. Pine bleibt die Tür, die du mit dotnet run öffnest. Die nächste Seite ist static, wo manche Mitglieder zum Klassennamen gehören, ohne eine Objektvariable davor zu brauchen.
Behalte void an der Methode, nicht am Konstruktor. Behalte das Objekt vor dem Aufruf: j.bump();. Behalte die Schreibzeile auf j.fill. Diese drei Gewohnheiten sind der Checkpoint dieser Seite, bevor du weitergehst.