OOP leren

Over exceptions, het voordeel van exceptions is dat alles stopt wat er bezig was, totdat de exception wordt opgevangen. Hierdoor hoef je niet overal meer met if-statements te controleren of iets wel gelukt is, je kan er gewoon van uitgaan dat iets is gelukt. Zo niet, dan wordt er wel een exception gegooid, en wordt de code die ervan uitging dat het was gelukt niet uitgevoerd.

Voorbeeldje. Alle code die eruit-gecomment is (geel?) wordt niet uitgevoerd dankzij de exception die vanuit pak_water() gegooid wordt. Want zodra de exception gegooid wordt springt PHP naar een bijpassend catch-blok. Of als dat er niet is, krijg je zo'n Uncaught Exception error.


Verder is het mogelijk om exceptions te filteren. Dat is het nut van verschillende exception-classes hebben:

Zie? Aan de hand van het soort exception kan je een goeie volgende stap programmeren. Misschien wil je Exception hier wel helemaal niet opvangen, omdat je die op een niveau lager beter kan afhandelen. (verderop hier een voorbeeldje van)

Je moet wel even opletten op de volgorde. PDOException is namelijk een uitbreiding van Exception (PDOException erft van Exception) Hetzelfde geldt voor UserSessionControllerException. Omdat alle exceptions van Exception moeten overerven vangt dat laatste blok altijd je exception op. Of in een voorbeeldje:

De code die ik hier eruit-gecomment heb zal ook nooit worden uitgevoerd, omdat alle PDOExceptions ook Exceptions zijn, en alle Exceptions door het eerste blok worden opgevangen. Alle PDOExceptions ook dus, en daarom zal het tweede blok nooit door die exceptions bereikt worden.

Dat filteren kan je ook in delen doen. Stel dat je een database, een backup-database en een tekstbestand hebt om je berichten in op te slaan:


Het is wat ingewikkelder misschien, exceptions, maar zie je hoe weinig if/else statements ik in totaal gebruikt heb? Amper eentje, puur omdat je tijdens het programmeren niet constant hoeft na te denken over "wat moet ik doen wanneer dit mislukt, of wanneer dat mislukt". Dat deel van je code groepeer je in catch-blokken.

Je moet wel een instantie aanmaken naar je class.

Er hoeft geen PDOException in omdat als je hem opvangt, het je niet verder helpt. Een UserSessionController zonder goed-werkende PDO is niet nuttig, dus dat het gooien van de exception het aanmaken van de instantie verhindert is alleen maar goed. En wat wil je met de exception doen als je hem opvangt? UserSessionController kan weinig goeds doen wanneer zo'n exception optreedt, dus niet opvangen lijkt mij het allerbeste.

Over die main- en backup-database, jep, dat heb je goed gezien :)

En of al die argumenten aan de constructor meegegeven moeten worden... Ik zou aan de constructor alleen de informatie meegeven welke nodig is bij het maken van een instantie van UserSessionController. Informatie welke direct vanaf het begin en altijd nodig is. Bijvoorbeeld een instantie van PDO (maar die maak je al aan in de constructor, dat kan ook) Zonder je instantie van PDO heb je gewoon niets aan je UserSessionController, dus die meegeven/aanmaken in de constructor is logisch.

Maar bijvoorbeeld gebruikersnaam en wachtwoord zijn alleen nodig voor de login-method van UserSessionController. Het heeft niet veel nut om die mee te geven aan de constructor. Stel dat je je UserSessionController juist wilt gebruiken om de sessie te beëindigen, dan zijn username & password niet erg nuttig.

Je maakt geen class voor AddUser. AddUser is een actie, een class is altijd een enkelvoudig zelfstandig naamwoord. :)

Je hebt dus iets nodig wat de actie addUser uit kan voeren. Wat voegt users toe (waaraan toe?) Iets dat de users beheert. Dus dan maak je een UserController/Store/Provider o.i.d. welke je kan gebruiken voor het opslaan en ophalen van gebruikers. En dan zie je weer dat je aan zo'n object ook alleen iets a la PDO aan de constructor zou meegeven, want adresgegevens e.d. zijn alleen nodig voor die ene addUser actie, en daarom geef je ze als argumenten mee aan een method, en niet aan de constructor.

Misschien dat je het op een andere manier makkelijker kan onthouden: Als je de gegevens maar eenmalig nodig hebt, horen ze over het algemeen niet in de constructor thuis (tenzij de constructor ze gebruikt om een ander object te starten wat hij langer nodig heeft) Dus stel dat je 5 gebruikers zou willen toevoegen, dan heb je bij alle 5 de gebruikers dezelfde database-gegevens nodig. PDO gaat dus in de constructor. Maar je hebt voor iedere gebruiker andere adresgegevens nodig, dus die gaan niet in de constructor, maar als argumenten mee aan de method die de individuele gebruikers aanmaakt.


PDO drivers moet je soms aanzetten door

