[PHP5] Singleton: waarom niet gewoon alles static?

[Verwijderd]

Dit vroeg ik mij laatst af. Ik ben een vrijwel onbekende in de wereld van OOP en de daarbijhorende 'design patterns'. Maar als je deze twee voorbeelden ziet:

PHP:

<?php
class Singleton {
  static private $instance;
  
  private function __construct() {}
  private function __clone() {}
  
  static public function getInstance() {
    if (!self::$instance instanceof self) {
      self::$instance = new Singleton();
    }
    return self::$instance;
  }

  public function connect() {
    // typische Singleton functie
  }
}
?>

vs.

PHP:

<?php
class Singleton {
  static public function connect() {
    // typische Singleton functie
  }
}
?>

Oftewel mijn vraag: waarom gebruikt men niet gewoon static properties en methods ipv een Singleton? Aangezien van er ook maar 1 class kan bestaan. Nu hoef je ook niet eerst getInstance() aan te roepen.

[.oisyn]

Omdat dat niet meer werkt als je Singleton klasse eigenlijk een derived klasse is die jouw singleton interface implementeert. En dan hoef je je code ook niet aan te passen als je ooit besluit een derived implementatie erin te hangen.

[ Voor 30% gewijzigd door .oisyn op 17-04-2007 19:26 ]

[Upsal]

Hmm, die vraag had ik laatst ook. Maar ik denk dat het gemakkelijker is om een singleton klasse te maken i.p.v. alle static maken als je veel attributen en methodes hebt (dan vergeet je ook niet steeds 'static' erbij te zetten).

[JeroenB]

In C# kun je tegenwoordig een hele class markeren als static. De belangrijkste reden om dat in het geval van een singleton niet te doen is simpelweg omdat een singleton niet statisch is, het is een instantie zoals ieder ander object met het verschil dat er maar eentje van in omloop mag zijn.

Maar dat roept de vraag op wat het verschil dan is. Kortweg kun je stellen dat een singleton state encapsuleert en daarom geconstrueerd (en opgeruimd, maar dat speelt tegenwoordig wat minder dankzij garbage collection) moet worden.

Als je een class hebt met een berg utility-methods die geen state nodig hebben, dan zou ik een class maken met alleen static methods. Als ze echter wel state gebruiken, dan moet het een instantieerbaar object zijn. En als er van dat object maar eentje van in omloop mag zijn (om wat voor reden dan ook, dat is een andere discussie), dan moet het daarnaast ook een singleton zijn.

[D-Raven]

Daarnaast wil je in de meeste gevallen je singleton ook thread safe maken (als hij state heeft in ieder geval). Als je singleton implementatie dan niks meer is dan een verzameling static methodes, dan bezorg je jezelf een hoop werk.

[.oisyn]

JeroenB schreef op vrijdag 20 april 2007 @ 20:52:
Maar dat roept de vraag op wat het verschil dan is. Kortweg kun je stellen dat een singleton state encapsuleert en daarom geconstrueerd (en opgeruimd, maar dat speelt tegenwoordig wat minder dankzij garbage collection) moet worden.

Opruimen is meer dan alleen geheugen vrijgeven, en dat laatste is het enige dat een GC voor z'n rekening neemt. Als je resources pas vrij gaat geven in de finalizers ben je over het algemeen verkeerd bezig.

Overigens, als je alleen static methods gebruikt wil dat nog niet zeggen dat een state niet mogelijk is - die state zal dan alleen ook static moeten zijn

[ Voor 12% gewijzigd door .oisyn op 23-04-2007 16:40 ]

[JeroenB]

.oisyn schreef op maandag 23 april 2007 @ 16:39:
Opruimen is meer dan alleen geheugen vrijgeven, en dat laatste is het enige dat een GC voor z'n rekening neemt. Als je resources pas vrij gaat geven in de finalizers ben je over het algemeen verkeerd bezig.

Dat ligt eraan wat voor resources het zijn, maar los daarvan probeerde ik het zo simpel mogelijk te maken.

Overigens, als je alleen static methods gebruikt wil dat nog niet zeggen dat een state niet mogelijk is - die state zal dan alleen ook static moeten zijn

Je kunt ook stoppen met het gebruiken van classes, maar da's beside the point denk ik.

[.oisyn]

JeroenB schreef op maandag 23 april 2007 @ 22:00:
[...]

Dat ligt eraan wat voor resources het zijn, maar los daarvan probeerde ik het zo simpel mogelijk te maken.

offtopic:
Dan had je dat stukje tussen haakjes er niet bij moeten zetten

Je kunt ook stoppen met het gebruiken van classes, maar da's beside the point denk ik.

