Door
Ozzie PHP
op 11-06-2014 10:23
gewijzigd op 11-06-2014 10:29
3.054 views
Hey guys,
Een kort vraagje. Mogen onderdelen van een framework vertrouwen op defines? Stel je hebt een kernel class en die heeft het root path nodig. Vevolgens zijn er nog een paar andere classes die ook het root path gebruiken. Nu kan ik aan de constructor van de kernel class het root path meegeven. Vervolgens geeft de kernel class het root path weer door aan andere classes. Dat is optie 1. Ik vraag me nu af of het oké is om alvorens de kernel class aan te roepen het root path te definen en dan in de kernel class en op overige plekken waar het nodig is gebruik te maken van de defined constant. Dus in plaats van telkens via de constructor het root path door te geven, define je het root path eenmalig en gebruik je overal die constant. Is dat oké?
Je moet per slot van rekening ergens beginnen, anders wordt configureren een onoplosbaar kip-en-eiprobleem. Om bijvoorbeeld iets te kunnen laden met een autoloader, moet je eerst de autoloader zelf laden en dus expliciet declareren wáár die te vinden is.
Definieer je niet expliciet constanten, dan is er altijd nog een standaardconfiguratie waarop veel standaardklassen impliciet blindvaren of terugvallen: php.ini. Daar heb je dus nog wel een keuze. Bijvoorbeeld verbindingsparameters voor de databaseserver kun je in constanten of in php.ini vastleggen.
<?php
$root_path = dirname(__DIR__);
...
$kernel = new Kernel($root_path);
?>
En nu zou ik dan gewoon dit doen?
<?php
define('ROOT_PATH', dirname(__DIR__));
...
$kernel = new Kernel();
?>
Het is dus niet "verkeerd" dat die kernel vertrouwt op een defined constant die buiten de class wordt aangemaakt?
Klassen die van buitenaf geconfigureerd moeten worden, zijn onvermijdelijk; denk bijvoorbeeld maar aan databaseconnecties.
Je kunt zo'n declaratie beter wel expliciet maken, dus die ergens in het script uitschrijven. Of je plaatst de volledige configuratie centraal in één gemeenschappelijk config.ini of in een gedeelde interface, als het maar logisch, duidelijk en consistent is. Je wilt geen class Kernel in Kernel.php hebben die achter de schermen en daarmee onzichtbaar iets uit een kernel.ini gebruikt.
Zelf gebruik ik die defines als fallback. Ik heb een config class, en daar staan alle defines in (als het goed is ;-)). Zo kan ik alles via de config aanroepen.
<?php
$config->get('root_path', ROOT_PATH);
?>
Eerste param is de key van de config array, bestaat hij niet dan geeft hij de 2de param terug.
>> Klassen die van buitenaf geconfigureerd moeten worden, zijn onvermijdelijk; denk bijvoorbeeld maar aan databaseconnecties.
Goed punt. Maar inderdaad. Zo'n configuratie zou ik in een apart bestand zetten. Maar een root path heb je op diverse plekken nodig, daarom is een define in dit geval wel mooi denk ik.
>> Ozzie was toch laatste bezig met een class waarin allerlei constanten gedefinieerd werden?
Ik gebruik wel een container, en daar komen ook paden in. Maar om die te maken, moet ik wel eerst een root path hebben :)
Zo'n root path heb je op een paar plekken nodig. Mijn 1e gedachte was dus om een variabele te gebruiken en die door te geven aan de constructor van de kernel, en de kernel geeft 'm dan weer door aan de class die de absolute paden aanmaakt. Maar wat er dus gebeurt is dat ik telkens dat root path via de constructors loop door te geven. Een define is dan denk ik handiger.
Elke functie, of het nou een klasse functie is of iets anders, mag NOOIT iets van de context gebruiken[sup]1[/sup]. Het mag zelfs niks van de context weten. Op deze manier ben je namelijk volledig afhankelijk van die context.
Dat is precies de rede waarom je superglobals niet in functies moet gebruiken, waarom het "global" keyword uit den boze is en waarom "passed by reference" zo verkeerd is. Aan dat rijtje mag je nu ook toevoegen: Het gebruik van globale constanten in een functie.
[tab]1) Er zijn hier uitzonderingen voor, de zogenaamde IO functies, maar die kom je maar zelden tegen. Dat is bijv. de echo functie (als dat een functie zou zijn) en een fwrite functie.[/tab]
