[PHP] Singleton nodig ?

[mcdronkz]

Ik ben bezig met een kleine applicatie waarmee ik één of meerdere camera's op afstand mee kan aansturen.

Ik heb een Camera object, hiervan worden instances gemaakt naar gelang het aantal camera's dat aangesloten is. Deze instances worden gemaakt door een cameraHandler.

Nu zit ik een beetje in dubio over de manier waarop ik de cameraHandler moet gaan aanpakken. Het is de bedoeling dat er een constructor in cameraHandler komt die de camera's gaat initialiseren en vervolgens camera objecten gaat genereren.

Voor hoever ik weet is het niet mogelijk om dit met een static class te realiseren. Hierin wordt het sowieso onmogelijk om tijdens het aanmaken van het object te camera's te initialiseren, immers, er wordt geen object aangemaakt.

Dan kan ik natuurlijk een "gewoon" object schrijven, en gewoon de constructor en dergelijke gebruiken. Maar dan denk ik, waarom zou je uberhaupt een instance van een object willen maken als je weet dat er nooit meer dan één instance gemaakt hoeft te worden ? En toen werd ik op het singleton pattern geattendeerd.

Maar wat is in deze situatie precies het nut van een singleton ? Ik kan toch ook gewoon het hele singleton principe vergeten en in m'n applicatie gewoon één instance maken... ? Meer dan één instance ga ik toch niet maken, dus wat schiet ik ermee op ? En wat is de meest wenselijke oplossing in deze situatie ?

[Muscrerior]

blaat-verhaal

[ Voor 94% gewijzigd door Muscrerior op 01-12-2008 16:28 . Reden: leesbaarheid ]

[wjv]

Als je code altijd gebruikt zal worden zo als jij bedoelt dan hoef je je daar niet druk over te maken. Maar in (grotere) omgevingen is het best handig als je met een singleton pattern kan afdwingen dat er altijd maar 1 instance van een object is. Dat kan je heel wat vervelend debug werk besparen.

[mithras]

mcdronkz schreef op maandag 01 december 2008 @ 16:22:
Ik ben bezig met een kleine applicatie waarmee ik één of meerdere camera's op afstand mee kan aansturen.

Ik heb een Camera object, hiervan worden instances gemaakt naar gelang het aantal camera's dat aangesloten is. Deze instances worden gemaakt door een cameraHandler.

Nu zit ik een beetje in dubio over de manier waarop ik de cameraHandler moet gaan aanpakken. Het is de bedoeling dat er een constructor in cameraHandler komt die de camera's gaat initialiseren en vervolgens camera objecten gaat genereren.

Voor hoever ik weet is het niet mogelijk om dit met een static class te realiseren. Hierin wordt het sowieso onmogelijk om tijdens het aanmaken van het object te camera's te initialiseren, immers, er wordt geen object aangemaakt.

Volgens mij kan het prima hoor:

PHP:

class cameraHandler{
  static function createCamera(){
    return new camera();
  }
}

class camera{
}
$camera1 = cameraHandler::createCamera();
$camera2 = cameraHandler::createCamera();

Dan kan ik natuurlijk een "gewoon" object schrijven, en gewoon de constructor en dergelijke gebruiken. Maar dan denk ik, waarom zou je uberhaupt een instance van een object willen maken als je weet dat er nooit meer dan één instance gemaakt hoeft te worden ? En toen werd ik op het singleton pattern geattendeerd.

Maar wat is in deze situatie precies het nut van een singleton ? Ik kan toch ook gewoon het hele singleton principe vergeten en in m'n applicatie gewoon één instance maken... ? Meer dan één instance ga ik toch niet maken, dus wat schiet ik ermee op ? En wat is de meest wenselijke oplossing in deze situatie ?

Met een singleton forceer je het tot een instantie. Wanneer je geen singleton gebruikt kan je daarmee rekening houden in je code, maar netter is om het meteen te verwerken in een singleton pattern.

Nu ik dit lees realiseer ik me ook dat je niet (mijn bovenstaand voorbeeld) met een static van cameraHolder zit, maar met camera zelf. In principe gebruik je het factory pattern, maar hoeft je camera geen singleton te zijn. Je kan bijvoorbeeld van hetzelfde type (=class) meerdere camera's hebben aangesloten (=instances). Dan krijg je problemen met singleton patterns.

