Methoden: static vs. instance

[Fireball29]

Hi!

Mich würde mal interessieren wann ihr eine Methode static deklariert? Man findet viele Meinungen dazu. Es soll allerdings eine Praxisdiskussion sein, keine Anfängerfrage ich programmiere schon jahrelang in Java.

Die Vorgabe ist ja eigentlich ganz klar, nur halten sich viele nicht daran. Deshalb der Hintergrund meiner Frage.

Viele Grüße,
Fireball

 

[MasterEvil]

Hm? Na immer dann wenn man eben kein Object der Klasse braucht
Kann man da denn was falsch machen?

 

[Marco13]

Methoden macht man static, wenn man sie static machen kann (d.h. so oft wie möglich), und fields macht man static, wenn man sie static machen muss (d.h. so selten wie möglich). Der Rest sind die Entscheidungen, für die Software-Entwickler die dicke Kohle kriegen

 

[Fireball29]

Methoden macht man static, wenn man sie static machen kann (d.h. so oft wie möglich), und fields macht man static, wenn man sie static machen muss (d.h. so selten wie möglich).

Gute Beschreibung!

 

[Leroy42]

Methoden macht man static, wenn man sie static machen kann (d.h. so oft wie möglich)

Da bin ich etwas anderer Meinung!

Methoden sollte man nur dann static machen, wenn sie keine
Relevanz zu einer Klasseninstanz haben, z.B die ganzen
java.lang.Math - Methoden (sqrt(), sin(), ...)

Aber ich gebe zu, das dann der Reiz von Marco13s Beschreibung
flöten ginge.

 

[Tellerrand]

"Methoden sollte man nur dann static machen, wenn sie keine Relevanz zu einer Klasseninstanz haben"
Kann man sie denn nicht erst dann static machen wenn sie keine Relevanz zur Klasseninstanz haben?

"Die Vorgabe ist ja eigentlich ganz klar, nur halten sich viele nicht daran. Deshalb der Hintergrund meiner Frage."
Wer hält sich wo nicht an welche Vorgabe?

 

[SlaterB]

> Methoden sollte man nur dann static machen, wenn sie keine Relevanz zu einer Klasseninstanz haben

widerspricht sich doch nicht mit

> Methoden macht man static, wenn man sie static machen kann



zusammen: Methoden sollten möglichst keine Relevanz zu einer Klasseninstanz haben

na gut, dass kann man auch negativ auslegen aber ist doch ein berechtiger Anspruch

 

[Marco13]

Naja - der Nachsatz hat ja auch seine Bedeutung. Es macht nicht unbedingt Sinn, vollkommen pauschal-brutal zu versuchen, alle Methoden static zu machen (mit "brutal" meine ich, dass man ja theoretisch JEDE Methode static machen könnte, indem man ihr eine Referenz auf ein Objekt der Klasse übergibt, in der sie steht, und auf deren fields sie nicht zugreifen darf, weil sie ja static ist (nicht lachen: In C++ wird das genau so gemacht: Jede Memberfunktion bekommt den "this"-Zeiger implizit übergeben!)). Irgendwo muß doch ein Mensch von Fall zu Fall die Entscheidung treffen.

 

[Ark]

Ich handhabe das so:

Man sollte so viele Methoden wie möglich statisch machen. Eine Methode sollte aber nicht statisch sein, sobald sie mindestens eine Instanz ihrer Klasse als Paramter eingegeben bekommen würde. In einem solchen Fall hätte man sich nämlich diesen Paramter sparen und stattdessen einfach this (für diesen Paramter) verwenden können.

Eigenschaften sollten statisch sein, wenn alle Instanzen diese Eigenschaften teilen; ansonsten nicht.

Ark

 

[Marco13]

Auch DAS ist (streng genommen) zu pauschal:

class Mensch
{
    String name;
    int alter;
 
    public void gibAus()
    {
        System.out.println(name+" "+alter);
    }

