Ik heb een autoload functie in een class staan. Nu heb ik in die class ook een register method staan die die de autoload functie, jawel... registreert :)
In mijn code hoef ik dan alleen dit te doen:
<?php
$autoloader = new Autoloader();
$autoloader->register();
?>
Een tijdje terug hadden we het in een ander topic over het constructen van classes en wanneer je dat doet. Ward gaf toen aan dat als je een class hebt waarbij je altijd dit doet:
<?php
$foo = new Foo();
$foo->doFoo();
?>
Dat je dan net zo goed doFoo() vanuit de constructor kunt laten uitvoeren.
Bij mijn autoloader class heb je nu zo'n zelfde situatie. De enige method die je kunt aanroepen is register. Dus het enige wat je met die class kunt doen is dit:
<?php
$autoloader = new Autoloader();
$autoloader->register();
?>
Nu vraag ik me dus af of ik dan niet beter de register method vanuit de constructor kan triggeren. Als ik dan de autoloader wil registreren, dan hoef ik alleen nog maar dit te doen:
<?php
new Autoloader();
?>
Op zich wel lekker kort, maar is dit gebruikelijk? In principe zie je nu in de code niet wat er gebeurt, maar dat zou je met commentaar kunnen ondervangen:
<?php
// Register the autoload method.
new Autoloader();
?>
Graag jullie reactie.
En alsnog moet je die autoloader niet binnen de klasse gaan configureren. Je wilt die autoloader namelijk ook gebruiken voor andere projecten en ook als jij je directory structure gaat veranderen moet je niet de klasse hoeven veranderen, maar alleen hoe je de klasse aanroept.
Als je dit soort dingen gaat opslaan in een klasse heb je echt OO nog niet begrepen en moet je ophouden met deze OO vragen te stellen. Ga dan eerst een maandje OO leren, zonder aan code of aan je framework te denken. Anders wordt het echt niks.
>> Je wilt die autoloader namelijk ook gebruiken voor andere projecten en ook als jij je directory structure gaat veranderen moet je niet de klasse hoeven veranderen, maar alleen hoe je de klasse aanroept.
Dat was nu dus niet de insteek. Wat betreft doorgeven van paden heb je gelijk. Zal ik nog even aanpassen. Maar ik heb dus een specifieke autoloader die alleen voor het Ozzie framework is bedoeld. Eigenlijk hoort ie dus ook niet in de library thuis.
>> Zo te zien heb je een soort master met meerdere slaves. Als dat inderdaad zo is, zou ik pad1 én pad2 doorgeven aan de autoloader, niet pad1 óf pad2.
Hij heeft ook alle 2 de paden...
Kun je nog even reageren op de FooConfigurator vraag? Dan laten we de autoloader even rusten. Ik moet even kijken wat ik daarmee ga doen.
Kun je nog even reageren op de FooConfigurator vraag? Dan laten we de autoloader even rusten. Ik moet even kijken wat ik daarmee ga doen.
Die "configurator" zal "iets" moeten "configureren", nietwaar? Naar alle waarschijnlijkheid is dat "iets" nog een "configuratie" ook. Lijkt me wel logisch.
Maar wees dan concreet. Is de configuratie één bestand? Is de configuratie één instelling? Of zijn het meerdere instellingen, bijvoorbeeld in een array? Of kan alles?
Wat Dos eigenlijk ook al zei: maak zulke keuzen expliciet in plaats van impliciet of "implied". Kies! En kies daarna door!
Ward, het maakt niet zozeer uit op welke manier er iets geconfigureerd moest worden. Dit is puur een voorbeeld. Ik snap het niet... eerst zeg je dat ik het via de constructor moet doen, en nu moet ik het weer expliciet doen?
Dit was gewoon een simpel voorbeeld. Je hebt een of andere data $foo. Daar moet iets mee gebeuren. Wat er mee moet gebeuren maakt niet uit, maar het is altijd hetzelfde. Weet je wat? Laten we zeggen dat $foo een taart is en dat de class die taart in stukken moet snijden. Dat is het enige wat die class doet. Nu is de vraag, geef jij zelf de opdracht om die taart in stukken te snijden:
<?php
$taart_snijder = new TaartSnijder($taart);
$taart_snijder->snijTaart();
$gesneden_taart = $taart_snijder->get();
?>
... of laat je de constructor de opdracht tot snijden geven:
<?php
$taart_snijder = new TaartSnijder($taart);
$gesneden_taart = $taart_snijder->get();
?>
De taart moet altijd 1x gesneden worden. Wie geeft de opdracht. Jijzelf of de constructor?
> Dat was nu dus niet de insteek. Wat betreft doorgeven van paden heb je gelijk. Zal ik nog even aanpassen. Maar ik heb dus een specifieke autoloader die alleen voor het Ozzie framework is bedoeld. Eigenlijk hoort ie dus ook niet in de library thuis.
Waarom zou die klasse niet door andere projecten gebruikt mogen worden? OO draait om hergebruik, niks anders.
Het idee van een class zonder public methods zodat andere code het zogenaamd niet uit kan voeren is een beetje paranoïde.
1) Waarom zouden libraries die jij kiest ooit jouw Autoloader class gebruiken?
2) Met de reflection API is het alsnog mogelijk.
In het geval van de versimpelde Autoloader is de register() method overbodig en kan je spl_autoload_register() gewoon in de constructor gebruiken.
Zonder reflection kan je zo goed als niets met dat Autoloader object. Wat me terug brengt op de vraag die ik eerder stelde.
Wat is [dan] je reden om een object aan te maken? Maak er twee static methods van zodat Autoloader een static helper class wordt. Ik zie namelijk geen enkele reden waarom je een object zou willen.
Ik verwacht dat constructors een bruikbaar object kunnen afleveren. Als ik niet genoeg parameters mee geef aan de constructor om een bruikbaar object af te leveren dan wil ik blijkbaar geen bruikbaar object. Daar hoor ik dan mijn redenen voor te hebben. Ik kan het object bijvoorbeeld als parameter doorgeven aan iets dat het verder initialiseert via setters.
>> Maak er twee static methods van zodat Autoloader een static helper class wordt.
Ik snap niet helemaal wat je bedoelt. Om welke 2 methods gaat het dan, en waar laat je die? Kun je misschien een heel simpel (schematisch) voorbeeldje geven?
>> Ik verwacht dat constructors een bruikbaar object kunnen afleveren. Als ik niet genoeg parameters mee geef aan de constructor om een bruikbaar object af te leveren dan wil ik blijkbaar geen bruikbaar object.
Oké... maar iemand anders op het forum zegt dat wanneer je een object aanmaakt het altijd zo goed als gebruiksklaar moet zijn. Anders heb je alleen maar een soort "omhulsel". En dat is dus lastig. De een zegt dit, de ander dat.