[storeman]

Ik kan je verhaal nog niet helemaal plaatsen, maar het idee achter een singleton is dat er niet meer dan één instantie kan bestaan van een bepaalde klasse. De verantwoordelijkheid van initialiseren van het object ligt in de klasse zelf, hierdoor hoef je hier nooit naar om te kijken buiten de klasse.

Wikipedia: Singleton (informatica)

[Janoz]

Het feit dat je het over één of meerdere camera's hebt zorgt er automatisch al voor dat een singleton niet van toepassing is. En dat is nog los van het feit dat ik het hele concept singleton nogal overbodig vind in een omgeving waar objecten over het algemeen na wat milliseconden weer opgeruimd worden.

[mcdronkz]

mithras schreef op maandag 01 december 2008 @ 16:30:
[...]
Volgens mij kan het prima hoor:

PHP:

class cameraHandler{
  static function createCamera(){
    return new camera();
  }
}

class camera{
}
$camera1 = cameraHandler::createCamera();
$camera2 = cameraHandler::createCamera();

[...]
Met een singleton forceer je het tot een instantie. Wanneer je geen singleton gebruikt kan je daarmee rekening houden in je code, maar netter is om het meteen te verwerken in een singleton pattern.

Nu ik dit lees realiseer ik me ook dat je niet (mijn bovenstaand voorbeeld) met een static van cameraHolder zit, maar met camera zelf. In principe gebruik je het factory pattern, maar hoeft je camera geen singleton te zijn. Je kan bijvoorbeeld van hetzelfde type (=class) meerdere camera's hebben aangesloten (=instances). Dan krijg je problemen met singleton patterns.

Het initialiseren van de camera's wil ik nu juist binnen de cameraHandler doen, anders zou de cameraHandler uberhaupt een beetje overbodig zijn en kan ik net zo goed $camera1 = new Camera(); doen .

In cameraHandler heb ik een array met daarin de Camera objecten, die dus geinstantieerd zijn in de constructor van cameraHandler. Het gaat dus ook niet om het Camera object, dat is allemaal prima, maar echt om de cameraHandler.

[mcdronkz]

Janoz schreef op maandag 01 december 2008 @ 16:37:
Het feit dat je het over één of meerdere camera's hebt zorgt er automatisch al voor dat een singleton niet van toepassing is. En dat is nog los van het feit dat ik het hele concept singleton nogal overbodig vind in een omgeving waar objecten over het algemeen na wat milliseconden weer opgeruimd worden.

Ik denk dat ik de vraag verkeerd gesteld heb, ik begrijp natuurlijk dat er meerdere instances van het camera object moeten komen, maar het gaat hier echt om de cameraHandler. Deze cameraHandler bediend dus één of meerdere camera's en daarom hoeft er nooit meer dan één instance van gemaakt te worden.

En inderdaad, ik had ook al twijfels over hetgeen wat je naar voren brengt in je laatste zin.

[mithras]

mcdronkz schreef op maandag 01 december 2008 @ 16:42:
[...]

Het initialiseren van de camera's wil ik nu juist binnen de cameraHandler doen, anders zou de cameraHandler uberhaupt een beetje overbodig zijn en kan ik net zo goed $camera1 = new Camera(); doen .

Google maar op factory pattern. Er zijn legio casussen te verzinnen waarbij je wél op die manier wil werken (maar dat gaat een beetje offtopic).

In cameraHandler heb ik een array met daarin de Camera objecten, die dus geinstantieerd zijn in de constructor van cameraHandler. Het gaat dus ook niet om het Camera object, dat is allemaal prima, maar echt om de cameraHandler.

Tja, dat ligt aan de beschrijving van je cameraHandler. Bestaat er maar 1 van, i.e. zorgt een tweede instantie voor een hoop problemen? Om die problemen af te vangen kan je een singleton toepassen.

Janoz schreef op maandag 01 december 2008 @ 16:37:
Het feit dat je het over één of meerdere camera's hebt zorgt er automatisch al voor dat een singleton niet van toepassing is. En dat is nog los van het feit dat ik het hele concept singleton nogal overbodig vind in een omgeving waar objecten over het algemeen na wat milliseconden weer opgeruimd worden.