    public static void gibAus(Mensch mensch)
    {
        System.out.println(mensch.name+" "+mensch.alter);
    }

    public static void gibAus(String name, int alter)
    {
        System.out.println(name+" "+alter);
    }
}

(Nur ein Beispiel, um zu verdeutlichen, dass man kein allgemeingültiges Beispiel angeben kann :wink: )

 

[Ark]

@Marco13: Wenn du dich auf meinen Beitrag beziehst, würde ich deinen bitte noch etwas erläutert haben, denn ich sehe auch an deinem Beispiel keinen Grund, warum meine Idee „zu pauschal“ sein soll. ???:L

Ark

 

[HLX]

Auch DAS ist (streng genommen) zu pauschal:

class Mensch
{
    String name;
    int alter;
 
    public void gibAus()
    {
        System.out.println(name+" "+alter);
    }

    public static void gibAus(Mensch mensch)
    {
        System.out.println(mensch.name+" "+mensch.alter);
    }

    public static void gibAus(String name, int alter)
    {
        System.out.println(name+" "+alter);
    }
}

(Nur ein Beispiel, um zu verdeutlichen, dass man kein allgemeingültiges Beispiel angeben kann :wink: )

Die static-Methoden sind doch nicht dein Ernst, oder? Das ist ja grausam... :autsch:

 

[Gast]

staticmethoden sooft wie möglich?? Schon mal was von OOP gehört?

 

[SlaterB]

> Schon mal was von OOP gehört?

als der Mensch das Rad erfunden hatte, fuhr er nur noch mit dem Auto,
selbst wenn der Weg vom Wohnzimmer in die Küche zu Fuss schneller wäre..

 

[Marco13]