in je PHP.ini te zetten. Vergeet niet de webserver (apache, IIS) te herstarten daarna. Als je bij een hostingprovider zit, en niet je eigen php.ini kan aanpassen, dan moet je even een lief mailtje sturen :)

Inderdaad, bij classes waar je een database nodig hebt is het meestal zo dat je in de constructor al voor de database-verbinding zorgt. Een class die voornamelijk als doel heeft data in/uit de database te halen... zonder database-verbinding is die vrij nutteloos ;)

Het is dan wel weer redelijk normaal om niet de verbinding zelf in de constructor te maken, maar er gewoon voor te zorgen dat je een verbinding hebt. Bijvoorbeeld zo:

Zo maken beide objecten gebruik van dezelfde verbinding, hoef je niet voor ieder object een aparte verbinding te openen. Die "PDO $db" in de constructor-definitie zorgt ervoor dat het eerste argument dat je aan de constructor meegeeft hoe dan ook een instantie van PDO moet zijn. Je kan dan geen UserController aanmaken (instantiëren) zonder een goeie PDO-instantie mee te geven. Of anders gezegd: je weet zeker dat wanneer je een UserController object hebt, die ook een goeie verbinding heeft. Net als wanneer je de verbinding in de constructor zelf start.


Ander voordeel, ook niet onbelangrijk, is dat je je database-login-gegevens niet in de class-definitie zelf meer hoeft te zetten. Als je 30 classes hebt, en in ieder je je gebruikersnaam & wachtwoord moet zetten, ook geen pretje.

Nog een ander voordeel, waar ik zelf erg bij mee ben, is dat wanneer je maar één instantie van PDO in je hele website gebruikt, je die ook heel gemakkelijk kan afwisselen voor een iets uitgebreidere versie tijdens het oplossen van foutjes. En dat zonder dat ik al m'n classes hoef aan te passen.


Of id in de constructor bij een User class moet? Stel dat je een instantie van je User class hebt, zonder een id. Kan je er dan nog alles mee wat je er normaal ook mee zou kunnen? Ik denk dat een id toch wel echt nodig is, omdat het noodzakelijk is voor update- en delete acties. Voor het maken van user objecten (de inserts) zou ik geen user object gebruiken, maar gewoon een method UserController::createUser($nickname, $password, ..) met alleen de noodzakelijke velden. Die doet dan de INSERT query, en maakt vervolgens een instantie van User voor je aan, compleet met het id dat je nu dankzij die INSERT query hebt. Daarna vul je dan de niet-zo-noodzakelijke gegevens in, en dan gebruik je je update-method van je UserController om die gegevens dan alsnog op te slaan.

De UserController heeft niet één en dezelfde id nodig om te werken, die heeft het id van de User nodig waarmee hij werkt. Dat kunnen meerderen zijn, dus welk id zou je dan aan de constructor meegeven? Geen :) (Ter vergelijking: de UserController kan alle acties met dezelfde databaseverbinding doen, en heeft voor alle acties een databaseverbinding nodig. Dus die gaat wel via de constructor)

Het User-object heeft echter ook voor vrijwel alle acties een id nodig, en hij heeft voor alle acties hetzelfde id nodig (namelijk zijn unieke id wat die ene user apart identificeert) Dus ik zou in de constructor van User wel een id vereisen.



Hierin zie je ook even waarom je niet de string 'mysql:host...' moet meegeven aan je constructor van UserController, maar echt de instantie zelf. Een string kan vanalles zijn, een db-identifier zoals jij geeft, of een sinterklaasgedichtje. Dat kan je PHP niet laten controleren totdat het te laat is (verbinding maken mislukt) Daarnaast heb je dan alsnog meerdere instanties van PDO voor dezelfde database, meerdere verbindingen naar dezelfde database. En dat is niet wat je wilt (want het is niet nodig)

Als je de hele PDO instantie meegeeft (Debug_PDO is een uitbreiding op PDO die ikzelf veel gebruik zoals ik eerder al aangaf) heb je voor al je controllers maar één verbinding nodig, en kan je je PDO object makkelijk omwisselen. (Bijvoorbeeld met een PDO emulator, die in werkelijkheid gewoon mysql_ functies gebruikt, maar precies hetzelfde eruit ziet als PDO. Handig als je geen echte PDO hebt)

Jep. Debug_PDO is een class die ik zelf gebruik, normaal zou je daar PDO neerzetten. Maar ik wou even laten zien dat deze manier als voordeel heeft dat je door alleen dat regeltje te veranderen, al je classes een andere manier van communiceren met de database kan laten doen.

Boven in je code ook even zetten:


Volgens mij gaat het fout op de regel

PDOStatement::bindParam verwacht namelijk een reference (dus een variabele) als tweede argument. Probeer bindParam eens te vervangen door bindValue. Die werkt hetzelfde, behalve dat die geen reference gebruikt, maar gewoon de waarde zelf.

Wat is de rest van je code, de code die de invoer van de veldjes neemt ($_POST neem ik aan?) en die een instantie van je class maakt? Misschien zit daar de fout in.