Statische Variablen von Objekten im Array

[Kanitrino]

Hallo Experten,

Ich möchte ein Spiel auf einer Art Schachbrett programmieren.

Dazu habe ich eine Klasse "Feld" geschrieben und eine Klasse "Brett". Letztere enthält einen Array

Feld[][] feld = new Feld[x][y]

Die einzelnen Feld-Objekte werden in einer Schleife initiiert mit

feld[i][j] = new Feld(..)

Nun gibt es in der Klasse "Feld" einige Variablen, die nur für das jeweilige Feld gelten, und andere, die für alle Felder gelten, die also statische Variablen der Klasse "Feld" sind. Diese statischen Variablen kann ich aber nun schlecht über den Konstruktor eingeben, da sie nur ein Mal benötigt werden. Ich behelfe mir über statische Setter-Methoden in der Klasse "Brett" (z. B.

public static void setBreite(int breite);

usw.

Frage : Ist das der Stand der Technik oder geht es nicht besser?
Sollten nicht die wichtigsten Variablen über den Konstruktor eingegeben werden, damit klar ist, dass sie zur Bildung eines Objekts benötigt werden ? Kann man sie vielleicht so in der Art

"Feld[][] feld = new Feld[x][y](int breite,...)"

eingeben ? Oder denke ich da zu formalistisch ?

 

[Guest]

Also "Stand der Technik" sind statische Methoden und Member nun nicht gerade, man sollte versuchen möglichst ohne sie auszukommen.

Die Frage die ich mir stelle: brauchen die Felder wirklich die Information über ihre Größe?

 

[Kanitrino]

Natürlich, auch eine Farbe, sie sollen sich ja hinterher selbst zeichnen.

Aber das war ja auch nur ein Beispiel. Das grundsätzliche Problem ist aber, dass manche Variablen für jedes Feld anders sind und manche für alle geich.

 

[diggaa1984]

na wo genau wäre da das problem, du hast statisches zeug für alle felder und den konstruktor für den rest.

@sollen sich selber zeichnen: Du könntest das auch in eine externe klasse auslager, die das zeichnen übernimmt, in der kannst du quasi nen setup vornehmen in der du die einstellungen zum zeichnen vorgibts, so auch breite und farbe, eventuell in abhängigkeit von nem Feldtypen, wenn du versch. hast, oder vom Status eines Feldes.

 

[Guest]

Das sich die Felder selber zeichnen ist wirklich keine gute Idee. Die Felder sollten nur Status-Informationen tragen, quasi das "Model" sein.

Das Zeichnen sollte das Brett übernehmen. Nur das Brett braucht zu wissen, wie groß ein Feld ist, da nur das Brett die Felder zeichnet.

 

[Kanitrino]

Eigentlich geht es um Hasen, die Gras fressen. Die aktuelle Graslänge auf dem Feld ist eine individuelle Größe jedes Feldes, die Wachstumsgeschwindigkeit und die maximale Länge eine universelle Eigenschaft. Für die Hasen ist die gefressene Grasmenge (Energie) individuell, der tägliche Verbrauch und die Sättigungsmenge eine (statische) Konstante.

Wen's interessiert - ich habe so was mal für Mammuts gemacht (http://www.kanitrino.de/PageDE/CroMagnon.html ), aber nun wollte ich es mal besser, d.h. so objektorientiert wie möglich machen.

 

[fehlerfinder]

Also "Stand der Technik" sind statische Methoden und Member nun nicht gerade, man sollte versuchen möglichst ohne sie auszukommen.

Mmh? Was spricht gegen statische Methoden und Attribute? In Maßen natürlich bzw. wo sie Sinn machen. Aber grundsätzlich sind die doch nicht "veraltet" (von wegen "Stand der Technik").
Es ist nur eben so, dass beim Einstieg in OOP schonmal übersehen wird, dass es den Grundsätzen der OOP widerspricht, wenn man ALLE Variablen statisch definiert (also das macht wirklich überhaupt keinen Sinn...)

Also: statische "Elemente" (Methoden und Attribute) sind absolut "Stand der Technik". Der Einsatz muss halt sehr sorgfältig überlegt sein. Und eine Variable oder auch Konstante, die für alle Objekte einer Klasse identisch ist, ist nunmal statisch und gehört nicht in die Instanz.

 

[diggaa1984]

Wen's interessiert - ich habe so was mal für Mammuts gemacht (http://www.kanitrino.de/PageDE/CroMagnon.html ), aber nun wollte ich es mal besser, d.h. so objektorientiert wie möglich machen.

Hm wenn du das schon hast, gibts da nix konzeptionelles was dir nun hilft die Klassen und Interaktionen auf OOP-Ebene zu bestimmen? So'n richtiges Problem wurde ja bisher noch nicht genannt
Der Ablauf der Simulation dürfte ja nicht das Problem sein, vermutlich dann eher die ganzen Beziehungen zwischen den Klassen oder? Könntest ja mal deine Vorstellung detaillierter beschreiben, dann könnte man eher sagen was im Sinne von OOP passt und was nicht.

 

[Marco13]

Allgemein: Statische Methoden sind nicht schlimm. Die hier schon mehrfach erwähnte Faust (oder Daumen, oder sonstige) Regel könnte sein:
- Methoden macht man statisch, wenn man sie ohne Krämpfe statisc machen KANN
- Fields macht man statisch, wenn man sie unbedingt statisch machen MUSS

Und man muss (und sollte) Fields nur SEHR, SEHR selten static machen (außer static final -> Konstanten). Wenn du irgendwann man zwei Felder mit unterschiedlichen Gras-Wachstums-Geschwindigkeiten haben willst (z.B. wegen verschiedener Boden-Qualitäten oder so...), ist das mit dem statischen Wert halt blöd :? Eine Möglichkeit könnte(!) sein, die Wachs-Geschwindigkeit einfach abzufragen...

class Feld
{
    private static int MAX_GROWTH_SPEED = 10;

    public int getMaxGrowthSpeed() { return Feld.MAX_GROWTH_SPEED; }
}

Das kann man danach notfalls noch leicht individualisieren

class Feld
{
    private static int DEFAULT_MAX_GROWTH_SPEED = 10;

    private maxGrowthSpeed = Feld.DEFAULT_MAX_GROWTH_SPEED;

    public int getMaxGrowthSpeed() { return maxGrowthSpeed; }
    public void setMaxGrowthSpeed(int maxGrowthSpeed) { this.maxGrowthSpeed = maxGrowthSpeed; }
}

... das sind alles Dinge, die DU dir überlegen musst....



Aber... zur eigentlichen, ursprünglichen Frage: Irgendwie hab ich die nicht ganz kapiert. Wenn man 10 Objekte vom Typ "Feld" hat, wird man ja nicht 10 mal die(selbe, statische) Eigenschaft setzen - und schon garnicht über ein Objekt.

Also nicht

for (int i...)
{
    feld[i] = new Feld();
    feld[i].setNonStatic(foo);
    ...
    feld[i].setSomethingStatic(123); // NEIN!
}

sondern

for (int i...)
{
    feld[i] = new Feld();
    feld[i].setNonStatic(foo);
    ...
}
Feld.setSomethingStatic(123);

Aber ob's das war....?! ???:L

 

[Kanitrino]

for (int i...)
{
    feld[i] = new Feld();
    feld[i].setNonStatic(foo);
    ...
}
Feld.setSomethingStatic(123);

Aber ob's das war....?! ???:L

Genau das war die Frage : Habe ich irgend etwas übersehen, dass ich die statischen Werte
- entweder sinnloserweise 10 000 mal über den Konstruktor eingebe
- oder sie über eine statische Methode anstatt über den Konstruktor eingebe. Meine Bedenken bestehen darin, dass ich einen Wert erst eingeben muss (z. B. n = Anzahl von irgendwas), das ich dann bei der Objektbildung bereits brauche (z. B. zur Definition eines Arrays im Konstruktor). Für oben zitierten Java-Schnipsel müsste man Feld.setSomething(123) also vor der Schleife definieren, sonst wird ein Array mit 0 Elementen festgesetzt. Dies kommt mir etwas unelegant vor.

Wie ich aber der bisherigen Diskussion entnehme, ist letzeres durchaus üblich.

****
Zur Frage, was ich OOP-mäßig überhaupt erreichen will :

1. In der ersten Fassung habe ich alle Eigenschaften (z. B. alter der hasen, energie, graslänge,...) jeweils als 2-dimensionalen Array - der das Spielbrett mit x*y Feldern wiedergibt - verwaltet (alter[x][y],...) . Das funktioniert zwar, weil alle diese Array-Elemente durch dieselben Indices angesteuert werden, es erscheint mir aber nur begrenzt genial zu sein.

Es sollte doch besser sein, alle Eigenschaften in eine "Feld"-Klasse zu stecken und aus dieser dann einen Array feld[][] zu machen.

2. Auf o. g. Homepage (irgendwann raff' ich das vielleicht auch noch mit den Links) gibt es noch andere Varianten, z.B. Wator, bei dem Haie Fische fressen. Im Gegensatz zum Gras bewegen die Fische sich aber.

Anstatt alles neu zu programmieren, wäre es doch schön, einen Teil der Klassen wiederverwenden zu können. Dazu muss das Programm aber gut aufgebaut sein. Und daran arbeite ich gerade.

 

[Guest]

Also "Stand der Technik" sind statische Methoden und Member nun nicht gerade, man sollte versuchen möglichst ohne sie auszukommen.

Mmh? Was spricht gegen statische Methoden und Attribute? In Maßen natürlich bzw. wo sie Sinn machen. Aber grundsätzlich sind die doch nicht "veraltet" (von wegen "Stand der Technik").

Ich habe ja nicht gesagt, daß es ein "Fehler" ist mit statischen Methoden und Attributen zu arbeiten, man sollte sie aber wenn möglich vermeiden. Der Threadsteller wollte ja wissen, ob sein Ansatz "Stand der Technik" ist, also ob man das heute "für gewöhnlich so macht" und das sehe ich eben nicht so.

Ein Problem ist z.B. daß die Breite der Felder an jeder beliebigen Stelle im Programmcode mittels der statischen Methode geändert werden kann, also nix is mit "data hiding".

 

[diggaa1984]

Auf o. g. Homepage (irgendwann raff' ich das vielleicht auch noch mit den Links) gibt es noch andere Varianten, z.B. Wator, bei dem Haie Fische fressen. Im Gegensatz zum Gras bewegen die Fische sich aber.

Anstatt alles neu zu programmieren, wäre es doch schön, einen Teil der Klassen wiederverwenden zu können. Dazu muss das Programm aber gut aufgebaut sein. Und daran arbeite ich gerade.

Das wäre natürlich super wenn du das so hinbekommst, müsstest dann aber mehr Schnittstellen reinbringen.
Quasi sowas wie "Futter" "Population" (welche Futter braucht) .. eventuell noch anderes. Und über diese Schnittstellen könntest quasi dann die jeweiligen Sachen implementieren

- Population muss "Futter" suchen um Energie zu bekomme, ob Futter nun Gras, Fisch oder Algen sind, muss in dem moment egal sein (Mammut, Haie, Kühe etc. implementieren oder erweitern Population)
- Futter wird von der Population benötigt, und verfügt dann über Sachen wie Wachstumsrate, Nährwert (zB 2 Energie statt 1) und was man sonst noch braucht (Gras, Fische würden nun Futter implementieren oder erweitern je nach Umsetzung)

Und im Hintergrund arbeitet eine Engine, welche alles steuert. Die wird eh immer wieder angepasst werden. Wenn dein Futter nun also Fische sind und die sich bewegen, dann baust das in die Engine rein, wenns Gras ist, gibts eben nur keine Bewegung. Auch die Engine könnte in dem Falle über das Interface/abstrakte Klasse aufs Futter zugreifen. Der Engine ist es auch egal obs Fische sind oder nicht, sie sieht nach aussen nur den Typ Futter, und dann wird fest implementiert wie sich das verhält.

 

[fehlerfinder]

man sollte sie aber wenn möglich vermeiden

Ist schon richtig - aber nicht, weil statische Methoden/Attribute etwa veraltet seien, sondern weil es manchmal eben passt und manchmal nicht. Das hat Kanitrino aber auch wohl verstanden.

"Stand der Technik"[...]"für gewöhnlich so macht" und das sehe ich eben nicht so.

Das sind aber zwei unterschiedliche Dinge. Natürlich definiert man nicht wahllos "für gewöhnlich" alles einfach als statisch, dennoch gibt es - völlig zu Recht - in Java die Möglichkeit, Methoden und Attribute statisch zu definieren. Wenn du z.B. ein Billard-Spiel programmierst, wirst du vermutlich irgendwann mal den Durchmesser einer solchen Kugel benötigen. Der ist für alle Kugeln gleich und wird deswegen statisch definiert. Wenn du dem Benutzer dann anbieten möchtest, das Spiel in der Medizinball-Variante (bei der dann mit Zaunpfählen als Queue gearbeitet wird ;-) ) zu spielen, wird eben einfach nur einmal der Klassen-Durchmesser (eben statisch) verändert. Ich hatte gerade kurz überlegt, ob das evtl. auch mit einer - zwischengeschalteten - Klasse "AllgemeineKugel" zu lösen wäre, in der dann der Durchmesser "nicht-statisch" definiert ist. Aber auch dann ist ja der Durchmesser in allen Instanzen separat gespeichert. Oder?

Ein Problem ist z.B. daß die Breite der Felder an jeder beliebigen Stelle im Programmcode mittels der statischen Methode geändert werden kann, also nix is mit "data hiding".

Das wiederum ist ja unabhängig von statisch oder nicht statisch. Gut, wenn du die Feldbreite nicht-statisch definierst, wird eben nur die Breite eines einzelnen Objekts verändert - aber durchaus auch "an jeder beliebigen Stelle im Programmcode". Dafür gibt's dann private, protected oder public.

 

[Guest]

Ein Problem ist z.B. daß die Breite der Felder an jeder beliebigen Stelle im Programmcode mittels der statischen Methode geändert werden kann, also nix is mit "data hiding".

Das wiederum ist ja unabhängig von statisch oder nicht statisch. Gut, wenn du die Feldbreite nicht-statisch definierst, wird eben nur die Breite eines einzelnen Objekts verändert - aber durchaus auch "an jeder beliebigen Stelle im Programmcode". Dafür gibt's dann private, protected oder public.

Nein, eben nicht an jeder beliebigen Stelle. Dazu muß das Objekt sichtbar sein und das sollte es nur für Programmteile, die dieses auch benutzen. Bei einem statischen Setter kommt man um das public nicht drumrum, es sei denn der Zugriff erfolgt nur in einem package, was wieder zu unschönen Design-"Zwängen" führt wie: alle Klassen XYZ müssen in einem Package liegen.

 

[Marco13]

Genau das war die Frage : Habe ich irgend etwas übersehen, dass ich die statischen Werte
- entweder sinnloserweise 10 000 mal über den Konstruktor eingebe
- oder sie über eine statische Methode anstatt über den Konstruktor eingebe.

Ne, das ist schon so....

Für oben zitierten Java-Schnipsel müsste man Feld.setSomething(123) also vor der Schleife definieren, sonst wird ein Array mit 0 Elementen festgesetzt. Dies kommt mir etwas unelegant vor.
Das ist eben die Eigenschaft von Variablen (nicht nur von statischen) : Sie haben den Wert, der ihnen zuletzt zugewiesen wurde..... :roll:



1. In der ersten Fassung habe ich alle Eigenschaften (z. B. alter der hasen, energie, graslänge,...) jeweils als 2-dimensionalen Array - der das Spielbrett mit x*y Feldern wiedergibt - verwaltet (alter[x][y],...) . Das funktioniert zwar, weil alle diese Array-Elemente durch dieselben Indices angesteuert werden, es erscheint mir aber nur begrenzt genial zu sein.
Es ist SEHR begrenzt genial :wink:

Es sollte doch besser sein, alle Eigenschaften in eine "Feld"-Klasse zu stecken und aus dieser dann einen Array feld[][] zu machen.
Ist es. Die Entscheidung, ob "maximaleWachsGeschwindigkeit" eine Eigenschaft eines jedes einzelnen Feldes ist, oder sie (statisch) für die ganze Klasse immer gleich sein soll, musst du treffen.

 

[Guest]

Also um mal aufs Thema zurückzukommen:
Ich weiß ja nicht, aber wäre es nicht am einfachsten, wenn schon als Attribut gespeichert, die Ausmaße in zwei Variablen zu definieren die konstant sind, will heißen:

public static final int WIDTH = 20;
public static final int HEIGHT = 20;

Aber wenn du sowieso schon die Felder selbstzeichnend haben willst, dann bietet es sich eigentlich an, die Klasse Feld von z.B. JPanel abzuleiten. Dann einfach die paintComponent überschreiben. Die Größe könnte man hier dann auch durch überschreiben der Methoden wie getSize(), getMaximumSize() oder getMinimumSize() regeln, sodass das Brett, das dann ein Container wäre, automatisch alles bei Benutzung eines Layoutmanagers richtig anordnet und skaliert.
hth

Gruß

taouri