Hoe lang duurt het voo..
OO PHP -> Singleton
Ik ben al een geruime tijd bezig met het opzetten van een Object Oriented PHP Blog. Ik ben nu zover dat een pagina al voor het grootste deel uit classen en modules bestaat. De pagina redenderd al goed alleen is de code er achter nog niet compleet. Er staat nog van alles hardcoded in en dat moet er nog uit.
Alleen zit ik met een dillema over een paar classen. Je hebt natuurlijk classen die je overal wilt gebruiken (configuratie, database, taal, template Engine). Nu had ik bedacht om hier allemaal singleton objecten van te maken zodat ik er vanuit elke andere class bij kan maar volgensmij ga je dan echt puur misbruik maken van het Singleton concept.
Verder is het zo dat je misschien wel eens ooit 2 databases zou willen gaan gebruiken. Dit kan dan niet meer omdat 't een singleton class is. De classes die een db verbinding nodig hebben een instantie van deze class meesturen is echter onmogelijk door mijn engine opzet. Ik kan vanuit mijn engine alleen lege constructors aanroepen en de class moet dan zelf de rest afhandelen.
Wat vinden jullie de mooiste oplossing? Toch de singleton objecten gebruiken of mijn engine aanpassen zodat ik wel parameters door kan geven (Ik heb nog geen idee hoe je die 't beste uit kan werken). Nog een andere optie is om de engine instantie door te geven aan elke (GUI)class zodat ze zelf instanties van een database of template engine kunnen ophalen uit de Engine class. Dit laatste doe ik in Java ook vaak als ik bijvoorbeeld vanuit een Panel iets van mijn Frame moet aanspreken. Dan geef ik 't Frame object mee aan het Panel. Mocht er dan een object bij de engine toegevoegt moeten worden dan zou je de engine kunnen extenden en daar een extra methode / property aan toe kunnen voegen. Tevens moet je dan natuurlijk bij de index.php oid de nieuwe class aanroepen.
Mijn voorkeur gaat op dit moment uit naar de laatste methode waar ik overal de Engine instantie doorgeef aan alle modules maar ik wil graag weten hoe jullie hierover denken en of jullie misschien nog andere ideeen hebben. Hieronder staat nog wat verduidelijking van mijn ontwerp en een beschrijving van 't singleton pattern zoals ik 't geleerd heb.
Verdere informatie over mijn ontwerp
In de database heb ik een aantal tabellen (pages, modules en attachments) koppeltabellen negeer ik even. Aan een page kunnen meerdere modules gekoppelt worden. Een module heeft een classname en een location (waar de class file zich bevind). Als ik nu bijv. de pagina blog aanroep dan zijn daar 4 modules (classen) aan gekoppelt. Een header, de blog, recente blog items en een footer. Deze worden dan als volgt aangemaakt:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
<php
foreach ($modules as $module)
{
new $module();
}
?>
foreach ($modules as $module)
{
new $module();
}
?>
Hierdoor kan ik dus verder geen parameters meegeven aan de modules.
UML Diagram: Blog UML Diagram (gif)
Uitleg over het Singleton design pattern:
Singleton is een soort container class die maar 1 instantie in je programma mag hebben. De class komt dus maar 1x voor. 't komt er eigenlijk op neer dat je een Singleton class overal aan kan roepen in elke andere class. Zoals wij 't op school geleerd hebben heeft een Singleton class meestal een addElement(), removeElement() en getElement(). Ik zou (in mijn ogen) het singleton pattern dan gaan misbruiken door er gewoon een soort van public variabele te maken.
Voorbeeld van (volgensmij) een goede toepassing van het Singleton pattern: Stel je hebt een chat programma. Dit programma heeft een lijst met gebruikers. Je wilt er zeker van zijn dat je maar 1 lijst met gebruikers hebt dus je maakt een singleton class met methoden addGebruiker, removeGebruiker, getGebruiker etc. De singleton class is dus een lijst met Gebruiker objecten.
Gewijzigd op 01/01/1970 01:00:00 door Roy Bongers
Voor database e.a. resources heb ik een soort van register, dat gebaseerd is op het Singelton pattern. Classes (handlers in mijn geval) kunnen via Base::acquire('database'); de instantie van mijn db-klasse raadplegen die ik met Base::regiser('database', new DatabaseControler(enz)); heb aangemaakt. En dat zo ook met mijn MainViewport en eventuele verbindingen naar buiten.
Ik gebruik dus alleen daar het singelton pattern, voor methods die eigenlijk prima als losstaande functies kunnen werken, en dus waar je niet met variabele omstandigheden te maken hebt (zoals bij een database object, die met verschillende database connecties geïnstantieerd kan zijn) zoals JSON::serialize en JSON::unserialize (wrapper voor pear::json) en Event::register, Event::trigger (er is maar 1 event-register), Base::loadHandler (geld immers voor hele scope, dus geen variabele omstandigheden) enz.
Door het Registry Pattern door te voeren hoef ik helemaal niks meer via de constructors door te sturen en kunnen ze dus leeg blijven. Elke class kan registry items toevoegen mocht hij iets nodig hebben En de engine voegt zelf al de template engine, config, db, en language objecten toe omdat die altijd nodig zijn. Verder zal daar denk ik nog een object bij komen met pagina details (title, meta info, rss feeds en extra css / javascripts).
Theoretisch gezien heb je volgensmij nu nog steeds een global object waarvandaan je alles aan kan roepen maar je kan nu inderdaad ook meerdere db connecties aan je registry hangen wat normaal niet zou kunnen als je je database class singleton zou maken bijv.
Bedankt! Volgensmij heb ik mijn ontwerp compleet nu.
Leuk gif-plaatje!!!