static, non-static Krise

[k3ltis]

Hallo liebe Leute,

ich habe ein konkretes Problem, bei dem ich nicht weiß, ob ich es "static" oder "non-static" machen soll. Ich kenne mich mit der Materie gut genug aus, um zu wissen, was static für Nachteile mit sich bringt - kenne aber auch die Vorteile.

Um zu verstehen was mein Problem ist, folgt nun eine Skizzierung der Klassen und Methoden, die daran beteiligt sind:

Class EnemieVerwaltung {
// verwaltet verschiedene arten von Gegnern,
// die in einem Array gespeichert werden

Enemie [] enemie; 
// Array vom Typ Enemie

public Enemie findeGegner(String name){
// Diese Methode sucht in dem Array enemie nach
// einem Objekt, zu dem der übergebene String name
// passt und gibt es zurück
}

}

Class WaveEnemies {

Enemie enemie;

// Diese Klasse speichert ein EnemieObjekt, von dem zunächst
// nur der name bekannt ist.
// Im Konstruktor wird dann folgendes passieren:

public WaveEnemies(String name){
//...
this.enemie = EnemieVerwaltung.findeGegner(name);
//...
}


}

So. Hier ist das Problem...
Ich müsste an JEDES WaveEnemies-Objekt eine Referenzvariable von EnemieVerwaltung
übergeben. Wenn ich die Methode "findeGegner(String name)" jedoch static mache - muss ich
zwangsläufig auch die Variable Enemie [] enemie; static machen - womit ich aber ein problem habe.

Was würdet ihr mir raten?


Edit: nicht dass es mir was ausmachen würde eine Referenzvariable einzurichten. Doch das wäre bei weitem nicht die einzige...
es gibt in dem Programm noch etliche Stellen an denen man den Referenzvaiablenwust durch ein simples static lösen könnte... es sieht langsam aber sicher ein wenig unübersichtlich aus...

 

[pzypher]

Ich würde mal behaupten, dass static weder Vor- noch Nachteile hat. Ob etwas static oder nicht sein soll/muss, ist in der Programmlogik eigentlich meist vorgegeben.

Ich nehme mal an, du benötigst nur ein Objekt bzw. kein Objekt der Klasse EnemieVerwaltung!? Wenn ja, dann erzeugst du entweder ein Objekt oder belässt die Klassenmember static.

Warum kannst du denn Enemie [] enemie nicht static machen?

 

[k3ltis]

Gute Frage, warum kann ich das nicht static machen?

Weil die ganze Welt immer gleich das Gesicht verzieht, wenn man etwas static macht, was man nciht unbedingt static machen muss. Das gilt vielleicht nicht bei Methoden, wohl aber bei Variablen.

Wenn mir ein allgemein "sauberer" Programmierstil schnurz wäre hätte ich diese Frage nicht gestellt... sondern das Ding einfach static gemacht, weil es die einfachere Lösung ist.

 

[nillehammer]

Mach es nicht static!

Allgemein gegen static spricht:

• Es verträgt sich nicht gut mit Vererbung (nur non-static Methoden können bspw. überschrieben werden)
• Man kann mit static Methoden keine Interfaces implementieren
• Durch den direkten Zugriff auf Klassen-Felder/-Methoden exportiert man die direkte Referenz auf die konkrete Implementierung. Das macht Codeänderungen schwieriger (höherer Anpassungsaufwand in Clientcode)
• Bestimmte Pattern lassen sich mit static nicht umsetzen
• Klassen mit static-Methoden lassen sich nicht für Dependency-Injection verwenden

EnemyVerwaltung

klingt nach einer Klasse, die zentrale Services erbringt (enemies finden, hinzufügen, löschen...). Definier Dir dafür ein Interface, das alle Methoden Vorschreibt, die Du brauchst:

public interface EnemyVerwaltung {

  /**
    * @return true, wenn enemy geadded werden konnte, sonst false
    */
  // "public Enemy" ;-))
  public boolean addeGegner(Enemy enemy);

  /**
    * @return einen Enemy nach seinem namen, null, wenn name invalid
    */
  public Enemy findeGegner(String name);

  /**
    * @return den gelöschten Enemy nach seinem namen, null, wenn name invalid
    */ 
  public Enemy loescheGegner(String name);
}

Lasse Deine Array-basierte Implementierung das Interface implementieren. Und programmier dann nur gegen das Interface.

Wofür der Aufwand? Du hast dann in Deinem Code nur Aufrufe auf Interface-Methoden. Die Implementierung dahinter kannst Du transparent austauschen. Unrealistisch? Du wirst vielleicht in zwei Wochen über das Map-Interface stoßen und merken, dass es mit Maps besser geht als mit Arrays. Schon hast du eine neue Implementierung. In einem Monat ist das Spiel so gut, dass Du gerne die Daten persistent speichern möchtest, vielleicht mit Datenbank. Wieder eine neue Implementierung...

Ist das Grund genug, warum man sehr viel seltener static Felder/Methoden benutzen sollte, als man es gemeinhin sieht?

 

[k3ltis]

Das ist nicht nur Grund genug, du hast mich absolut überzeugt!

Danke dafür!

p.s.: und danke für die rechtschreibkorrektur