Door
Lord Gaga
op 19-06-2014 09:58
gewijzigd op 19-06-2014 10:00
1.157 views
Hallo,
Op dit moment ben ik bezig met een aantal classes en ik snap even niet tot in hoeverre ik moet valideren.
Stel je hebt een class die een ID en een naam verwachten als parameters.
Controleer je in de class dan ook of:
- Het ID een number is
- Deze number een integer is
- De naam een string is
- De string alleen uit letters bestaat
Of gaat dit te ver?
Ik hoop dat iemand me hier antwoord op kan geven.
Alvast bedankt!
Edit:
De parameters zijn geen user input maar worden door de programmeur (in dit geval ik) zelf ingevoerd.
Oke, dus stel dat ik als parameter een canvas element verwacht, dan moet ik dus checken of:
- De parameter NIET null is (Want null is ook een object en null.nodeType geeft een error)
- De parameter een object is (Want node is een object)
- Het object een nodeType heeft (Als het object een nodeType heeft, is dit een node)
- Het object de nodeName 'CANVAS' heeft (Het is dus een canvas element)
Bij multi-byte karaktersets kan de stringlengte wel eens anders uitvallen dan je verwacht. Vandaar dat sommigen strlen() bijvoorbeeld door een mb_strlen() of strlen_utf8() vervangen.
Dat lijkt me niet zinvol. Je zegt zelf al dat het overbodig is, dus dan heeft het geen enkele toegevoegde waarde.
Mijns insziens moet je vooral controleren wat "van buitenaf" komt en wat je als programmeur dus niet zelf in de hand hebt.
Op het moment dat een ID een class binnenkomt, dan moet die ID al kloppen. Het moet niet zo zijn dat de class die ID nog eens moet gaan controleren.
Jij als programmeur weet wat voor ID er verwacht wordt, dus op het moment dat je die zelf intypt, weet je dat het klopt: $foo = new Foo(12);
Echter, op het moment dat een bezoeker een ID opvraagt, zou je deze wel kunnen controleren. Als jij weet dat het ID een getal moet zijn, kun je controleren of het inderdaad een getal is.
Als je alles zou controleren, dan zou je alles wat je zelf doet ook moeten gaan controleren, en dat wordt een beetje belachelijk.
Stel dat ik in mijn code zet:
<?php
$admin = new Admin();
$admin->setName('Ozzie PHP');
en dan vervolgens...
$validator = new AdminValidator();
$validator=>validate($admin); // dus nu ga ik controleren wat ik zelf heb ingetypt
?>
Dit lijkt me nogal overkill. Nee, vooral dus de dingen controleren die van buitenaf komen.
Op het moment dat een ID een class binnenkomt, dan moet die ID al kloppen. Het moet niet zo zijn dat de class die ID nog eens moet gaan controleren.
Jij als programmeur weet wat voor ID er verwacht wordt, dus op het moment dat je die zelf intypt, weet je dat het klopt: $foo = new Foo(12);
Dan moet je toch nog ergens formaliseren wat een geldige ID is. De class Product weet zelf niet dat de ID bijvoorbeeld slechts een UNSIGNED SMALLINT is in de database en dus niet groter dan 65535 mag zien. Dat weet een class ProductMapper misschien wel, maar je wilt voor validaties niet afhankelijk zijn van exceptions van een mapper.
Omgekeerd kan de product-ID misschien een UNSIGNED BIGINT zijn. Dan heeft een class ProductMapper daar geen enkele moeite mee, maar loop je misschien ergens vast omdat PHP 18446744073709551615 niet als integer kan behappen.
Kortom: een apart data-object voor de product-ID zou dan niet verkeerd zijn.
>> Dan moet je toch nog ergens formaliseren wat een geldige ID is. De class Product weet zelf niet dat de ID bijvoorbeeld slechts een UNSIGNED SMALLINT is in de database en dus niet groter dan 65535 mag zien.
Lijkt mij dat je dan enkel wanneer het gaat om user input vanuit een formulier of URL een validatie gaat toepassen. Het lijkt me niet de bedoeling dat je jezelf gaat controleren. Als ik als programmeur in mijn code ergens typ $id = 12, dan kun je er vanuitgaan dat dat klopt, en dat je niet hoeft te controleren of 12 inderdaad een getal is groter dan 0 en kleiner dan x. Dat is aan de programmeur.
>> Jij als programmeur weet wat voor ID er verwacht wordt [...]
Dan zit het alleen in jouw hoofd en is het nergens in de software terug te vinden. Wat je niet formaliseert door het in te bouwen, wordt niet gebruikt.
>> Als ik als programmeur in mijn code ergens typ $id = 12 [...]
Dat lijkt me een hoogst zeldzame uitzondering, want wanneer ga je nu een applicatie bouwen waar je zó specifiek een "hard coded" integer instelt? Dat zou dan op zijn minst een constante moeten zijn.
Ja, die uitzondering is dan wel verdedigbaar, maar dat is intern. Het gaat hier om de ruimere vraag: wanneer en hoe valideer je, zowel intern als extern?
Als je een schaalbaar systeem bouwt met een groeiende en veranderende database, dan zul je toch ergens moeten vastleggen wat een valide product-ID is. En dat wil je maar op één plaats doen, niet alleen omdat je het maar één keer wilt vastleggen, maar vooral omdat alle samenwerkende klassen dan exact dezelfde "definitie" van een product-ID hanteren.
Dat zou ik niet beperken tot validaties van externe input. Het systeem heeft meer "check & balances" nodig — ook intern.