Op zich brengt een singleton niet bijzonder veel extra load erbij, dus je hoeft het vanwege performance niet echt te laten. Daarnaast gaat het cachen makkelijker afaik.
Tot slot kan je makkelijker een transparante structuur opzetten. In mijn cms is het cms een singleton. Ik heb een functie CMS() die de instantie van de singleton retourneert. Vervolgens kan je bijzonder makkelijk dit soort dingen doen:

PHP:

CMS()->plugin->user->isAuthorized( 'blog', 'article', 'view' );
//of
CMS()->database->query( $query );

En dat werkt gewoon overal. Geen problemen met je instances en je verschillende scopes waarin je opereert

[ Voor 36% gewijzigd door mithras op 01-12-2008 16:51 ]

[mcdronkz]

mithras schreef op maandag 01 december 2008 @ 16:47:
[...]
Tja, dat ligt aan de beschrijving van je cameraHandler. Bestaat er maar 1 van, i.e. zorgt een tweede instantie voor een hoop problemen? Om die problemen af te vangen kan je een singleton toepassen.

Het maakt werkelijk niets uit. Vandaar dat ik zelf ook het niet helemaal zie. Nu maak ik dit puur om de principes van OO te leren dus denk ik dat het niet verkeerd is om te implementeren, maar het is eigenlijk vrij overbodig.

Oh ja, en als ik dan toch een singleton zou introduceren, maakt het dan nog uit of ik de $instance variabele bovenin de class declareer of ik kan ik dat net zo goed in de method getInstance() doen ? Ik zie namelijk dat beide methoden gebruikt worden.

[ Voor 18% gewijzigd door mcdronkz op 01-12-2008 17:12 ]

[Hydra]

mcdronkz schreef op maandag 01 december 2008 @ 16:22:
Maar wat is in deze situatie precies het nut van een singleton ? Ik kan toch ook gewoon het hele singleton principe vergeten en in m'n applicatie gewoon één instance maken... ? Meer dan één instance ga ik toch niet maken, dus wat schiet ik ermee op ? En wat is de meest wenselijke oplossing in deze situatie ?

Je gebruikt een singleton niet omdat het een technisch 'probleem' oplost. Je gebruikt design patterns omdat ze je helpen een beter design te maken. Dit helpt jou (en eventuele opvolgers) op de lange termijn omdat een goed ontworpen applicatie beter uitbreidbaar en beheerbaar is.

Janoz schreef op maandag 01 december 2008 @ 16:37:
Het feit dat je het over één of meerdere camera's hebt zorgt er automatisch al voor dat een singleton niet van toepassing is. En dat is nog los van het feit dat ik het hele concept singleton nogal overbodig vind in een omgeving waar objecten over het algemeen na wat milliseconden weer opgeruimd worden.

Een goed en duidelijk design is nooit 'overbodig'. Als je een pattern herkent, waarom zou je het niet toepassen?

[ Voor 27% gewijzigd door Hydra op 01-12-2008 17:23 ]

[mcdronkz]

Hydra schreef op maandag 01 december 2008 @ 17:22:
[...]


Je gebruikt een singleton niet omdat het een technisch 'probleem' oplost. Je gebruikt design patterns omdat ze je helpen een beter design te maken. Dit helpt jou (en eventuele opvolgers) op de lange termijn omdat een goed ontworpen applicatie beter uitbreidbaar en beheerbaar is.

Daar heb je gelijk in. Maar rechtvaardigt het feit dat het aanmaken van meerdere cameraHandler instances in de toekomst voor problemen kan zorgen het gebruik van een singleton pattern ?

[Hydra]

mcdronkz schreef op maandag 01 december 2008 @ 17:24:
Daar heb je gelijk in. Maar rechtvaardigt het feit dat het aanmaken van meerdere cameraHandler instances in de toekomst voor problemen kan zorgen het gebruik van een singleton pattern ?

Als er van een object maar een instance aangemaakt MAG worden, dan lijkt me een Singleton pattern toch gewoon toepasbaar?

[mcdronkz]

Hydra schreef op maandag 01 december 2008 @ 17:29:
[...]


Als er van een object maar een instance aangemaakt MAG worden, dan lijkt me een Singleton pattern toch gewoon toepasbaar?

