OOP leren

Gesponsorde koppelingen:

Variabelen altijd uit de quotes halen.
Bij een echo gebruik je meestal best enkele quotes ( ' ).

Verder snap ik dit niet: if(empty($this->name)) $this->name = $newPersonName;
Het is niet gebruikelijk dat je een eigenschap niet mag overschrijven.

a. mb_strlen is de multi-byte versie van strlen. ß is bij mij volgen strlen() bijvoorbeeld 2 karakters lang vanwege utf-8. mb_strlen kan daar beter mee overweg. Maar dat is een detail, en heeft niet veel met OOP te maken :)

b. $roel->name is een verwijzing naar de member-variabele de class waarvan een instantie zit in $roel. $roel->name zal een foutmelding opleveren wanneer je $name een private of protected member maakt. $roel->name() roept die name-method (de "getter") aan. Getters en setters zijn maar naampjes, het zijn het gewoon methods uiteindelijk.

c. Ik gebruikte gewoon even fictieve functies om te laten zien wat je op dat soort plekken in je code zou kunnen doen. Veel functies gebruiken in plaats van overal plat de code neerzetten is sowieso wel prettig om je code begrijpbaar en hapbaar te houden.

d. Is $pincode noodzakelijk bij het aanmaken van het object? Kan je object bestaan zonder dat z'n pincode-member een waarde heeft? Heeft je object een standaard-waarde voor pincode?

e. In de praktijk kan je public gebruiken wanneer je geen "zin" hebt om een getter & setter te schrijven, maar dat is best een slechte gewoonte. Ik ken geen theoretisch gezien goed gebruik van public voor member-variabelen in PHP, omdat PHP geen dingen kent als read-only en het afdwingen van types voor variabelen. (waardoor je effectief niet weet wat er in een variabele zit zonder te controleren)

f. De standaard-Exception class is Exception. Alleen instanties van Exception kan je gebruiken in combinatie met throw. (throw new stdClass() werkt niet) Je kan je eigen exceptions maken door Exception te extenden (want een MijnSpecialeException is ook een Exception, want het erft alle eigenschappen van Exception over) Eigen exceptions kan je bijvoorbeeld gebruiken om het soort aan te duiden (valende setters, maar daar kan je ook de standaard InvalidArgumentException meestal wel voor gebruiken) of om je eigen details aan de exception toe te voegen. PDOException bevat bijvoorbeeld de extra member $errorInfo, waarin extra informatie van de database(driver) over de fout staat. Zou je zelf een HTTP-Request class maken (een class die webpagina's kan opvragen o.i.d.) dan zou je een HTTPRequestException kunnen maken die details over de fout bevat (de http-headers die de server terugstuurde bijv.)

g. Je mag bij if-else statements de accrolades weglaten, maar dan wordt alleen de eerst volgende opdracht als de opdracht beschouwd die normaal binnen de accolades staat. Bijv: if(is_valid()) echo 'a'; echo 'b'; Nu zal alleen de eerste echo afhankelijk zijn van is_valid(), de tweede echo wordt altijd uitgevoerd. Dat is ook de reden dat je voorzichtig moet zijn met het weglaten van accolades, je code kan er bestwel onleesbaar door worden.

h. Alle invoer die niet hard-coded in je PHP staat is potentieel gevaarlijk. Ooit was er een idee om PHP te voorzien van 'tainted variabelen'. De variabelen houden dan bij hoe gevaarlijk ze zijn. Zo kreeg je een foutmelding wanneer je mysql_query('SELECT * FORM tabel WHERE x = ' . $_POST['varname']) deed, omdat $_POST['varname'] van buiten kwam, en gemene quotes zou kunnen bevatten die je query manipuleren. Pas wanneer je $_POST['varname'] eerst door mysql_real_escape_string haalde werd het resultaat daarvan gemarkeerd als veilig-voor-sql-code. Hetzelfde geldt voor HTML. echo $_POST['data'] kan gevaarlijk zijn, als $_POST['data'] HTML bevat. Bijvoorbeeld een meta-redirect tag naar een foute site, of Javascript die je cookies steelt. Daarom is het heel belangrijk om iedere keer als je een variabele echo't, na te gaan waar alle data in die variabele vandaan komt, en welke inhoud er in theorie allemaal in zou kunnen zitten. Eigenlijk hoop ik dat ze die tainted variabelen ooit nog op een of andere manier in PHP stoppen, al dan niet uitschakelbaar, maar het zou enorm helpen met het vinden van veiligheidslekken. Tot dan kan je of heel goed zelf die taints bijhouden (is te doen, maar je moet wat oefenen) of je kan veilig spelen en htmlentities op alle variabelen gebruiken.

Op PHPhulp staan wel een aantal tutorials over XSS, en hoe je je er tegen kan wapenen. Op PHP.net is het proposal voor tainted variabelen te vinden. Voor jouw interessant is vooral hoe de taints door kunnen sijpelen in andere variabelen (immers 'abc' . $_POSt['xxx'] is net zo onveilig als $_POST['xxx']). sprintf is ook wel handig hiervoor (maar ook voor veel andere dingen) omdat je op die manier alvast kunt vaststellen van wat voor type je in je uitvoer verwacht, en je ook zeker bent dat je dat type tekst in je uitvoer zal krijgen. (bijv. %d garandeert een nummer, evil-javascript-html is dan dus uitgesloten)

Ik leer echt veel van je Jelmer! Bedankt!

Dus ipv $roel->name moet ik eigenlijk $roel->get_name() gebruiken? Dus wat ik eerst deed was direct de property aanroepen (had ik zelf niet door :D)?

Ik zal eens wat verder knutselen, en dan kom ik op dit topic terug :). Verder zal ik eens PDO gaan proberen.

