Wann nutzt man static?

Overskill

Aktives Mitglied
Hey Leute Frage klingt leicht und ich weiß auch wie static funktioniert etc., aber wann habt ihr es schon einmal praktisch gebraucht(außer in der main 😛 ). Würde mich mal für ein paar Beispiele interessieren, da ich es auch noch nicht bei GUIS oder Threads verwendet habe/ bzw. verwendet gesehen habe. Bitte nicht sone 0815 Übungsbespiele wie Bierkästen durch den Konstruktor hochzählen 😀. Nur sowas wie final static ...?
#

Danke
Over
 
Zuletzt bearbeitet:
da ich es auch noch nicht bei GUIS oder Threads verwendet habe/ bzw. verwendet gesehen habe

Welches Framework? ... spielt eigentlich keine Rolle. Schau mal in die Klasse Color. Die Klasse "Math" ist der absolute static Anhänger.

Am besten benutzt man sie gar nicht. Wer ohne auskommt hat immer das bessere OOP Design.

Wen interessiert schon das OOP Design? Ich nutze gerne "char, int, float, ...". Ich nutze gerne Enums. Ich werde auch Lambdas nutzen.


PS: Galileo Computing :: Java ist auch eine Insel - 5 Eigene Klassen schreiben
 
Zuletzt bearbeitet:
Am besten benutzt man sie gar nicht. Wer ohne auskommt hat immer das bessere OOP Design.

Was statische Variablen angeht, stimme ich dir zu. Wenn schon static, dann i.d.R. auch final...
Dass statische Methoden dem OOP-Gedanken wiedersprechen, finde ich aber nicht. Das (eventuell) unnötige Erstellen einer Instanz kann u.U. doch recht teuer werden. Da wird mitunter sogar der Speicher knapp 🙂
 
Was statische Variablen angeht, stimme ich dir zu. Wenn schon static, dann i.d.R. auch final...
Dass statische Methoden dem OOP-Gedanken wiedersprechen, finde ich aber nicht. Das (eventuell) unnötige Erstellen einer Instanz kann u.U. doch recht teuer werden. Da wird mitunter sogar der Speicher knapp 🙂

Bin ich im Prinzip bei dir wenn man weis wo man gefahrlos static objecte einsetzen darf. Leider kenne ich zu viele Apps die z.b.mal eben eine static methode benutzen um mit einem webservice zu reden. Da man ja von ganz vielen Stellen aus in der app auf den Webservice zugreifen muss ist das die einfachste Lösung. Also mache ich den Zugriff static.... Falscher geht es einfach nicht mehr.

Deshalb ist meine Meinung. Wer keine static benutzt kann erstmal keinen fehler machen. Anders herum aber eben schon.

Gruss

Claus
 
Zuletzt bearbeitet:
nicht aus meiner Feder aber gerade zur Hand:

Java:
public class JSFUtils
{

  private static final String NO_RESOURCE_FOUND = "Missing resource: ";

  /**
   * Method for taking a reference to a JSF binding expression and returning
   * the matching object (or creating it).
   * @param expression EL expression
   * @return Managed object
   */
  public static Object resolveExpression(String expression)
  {
    FacesContext facesContext = getFacesContext();
    Application app = facesContext.getApplication();
    ExpressionFactory elFactory = app.getExpressionFactory();
    ELContext elContext = facesContext.getELContext();
    ValueExpression valueExp =
      elFactory.createValueExpression(elContext, expression, Object.class);
    return valueExp.getValue(elContext);
  }

  public static String resolveRemoteUser()
  {
    FacesContext facesContext = getFacesContext();
    ExternalContext ectx = facesContext.getExternalContext();
    return ectx.getRemoteUser();
  }

  public static String resolveUserPrincipal()
  {
    FacesContext facesContext = getFacesContext();
    ExternalContext ectx = facesContext.getExternalContext();
    HttpServletRequest request = (HttpServletRequest) ectx.getRequest();
    return request.getUserPrincipal().getName();
  }

  public static Object resloveMethodExpression(String expression,
                                               Class returnType,
                                               Class[] argTypes,
                                               Object[] argValues)
  {
    FacesContext facesContext = getFacesContext();
    Application app = facesContext.getApplication();
    ExpressionFactory elFactory = app.getExpressionFactory();
    ELContext elContext = facesContext.getELContext();
    MethodExpression methodExpression =
      elFactory.createMethodExpression(elContext, expression, returnType,
                                       argTypes);
    return methodExpression.invoke(elContext, argValues);
  }
}
 
Und was passiert nun, wenn z.b. Die letzte Methode von einem thread aufgerufen wird und bevor sie beendet ist, kommt ein task Switch und der dann aktive thread ruft die ebenso auf? Dann hast du aber eine ganz feine Race-Condition und so einen Fehler zu finden ist richtig schwer.

Gruss

Claus
 
Zuletzt bearbeitet:
static-Variablen sollte man vermeiden, da stimm' ich Joose zu.

Wann macht man eine Methode 'static'?
Ganz einfach - wenn sie keine Objekteigenschaften benötigt (liest oder schreibt) - d.h. immer, wenn's keinen Compilerfehlermeldung ergibt. (Ich stimme jedoch Joose zu, dass dies oft auf einen Programmaufbau hindeutet, der nicht sehr OOP-geprägt ist.)

Beispiel:
Java:
public class ComplexeZahl
{
  public static ComplexeZahl add( ComplexeZahl c1 , ComplexeZahl c2 )
  {
    // [...] arbeitet ohne jemals auf 'this' zuzugreifen, darum 'static'
  }
}

