class zonder public method?
En dus doe jij wat jij het mooist vind.
Ozzie PHP op 11/11/2013 20:52:33:
Oké... maar iemand anders op het forum zegt dat wanneer je een object aanmaakt het altijd zo goed als gebruiksklaar moet zijn.
Dit hoeft niet perse in strijd te zijn met mijn verwachtingen van constructors. De vraag tijdens het schrijven van de constructor is dan "Wat is verplicht, wat is optioneel, en welke optionele dingen wil ik via de constructor in kunnen stellen?"
Op basis van welke parameters ik aan de constructor geef krijg in een object in de staat (state) die ik wil.
Of dit volledig geïnitialiseert is, of maar voor een deel hangt er vanaf wat ik nodig heb.
Of de constructor zo geschreven is dat het object altijd volledig geïnitialiseert uit de constructor komt, of niet hangt er vanaf wat ik nodig heb.
Zoiets is een stuk beter dan een class met alleen maar non-public methods waar jij de instatie nooit van gebruikt.
Code (php)
(Wanneer zou je trouwens een autoloader willen unregisteren?)
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
<?php
new Autoloader;
// versus
Autoloader::init();
?>
new Autoloader;
// versus
Autoloader::init();
?>
Zoals ik eerder zei, als ik 'new Autoloader;' zie staan -zonder het op te slaan in een variabele- ga ik er vanuit dat het weg kan. Constructors initialiseren objecten. Maar met het object wordt niets gedaan. Ik zal er waarschijnlijk niet van uit gaan dat de environment geïnitialiseert wordt door de constructor van Autoloader. De scope van een constructor is het object.
Je zou ook de hele Autoloader::init() in de global scope in je bootstrap/kernel/whatever kunnen zetten. Ik heb geen sterke voorkeur zolang je het maar niet vanuit een constructor doet!
Je kan autoloaders unregisteren om onnodige aanroepen naar die autoloader te voorkomen wanneer je voorbij een punt bent waar je die autoloader nodig had om library X correct te laten werken.
Stel je gebruikt een library om emails te versturen. De emails zijn verstuurd. Vervolgens ga je een library gebruiken om een form op te bouwen. Elk element wordt voorgesteld door zijn eigen class. Dat betekend veel calls naar de autoloaders. Waarom zou je de email library's autoloader nog laten zoeken? Wat is het nut? Het kost alleen maar tijd.
Gewijzigd op 11/11/2013 22:00:46 door Dos Moonen
Oké... en nu wordt het dus even lastig te begrijpen voor mij. Ik heb hier namelijk onlangs een hele discussie over gehad hier op het forum. Ik ging er vanuit dat een constructor uitsluitend bedoeld was om een class "gebruiksklaar" te maken.
Ik ga je een voorbeeld geven en dan ben ik benieuwd hoe jij dat ziet.
Stel ik heb een class waarin ik paths kan opslaan. Deze paths worden voorafgegaan door een path_prefix. Mijn idee was dan ongeveer dit:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$path_prefix = 'root/foo/bar/';
$paths = new Paths($path_prefix);
$paths->add($paths_array);
?>
$path_prefix = 'root/foo/bar/';
$paths = new Paths($path_prefix);
$paths->add($paths_array);
?>
Wat je dus ziet is dat ik de $path_prefix meegeef aan de constructor. De constructor set $path_prefix als class property. Dit was mijn idee van wat een constructor behoort te doen. De class "gebruiksklaar" maken. Nu is de class gebruiksklaar en kun je er paden aan toevoegen.
Vorige week werd me verteld dat dat niet goed is, omdat je op deze manier direct na het constructen van de class een leeg "omhulsel" hebt. Je hebt een class waar niks in zit. Dat zou niet moeten. Daarom moet je de $paths_array direct al via de constructor meegeven:
Code (php)
1
2
3
2
3
<?php
$paths = new Paths($paths_array, $path_prefix);
?>
$paths = new Paths($paths_array, $path_prefix);
?>
Er werd dus gezegd dat het "vullen" van een class door de constructor moet gebeuren, zodat je meteen na het instantiëren een "gevuld" object hebt en niet een leeg omhulsel.
Maar jij lijkt nu weer iets anders te zeggen, dus ik begin het spoor een beetje kwijt te raken... Snap je?
>> Je kan autoloaders unregisteren om ...
Ah, oke... op die manier. Duidelijk!
Gewijzigd op 11/11/2013 22:14:48 door Ozzie PHP
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
<?php
$path_prefix = 'root/foo/bar/';
$paths = new Paths($path_prefix);
... // misschien een paar regels verder, misschien 8 calls dieper, wie weet
$paths->add($paths_array);
?>
$path_prefix = 'root/foo/bar/';
$paths = new Paths($path_prefix);
... // misschien een paar regels verder, misschien 8 calls dieper, wie weet
$paths->add($paths_array);
?>
Dit is MISSCHIEN gewild. Het kan zijn dat het nodig is om een kip-of-het-ei probleem te voorkomen. Of een andere zeldzame reden.
Code (php)
1
2
3
2
3
<?php
$paths = new Paths($paths_array, $path_prefix);
?>
$paths = new Paths($paths_array, $path_prefix);
?>
Dat zal over het algemeen gewild zijn. Volgens de vuistregel is dat hoe je het doet. Het feit dat ik zeg dat het niet altijd het geval is moet je voorlopig proberen te vergeten.
Gewijzigd op 11/11/2013 22:32:20 door Dos Moonen
Code (php)
1
2
3
2
3
<?php
$paths = new Paths($paths_array, $path_prefix);
?>
$paths = new Paths($paths_array, $path_prefix);
?>
Dan wordt er toch ook "onderwater" een method uitgevoerd die je niet ziet?
En dan kom ik weer bij mijn eerdere voorbeeld, waar ik eigenlijk telkens geen antwoord op krijg...
Stel we hebben een taart die door een class in stukken moet worden gesneden... wie moet dan de opdracht geven om de taart in stukken te snijden:
Hier geef ik de opdracht zelf:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$taart_snijder = new TaartSnijder($taart);
$taart_snijder->snijTaart();
$gesneden_taart = $taart_snijder->get();
?>
$taart_snijder = new TaartSnijder($taart);
$taart_snijder->snijTaart();
$gesneden_taart = $taart_snijder->get();
?>
Maar ik kan ook de constructor de opdracht laten geven, en dan ziet de code er zo uit:
Code (php)
1
2
3
4
2
3
4
<?php
$taart_snijder = new TaartSnijder($taart);
$gesneden_taart = $taart_snijder->get();
?>
$taart_snijder = new TaartSnijder($taart);
$gesneden_taart = $taart_snijder->get();
?>
Beiden stukjes code doen hetzelfde, maar wat is de juiste manier? De taart moet altijd in stukken worden gesneden, dus zou ik denken dat de constructor hier opdracht voor mag geven... ???
Ozzie PHP op 11/11/2013 22:37:42:
Dan wordt er toch ook "onderwater" een method uitgevoerd die je niet ziet?
Is er zo'n methode nodig? Je kan het ook in de constructor doen zonder een andere methode er voor aan te roepen. Dus is het voor wat jij wilt doen nodig om zo'n methode te hebben?
Ozzie PHP op 11/11/2013 22:37:42:
Stel we hebben een taart die door een class in stukken moet worden gesneden... wie moet dan de opdracht geven om de taart in stukken te snijden:
Hier geef ik de opdracht zelf:
Maar ik kan ook de constructor de opdracht laten geven, en dan ziet de code er zo uit:
Beiden stukjes code doen hetzelfde, maar wat is de juiste manier? De taart moet altijd in stukken worden gesneden, dus zou ik denken dat de constructor hier opdracht voor mag geven... ???
Hier geef ik de opdracht zelf:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$taart_snijder = new TaartSnijder($taart);
$taart_snijder->snijTaart();
$gesneden_taart = $taart_snijder->get();
?>
$taart_snijder = new TaartSnijder($taart);
$taart_snijder->snijTaart();
$gesneden_taart = $taart_snijder->get();
?>
Maar ik kan ook de constructor de opdracht laten geven, en dan ziet de code er zo uit:
Code (php)
1
2
3
4
2
3
4
<?php
$taart_snijder = new TaartSnijder($taart);
$gesneden_taart = $taart_snijder->get();
?>
$taart_snijder = new TaartSnijder($taart);
$gesneden_taart = $taart_snijder->get();
?>
Beiden stukjes code doen hetzelfde, maar wat is de juiste manier? De taart moet altijd in stukken worden gesneden, dus zou ik denken dat de constructor hier opdracht voor mag geven... ???
Ik zou het beiden herschrijven naar iets als dit:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
<?php
$taart = new AppelTaart(Vorm::CIRKEL, array(new Kaneel, new Krent, new Walnoot));
$vlaai = new Vlaai(Vorm::CIRKEL, array(new Kokos, new Chocolade));
$taartMes = new TaartMes(TaartMes::DUBBELZIJDIG); // kans van 1 op 384 op een SnijWondException
$taartStukken = $taartMes->verdeel($taart, 10); // tien gelijke stukken
$vlaaiStukken = $taartMes->verdeel($vlaai, array(1, 1, 2, 2, 2, 3, 3, 5)); 8 stukken met groote van $value/array_sum(array(1, 1, 2, 2, 2, 3, 3, 5))
?>
$taart = new AppelTaart(Vorm::CIRKEL, array(new Kaneel, new Krent, new Walnoot));
$vlaai = new Vlaai(Vorm::CIRKEL, array(new Kokos, new Chocolade));
$taartMes = new TaartMes(TaartMes::DUBBELZIJDIG); // kans van 1 op 384 op een SnijWondException
$taartStukken = $taartMes->verdeel($taart, 10); // tien gelijke stukken
$vlaaiStukken = $taartMes->verdeel($vlaai, array(1, 1, 2, 2, 2, 3, 3, 5)); 8 stukken met groote van $value/array_sum(array(1, 1, 2, 2, 2, 3, 3, 5))
?>
Telkens heb ik objecten waar ik meteen iets mee kan doen.
Die class kan dus niks anders dan kersen uit de taart halen. Je kunt verder niks bepalen. Stop je dan de functie die de kersen uit de taart haalt in de constructor? Of moet je een method aanroepen?
Worden de kersen door (in opdracht van) de constructor verwijderd:
Code (php)
1
2
3
4
2
3
4
<?php
$kers_verwijderaar = new KersVerwijderaar($taart); // op dit moment worden de kersen via de constructor direct verwijderd
$kale_taart = $kers_verwijderaar->getTaart();
?>
$kers_verwijderaar = new KersVerwijderaar($taart); // op dit moment worden de kersen via de constructor direct verwijderd
$kale_taart = $kers_verwijderaar->getTaart();
?>
of geef je de opdracht tot het verwijderen van de kersen zelf?
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$kers_verwijderaar = new KersVerwijderaar($taart); // op dit moment zitten de kersen er nog op!
$kers_verwijderaar->verwijderKersen(); // nu pas worden de kersen verwijderd
$kale_taart = $kers_verwijderaar->getTaart();
?>
$kers_verwijderaar = new KersVerwijderaar($taart); // op dit moment zitten de kersen er nog op!
$kers_verwijderaar->verwijderKersen(); // nu pas worden de kersen verwijderd
$kale_taart = $kers_verwijderaar->getTaart();
?>
Ik ga proberen mijn vraag zo duidelijk mogelijk te formuleren. In het laatste voorbeeld zie je in de code dat de kersen worden verwijderd. Immers er staat $kers_verwijderaar->verwijderKersen(); Je zou dus kunnen zeggen dat deze code misschien duidelijker is dan het 1e voorbeeld waarin je dit niet kunt zien.
Echter... welk voorbeeld is logischer? Het enige wat de KersVerwijderaar class kan is kersen verwijderen, en dat kan ook maar 1x, want daarna zijn ze al verwijderd. Vanuit dat oogpunt is het dus logischer dat de constructor opdracht geeft om de kersen te verwijderen. Alleen je ziet dit dan niet terug in de code zoals in het 2e voorbeeld.
In dit specifieke voorbeeld, wat zou dan de juiste variant zijn. Ga je voor de logische variant (de 1e optie) die precies doet wat ie moet doen, of ga je voor de 2e variant, waarbij je eigenlijk onnodig een functie moet aanroepen, maar waardoor je wel weer duidelijker ziet wat er gebeurt?
Toevoeging op 12/11/2013 01:45:35:
Dos Moonen op 11/11/2013 21:59:38:
Je kan autoloaders unregisteren om onnodige aanroepen naar die autoloader te voorkomen wanneer je voorbij een punt bent waar je die autoloader nodig had om library X correct te laten werken.
Stel je gebruikt een library om emails te versturen. De emails zijn verstuurd. Vervolgens ga je een library gebruiken om een form op te bouwen. Elk element wordt voorgesteld door zijn eigen class. Dat betekend veel calls naar de autoloaders. Waarom zou je de email library's autoloader nog laten zoeken? Wat is het nut? Het kost alleen maar tijd.
Stel je gebruikt een library om emails te versturen. De emails zijn verstuurd. Vervolgens ga je een library gebruiken om een form op te bouwen. Elk element wordt voorgesteld door zijn eigen class. Dat betekend veel calls naar de autoloaders. Waarom zou je de email library's autoloader nog laten zoeken? Wat is het nut? Het kost alleen maar tijd.
Nog even een vraag hierover he... als ik jou goed begrijp register en unregister jij dus regelmatig autoloaders? Van de ene kant snap ik wat je doet, maar van de andere kant vraag ik me ook af of je daarmee het nut van een autoloader niet teniet doet.
Een autoloader dient voor gemakt, zodat je ongestoord classes kunt aanroepen. Op de manier hoe jij het doet, moet je nu constant autoloaders gaan registeren en unregisteren. Maak je het jezelf dan niet heel lastig?
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<?php
// register default autoloader
// code...
// Er treedt een Exception op..
// De exception moet gemaild worden...
// register de mail autoloader
// stuur een mail
// unregister de mail autoloader
// code...
// er moet een pdf gemaakt worden
// register de pdf autoloader
// maak een pdf
// het creëren van de pdf gaat mis
// Er treedt een Exception op..
// De exception moet gemaild worden...
// register de mail autoloader
// stuur een mail
// unregister de mail autoloader
// unregister de pdf autoloader
// log de Exception
// register de logger autoloader
// log de Exception
// unregister de logger autoloader
// enz.
?>
// register default autoloader
// code...
// Er treedt een Exception op..
// De exception moet gemaild worden...
// register de mail autoloader
// stuur een mail
// unregister de mail autoloader
// code...
// er moet een pdf gemaakt worden
// register de pdf autoloader
// maak een pdf
// het creëren van de pdf gaat mis
// Er treedt een Exception op..
// De exception moet gemaild worden...
// register de mail autoloader
// stuur een mail
// unregister de mail autoloader
// unregister de pdf autoloader
// log de Exception
// register de logger autoloader
// log de Exception
// unregister de logger autoloader
// enz.
?>
Lijkt me wat omslachtig...
Gewijzigd op 12/11/2013 01:48:25 door Ozzie PHP
Ozzie PHP op 11/11/2013 23:50:43:
Echter... welk voorbeeld is logischer? Het enige wat de KersVerwijderaar class kan is kersen verwijderen, en dat kan ook maar 1x, want daarna zijn ze al verwijderd. Vanuit dat oogpunt is het dus logischer dat de constructor opdracht geeft om de kersen te verwijderen. Alleen je ziet dit dan niet terug in de code zoals in het 2e voorbeeld.
In dit specifieke voorbeeld, wat zou dan de juiste variant zijn. Ga je voor de logische variant (de 1e optie) die precies doet wat ie moet doen, of ga je voor de 2e variant, waarbij je eigenlijk onnodig een functie moet aanroepen, maar waardoor je wel weer duidelijker ziet wat er gebeurt?
In dit specifieke voorbeeld, wat zou dan de juiste variant zijn. Ga je voor de logische variant (de 1e optie) die precies doet wat ie moet doen, of ga je voor de 2e variant, waarbij je eigenlijk onnodig een functie moet aanroepen, maar waardoor je wel weer duidelijker ziet wat er gebeurt?
Een 3e variant biedt je beide in één expressie: logisch en inzichtelijk.
Code (php)
1
2
3
2
3
<?php
$kale_taart = KersVerwijderaar::verwijderKersen($taart);
?>
$kale_taart = KersVerwijderaar::verwijderKersen($taart);
?>
Ozzie PHP op 11/11/2013 23:50:43:
Een autoloader dient voor gemakt, zodat je ongestoord classes kunt aanroepen. Op de manier hoe jij het doet, moet je nu constant autoloaders gaan registeren en unregisteren. Maak je het jezelf dan niet heel lastig?
Lijkt me wat omslachtig...
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<?php
// register default autoloader
// code...
// Er treedt een Exception op..
// De exception moet gemaild worden...
// register de mail autoloader
// stuur een mail
// unregister de mail autoloader
// code...
// er moet een pdf gemaakt worden
// register de pdf autoloader
// maak een pdf
// het creëren van de pdf gaat mis
// Er treedt een Exception op..
// De exception moet gemaild worden...
// register de mail autoloader
// stuur een mail
// unregister de mail autoloader
// unregister de pdf autoloader
// log de Exception
// register de logger autoloader
// log de Exception
// unregister de logger autoloader
// enz.
?>
// register default autoloader
// code...
// Er treedt een Exception op..
// De exception moet gemaild worden...
// register de mail autoloader
// stuur een mail
// unregister de mail autoloader
// code...
// er moet een pdf gemaakt worden
// register de pdf autoloader
// maak een pdf
// het creëren van de pdf gaat mis
// Er treedt een Exception op..
// De exception moet gemaild worden...
// register de mail autoloader
// stuur een mail
// unregister de mail autoloader
// unregister de pdf autoloader
// log de Exception
// register de logger autoloader
// log de Exception
// unregister de logger autoloader
// enz.
?>
Lijkt me wat omslachtig...
Zo omslachtig is dat soms inderdaad. Verwerk maar eens een bestelling voor een webwinkel. Een geslaagde betaling (namespace betaalprovider) leidt tot het mailen (namespace mailer) van een PDF (namespace PDF-framework) en een order (namespace fulfilment) die je meteen inschiet bij de vervoerder (PostNL namespace). En ondertussen moet je eigen framework nog iets fatsoenlijks op het scherm van de klant toveren...
Gewijzigd op 12/11/2013 08:47:02 door Ward van der Put
Ozzie PHP op 11/11/2013 23:50:43:
Die class kan dus niks anders dan kersen uit de taart halen. Je kunt verder niks bepalen. Stop je dan de functie die de kersen uit de taart haalt in de constructor? Of moet je een method aanroepen?
Worden de kersen door (in opdracht van) de constructor verwijderd:
of geef je de opdracht tot het verwijderen van de kersen zelf?
Ik ga proberen mijn vraag zo duidelijk mogelijk te formuleren. In het laatste voorbeeld zie je in de code dat de kersen worden verwijderd. Immers er staat $kers_verwijderaar->verwijderKersen(); Je zou dus kunnen zeggen dat deze code misschien duidelijker is dan het 1e voorbeeld waarin je dit niet kunt zien.
Echter... welk voorbeeld is logischer? Het enige wat de KersVerwijderaar class kan is kersen verwijderen, en dat kan ook maar 1x, want daarna zijn ze al verwijderd. Vanuit dat oogpunt is het dus logischer dat de constructor opdracht geeft om de kersen te verwijderen. Alleen je ziet dit dan niet terug in de code zoals in het 2e voorbeeld.
In dit specifieke voorbeeld, wat zou dan de juiste variant zijn. Ga je voor de logische variant (de 1e optie) die precies doet wat ie moet doen, of ga je voor de 2e variant, waarbij je eigenlijk onnodig een functie moet aanroepen, maar waardoor je wel weer duidelijker ziet wat er gebeurt?
Worden de kersen door (in opdracht van) de constructor verwijderd:
Code (php)
1
2
3
4
2
3
4
<?php
$kers_verwijderaar = new KersVerwijderaar($taart); // op dit moment worden de kersen via de constructor direct verwijderd
$kale_taart = $kers_verwijderaar->getTaart();
?>
$kers_verwijderaar = new KersVerwijderaar($taart); // op dit moment worden de kersen via de constructor direct verwijderd
$kale_taart = $kers_verwijderaar->getTaart();
?>
of geef je de opdracht tot het verwijderen van de kersen zelf?
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$kers_verwijderaar = new KersVerwijderaar($taart); // op dit moment zitten de kersen er nog op!
$kers_verwijderaar->verwijderKersen(); // nu pas worden de kersen verwijderd
$kale_taart = $kers_verwijderaar->getTaart();
?>
$kers_verwijderaar = new KersVerwijderaar($taart); // op dit moment zitten de kersen er nog op!
$kers_verwijderaar->verwijderKersen(); // nu pas worden de kersen verwijderd
$kale_taart = $kers_verwijderaar->getTaart();
?>
Ik ga proberen mijn vraag zo duidelijk mogelijk te formuleren. In het laatste voorbeeld zie je in de code dat de kersen worden verwijderd. Immers er staat $kers_verwijderaar->verwijderKersen(); Je zou dus kunnen zeggen dat deze code misschien duidelijker is dan het 1e voorbeeld waarin je dit niet kunt zien.
Echter... welk voorbeeld is logischer? Het enige wat de KersVerwijderaar class kan is kersen verwijderen, en dat kan ook maar 1x, want daarna zijn ze al verwijderd. Vanuit dat oogpunt is het dus logischer dat de constructor opdracht geeft om de kersen te verwijderen. Alleen je ziet dit dan niet terug in de code zoals in het 2e voorbeeld.
In dit specifieke voorbeeld, wat zou dan de juiste variant zijn. Ga je voor de logische variant (de 1e optie) die precies doet wat ie moet doen, of ga je voor de 2e variant, waarbij je eigenlijk onnodig een functie moet aanroepen, maar waardoor je wel weer duidelijker ziet wat er gebeurt?
Dit klinkt echt alsof je puur een object wilt aanmaken omdat het kan. Wat voor redenen heb jij dat dit een object MOET worden en het dus geen functie/static method kan zijn?
Maar ga je die namespaces dan echt pas registreren op het moment dat je ze nodig hebt? En dan als bijv. de mail verstuurd is, ga je dan de e-mailnamespace weer unregisteren? Registreer je niet alles gewoon in 1x, waarbij je de belangrijkste namespaces als eerst registreert?
>> Dit klinkt echt alsof je puur een object wilt aanmaken omdat het kan. Wat voor redenen heb jij dat dit een object MOET worden en het dus geen functie/static method kan zijn?
Dat is een goede vraag. Het voorbeeld in de praktijk is dat ik bijv. een aantal services wil configureren op het moment dat deze nog niet gecached zijn. Ik heb een class die de betreffende services ophaalt uit de cache, maar als het cache bestand niet bestaat dan moeten een aantal services geconfigureerd worden. Hier wil ik een aparte class voor gebruiken. (Wat ik nu vertel heeft trouwens betrekking op het initialisatieproces van het request.)
Feitelijk krijg je dus zoiets als dit:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
<?php
class Foo {
public function get() {
// haal de services op uit de cache
// indien geen cache:
$services_configurator = new ServiceConfigurator();
return $services_configurator->get();
}
}
class ServiceConfigurator {
private $services;
public function __construct() {
$this->configure();
}
public function configure() {
// configure the services
$this->services = $services;
}
public function get() {
return $this->services;
}
}
?>
class Foo {
public function get() {
// haal de services op uit de cache
// indien geen cache:
$services_configurator = new ServiceConfigurator();
return $services_configurator->get();
}
}
class ServiceConfigurator {
private $services;
public function __construct() {
$this->configure();
}
public function configure() {
// configure the services
$this->services = $services;
}
public function get() {
return $this->services;
}
}
?>
Dit is ongeveer het idee. Hier lijkt het me logischer om de method configure() in de constructor te stoppen, in plaats van deze handmatig aan te roepen.
P.s. ik ben m'n autoloader dynamisch aan het maken... Ik ben nog wel even benieuwd. Ik wil ook een PSR0 autoload method toevoegen, maar aan welke exacte eisen moet deze voldoen? Weet iemand dat?
Gewijzigd op 12/11/2013 13:48:57 door Ozzie PHP
Ozzie PHP op 12/11/2013 13:46:57:
P.s. ik ben m'n autoloader dynamisch aan het maken... Ik ben nog wel even benieuwd. Ik wil ook een PSR0 autoload method toevoegen, maar aan welke exacte eisen moet deze voldoen? Weet iemand dat?
https://github.com/php-fig/fig-standards/tree/master/accepted
Ik gebruik Foo\Bar\FooBar, maar in de voorbeelden zie ik bijv. \Symfony\Core\Request
Moet een class wel of niet met een slash beginnen?
Gewijzigd op 12/11/2013 14:06:17 door Ozzie PHP
Ozzie PHP op 12/11/2013 13:59:36:
Super!
Ik dacht trouwens dat een class-naam niet met een slash behoort te beginnen?
Ik gebruik Foo\Bar\FooBar, maar in de voorbeelden zie ik bijv. \Symfony\Core\Request
Moet een class wel of niet met een slash beginnen?
Ik dacht trouwens dat een class-naam niet met een slash behoort te beginnen?
Ik gebruik Foo\Bar\FooBar, maar in de voorbeelden zie ik bijv. \Symfony\Core\Request
Moet een class wel of niet met een slash beginnen?
http://www.php.net/manual/en/language.namespaces.faq.php#language.namespaces.faq.full
De hele pagina lezen kan geen kwaad.
Snaptje je mijn voorbeeld van de ServiceConfigurator?
Nou, lees eens de PSR-0 specificatie en je weet het... Een beetje moeite doen mag ook wel.