dicht timmeren?
Pagina: « vorige 1 2 3 4 5 volgende »
Enige twijfelpuntje is of ik i nm'n exists functie de combinatie van isset en array_key_exists moet gebruiken. Dit doe ik nu wel. Dit levert voordeel op als de key via isset wordt gevonden (deze functie is zeer snel), maar een nadeel als de key niet geset is... iemand advies daarin?
Dit is dus één van de situaties waar je het juist wel moet doen.
Oplossing: Maak een functie, exists en controleer in de get / set functie of een key daadwerkelijk bestaat.
Je kan je register ArrayObject laten extenden. Dan kan je met offsetExists controleren of hij daadwerkelijk bestaat.
Snap je?
Niels
Nee, dat snap ik niet.
Ik heb het nu als volgt... waarbij ik meld dat deze situatie niet alleen voorkomt bij de registry maar ook bij m'n session class en configuration class.
Ik heb dus een functie get, die geeft direct de waarde terug (zonder te controleren of die bestaat). Het is dus de verantwoordelijkheid van de programmeur om ervoor te zorgen dat wanneer hij iets "get" hij zeker weet dat het eerder al ge"set" is. Als hij dat niet zeker weet, dan zet hij om de get een exists functie, als volgt:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
if (Registry::exists('geenideeofditgesetis')) {
$data = Registry::get('geenideeofditgesetis');
}
?>
if (Registry::exists('geenideeofditgesetis')) {
$data = Registry::get('geenideeofditgesetis');
}
?>
Ik vind dit eigenlijk wel een mooie manier. Zo kan er niks mis gaan.
Ik vind dit geen mooie manier. Als je iets niet zeker weet kost het altijd drie regels code. Of je moet de ternary operator methode gebruiken.
Ik zou het als volgt doen: (als je ArrayObject extends)
Code (php)
Niels
Gewijzigd op 22/03/2012 10:07:30 door Niels K
Dat zou op zich wel kunnen, en zo had ik het eerst ook.
ECHTER... nu komt het :)
Ik heb er eens goed over nagedacht. Op jouw (en voorheen ook mijn) manier voer je ten eerste meer controles uit dan wanneer je het resultaat direct teruggeeft.
Ten tweede, stel een user moet inloggen en bij een geslaagde inlogpoging wordt het userobject in de registry geplaatst. Nu haal ik op een andere pagina de user op, maar deze is niet aanwezig in de registry omdat de inlogpoging niet geslaagd is. BOEM, er wordt een exception gegooid! Niet handig, want ik wil in dit geval gewoon een nette melding tonen dat de gebruiker eerst moet inloggen! Hoe lossen we dat op? Toch maar een exists functie eromheen bouwen en pas daarna de user ophalen. Nog meer controles!
Ik leg dus de verantwoordelijkheid nu bij de programmeur neer. Dat is iets minder gebruiksvriendelijk voor de programmeur, maar wel beter voor de performance.
Maar allemaal leuk en aardig dat geneuzel over wat goed en niet goed is. Laat ik het eens vergelijken met een real-life voorbeeld.
Ik ga iedere ochtend douchen, ontbijten en dan met de auto naar m'n werk. Ik ga er iedere ochtend vanuit dat ik brood en beleg heb (dat heb ik immers gekocht) en dat mijn auto aanwezig is op de plek waar ik 'm de avond van tevoren heb neergezet. Mijn proces ziet er in code als volgt uit:
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
<?php
$ik->douchen();
$brood_beleg = Registry::get('brood_beleg');
$ik->eten($brood_beleg);
$auto = Registry::get('auto');
$ik->vroem($auto);
?>
$ik->douchen();
$brood_beleg = Registry::get('brood_beleg');
$ik->eten($brood_beleg);
$auto = Registry::get('auto');
$ik->vroem($auto);
?>
Op jouw manier ziet het proces er als volgt uit, waarbij ik de controle in de get functie even heb vertaald in een boolean controle. Dit is even met een hele dikke knipoog en het gaat niet om de exacte invulling. Het gaat vooral om de algemene gedachte erachter. Mijn manier is, vind ik, efficiënter en meer to the point. Jouw manier kent een betere foutafhandeling, maar weegt dat zwaarder op tegen de extra controles... in ieder geval leuk om daar je gedachten eens over te laten gaan. Jouw manier:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?php
$niels->douchen();
$boolean = isErBroodBeleg();
if ($boolean) {
$brood_beleg = Registry::get('brood_beleg');
} else {
die('Whhaaaahhh... mn brood is op!!');
}
if ($brood_beleg) {
$niels->eten($brood_beleg);
}
$boolean = staatMnAutoOpDeJuistePlek();
if ($boolean) {
$auto = Registry::get('auto');
} else {
die('Helluuuup mn auto is gejat!!');
}
if ($auto) {
$niels->vroem($auto);
}
?>
$niels->douchen();
$boolean = isErBroodBeleg();
if ($boolean) {
$brood_beleg = Registry::get('brood_beleg');
} else {
die('Whhaaaahhh... mn brood is op!!');
}
if ($brood_beleg) {
$niels->eten($brood_beleg);
}
$boolean = staatMnAutoOpDeJuistePlek();
if ($boolean) {
$auto = Registry::get('auto');
} else {
die('Helluuuup mn auto is gejat!!');
}
if ($auto) {
$niels->vroem($auto);
}
?>
Gewijzigd op 22/03/2012 10:34:26 door Ozzie PHP
Zoals beloofd een reactie ;-)
Quote:
Ik heb er eens goed over nagedacht. Op jouw (en voorheen ook mijn) manier voer je ten eerste meer controles uit dan wanneer je het resultaat direct teruggeeft.
Dat maakt in mijn ogen in dit geval niet uit. Dit is gewoon noodzakelijk.
Quote:
Ten tweede, stel een user moet inloggen en bij een geslaagde inlogpoging wordt het userobject in de registry geplaatst. Nu haal ik op een andere pagina de user op, maar deze is niet aanwezig in de registry omdat de inlogpoging niet geslaagd is. BOEM, er wordt een exception gegooid! Niet handig, want ik wil in dit geval gewoon een nette melding tonen dat de gebruiker eerst moet inloggen! Hoe lossen we dat op? Toch maar een exists functie eromheen bouwen en pas daarna de user ophalen. Nog meer controles!
Dat is een foute denkwijze best Ozzie. Ik ben van mening dat je een user niet in het register moet stoppen. Die moet het sessie object onthouden.
Per functie moet je controleren of een user daadwerkelijk ingelogd is. Niet of hij in de storage zit.
Bijv:
Snap je? Je moet leren de verantwoordelijkheden te abstraheren. Een Register heeft niets te maken met het feit of een gebruiker daadwerkelijk ingelogd is nietwaar? Een register moet zich druk maken om het feit dat hij / zij dingen moet opslaan en weer moet retourneren. Wat hij precies opslaat, retourneert? Tzal hem een worst zijn!
;-)
Dat van die user was een voorbeeld. Ik zal m'n voorbeeld aanpassen.
Stel ik wil een user opslaan in de registry, maar dit doe ik pas als die user is ingelogd...
Ergens anders wil ik die user weer uit de registry halen. Ik controleer of de user is ingelogd. Ik weet dat als hij is ingelogd er een user object in de registry aanwezig is, dus dan haal ik dat direct uit de registry. Ik hoef dan niet eerst nog te controleren of het aanwezig is.
Snap je? Mijn stelling is dus dat op het moment dat ik iets uit de registry ophaal ik ervan overtuigd moet zijn dat datgene ook in de registry aanwezig is. Indien ik dat niet zeker weet, dan pas gebruik ik de exists functie.
Geef mij eens een situatie waarin dit soort dingen voorkomen? Ik kan zo snel geen (goede) situatie bedenken.
Ik heb het bovenstaande nog niet meegemaakt eigenlijk. Terwijl ik toch de manier gebruik die ik hierboven heb omschreven.
Niels
Als ik nu iets nodig heb uit de configuratie doe ik simpelweg:
$value = Registry::get('config')->my_value;
Dit is puur even een voorbeeldje he. Aangezien ik weet dat de config altijd aanweig is in de registry is het niet nodig om eerst een controle uit te voeren. Dat is eigenlijk wat ik bedoel te zeggen.
Pas op het moment dat ik niet zeker ben of een waarde aanwezig is in de registry pas dan bouw ik een extra controle in:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
if (Registry::exists('misschienbestaatdit')) {
$value = Registry::get('misschienbestaatdit');
}
?>
if (Registry::exists('misschienbestaatdit')) {
$value = Registry::get('misschienbestaatdit');
}
?>
Snap je?
Jij retourneert nu het configuratie object en aan het configuratie object vraag je nu die 'my_value'. Het register hoeft hier dus niets van af te weten. In de __get van het configuratie object moet je afvangen of die value daadwerkelijk bestaat. (ik neem overigens aan dat je de key bedoeld ;-))
Zoals ik al zei kan ik geen situatie bedenken waarin ik niet weet of een object daadwerkelijk in het register zit.
Snap je ? ;-)
Niels
CORRECT
"In de __get van het configuratie object moet je afvangen of die value daadwerkelijk bestaat. (ik neem overigens aan dat je de key bedoeld ;-))"
Maar dat afvangen doe ik dus niet omdat ik weet dat de waarde die ok opvraag bestaat.
"Zoals ik al zei kan ik geen situatie bedenken waarin ik niet weet of een object daadwerkelijk in het register zit."
CORRECT, in de praktijk zal dit ook niet vaak voorkomen, dus.... daarom heb ik geen controle in de get functie :)))))
Snap je?
Quote:
Maar dat afvangen doe ik dus niet omdat ik weet dat de waarde die ok opvraag bestaat.
In het configuratie object zou ik daar iets voorzichtiger mee zijn. Dit omdat je in de loop van het project ook nog configuratie kan aanmaken. (of je moet er voor zorgen dat dit niet kan)
In het register is dat dan inderdaad niet nodig, your right ;-) Ik heb even naar Zend Framework gekeken, maar daar zie ik wel dat het register mijn bovenstaande manier toepast. (iets anders, maar komt op hetzelfde neer)
This en blijft een persoonlijke keuze ;-)
Ik heb een paar classes (bijv. de Application / bootstrap class en een Autoloader class) waarin ik een statische variabele set nadat ze 1x geconstruct zijn. Als je ze daarna nog een keer probeert te constructen wordt er een exception gegooid. Ik heb dit gedaan om te voorkomen dat iemand zo'n class ooit per ongeluk zal gaan gebruiken... want zoals je wel zult begrijpen gebruik je een bootstrap class in je project maar 1x en kun je een bootstrap niet meerdere keren gebruiken. Echter, het "dicht timmeren" van zo'n class zodat je deze niet dubbel kan gebruiken zorgt voor extra code en de code wordt er ook niet echt niet netter op. Maar goed, het voorkomt dus wel dat iemand een class dubbel gebruikt als dat niet mag.
Wat vinden jullie hiervan? Goed of niet?
(Aub geen opmerkingen over singletons, want daar gaat mijn vraag niet over. Het gaat mij er puur om of je een programmeur of jezelf moet beschermen tegen het mogelijk dubbel gebruiken van een class die daar niet voor bedoeld is.)
Toch even een opmerking, voor als iemand dit topic ooit eens doorleest:
Ik meen me te herinneren dat al eens gezegd is dat je eigenlijk nooit een klasse hebt die maar één keer gebruikt *mag* worden. Probeer dit soort programmeertrucjes dan ook te vermijden.
Gewijzigd op 30/03/2012 18:19:13 door Mark PHP
Maar de vraag is dus of via trucjes ervoor moet gaan zorgen dat die class maar 1x gebruikt kan worden... of moet je dat aan een programmeur overlaten en hopen dat die snugger genoeg is om die class niet nog een keer te gebruiken?
Tot slot: gebruik NOOIT trucjes als je programeert.
Dit is dus min of meer mijn vraag... in hoeverre moet je middels code voorkomen dat een programmeur verkeerde dingen doet?
Liever gooi ik ook al die controles eruit, want dat vind ik een stuk netter staan, maar het gaat mij vooral om de gedachte erachter:
"Moet ik als ik aan het programmeren ben dingen doen om te voorkomen dat een andere programmeur (of ikzelf) in de toekomst bepaalde dingen fout kan doen?"
Of moet je daar gewoon helemaal niet over nadenken en die verantwoordelijkheid volledig aan de programmeur laten?
Toevoeging op 30/03/2012 20:30:59:
Ander voorbeeld:
Stel een programmeur moet ergens als parameter een url prefix invullen, maar ik wil niet dat die prefix begint of eindigt met een slash.
Nu kan ik dit bij de functieomschrijving aangeven, maar in sommige gevallen controleer ik dus ook of de invoer correct is en gooi ik een exception als dit niet het geval is.
Ik doe dit vooral met dingen die makkelijk fout kunnen gaan, maar is zoiets nu wel of niet goed om te doen... ik vind het lastig...
Stel een pad mag niet eindigen op een slash, dan staat dit in het commentaar bij de functie-omschrijving. Echter, ik controleer het vervolgens ook nog eens via regex. Ik zit er nu dus aan te denken om die regex controle achterwege te laten.
Goed idee?
Pagina: « vorige 1 2 3 4 5 volgende »