Array Objekte einer Klasse zuordnen

[James15225]

Ich will ein Mensa Verwaltungsprogramm schreiben. Ich will sehen wann ein Schüler in der Mensa essen war. Ich wollte wissen ob man folgende Methode so schreiben kann. Es gibt zwei Klassen. Einmal die Klasse "Schüler" und einmal die Klasse"Mensaschein",die über einen Array assoziert ist.

public void NeuerMensaEintrag(String datum){
int q=1;
mensaschein[q]=new Mensaschein(datum);
q=q+1;
}
Ich weiss nicht, ob die Methode so funktioniert wie ich es mir vorstelle. Also ich will das bei jedem Aufruf der Array um eins erhöht wird und das an der Stelle q dann ein Objekt von der Klasse Mensaschein gespeichert wird mit dem datum, dass man beim Aufruf der Methode übergeben hat. Kann man das so zuweisen?

 

[MoxxiManagarm]

Syntaktisch scheint es mir korrekt. Aber du initialisierst q immer beim Methodenaufruf mit 1. q wird also an der Stelle immer 1 sein und am Ende der Methode 2.

 

[Manuel.R]

nee....
immer wenn ein neuer MensaScheinEintrag kommt ist q=1 und das q=q+1 kanst du dir sparen....

wird die Methode aufgerufen ist q=1....

Guck dir mal an was Heap und Stack im Speichermodell von Java bedeuten.

 

[Manuel.R]

dynamisch einen Array erweitern heißt:
1.) nimm den alten Array --> hole dir die länge
2.) addiere die alte Länge plus 1
3.) erstelle einen neuen Array mit der neuen Länge
4.) kopiere die Daten aus dem alten Array in den neuen Array
5.) und setze die Referenzen korrekt, dass die Assoziationen erhalten bleiben

die Lösung ist die Verwendung einer ArrayList anstatt eines Arrays. Die Liste wächst automatisch (dynamisch) mit.

 

[mrBrown]

Guck dir mal an was Heap und Stack im Speichermodell von Java bedeuten.

Das hat hiermit aber überhaupt nichts zu tun und dürfte jeden Anfänger nur verwirren...

 

[Manuel.R]

wenn man objekt-orientiert entwickeln möchte.... und das ist der Anspruch an die Mensa-Verwaltung (Schüler und Schein) kann man sich auch damit beschäftigen, warum das q immer wieder 1 ist wenn ein neues Objekt hinzugefügt wird.

Dazu gehört vielleicht auch das Verständnis zu Call by Value und -Reference....

Einfach nur immer los-coden ist auch nicht immer richtig.....

 

[Flown]

wenn man objekt-orientiert entwickeln möchte.... und das ist der Anspruch an die Mensa-Verwaltung (Schüler und Schein) kann man sich auch damit beschäftigen, warum das q immer wieder 1 ist wenn ein neues Objekt hinzugefügt wird.

Dazu gehört vielleicht auch das Verständnis zu Call by Value und -Reference....

Einfach nur immer los-coden ist auch nicht immer richtig.....

Das hat einfach was mit Scoping zu tun

 

[mrBrown]

wenn man objekt-orientiert entwickeln möchte.... und das ist der Anspruch an die Mensa-Verwaltung (Schüler und Schein) kann man sich auch damit beschäftigen, warum das q immer wieder 1 ist wenn ein neues Objekt hinzugefügt wird.

Vielleicht solltest du dich mal mit damit auseinandersetzen, die '1' ist nicht mal ein Objekt

Und relevant, ob Heap oder Stack, ist hier nicht. Das ist nur Scope und Deklaration.

Dazu gehört vielleicht auch das Verständnis zu Call by Value und -Reference....

Ehrlich gesagt fällt mir grad kein Beispiel ein, bei dem ich da in der letzten Zeit drüber nachgedacht hätte oder es eine Rolle gespielt hätte...
"Call by Value" wird halt auch für Objekte benutzt, auch wenn da eine Referenz auf das Objekt übergeben wird
Der Unterschied Mutable/Immutable ist da relevanter...

 

[Manuel.R]

Das hat einfach was mit Scoping zu tun

..... und der Scope hat nichts mit dem Stack oder Heap zu tun? ... das q kein Objekt ist, ist mir auch klar....

