[Java] gebruik van static

[Verwijderd]

De laatste tijd gebruik ik vaak static methode en static singeltons als het kan en het mij de beste oplossing lijkt. Alleen begin ik de laatste tijd ook te twijfelen over hoe dit wordt opgelost in het geheugen van mijn VM, want daar weet ik eigenlijk weinig over en ik kan het ook nergens vinden, ook kwam ik in de FAQ tegen dat static moest worden vermijdt. Dusss iemand er iets over te vertellen

[Creepy]

Wat is nu precies je vraag? Wat er fout en goed is aan static?
En wat voor relevantie heeft dit met hoe het opgelost wordt in de VM?
Misschien dat je je post wat kan verduidelijken door te vertellen waarom en op welke manier jij static gebruikt en waarom jij denkt dat dit een probleem zou zijn.

[Michali]

Gebruik gewoon static's wanneer het echt bruikbaar is. En gebruik zeker geen singletons wanneer het kan. Je moet een singleton pas gebruiken als je een bepaalde statefull object op meerdere plaatsen nodig hebt en wil dat de state op alle plaatsten gelijk/synchroon blijft. Dan is het beter om een singleton te maken, dan het object als parameter allerlei weggetjes door te sturen. Maar gebruik je een object echt maar in een bepaalde context of is het echt een stateless object, dan zou ik er geen singleton van maken.

Ik zou me verder niet zo druk maken over de performance van deze dingen. Gebruik ze gewoon met mate, dan kan er weinig mis gaan.

[Verwijderd]

Het motto is: singletons of statics zijn eigenlijk globale variablen. Globale variablen vermijd je zo veel mogelijk omdat het een analyse van je applicatie (wie veranderd wat en wanneer) heel erg lastig maakt.

Als je een singleton gebruikt omdat 'je dan zo lekker makkelijk bij een waarde kunt komen, want het is zo lastig om parameters telkens door te geven', dan gebruik je het als een global en dat moet je zo veel mogelijk (eigenlijk helemaal) vermijden.

Singletons zijn alleen voor uitzonderlijke situaties, bijvoorbeeld voor een connection pool, of in het algemeen voor het regelen van toegang tot een resource waarvan er logisch of fysiek maar 1'tje is.

[Verwijderd]

JA ik heb het een beetje met klasses, waarvan de waardes niet te veranderen. En als je een instanties van deze klasse maakt, de variablen altijd hetzelfde zullen zijn

[NMe]

Verwijderd schreef op donderdag 23 december 2004 @ 00:51:
JA ik heb het een beetje met klasses, waarvan de waardes niet te veranderen. En als je een instanties van deze klasse maakt, de variablen altijd hetzelfde zullen zijn

Klassen hebben geen waarden, klassen hebben attributen en methodes, en het enige wat daar een "waarde" kan hebben, is een attribuut. Verder zijn onveranderlijke variabelen dus gewoon constanten.

En je hebt nog steeds niet al teveel verteld over hoe je static nou gebruikt, dus kan ook niemand hier zeggen of dat goed of fout is.

[whoami]

Verwijderd schreef op woensdag 22 december 2004 @ 14:20:
Het motto is: singletons of statics zijn eigenlijk globale variablen. Globale variablen vermijd je zo veel mogelijk omdat het een analyse van je applicatie (wie veranderd wat en wanneer) heel erg lastig maakt.

Bij een singleton ligt dat toch wat anders:
Een gewone global kan je overal veranderen, een singelton niet, die is read only en kan slechts door 1 stuk code veranderd worden: de singleton zelf.

There are uses of global variables which do not violate the open
closed principle; and are therefore quite benign. Consider the
"Abstract Factory" pattern from the GOF book (Design Patterns, Gamma,
et. al., Addison Wesley, 1995). This pattern, which enables the open
closed principle in a very sticky scenario, virtually requires the use
of a single global variable to hold the factory. In this case, only
one module in the program makes changes to the global. All others use
the value in the global but do not modify it. Moreover, the concept
of the "Factory" is a global concept. It applies to many modules
simultaneously.

The moral here is that we should never proscribe a practice without
fully understanding the reasons behind that proscription. Global
variables carry a high potential for violation of the OCP, yet there
are valid, even necessary, uses for them. Software engineers should
not simply rely upon common conventions and religious proscriptions.
Rather they should learn the principles of software design so that
they can determine for themselves the cost/benefit of a given practice
in a given context.

Ik ben het wel met je eens dat je 'gewone' global variables niet moet gebruiken, omdat je die overal in je applicatie kunt wijzigen, het debuggen lastiger maakt, en het moeilijker wordt om aanpassingen/uitbreidingen te maken in je app.

[Verwijderd]

nou bijvoorbeeld heb ik deze klasse:

Java:

public class ActionMap {

  private static Map actions = new HashMap();


  /**
   * De default action, deze wordt aangeroepen als er geen bijpassende action gevonden wordt in de hashmap
   * met deze action wordt de request door gestuurdt naar de index-pagina
   */
  private static final Action DEFAULT = new Action(){
      public String perform(HttpServletRequest request, HttpServletResponse response){
        return "example_input.jsp";
      }
    };


//voeg alle actions toe aan de hashmap
  static{
    actions.put( "default", DEFAULT );

    //Start medewerkers-actions
    actions.put( "employeelogin", new EmployeeLogin() );
    actions.put( "employeelogoff", new EmployeeLogoff() );
    actions.put( "addemployee", new AddEmployee() );
    actions.put( "editemployee", new EditEmployee() );
    actions.put( "deleteemployee", new DeleteEmployee() );
    actions.put( "searchemployee", new SearchEmployee() );
    actions.put( "allemployees",  new AllEmployees() );
    //einde medewerkers-actions

    //etc




//maak er een immutable map van ivm threadsafty en security
    actions =  java.util.Collections.unmodifiableMap( actions );
  }


  /**
   * Een private constructor zodat er geen instaties van deze klasse gemaakt kan worden
   * Dit wordt ook gebruikt in de Managerklassen in de pec.sql package
   */
  private ActionMap(){}


  /**
   * Zoek een action op aan de hand van zijn naam
   *
   * @param actionname String De naam van de gewenste action
   * @return Action De gevonden Action
   */
  public static Action getActionByName( String actionname ){
    return (Action) actions.get( actionname );
  }

}

tja waarom zou ik hier een object van maken

[Verwijderd]

whoami schreef op donderdag 23 december 2004 @ 09:05:
[...]

Bij een singleton ligt dat toch wat anders:
Een gewone global kan je overal veranderen, een singelton niet, die is read only en kan slechts door 1 stuk code veranderd worden: de singleton zelf.

Dat is waar. Met een singleton hou je controlle over de data die door de singleton encapsulated wordt. Echter, dat verschilt weinig van een gewone globale class in C++ met private member data en getters/setters. Natuurlijk, de singleton kan maar 1 instantie van zijn en dat is wezenlijk anders dan een 'gewone' global.

Waar ik echter voornamelijk op doelde is dat het gebruik van een Singleton heel snel vervalt tot het soort gebruiks patroon wat je ook voor een global ziet: gevallen waar helemaal geen singleton rechtvaardigd is, maar waar mensen het gewoon makkelijk vinden omdat ze zo lekker snel bij hun data kunnen, ipv een bepaald object telkens door te geven.