Waar ik op reageerde was dat het een beetje werd afgedaan als dat je geen static methods kon gebruiken als je singleton een state bij moet houden. Dat is natuurlijk niet zo, dus dat is tevens geen argument om een instance te gebruiken ipv static method.

[JeroenB]

.oisyn schreef op maandag 23 april 2007 @ 23:22:

offtopic:
Dan had je dat stukje tussen haakjes er niet bij moeten zetten

offtopic:
Het probleem is dat ik al genoeg op fora rondhang om te verwachten dat veel opmerkingen gericht op het geven van inzicht aan beginners wel tot een niet-educationele zeik-discussie leiden met forum-regulars. Ik poogde daarbij te voorkomen dat iemand zou beginnen over het opruimen van geheugen, maar helaas leidde dat tot een soortgelijke reactie maar dan juist over dat opruimen zelf

Waar ik op reageerde was dat het een beetje werd afgedaan als dat je geen static methods kon gebruiken als je singleton een state bij moet houden. Dat is natuurlijk niet zo, dus dat is tevens geen argument om een instance te gebruiken ipv static method.

Kunnen en moeten zijn verschillende dingen. Het feit dat je alles met static methods en members aan elkaar kunt programmeren wil niet zeggen dat het zinvol is om dat te doen. Claimen dat het wel kan is leuk voor kenners en verwarrend voor beginners. En iemand uit die laatste groep had een vraag.

[.oisyn]

Het feit dat je alles met static methods en members aan elkaar kunt programmeren wil niet zeggen dat het zinvol is om dat te doen

Niemand zegt ook dat het zinvol is om te doen.

Claimen dat het wel kan is leuk voor kenners en verwarrend voor beginners

Claimen dat het niet kan is misinformatie, sta er dan ook niet raar van te kijken als iemand er wat van zegt. Wees gewoon correct maar zeg er dan bij dat je het beter niet kunt doen. De imho enige reden om voor singleton instances te gaan wat het design betreft staat al in de eerste reactie van deze draad.

[ Voor 6% gewijzigd door .oisyn op 23-04-2007 23:49 ]

[JeroenB]

.oisyn schreef op maandag 23 april 2007 @ 23:48:
Claimen dat het niet kan is misinformatie, sta er dan ook niet raar van te kijken als iemand er wat van zegt.

Waar claim ik dan dat het niet kan? Zeggen dat je het niet moet doen is iets anders dan claimen dat het niet kan.

Wees gewoon correct maar zeg er dan bij dat je het beter niet kunt doen. De imho enige reden om voor singleton instances te gaan wat het design betreft staat al in de eerste reactie van deze draad.

Het initialiseren en opruimen van state op een gecentraliseerde plek is imho ook een goede reden. Dat je dat op een andere manier ook kunt bereiken is vanuit het oogpunt van design niet interessant.

[.oisyn]

JeroenB schreef op dinsdag 24 april 2007 @ 14:40:

Waar claim ik dan dat het niet kan?

Hier

JeroenB schreef op vrijdag 20 april 2007 @ 20:52:
Als ze echter wel state gebruiken, dan moet het een instantieerbaar object zijn

Daar staat niet "je moet het niet doen", daar staat dat het zo moet zijn. Toch een belangrijk nuanceverschil. Waarschijnlijk bedoel je het eerste, en daar ben ik het ook mee eens. Maar zo stond het er niet en zo vatte ik het ook niet op, vandaar mijn reactie.

Het initialiseren en opruimen van state op een gecentraliseerde plek is imho ook een goede reden. Dat je dat op een andere manier ook kunt bereiken is vanuit het oogpunt van design niet interessant.

Maar die redenatie klopt niet. Als je zegt "A, want B", terwijl B ook geldt als !A, dan is B geen valide argument voor A. A is hier natuurlijk het gebruik van een instance ipv een static, en B is het op een gecentraliseerde plek initialiseren en opruimen. Je eigenlijke argument is dat A mooier is dan !A (daar ben ik het mee eens), maar B heeft daar maar weinig mee te maken .

Dit alles natuurlijk naast het feit dat een setje functies natuurlijk technisch gezien geeneens een singleton is. Maar een setje functies zijn niet per se lelijk, en een singleton is tevens ook niet per se mooi (doorgaans worden ze te vaak gebruikt, de 'er mag er maar 1 van zijn' restrictie slaat vaak nergens op en is meestal een excuus om die ene instance via een global (functie danwel variabele) beschikbaar te maken, zodat je 'm niet overal aan mee hoeft te geven. Handig, maar nou net niet het doel van een singleton).

[ Voor 11% gewijzigd door .oisyn op 24-04-2007 15:12 ]