und call by ..... ist in soweit relevant, dass im Verlauf der Anwendung Objekte angepasst werden sollen... gerade bei der Funktion "neuerMensaSchein(...)" Neben dem Datum für den neuen Schein müsstest du der Methode auch den passenden Schüler mit übergeben, der den Schein erhalten soll. Der Schüler selbst kapselt eine Datenstruktur (Liste) von Mensascheinen, die nur ihm gehören.

Im Verlauf der Ausführung befindet sich die Methode und die lokalen Parameter im Stack. Wird die Ausführung beendet, verlassen die Daten den Stack (sie sind einfach weg)... "ja sie verlassen dann auch den sichtbarkeitsbereich (Scope)"
Was bleibt von der Erkenntnis ist, dass alles was du in der Methode gemacht hast, weg ist, ausser du übergibst der Methoden Objektreferenzen, die die Änderungen auf eine bestimmte Dauer speichern.

 

[Manuel.R]

Ein Möglichkeit wäre auch zu sagen, das Schüler-Objekt selbst besitzt die Funktion einen Mensaschein zu seiner Liste hinzuzufügen.

class Schueler{

private String id;
private String vorname;
private String nachname;

private List<MensaSchein> mensascheine;

//constructor

//getter + setter

//Methode für das Hinzufügen und Entfernen eines Mensascheins

//überschreiben von equals und hashcode 

}

 

[mrBrown]

..... und der Scope hat nichts mit dem Stack oder Heap zu tun?

Nicht so, dass es irgendwie relevant für einen Einsteiger ist (oder auch für einen Fortgeschrittenen)

und call by ..... ist in soweit relevant, dass im Verlauf der Anwendung Objekte angepasst werden sollen... gerade bei der Funktion "neuerMensaSchein(...)" Neben dem Datum für den neuen Schein müsstest du der Methode auch den passenden Schüler mit übergeben, der den Schein erhalten soll. Der Schüler selbst kapselt eine Datenstruktur (Liste) von Mensascheinen, die nur ihm gehören.

Alles in Java ist call-by-value.
Hat aber auch mit deinem Beispiel nicht wirklich was zu tun.

Im Verlauf der Ausführung befindet sich die Methode und die lokalen Parameter im Stack. Wird die Ausführung beendet, verlassen die Daten den Stack (sie sind einfach weg)... "ja sie verlassen dann auch den sichtbarkeitsbereich (Scope)"
Was bleibt von der Erkenntnis ist, dass alles was du in der Methode gemacht hast, weg ist, ausser du übergibst der Methoden Objektreferenzen, die die Änderungen auf eine bestimmte Dauer speichern.

Ob sie den Stack verlassen oder nicht ist völlig irrelevant für diesen Anwendungsfall und auch ziemlich missverständlich. Objekte liegen erstmal im Heap, und nicht auf dem Stack - auch als Parameter oder lokale Variable.

Relevant ist da nur, ob das Objekt/der primitive Wert noch irgendwie erreichbar ist. Und das hängt maßgeblich vom Scope ab, und nicht davon, ob es auf'm Stack oder Heap liegt.

(Die "Java-Bible" Effective Java erwähnt Stack und Heap in dem Kontext immerhin Null mal, scheint also echt wesentlich zu sein )

 

[Flown]

..... und der Scope hat nichts mit dem Stack oder Heap zu tun? ... das q kein Objekt ist, ist mir auch klar....

Scoping ist in diesem Kontext unabhängig von Stack oder Heap, das sind dann nur Implementierungsdetails.

 

[Manuel.R]

Nicht so, dass es irgendwie relevant für einen Einsteiger ist (oder auch für einen Fortgeschrittenen)
Alles in Java ist call-by-value.

Das ist und wird immer ein Streit-Thema bleiben was Java hier macht.....

Ob sie den Stack verlassen oder nicht ist völlig irrelevant für diesen Anwendungsfall und auch ziemlich missverständlich. Objekte liegen erstmal im Heap, und nicht auf dem Stack - auch als Parameter oder lokale Variable.

sind jedoch nie erreichbar.... --> Man könnte aus Spaß untersuchen, ob ein wiederholtes Ausführen der Methode zu einem Speicherproblem führt (Memory Leak). immer wieder einen Mensaschein erzeugen. Die Referenzen sind an das ausführende Objekt gebunden und es besteht kein Zugriff.

