oke na uitstekende hulp zoals altijd hier van onder andere Wouter en Erwin heb ik maar even geprobeerd om zonder tutorials etc een class te bouwen. (wel kijken naar de linkjes van wouter) want het was idd nog een beetje kopieren en plakken met OOP maar ik ben nu wel op de goede weg denk ik. heb begin gemaakt met een class 'databaseConfig' hier staat de database configuratie in. dan heb ik vervolgens een class gemaakt genaamd 'databaseConnect' hier ga ik connecten met de database. maar nu. snap ik een paar dingen niet.

wat is het verschil tussen

abstract class ...
en
class ...

en moet ik nu de databaseConnect extenden uit de databaseConfig of moet ik hier de __construct gebruiken zoals __construct(databaseConfig)? of denk ik nu helemaal verkeerd?
Wouter J op 11/06/2012 16:58:38

Erwin (en Reshad), dbConfig en dbConnect hebben toch een HEEFT_EEN relatie en niet een IS_EEN relatie? Die hele extend hoort daar toch niet? Je wilt toch zoiets doen:

Volgens mij ligt dat een beetje in het midden. Zoals het nu is opgebouwd is de abstracte basis class precies dat; een basis class voor alle connector objecten. Daar kan ik mee leven. Daarna heb je nog een class nodig die de database functionaliteit beschikbaar maakt voor de applicatie. Die class zal een HEEFT_EEN relatie hebben met de connectie classes.



[size=xsmall]Toevoeging op 11/06/2012 17:08:01:[/size]

Hmm, volgens mij loopt het een beetje door elkaar door de naamgeving. Volgens mij de vertaling tussen Reshad's classes en de namen van Wouter:
databaseConfig (abstract) - dbConnect
databaseConnectMySql - dbConnectMySQL
..... - dbConfig

Naamgeving loopt volgens mij dus niet helemaal 1-op-1, maar het idee wel.
Of ben ik nu degene die de weg kwijt is :-)
ik zal wel even met een schoon blad beginnen met de benamingen van wouter want het is nu een beetje een rommeltje maar dat maakt niet uit het hoeft niet te werken nu nog het is alleen maar die logica erin stampen :) dus ik ga het weer even helemaal opnieuw opbouwen zoals wouters schema. dat is wel heel duidelijk zo. ik post het hier zo wel ff :)

en jongens bedankt voor de tijd en moeite ik waardeer het enorm!
Erwin, mijn plan was:
1 klasse waarin db settings worden opgeslagen (zoals username, password, host, database, prefix, ect.) = dbConfig, en 1 set van klassen die de connection regelt met een mooi adapter pattern = dbConnect en de hele reeks erachteraan.
Ik denk dat ik je inderdaad op dat punt niet begrepen heb. Ik had geen aparte class in mijn hoofd voor alleen de configuratie gegevens.

Het connect gedeelte deelde ik wel, maar daar bovenop een facade zo je wilt die met een simpele functie een complete query kan draaien. Dit is wat ik zelf namelijk heb en daar lees je dan al snel naartoe natuurlijk. Dus het extra object dat je aangaf zag ik als die facade, niet als het config object. Alleen is dan de HEEFT_EEN relatie omgedraaid.
Half, er zitten namelijk nog wat methoden in die abstract horen te zijn en dus ook wat klassen die abstract moeten zijn.
bedoel je dat dbConnect ook abstract moet zijn?
Je mag zelf bedenken welke klassen hier nou niet aangemaakt mag worden, omdat hij niet echt bestaat en welke methoden hier abstract, en dus doorgegeven moeten worden aan de children, zijn. Eigenlijk heb ik je al veel voorgezegd, dus ga zelf maar eens aan de slag!
oke ik heb het een en ander erin verwerkt gewijzigd en aangemaakt. volgens mij is hij nu wel goed.

ik heb het zelfs getest en ik krijg gewoon rijen etc uit de database terug en hij werkt zelfs!

alleen nu mijn vraag. is het een beetje OO http://pastebin.com/zgShuEjV
Nee, je hebt het nog steeds niet door. Wat je wilt is dat je 1 klasse hebt waarin je de instellingen opslaat (dbConfig) en 1 klasse waarin je de connectie aanmaakt (dbConnect). De dbConfig geef je mee aan de dbConnect constructor waardoor je in de dbConnect klassen gewoon $this->config->user kan gebruiken om iets op te halen of $this->config->pass.
Want waar denk je dat je die dbConfig klasse nu voor gebruikt? En waarom denk je dat hij abstract moet zijn?

Tevens moet je dubbele code weglaten en plaatsen in de superklasse. Stel je maakt er nog een adapter bij dan heb je hier nog code in staan die dubbel is en dus niet per adapter verschilt. Plaats die dan in de abstracte dbConnect klasse, zodat alle subklassen (dus alle adapters) deze automatisch al krijgen.

En waarom definieer je methods in de superklasse dbConfig en maak je die vervolgens na in de dbConfigMySQL klasse? Als je niet weet hoe je een method moet invullen, omdat deze verschilt voor alle subklassen moet je hem abstract maken en laten invullen door de subklassen.

Reageren