Was jetzt die Frage, ob static oder nicht, mit OOP zu tun hat? Natürlich sollte man nicht krampfhaft versuchen, alles möglichst static zu machen, aber wenn eine Methode irgendwas übergeben bekommt, dann unabhängig von irgendwelchen Fields damit rumrechnet, und irgendwas zurückgibt, kann sie doch static sein - un sollte das dann imho auch. Und das Beispiel sollte nur verdeutlichen, dass man zwar irgendwas auf biegen und brechen static machen kann, dass aber nicht tun sollte, wenn es "keinen Sinn ergibt". Und WANN es Sinn ergibt, ist eben die Frage, die man von Fall zu Fall entscheiden muss... (mehr wollt' ich damit ja nicht sagen :roll: )

 

[HLX]

Was jetzt die Frage, ob static oder nicht, mit OOP zu tun hat? Natürlich sollte man nicht krampfhaft versuchen, alles möglichst static zu machen, aber wenn eine Methode irgendwas übergeben bekommt, dann unabhängig von irgendwelchen Fields damit rumrechnet, und irgendwas zurückgibt, kann sie doch static sein - un sollte das dann imho auch. Und das Beispiel sollte nur verdeutlichen, dass man zwar irgendwas auf biegen und brechen static machen kann, dass aber nicht tun sollte, wenn es "keinen Sinn ergibt". Und WANN es Sinn ergibt, ist eben die Frage, die man von Fall zu Fall entscheiden muss... (mehr wollt' ich damit ja nicht sagen :roll: )

Ok. Ich war mir sicher, dass es eine Homage an static war, wg. einem vorherigen Beitrag, in dem stand: static so oft wie möglich.

Im Sinne der Objektorientierung sollte man schon im Vorfeld zusehen, static nur für tatsächlich klassenbezogene Vorgänge und Utilities zu verwenden und ansonsten so weit wie möglich zu vermeiden, sprich: gut überlegen, ob bestimmte Operationen von einem Objekt ausgeführt werden sollten.

 

[Christian76]

Static Methoden benutze ich selten. Meistens verwende ich in meinen Programme durch static deklarierte
globale Varialben in einer Controlerklasse. Z.b. sowas hier:

class controll
{
    public static int Wert;
}

 

[mephi]

Static Methoden benutze ich selten. Meistens verwende ich in meinen Programme durch static deklarierte
globale Varialben in einer Controlerklasse. Z.b. sowas hier:

class controll
{
    public static int Wert;
}

ähm und der sinn davon ist welcher?

 

[Marco13]

ähm und der sinn davon ist welcher?

Vermutlich: Sich das Leben leicht zu machen.
Bis man mal etwas ändern muss. Oder man mal ZWEI Control's braucht. Oder ein Programm mit mehr als 1000 LOC schreiben muss. Oder bis man solchen Code nachvollziehen muß, wenn er von jemand anderem geschrieben wurde.

 

[Guest]

@ mephi

Wenn ich mehrere Objekte habe, die aber alle auf einen Variable zugreifen. Keine lokale Klassenvariable, sondern eine Globale.

 

[Marco13]

class controll
{
    private int wert;
    public int getWert() { return wert; }
    public void setWert(int w) { wert = w;}
}

class A 
{
    private controll c;
    ...
        c.setWert(5);
}


class B 
{
    private controll c;
    ...
        int w = c.getWert();
}

Aber das ist so viel Tipparbeit :roll:

 

[Christian76]

ach, naja:

class A
{
    ...
    controll.i=1;
    ...
}

class B
{
    ...
    controll.i=1;
    ...
}

class controll
{
    public static int i;
}

das geht finde ich!

 

[HLX]

ach, naja:

class A
{
    ...
    controll.i=1;
    ...
}

class B
{
    ...
    controll.i=1;
    ...
}

class controll
{
    public static int i;
}

das geht finde ich!

Naja, direkter Zugriff auf Variablen ist eigentlich nicht schön. Was machst du, wenn du, wenn du controll ableiten willst und in der Ableitung z.B. die Variable controll nicht mehr von außen modifizierbar sein soll?

 

[Fireball29]

So, wunderbar, im Grunde wurde ja schon alles gesagt, zumindest in der Theorie

- eine Variable wird static wenn sie logisch nicht zu einer bestimmten Instanz gehört, sondern der Klasse zugeordnet werden kann
- eine Methode wird static wenn sie keine lokalen Variablen benutzt, wobei natürlich die aktuelle Instanz also this gemeint ist

Die Verwendung der Regeln sollte allerdings sinnvoll sein, denn wie schon erwähnt wurde kann man ja immer das aktuelle Objekt (this) an die static Methode übergeben, was wohl fast immer unsinnig ist.

Ich verwende statische Methode sehr gerne um allgemeine Funktionalität, welche zur Klasse gehört und oft gebraucht wird, an der richtigen Stelle abzulegen. Dies dient der Wiederverwendbarkeit und Vermeidung von Redundanz.
Und wie besch... Redundanz ist wissen die meisten von uns sicher aus dem Programmiereralltag

Wenn man das sauber aufbaut und beherrzigt, sucht, findet und erstellt man Methoden eigentlich fast immer an der richtigen Stelle. Und das ist es, was ich vor allem unter objektorientierter Programmierung verstehe, eine logische und strukturierte Menge von Objekten (mit Eigenschaften und Funktionalitäten) mit minimaler Redundanz.

Viele Grüße,
Fireball

 

[HLX]

eine Methode wird static wenn sie keine lokalen Variablen benutzt, wobei natürlich die aktuelle Instanz also this gemeint ist

Falsch! Wird durch das Singleton-Pattern widerlegt --> Instanziierung der "lokalen" Variable in der static-Methode. Du meinst wahrscheinlich Objektvariable

Versucht das nicht in irgendwelche Programmier-Regeln zu pressen. In der Objektorientierung sollte man in der Lage sein zwischen Objektfunktionalität und Klassenfunktionalität zu unterscheiden. Fragt euch, was Ihr mit eurer Funktion/Methode erreichen wollt. Handelt es sich um etwas, was das spezifische Objekt können muss oder um ein Unterscheidungsmerkmal zu anderen Objekten oder wird z.B. eine einzelne Factory benötigt etc.