// nicht sehr OOP; besser:

public class ComplexeZahl
{
  public void add( ComplexeZahl c )
  {
    this.realTeil += c.getRealteil();
    this.imagTeil += c.getImagteil();
  }
}
 
Oder noch besser direkt

Java:
public ComplexNumber add(ComplexNumber c) {
    return new ComplexNumber(this.re + c.getRe(), this.im + c.getIm());
}

und die Klasse komplett immutable halten. Sowas ist schließlich ein Paradebeispiel für ein Value-Object. Wenn man das beherzigt, dann ist gegen deine erste Variante (die static-Methode) sogar überhaupt nichts einzuwenden.

😛opcorn:
 
Objekt im Sinne von Instanz, da magst du recht haben aber in diesem Fall meine ich eher das Objekt als solches. Wie eben auch ein Auto, ein Haus und ein Boot Objekte sind.

Gruß

Claus

Hä? Keine Objekte einer Instanz sondern Objekte als solches? Bitte was? Objekte sind immer Instanzen einer Klasse. Auch ein Haus, ein Boot und ein Auto Objekt. Das hat alles nichts mit static zu tun.

Gib doch einmal ein konkretes Beispiel für so ein zwei Methoden einer solchen Hilfsklasse.

Gruss

Claus

Eine Klasse static oder Methoden static zu setzen macht vor allem dann Sinn, wenn ich weiß das ich aus einer Klasse keine Objekte erzeugen muss, weil es keine Objekteigenschaften beinhaltet. Schau dir doch mal die Klasse Math der Java Standardbibliothek an, wenn du Beispiele für static Methoden suchst.

Ich habe irgendwie den Eindruck, du weißt gar nicht so wirklich wofür static gut ist. Vielleicht meinst du sogar das Richtige aber das Fachvokabular scheint dir nicht so geläufig zu sein.
 
Zuletzt bearbeitet:
Hä? Keine Objekte einer Instanz sondern Objekte als solches? Bitte was? Objekte sind immer Instanzen einer Klasse. Auch ein Haus, ein Boot und ein Auto Objekt. Das hat alles nichts mit static zu tun.
Du willlst ihn doch falsch verstehen.... er hätte auch schreiben können "irgendwelche Dinge" o.Ä.

Ich habe irgendwie den Eindruck, du weißt gar nicht so wirklich wofür static gut ist. Vielleicht meinst du sogar das Richtige aber das Fachvokabular scheint dir nicht so geläufig zu sein.

Wenn du so willst...

Eine Klasse static zu setzen macht - oder zumindest Methoden aus dieser - macht vor allem dann Sinn, wenn ich weiß das ich davon keine Objekte erzeugen muss. Schau dir doch mal die Klasse Math der Java Standardbibliothek an, wenn du Beispiele für static Methoden suchst.

...dann solltest du wissen, dass die Klasse Math zwar final und nicht instanzierbar ist, aber das heißt noch lange nicht, dass die Klasse static ist. Das ist in Java bei "1st Lvl Klassen" nämlich gar nicht möglich.

😛opcorn:
 
Zuletzt bearbeitet:
Ich würde dahingehend eh nur variablen und oder Methoden / Klassen als static deklarieren insofern diese :

( der gesamten Anwendung / bzw. bestimmten Schichten, immer zur Verfügung stehen müssen / sollen )

und oder :

- konstant bleiben ( sprich Konstanten )
- Hilfsmethoden bereitstellen welche nur an wenigen punkten innerhalb der eigentlichen Applikation genutzt werden,
und somit gewisse Funktionalität kapseln ( Erzeugen von Writern / Streams / usw. )
- oder wenn ich garantieren muss das z.B alle Instanzen einer Klasse zetral verfügbar sein müssen, so kann ich den weg
über eine Statische Collection wählen, welcher bei Objekterzeugung direkt alle Objekte hinzugefügt werden.

Aber das ist nur meine Meinung, auch wenn es nicht in allen Punkten dem Gedanken der OOP entspricht 😉
 
Zuletzt bearbeitet:
I
- oder wenn ich garantieren muss das z.B alle Instanzen einer Klasse zetral verfügbar sein müssen, so kann ich den weg
über eine Statische Collection wählen, welcher bei Objekterzeugung direkt alle Objekte hinzugefügt werden.

Das ist ein schönes Beispiel, fnde ich. So löse ich es z.B. im Webumfeld, wenn ich mir eingeloggte Besucher merken muss und direkten Zugriff auf deren Session-Objekt haben möchte.
 
...dann solltest du wissen, dass die Klasse Math zwar final und nicht instanzierbar ist, aber das heißt noch lange nicht, dass die Klasse static ist. Das ist in Java bei "1st Lvl Klassen" nämlich gar nicht möglich.

Ich habe auch nicht geschrieben das die Klasse Math static ist, sondern das er da statische Methoden finden kann, nach denen er gefragt hatte. ob "1st Level" oder nicht, solche Rechenoperationen würde ich genauso statisch implementieren, auch wenn sie nicht zum JDK gehören würden.

Du willlst ihn doch falsch verstehen.... er hätte auch schreiben können "irgendwelche Dinge" o.Ä.

Verstehe ich immer noch nicht. Was denn für "Dinge"? Entweder ich habe Objekte, oder ich habe keine. Es gibt kein "dazwischen". Wenn ich Objekte habe, dann sind das immer Instanzen einer Klasse - was denn auch sonst?
 
Zuletzt bearbeitet:

Neue Themen


Zurück
Oben