Ja, daar bestaat (bij mij in elk geval) geen twijfel over. Maar de vraag is in hoeverre het noodzakelijk is.

[Herko_ter_Horst]

Aangezien je zelf zegt dat het gebruik van meerdere CameraHandlers problemen kan opleveren, lijkt het antwoord me duidelijk...

Enkel het feit dat er "toevallig" maar één instantie gebruikt wordt, is geen reden om er een singleton van te maken. Als het echter niet "toevallig" is, maar er een specifieke reden is waarom er maar één instantie MAG zijn (bijvoorbeeld omdat anders het beheer van je camera's in de soep loopt), dan is dat een goede reden om er expliciet een singleton van te maken (en er dus niet meer op te vertrouwen dat het goed gaat omdat er "toevallig" maar één instantie aangemaakt wordt in je applicatie), om te voorkomen dat je per ongeluk toch 2 (of meer) van die dingen krijgt en dan ineens vreemde dingen gebeuren.

[ Voor 74% gewijzigd door Herko_ter_Horst op 01-12-2008 17:46 ]

[mcdronkz]

Herko_ter_Horst schreef op maandag 01 december 2008 @ 17:40:
Aangezien je zelf zegt dat het gebruik van meerdere CameraHandlers problemen kan opleveren, lijkt het antwoord me duidelijk...

Feitelijk zei ik dat dat in de toekomst het geval zou kunnen zijn, al lijkt die kans alsnog te verwaarlozen. Maar oké, singleton pattern wél gebruiken dus

[Herko_ter_Horst]

(Lees ook mijn edit van de post hierboven)
Ja, doen: daarmee maak je eens en voor altijd duidelijk wat de bedoeling is van dat ding.

[Janoz]

mithras schreef op maandag 01 december 2008 @ 16:47:

Op zich brengt een singleton niet bijzonder veel extra load erbij, dus je hoeft het vanwege performance niet echt te laten. Daarnaast gaat het cachen makkelijker afaik.
Tot slot kan je makkelijker een transparante structuur opzetten. In mijn cms is het cms een singleton. Ik heb een functie CMS() die de instantie van de singleton retourneert. Vervolgens kan je bijzonder makkelijk dit soort dingen doen:

PHP:

CMS()->plugin->user->isAuthorized( 'blog', 'article', 'view' );
//of
CMS()->database->query( $query );

En dat werkt gewoon overal. Geen problemen met je instances en je verschillende scopes waarin je opereert

Grappig dat je met je twee voorbeelden precies laat zien hoe een singleton normalitair absoluut niet gebruikt mag worden. Waarom kom ik zo op terug.

Hydra schreef op maandag 01 december 2008 @ 17:22:
Een goed en duidelijk design is nooit 'overbodig'. Als je een pattern herkent, waarom zou je het niet toepassen?

Ten eerste herkende ik niet het pattern mbt de camera's. Daarnaast spreek je binnen php nooit over een werkelijk singleton pattern. Zou je daadwerkelijk een situatie herkennen waarbinnen het singleton pattern van toepassing was dan zou je eerder op zoek moeten naar een ander platform. Overal waar mensen zeggen het singleton pattern te gebruiken binnen php is het eigenlijk niks anders dan een 'thread local' object wat handig toegangkelijk is.

In singleton gebruik je wanneer je gegarandeerd maat 1 instantie van een class wilt hebben over je gehele applicatie. Het singleton pattern garandeerd dat er maar 1x een constructor aangeroepen wordt. Een singleton pattern gebruik je bijvoorbeeld wanneer je een gegarandeerd uniek volgnummer wilt genereren of een pool van database connecties die gegarandeerd nooit boven de x connecties uit komt.

Binnen php wordt op geen enkele manier levende objecten gedeeld tussen de verschillende threads. Twee aanroepen die tegelijk plaatsvinden zullen er voor zorgen dat er twee objecten worden aangemaakt. Dat was nu niet precies wat je wilde voorkomen door een singleton te gebruiken.

En om nu weer terug te komen op de code van Mithras. Een methode aanroep op een singleton moet zijn als een get request: idempotent. Een singleton zou geen context of thread afhankelijke data moeten bevatten. Een 'echte' singleton implementatie van het CMS zal finaal in de soep draaien wanneer er twee mensen tegelijk een pagina op zouden vragen aangezien hetzelfde object niet naar twee database resultsets of user profiles tegelijk kan wijzen.

[g4wx3]

Mijn amateuristische mening:

Je kunt perfect zonder, dus waarom zou je het gebruiken?
Schrijf gewoon je klasse maak jeinstant aan, en concentreer je op de echte dingen.

(Ik heb hier ook ooit vragen gehad over singletons in php, omdat ik die kende uit javascript, maar in php heb je dat niet nodig, in javascript gebruik ik het de hele tijd, maar het is dan ook een heel andere manier van denken.

[Verwijderd]

g4wx3 schreef op maandag 01 december 2008 @ 19:23:
Mijn amateuristische mening:

Je kunt perfect zonder, dus waarom zou je het gebruiken?
Schrijf gewoon je klasse maak jeinstant aan, en concentreer je op de echte dingen.

(Ik heb hier ook ooit vragen gehad over singletons in php, omdat ik die kende uit javascript, maar in php heb je dat niet nodig, in javascript gebruik ik het de hele tijd, maar het is dan ook een heel andere manier van denken.

Wat heeft een andere (script)taal te maken met de manier waarop je software schrijft en hoe je over design patterns (in dit geval singleton) denkt?

Singleton objects gebruiken als handig 'thread local' en vervolgens alle functionaliteit in je app toegankelijk maken via die singleton is natuurlijk lekker handig omdat je niet erg hoeft na te denken over je ontwerp; immers je singleton object bevat alle andere nodige objecten en dus kun je elke willekeurige functionaliteit overal aanroepen. Imo lijkt dit gewoon op een verkapte functies.php waarin je alle functies declareert, met her en der een global $var er in.

Dat singleton's overbodig zijn in php ben ik het niet geheel mee eens. Ik ben het ermee eens dat het lang niet altijd nodig is, maar een db connection handler object is erg handig om als singleton te definieren, vooral als je meerdere classes hebt die iets met queries moeten doen. Nu kun je natuurlijk altijd en overal je db object meegeven in de constructor, maar er zijn genoeg redenen waarvoor je dat niet zou willen.

Daarnaast vind ik in het geval van een db object, wat dus enkel functionaliteit biedt om resultsets terug te geven na een query() (evt. uitgebreid met iterator-meuk) als singleton totaal niet erg/vies/lelijk.
Nodig? Nee, 't kan ook zonder, maar m'n code ziet er stukken leesbaarder uit, en mits goed gedocumenteerd, is het prima (zo niet beter) te onderhouden.

Daarnaast is het onmogelijk als developer om per ongeluk $db = new blabla; te doen, want dat lukt gewoon niet, zodat ik zeker weet dat de db instance altijd goed geinstantieerd is, en de connectie ook echt gelukt is.

[voodooless]

Singleton in PHP is natuurlijk een vreemd iets. Je kunt niet zeggen dat er maar een instantie is binnen je applicatie omdat, zoals Janoz al terecht opmerkte, een object maar een lifetime van enkele miliseconden heeft. twee users die dan tegelijk een pagina opvragen met een Camera object, zullen niet het zelfde object krijgen, maar twee verschillende.

Kortom, een Singleton is in php helemaal niet aan de orde

[mcdronkz]

voodooless schreef op maandag 01 december 2008 @ 21:19:
Kortom, een Singleton is in php helemaal niet aan de orde

Vind ik toch wel een beetje kort door de bocht hoor. Het is eigenlijk allemaal wel gezegd, maar zeker bij de grotere projecten met meerdere ontwikkelaars is het uitermate prettig als vastgelegd is dat er niet meer dan één instance van een object gemaakt kan worden om eventuele conflicten te voorkomen.

[Janoz]

In php is het enige dat je kunt garanderen dat er maar 1 object per request gemaakt wordt. Wanneer je drukke site 10 simultanious bezoekers heeft zullen er toch echt 10 instanties van die class zijn. Ja, wat wrapperfuncties rond een global object is leuk en zeker ook handig in een groter project, maar officieel is het geen singleton.

[voodooless]

mcdronkz schreef op maandag 01 december 2008 @ 22:51:
Vind ik toch wel een beetje kort door de bocht hoor.

Het is niet kort door de bocht, maar gewoon feitelijk correct. Ook al zijn er geen twee request in een keer, iedere keer dat er een request is wordt het object opnieuw aangemaakt. Dat er dan toevallig per request maar een instantie wordt maakt het imho nog geen singleton.

[AtleX]

Voodooless: Bij zowel ASP.net als PHP wordt een Singleton maar 1x geïnstantieerd per instantie van je applicatie. Dat bij PHP je instantie doodgaat aan het einde van de request betekent imho nog niet dat het dan geen Singleton meer mag heten.

[voodooless]

AtleX schreef op dinsdag 02 december 2008 @ 08:37:
Voodooless: Bij zowel ASP.net als PHP wordt een Singleton maar 1x geïnstantieerd per instantie van je applicatie. Dat bij PHP je instantie doodgaat aan het einde van de request betekent imho nog niet dat het dan geen Singleton meer mag heten.

Dan trek je bij php een applicatie gelijk aan een request. Dat kun je natuurlijk doen om je singleton te redden, maar wijkt wel erg af van wat bijvoorbeeld .net of Java zien als (web)applicatie.

Uiteindelijk is het maar net hoe je het wil bekijken. En ik als Java man krijg toch wel de kriebels als je dit op deze manier een singleton wil noemen

[Hydra]

voodooless schreef op dinsdag 02 december 2008 @ 09:08:
Uiteindelijk is het maar net hoe je het wil bekijken. En ik als Java man krijg toch wel de kriebels als je dit op deze manier een singleton wil noemen

Als 'java man' vind ik het vreemd dat een andere 'java man' kennelijk design patterns en de implementatietaal niet kan scheiden.

[voodooless]

Hydra schreef op dinsdag 02 december 2008 @ 10:40:
Als 'java man' vind ik het vreemd dat een andere 'java man' kennelijk design patterns en de implementatietaal niet kan scheiden.

Dat heeft er niets mee te maken. Het probleem is de definitie van applicatie. In de context van php beperkt zich dat blijkbaar tot een request. Binnen deze context kun je natuurlijk over een singleton praten.

[AtleX]

voodooless schreef op dinsdag 02 december 2008 @ 09:08:
[...]


Dan trek je bij php een applicatie gelijk aan een request.

Nee, een applicatie is een ding, dat doet verder niets. Pas als je de applicatie start gaat hij wat doen. Bij PHP wordt er bij elke request een instantie gestart, bij Java en ASP.net handelt 1 instantie van de applicatie de requests af. De levendsduur van een instantie is verschillend bij de systemen, maar dat neemt niet weg dat het principe van een Singleton hierbij gelijk blijft: Een Singleton wordt 1x geïnstantieerd tijdens de lifecycle van een instantie van een applicatie.

[Janoz]

Een singleton is een pattern dat je gebruikt om in een multithreaded omgeving garanties te kunnen geven.

Definieer je een request als een applicatie dan is er geen sprake van een multithreaded omgeving. Definieer je de web applicatie ansich als applicatie dan is er geen application scope waarbinnen je kunt garanderen dat er 1 instance is.

Hieruit blijkt dat de gebruikte omgeving daadwerkelijk van invloed is op het kunnen toepassen van een bepaald pattern.

De enige manier om daadwerkelijk een singleton pattern te implementeren in php, is gebruik te maken van de shared memory library.

[AtleX]

Janoz schreef op dinsdag 02 december 2008 @ 11:02:
Een singleton is een pattern dat je gebruikt om in een multithreaded omgeving garanties te kunnen geven.

Wikipedia omschrijft het Singleton pattern als volgt:

quote: http://en.wikipedia.org/wiki/Singleton_pattern

In software engineering, the singleton pattern is a design pattern that is used to restrict instantiation of a class to one object.

En Google's zoekresultaten zijn het daar mee eens. Singletons zijn imho ook prima bruikbaar in een single-thread omgeving waarbij je simpelweg maar 1 instantie van een object wilt hebben.

[Janoz]

AtleX schreef op dinsdag 02 december 2008 @ 11:00:
[...]

Nee, een applicatie is een ding, dat doet verder niets. Pas als je de applicatie start gaat hij wat doen. Bij PHP wordt er bij elke request een instantie gestart, bij Java en ASP.net handelt 1 instantie van de applicatie de requests af. De levendsduur van een instantie is verschillend bij de systemen, maar dat neemt niet weg dat het principe van een Singleton hierbij gelijk blijft: Een Singleton wordt 1x geïnstantieerd tijdens de lifecycle van een instantie van een applicatie.

Een applicatie is niet enkel een ding. In andere omgevingen dan php is het een goed gedefinieerde scope. Wat Voodooless zegt is dus precies wat jij hierboven ook zegt. Je reactie is dus wat vreemd. Je zegt oneens te zijn met Voodooless, maar verteld vervolgens hetzelfde verhaal. Jij definieerd "application scope == request scope" om het singleton pattern 'recht te breien'.

[voodooless]

Janoz schreef op dinsdag 02 december 2008 @ 11:13:
Jij definieerd "application scope == request scope" om het singleton pattern 'recht te breien'.

Dat is dus precies wat ik bedoel

[mithras]

Janoz schreef op dinsdag 02 december 2008 @ 11:13:
[...]

Jij definieerd "application scope == request scope" om het singleton pattern 'recht te breien'.

Ik zou het niet echt "recht breien" noemen. Dat impliceert alsof het eigenlijk niet waar is, maar dat je met wat kromme argumenten het wel kan beargumenteren.

Iedereen beschrijft hier een singleton in de gehele application scope. Omdat bij php de application scope gelijk is aan de request scope, is het een logisch gevolg dat singletons alleen gedurende één request blijven bestaan. Dat heeft niets te maken met multithreaded omgevingen, maar is gewoon het volgen van je definitie en de daarop toegepaste logica.

Wat verder gevolgen zijn van singletons in php lijkt me niet van belang om te bepalen of een singleton in php überhaupt bestaat.

[Janoz]

AtleX schreef op dinsdag 02 december 2008 @ 11:12:
[...]

Wikipedia omschrijft het Singleton pattern als volgt:

[...]

En Google's zoekresultaten zijn het daar mee eens. Singletons zijn imho ook prima bruikbaar in een single-thread omgeving waarbij je simpelweg maar 1 instantie van een object wilt hebben.

Zoek dan ook even door om te achterhalen waarom je een singleton pattern gebruikt. Wat het achterliggende probleem is dat door een singleton pattern opgelost wordt. Het enige echte voordeel van het 'singleton pattern' in php is het schoonhouden van de global namespace. De andere voordelen als een enkele instantie, efficiente lazy loading gaan niet op.

Nemen we het voorbeeld van die camera erbij. Stel dat je een object hebt waarmee je de camera kunt bedienen. Je kunt echter maar 1 connectie met de camera opzetten om hem aan te sturen. Zodra er een tweede connectie met de camera opgezet wordt, wordt deze geweigerd. Een situatie waarop je het singleton pattern toe zou kunnen passen.

Hoe doe je dit in php? Volgens mij niet. Je kunt op geen enkele manier de verbinding met de camera overdragen van het ene request naar het andere request. Twee simultane request zullen er voor zorgen dat één van beiden een foutmelding zou krijgen. Kortom, het probleem is op te lossen met en singleton pattern, maar dat valt niet te implementeren in php.

mithras schreef op dinsdag 02 december 2008 @ 11:22:
[...]
Ik zou het niet echt "recht breien" noemen. Dat impliceert alsof het eigenlijk niet waar is, maar dat je met wat kromme argumenten het wel kan beargumenteren.

Iedereen beschrijft hier een singleton in de gehele application scope. Omdat bij php de application scope gelijk is aan de request scope, is het een logisch gevolg dat singletons alleen gedurende één request blijven bestaan. Dat heeft niets te maken met multithreaded omgevingen, maar is gewoon het volgen van je definitie en de daarop toegepaste logica.

Wat verder gevolgen zijn van singletons in php lijkt me niet van belang om te bepalen of een singleton in php überhaupt bestaat.

Juist wel. De problemen die door singletons opgelost worden, worden niet opgelost met de standaard php implementaties zoals ik hierboven laat zien. De vraag is dan ook of je het dan nog steeds een singleton mag noemen, en mijn antwoord daarop is dan 'eigenlijk niet echt'.

Het promoveren van de request scope naar application scope noem ik een krom argument.

Daarnaast heeft het wel degelijk met multithreaded omgevingen te maken. Een php webapplicatie is namelijk wel degelijk een multithreaded omgeving, maar dan ééntje zonder een application scope.

[ Voor 31% gewijzigd door Janoz op 02-12-2008 11:35 ]

[Herko_ter_Horst]

Janoz schreef op dinsdag 02 december 2008 @ 11:30:
Juist wel. De problemen die door singletons opgelost worden, worden niet opgelost met de standaard php implementaties zoals ik hierboven laat zien. De vraag is dan ook of je het dan nog steeds een singleton mag noemen, en mijn antwoord daarop is dan 'eigenlijk niet echt'.

Het promoveren van de request scope naar application scope noem ik een krom argument.

Je kan het ook andersom bekijken: design patterns zijn taal-onafhankelijk. Het feit dat PHP geen "application scope" heeft, kun je zien als een implementatie-detail van de standaard PHP omgeving. Voor je design zou het niet uit moeten maken. Dus als je de CameraManager in een Java omgeving als singleton kan implementeren, dan hier ook.

Je moet je er dan uiteraard wel van bewust zijn, dat deze specifieke omgeving geen "echte" support biedt voor singletons.

[mcdronkz]

Ik geloof dat ik begin te begrijpen wat hier gezegd wordt. Even resumerend: het is bij een PHP applicatie zo dat er eigenlijk een nieuwe instance van de applicatie wordt gemaakt bij elk request dat er plaatsvindt. Je kunt dan wel leuk een singleton pattern gaan implementeren, maar dat voorkomt dus niet dat er tijdens een ander request gewoon een nieuwe instance van de applicatie (en daarmee ook van het object) wordt aangemaakt.

De cameraHandler is gerust een halve seconde bezig (zit 'm in de achterliggende software, gphoto2) en ik kan dus niet voorkomen dat er op een bepaald moment twee mensen bezig zijn om tegelijkertijd de camera's te initialiseren omdat er per request toch nog een instance van de applicatie en het object wordt aangemaakt.

Nu is dat in mijn eigenlijk geen probleem hoor, of laat ik zeggen: ik heb nog geen problemen ondervonden, maar ik kan me situaties indenken waarin je dat gelazer niet wilt hebben omdat je bijvoorbeeld simultaan naar bestanden zit te schrijven of iets dergelijks, en dat wil je liever voorkomen of in elk geval goed in de hand hebben. Immers, anders loop je de kans om I/O errors en dergelijke te krijgen. Ik denk dat het toch wel belangrijk is om daar rekening mee te houden, ik had het in elk geval over het hoofd gezien.

Je leert nog eens wat hier. Als bovenstaand nou nergens op slaat, verbeter me effe dan.

[Verwijderd]

Je kunt het hooguit simuleren als je gebruik maakt van shared memory en een eigen soort locking aangezien je niet iets als een mutex kunt gebruiken. Een workaround is bijvoorbeeld een tijdelijk bestand ergens maken, als dat nog niet bestaat, en weer verwijderen als een proces klaar is met de resource. Bestaat het bestand al? Dan moet er ofwel gewacht worden, of er moet worden doorgegeven dat er geen lock kon worden verkregen. MAar heb blijft een beetje behelpen.

Wat je misschien beter kunt doen, is dit in in bijvoorbeeld Java schrijven.

[Janoz]

Herko_ter_Horst schreef op dinsdag 02 december 2008 @ 18:25:
[...]

Je kan het ook andersom bekijken: design patterns zijn taal-onafhankelijk. Het feit dat PHP geen "application scope" heeft, kun je zien als een implementatie-detail van de standaard PHP omgeving. Voor je design zou het niet uit moeten maken. Dus als je de CameraManager in een Java omgeving als singleton kan implementeren, dan hier ook.

Je moet je er dan uiteraard wel van bewust zijn, dat deze specifieke omgeving geen "echte" support biedt voor singletons.

Een design pattern is zeker taal onafhankelijk, maar dat betekend niet dat het onafhankelijk is van de features die de taal bied. Nogmaals, voor je design is het van uitermate belang dat je weet om te gaan met die beperkingen. Ik dacht dat ik al had laten zien waarom de gebruikelijke php 'singleton' implementaties niet dezelfde functionaliteit bieden en de problemen oplossen als bv een java implementatie.