zalige post jelmer...jij zou boeken moeten schrijven :-) ik zou er zeker kopen...hier leer ik meer van dan ik op school doe

a. Jouw implementatie van display_person gaat niet werken. Je probeert de functie 2 antwoorden te laten geven (na elkaar) maar bij het eerste return-statement dat je binnen de functie tegenkomt zal je functie stoppen, en zal de 'uitvoer' van die functie dat zijn wat je op dat moment returnt.

Verder hoeft je Person-class op zich niet zo'n method te hebben. Je kan denk ik beter de Person-class verantwoordelijk houden voor de werkelijke data van de persoon, en een andere class of functie verantwoordelijk maken voor het correct weergeven (omzetten naar HTML, of XML, of een plaatje) van je Person-objecten. Eigenlijk is het over het algemeen een goed plan om je classes en je functies zo min mogelijk zelf te laten doen, en zoveel mogelijk te laten uitbesteden aan andere functies en classes. Daardoor komt er in je code eigenlijk allemaal goed-leesbare pseudo-code te staan (gewoon functienamen die beweren dat ze iets doen, geen daadwerkelijke code die allemaal ingewikkelde statements bevat), en kan je je beter focussen op één ding tegelijk.

b. form_is_submitted is niet specifiek voor de Person-class, maar is meer een hulp-functie. Of eigenlijk is het meer zo'n functie als ik hierboven beschreef. Het is maar een functie om één simpel statement heen, maar je code is erdoor veel simpeler te lezen voor mensen die geen PHP kennen (en dus niet bekend zijn met $_SERVER) of voor later, wanneer er alweer een betere manier is om dat te doen. Hij kan trouwens korter als je dat zou willen:


c. Als je User_Store class ergens van afhankelijk is (bijvoorbeeld een $link_identifier die mysql_connect teruggeeft, of een instantie van PDO) dan zou je die via de constructor mee kunnen geven. Als hij nergens van afhankelijk is, dan mag je de constructor leeg laten. Je kan de constructor ook gebruiken om wat initialisatie-werk te doen. In een heeeeeel slecht voorbeeld zou je in de constructor kunnen controleren of de tabel wel bestaat, en zo niet deze aanmaken. (Maar dat doe je natuurlijk niet, omdat die extra query in de praktijk volledig overbodig is, omdat de tabel toch altijd wel bestaat, en je het anders zelf handmatig makkelijker kan oplossen :) )

d. Ik zou het veilig maken van je data voor queries of html zo dicht mogelijk bij de plek waar je de waarden ook daadwerkelijk in de query gaat gebruiken of in de html gaat printen zetten. Stel dat je bijvoorbeeld standaard htmlentities over je invoer haalt, maar je beslist toch $_POST['xxx'] in imagettftext te willen gebruiken, dan moet je eerst die entities weer terugdraaien. Als je je data altijd zo rauw en puur mogelijk houdt, dan kan je die op het moment dat hij veilig moet zijn voorzien van de juiste filters, en alleen de juiste filters (dat zijn filters die geen sporen nalaten, vergelijk het resultaat van addslashes met mysql_real_escape_string) alvorens je de data op die plek gebruikt. En omdat de functie die bijvoorbeeld de query opbouwt het beste weet wat veilig is voor die query (alles wat door mysql_real_escape_string is gekomen) en wat niet, is het goed om inderdaad binnen die functie de filters er overheen te halen.

Er moet uiteindelijk een plek zijn in je code waar je de gegevens uit de database omzet in een leuke webpagina, ik denk dat dat pad van gegevens er zeg maar zo ongeveer uit zou zien:

Die laatste twee regeltjes zouden de display_person functie kunnen zijn:

Je zou ook in plaats van een functie een nieuwe class kunnen gebruiken, bijvoorbeeld de class Website, welke diezelfde functie als method kent (maar dan er een mooie layout omheen tekent) Wat ik vooral in het voorbeeld wou laten zien is dat het totaal niet uitmaakt welke persoon er in $person zit, zolang je weet dat $person de methods die de class Person heeft ook heeft, weet je hoe je hem moet gebruiken, en kan je binnen de functie display_person veilig $person->name() en $person->age() aanroepen.


