# Wann nutzt man static?



## Overskill (22. Okt 2014)

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


----------



## Thallius (22. Okt 2014)

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

Gruß

Claus


----------



## Overskill (22. Okt 2014)

Irgendwie gefällt mir deine Einstellung zum Programmieren .

Danke
Over


----------



## Ruzmanz (22. Okt 2014)

> 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


----------



## stg (22. Okt 2014)

Thallius hat gesagt.:


> 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


----------



## Thallius (22. Okt 2014)

stg hat gesagt.:


> 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


----------



## Moro (23. Okt 2014)

Thallius hat gesagt.:


> Bin ich im Prinzip bei dir wenn man weis wo man gefahrlos static objecte einsetzen darf.



Zu wissen das es keine static Objekte gibt, weil statische Klassischen nicht instanziert werden können, wäre ja schon mal ein Anfang ;-) !


----------



## Thallius (23. Okt 2014)

Moro hat gesagt.:


> Zu wissen das es keine static Objekte gibt, weil statische Klassischen nicht instanziert werden können, wäre ja schon mal ein Anfang ;-) !



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


----------



## Deros (23. Okt 2014)

In Hilfsklassen nutze ich gerne static-methoden und da finde ich es auch angebracht da ich kein Objekt der Klasse brauche...


----------



## Thallius (23. Okt 2014)

Deros hat gesagt.:


> In Hilfsklassen nutze ich gerne static-methoden und da finde ich es auch angebracht da ich kein Objekt der Klasse brauche...



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

Gruss

Claus


----------



## Deros (23. Okt 2014)

nicht aus meiner Feder aber gerade zur Hand:


```
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);
  }
}
```


----------



## Thallius (23. Okt 2014)

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


----------



## Deros (23. Okt 2014)

Clientseitig müsste ich mir da schon absichtlich selbst ein Bein stellen und serverseitig verhindert das mein Framework


----------



## arilou (23. Okt 2014)

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:
	
	
	
	





```
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();
  }
}
```


----------



## stg (23. Okt 2014)

Oder noch besser direkt


```
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:


----------



## Moro (23. Okt 2014)

Thallius hat gesagt.:


> 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.



Thallius hat gesagt.:


> 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.


----------



## stg (23. Okt 2014)

Moro hat gesagt.:


> 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:


----------



## kaoZ (23. Okt 2014)

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


----------



## stg (23. Okt 2014)

kaoZ hat gesagt.:


> 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.


----------



## Moro (23. Okt 2014)

stg hat gesagt.:


> ...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. 



stg hat gesagt.:


> 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?


----------

