Het topic luidt "PHP PDO Class", dus ik neem aan dat je al een soort van wrapper hieromheen aan het schrijven bent?

Het belangrijkste aan een wrapper class lijkt mij (o.a.) toegevoegde waarde. Als het enkel een soort van aliassen introduceert voor bepaalde methoden zonder dat het echt werk bespaart, dan heeft dat niet echt toegevoegde waarde.

Het gebruik van wrapper classes in het algemeen is in zichzelf wel nuttig omdat dit hard coding vermindert - je zult geen PDO-specifieke functies meer in je code hebben, die zitten dan enkel in je PDO (MySQL?) wrapper.

Maar tenzij je een volledige Database Abstraction Layer maakt, wat veel verder voert dan een wrapper (en waar er waarschijnlijk genoeg van te vinden zijn, je hoeft in dat opzicht niet opnieuw het wiel uit te vinden) blijf je hard coding houden. Immers, de SQL in jouw code is (redelijk) database-specifiek. Ook zou je kunnen kijken naar ORMs, Object Relational Mappers.

Maar een (simpele) wrapper (die werk verzet) kan nog steeds van toegevoegde waarde zijn. Welke database-typen gebruik je trouwens? Als dit enkel MySQL is, waarom schrijf je dan geen wrapper voor MySQLi?

Anyhowwwww... Als je met OOP bezig bent regel je het detecteren en afhandelen van fouten meestal / grotendeels via exceptions (en daarmee dus try-catch blokken). En exceptions zijn vooral bedoeld voor dingen die onverwacht fout gaan. Vanwege de aard van exceptions ("Er gaat iets fout en ik weet niet precies wat ik hiermee aan moet") is het ook niet aan de klasse zelf om te bepalen wat hiermee dient te gebeuren, dit doet een hogere laag. Een exception wordt zelden tot nooit afgehandeld op de plek waar deze werd gegenereerd. Je kunt wel classes extenden van elkaar, maar het lijkt mij niet dat je je database-exceptions als een soort van verlengstuk van je database-class moet zien. Dit zou wel een extension kunnen zijn van een eigen lijn van exception classes, maar hier moet je wat mij betreft ook waken voor wildgroei, het lijkt mij niet erg zinnig om voor elke class een exception class bij te schrijven, tenzij het lastig is om te identificeren waar fouten vandaan komen, maar daar heb je logging voor. Je zou een aparte exceptions-log kunnen maken waarin je je traces dumpt ofzo. Kortom, het is tevens zaak dat je dingen niet alleen op een manier oplost (en bij voorkeur dus de goede :p), maar ook op de juiste plaats.

Wat ik denk dat vooral nu belangrijk is is dat je eerst duidelijk krijgt wat je precies wilt (kunnen) doen, en vervolgens hoe je dit op een juiste OOP-wijze vormgeeft want het klinkt nu een beetje alsof je een vaag idee hebt, maar nog niet precies hebt uitgewerkt hoe of wat. Het is ook belangrijk dat je vervolgens deze keuzes, die in wezen ontwerpbeslissingen zijn, kunt onderbouwen. Zoals bijvoorbeeld mijn eerdere vraag, indien je met PDO werkt, waarom PDO en niet iets anders?