Merk ook even op hoe ik m'n $person_store vul. Ik geef hem de link-identifier mee (zie de handleiding van mysql_connect) zodat hij deze heeft wanneer hij intern mysql_query aanroept (welke de link-identifier als tweede argument slikt) Nu is bij mysql de link-identifier optioneel, en alleen nodig wanneer je meerdere verbindingen met verschillende databases gebruikt, en daarom gebruikte ik in m'n voorbeeld PDO, omdat je wanneer je PDO gebruikt altijd je instantie van PDO erbij moet hebben (omdat PDO een class is, maar in weze is het hetzelfde als bij mysql_connect, de instantie van PDO bevat de informatie over welke database je moet aanspreken) Dus omdat m'n Person_Store object zonder die link-identifier niet weet met welke database hij moet praten, en daardoor compleet clueless en onbruikbaar is, mag je zeggen dat hij nogal afhankelijk is van die link-identifier, en dat je die al bij de constructor mag meegeven.

Je ziet het meegeven van dit soort 'objecten' aan de constructor (okee, link-identifier is niet een object, maar PDO wel) wel vaker, omdat het eigenlijk de beste* manier is om je classes die toch afhankelijk zijn van andere classes in hun behoeften te voorzien.

* vind ik :) Er zijn mensen die liever een registery of singleton gebruiken, maar dan raak je eigenlijk een deel van de kracht van object georiënteerd programmeren kwijt. Maar dat is een ander verhaal.

Dat ligt niet aan dat stukje code, dat stukje code werkt hier perfect (klein detail, je kan nog wel even public voor function __construct zetten.)

Ik zou het inloggen niet in de class User zelf opnemen. Bij de login-procedure is het user-object het subject, het object dat het ondergaat (dat slachtoffer is, het krijgt meerwaarde)

Ik zou een aparte class maken welke je login-sessie beheert, UserSession o.i.d. Je zou daarin het inloggen kunnen regelen, en vanuit daar kan je dan bijvoorbeeld via de method $usersession->user() een instantie van deze User class krijgen voor de op dat moment ingelogde user. User is dan dus meer een resultaat van het inloggen dan diegene die voor het inloggen verantwoordelijk is.

edit: of gebruik je nog PHP 4? Dan zou het kunnen dat die bovenstaande code niet werkt. PHP 4 kent onder andere geen public/private/protected, geen __construct, en nog een heleboel ellende met references naar instanties. Wil je OOP leren? Dan kan je niet zonder PHP 5 (in 4 is het ingewikkelder om te leren zelfs!)

iemand?

Ik zou sowieso geen PDOException gooien. PDOExceptions worden normaal alleen gegooid wanneer er een fout is met de database (fout in query, fout met verbinding). Als je nu ook een PDOException gaat gooien voor fout met wachtwoord, dan heeft PDOException geen speciale betekenis meer. Je kan beter een eigen exception maken en die gooien:


Trouwens, is dit voor even, of sla je geen sha1-hash van je wachtwoord op? Alleen een hash opslaan is veiliger, want dan kan niet iemand je wachtwoord zomaar ontfutselen wanneer hij via sql-injection o.i.d. de verkeerde data uit de database weet te vissen. Je gebruikt wachtwoord uit je database niet verder in je code, dus je hoeft hem ook niet in het SELECT deel van je query te vermelden :)

Vang exceptions pas af wanneer je een alternatief hebt. Als je UserSessions class geen verbinding kan maken, dan is dat niet een probleem dat UserSessions kan oplossen. Laat die exception dan gewoon vallen, en vang hem op daar waar je bijvoorbeeld een fout-pagina kan weergeven.

Sowieso kan je geen try/catch blokken of zelfs constructors aanroepen bij het definiëren van de class. Die code moet dan in de constructor. En je moet je $db dan even een (protected?) membervariabele van je class maken, en hem aanspreken via $this->db.

Verder, als je PDO gebruikt, is deze ook erg nuttig (direct aanroepen nadat je je PDO object hebt aangemaakt)


En als laatste: UserSessions? Het is op zich logischer om een class naar een zelfstandig naamwoord enkelvoud te vernoemen. Immers, je maakt instanties aan van die class, en die instanties zijn dan zeg maar de individuen.

$x is niet meerdere personen, net zoals $y niet meerdere sessies tegelijkertijd kan zijn. Ik zou je class UserSessionController of UserSessionProvider o.i.d. noemen, want dat is het. Het is een class die iemand in staat stelt in te loggen en een sessie te starten.

Ik zou oppassen met het gebruik vand md5, er zijn op internet al veel scripts die het kunnen "kraken" al vermoed ik gewoon dat het eens script is wat in een grote database kijkt, maar als een hacker md5 wil kraken is hij veel sneller klaar met sha1 () of hash ( 'sha256' , $text ) .