Relevant ist da nur, ob das Objekt/der primitive Wert noch irgendwie erreichbar ist. Und das hängt maßgeblich vom Scope ab, und nicht davon, ob es auf'm Stack oder Heap liegt.

Jeder Thread eines Programmes erhält für den Stack einen eigenen Speicherbereich mit fixer Größe zugewiesen. Darauf werden Informationen zum Programmablauf (z.B. Funktionsparameter) und lokale Variablen gespeichert. Beim Anlegen neuer lokaler Variablen wächst der Stack an und beim Verlassen des Sichtbarkeitsbereichs ("Scope") schrumpft er wieder und der Speicher wird automatisch aufgeräumt.

Der Scope ist durch die Methode definiert. Beim Verlassen der Methode besteht kein Zugriff mehr auf die lokalen Variablen der Methoden. Ein erneutes Aufrufen führt zur erneuten Erstellung der jeweiligen Variablen und Objekte.

Scheißegal wie, der Mensaschein aus der Methode ist weg und der Schüler muss hungern und alles nur weil nicht jeder den Schein sieht als lokale Variable.......

 

[mrBrown]

Das ist und wird immer ein Streit-Thema bleiben was Java hier macht.....

Was Java macht ist eigentlich ziemlich klar.
Streitfrage ist nur, was call-by-reference meint, und den meisten Definitionen nach, wird es in Java nicht benutzt.

sind jedoch nie erreichbar.... --> Man könnte aus Spaß untersuchen, ob ein wiederholtes Ausführen der Methode zu einem Speicherproblem führt (Memory Leak). immer wieder einen Mensaschein erzeugen. Die Referenzen sind an das ausführende Objekt gebunden und es besteht kein Zugriff.

Der erste und letzte Satz ist etwas unverständlich.

Zum Mittelteil: probiers aus und du wirst kein eindeutiges Ergebnis bekommen. Ist, wie schon gesagt wurde, Implementierungsdetail.

Jeder Thread eines Programmes erhält für den Stack einen eigenen Speicherbereich mit fixer Größe zugewiesen. Darauf werden Informationen zum Programmablauf (z.B. Funktionsparameter) und lokale Variablen gespeichert. Beim Anlegen neuer lokaler Variablen wächst der Stack an und beim Verlassen des Sichtbarkeitsbereichs ("Scope") schrumpft er wieder und der Speicher wird automatisch aufgeräumt.

Das hast du sehr schön erklärt. Ist aber, wie schon gesagt wurde, zum Teil auch Implementierungsdetail und für den Programmierer normalerweise nur relevant, wenn's nen Stackoverflow gibt.

Der Scope ist durch die Methode definiert. Beim Verlassen der Methode besteht kein Zugriff mehr auf die lokalen Variablen der Methoden. Ein erneutes Aufrufen führt zur erneuten Erstellung der jeweiligen Variablen und Objekte.

Scope ist nicht nur durch Methoden definiert, sondern auch jedes if, jede Schleife und jeder Block haben einen einem eigenen Scope.

Scheißegal wie, der Mensaschein aus der Methode ist weg und der Schüler muss hungern und alles nur weil nicht jeder den Schein sieht als lokale Variable.......

Und das, obwohl der Mensaschein auf dem Heap liegt

 

[James15225]

Ok ich bin euch sehr dankbar für eure Antworten, muss aber sagen, dass ich nicht alles verstanden habe. Also ich habe verstanden, dass q beim Methodenaufruf immer wieder auf 1 initialisiert wird und deshalb nicht über 2 geht. Kann mir dann vielleicht jemand ein konkretes Beispiel geben, wie man ein Array dynamisch um eins steigert.

 

[Javinner]

Ok ich bin euch sehr dankbar für eure Antworten, muss aber sagen, dass ich nicht alles verstanden habe. Also ich habe verstanden, dass q beim Methodenaufruf immer wieder auf 1 initialisiert wird und deshalb nicht über 2 geht. Kann mir dann vielleicht jemand ein konkretes Beispiel geben, wie man ein Array dynamisch um eins steigert.

#4 @Manuel.R hat es dir bereits in Schritten aufgeführt, was in diesem Fall zu tun wäre.
In seinem Post #10 hat er eine Klasse gepostet, die würde ich ausbauen