Warum nicht static ?

[Major_Sauce]

Nabend,

ich führe hier gerade eine kleine Diskussion mit jemandem, der so ziehmlich überall static verwendet, wo er nur "kann".
Nun wurde mir immer eingeprügelt -> "static" = BÖSE.
Nun frage ich mich aber warum ist dass den eigentlich so ?
Ich weiß dass dadurch meißt die Kapselung stark vernachlässtigt wirde, die Sicherheit darunter leidet, aber was genau ist denn so schlimm an static ?
Ich weiß auch dass es durchaus Situationen gibt in denen man static benutzen sollte, sonst wäre das ganze ja nutzlos, aber wieso sollte ich es nicht einfach als Standart-modifier benutzen ?

mfg Major

 

[MWin123]

Mit einer Google Suche würdet ihr einen Haufen Argumente finden:

http://stackoverflow.com/questions/7026507/why-are-static-variables-considered-evil
http://stackoverflow.com/questions/2671496/java-when-to-use-static-methods
http://stackoverflow.com/questions/1766715/when-not-to-use-the-static-keyword-in-java

 

[ARadauer]

Solange eine Klasse keinen Zustand hat, finde ich es ok.. Irgendwelche Utility/Helper usw..
Aber wenn eine Klasse fachliche Attribute hat... Entitäten/VOs/TOs..... zb ein Kunden Objekt... dann auf keinen Fall... sollte klar sein...

Warum nicht irgendwelche Controller/Service/DAO Klassen statisch machen? Ganz klar: Testbarkeit..., Wiederverwendung, Parameterisierbarkeit, Struktur,

Bei irgendwelchen kleinen Anwendungen ist es im Grunde relativ egal, aber man soll sich auch bei kleinen Projekten "schönes Design" angewöhnen. Sonst fliegt mein bei größeren EnterpriseAnwendungen schnell mal auf die Schnauze ;-)

Ob nicht objektorientiert zu arbeiten jetzt "böse" ist, darüber lässt sich streiten... Es gibt andere mittel und Wege. Aber alles grundsätzlich static zu machen ist einfach nicht der Weg wie man in mit java gehen sollte.

 

[RalleYTN]

static kannst du immer bei allem verwenden, wovon es nur eins gibt. Kleines Beispiel: du möchtest eine Bibleotheck schreiben, die erweiterte Behandlungen von Exceptions anbietet. Da diese Bibleotheck nur Methoden hat wie:

• showDialog(Exception exception)
• print(Exception exception)
• writeLog(Exception exception, String file)
• sendLog(Exception exception, String to)

welche nur einmal existieren und deren Klassen nicht extra als Objekte erzeugt werden müssen, kannst du die Methoden statisch machen. Wenn du allerdings z.B. für ein Spiel eine Gegnerklasse definierst und du später mehrere Objekte davon erzeugst, dann solltest du alles nicht-statisch lassen, was Einfluss auf die Variablen für das eines dieser Objekte ändert, übergibt, verarbeitet etc..

 

[Major_Sauce]

Das ist mir wohl klar, das Verständnis ist nicht das Problem.
Die Frage ist eher, wieso gibt es oft solche "Machs nicht" Drohungen ?
Ich kenne mich recht "gut" mit Java aus, ich programmiere kleine Spiele und streame das ganze.
Neulich war ich am streamen und habe bei einem Kachel-Basierten Spiel public static final werte vergeben, für höhe und breite der Kachel.
Ich sehe da nichts falsches drin, final weis nicht verändert werden soll, public static damit ich jeder zeit von überall drauf zugreifen kann.
Nun bin ich am streamen und 3 oder 4 User meinen,sie müssen sich aufregen dass ich "Static" verwende.
Ich weiß dass es nicht schlimm ist, aber es wäre interessant zu wissenw as da in der Vergangenheit war, dass static einfach als "Böse" angesehen wird.

 

[Flown]

Static wird ja nicht als böse angesehen, sondern wird eben in den meisten Fällen falsch eingsetzt.
Static ist nichts anderes als ein Singleton und ist in der Klasse als auch in der Instanz verfügbar. Das Problem was sich hier meistens aufwirft, dass unerfahrene Programmierer static Kontext im Instanzkontext verwenden und sich wundern, warum sich ein Programm so verhält.
Also ich verwende static wirklich nur als Konstanten - wie du beschrieben hast static final - alle anderen Problemstellungen kann man anders lösen.

 

[Thallius]

Die Verlockung etwas "mal eben schnell" static zu machen, weil man dann ganz einfach von überall aus darauf zugreifen kann ist einfach riesig. Vor allem für Anfänger.
zu 99% ist das aber nicht nötig, sondern kann mit einem besseren Software-Design auch ohne static gelöst werden, was die Sache viel eleganter und auch für anderer einfacher zu verstehen und zu warten macht.

Gruß

CLaus

 

[RalleYTN]

Das ist mir wohl klar, das Verständnis ist nicht das Problem.
Die Frage ist eher, wieso gibt es oft solche "Machs nicht" Drohungen ?
Ich kenne mich recht "gut" mit Java aus, ich programmiere kleine Spiele und streame das ganze.
Neulich war ich am streamen und habe bei einem Kachel-Basierten Spiel public static final werte vergeben, für höhe und breite der Kachel.
Ich sehe da nichts falsches drin, final weis nicht verändert werden soll, public static damit ich jeder zeit von überall drauf zugreifen kann.
Nun bin ich am streamen und 3 oder 4 User meinen,sie müssen sich aufregen dass ich "Static" verwende.
Ich weiß dass es nicht schlimm ist, aber es wäre interessant zu wissenw as da in der Vergangenheit war, dass static einfach als "Böse" angesehen wird.

Da hätt auch ich kein static verwendet.
Die Werte wären dann in meiner Map-Klasse und über ein Getter zu erreichen. Das was ich immer als public static final deklariere ist eine instanz der Hauptklasse in der Hauptklasse.

public final class Game {
    public static final Game GAME = new Game();

    private Map map = new Map();

    public static void main(String[] args) {

    }

    public Map getMap() {
        return this.map;
    }
}

Auf diese Weise kann man eigentlich fast alles in einem Spiel nicht-static lassen und hat trotzdem von überall Zugriff.
Zum Beispiel will ich die Breite der Karte haben.

Game.GAME.getMap().getWidth();

 

[Thallius]

Sorry aber das ist genau das falsche Design das ich meinte

Es gibt überhaupt keine Grund von ausserhalb auf Game zuzugreifen, denn alles innerhalb von Game ist Bestandteil davon. Genau damit brichst du das komplette OOP Konzept.

Gruß

Claus

 

[Tom299]

Ich nutze static immer, wenn ich zentrale Variablen brauche, auf die ich von überall Zugriff brauche und ich fühle mich dabei überhaupt nicht böse

z.B. wenn du eine GUI-Anwendung hast und ein Benutzer loggt sich ein, du den Benutzer aber auf allen sagen wie 40 Views / Controllern brauchst. Gibst du dann jeder View bzw. jedem Controller den User im Konstruktor oder per Setter mit? Und wenn du noch andere Objekte brauchst, wie groß würde dann dein Konstruktor oder die Setter-Liste werden?
Nee, für sowas nutze ich dann doch lieber eine Globals-Klasse, die alle static-Objekte usw. beinhaltet und von wo ich überall drauf zugreifen kann. Und das ist sicherlich übersichtlicher und verständlicher, also zisch Objekte durch die ganzen Klassen durchzuschleifen.

Ich nutze auch gerne statische Methoden um z.B. ein Datum zu formatieren oder sonstige zentrale Methoden im Zugriff zu haben.

Das ist zumindest meine Meinung

 

[Thallius]

Jeder View sollte seinen Controller haben. Das nennt sich dann MVC und dieser Controller hat natuerlich Zugriff auf das Modell und dieses Modell gibt ihm den Benutzer.

Gerade für sowas braucht es absolut keine static.

Gruß

Claus