Door
P-ter AA
op 20-02-2013 14:30
gewijzigd op 20-02-2013 14:41
1.178 views
Hallo PHPHulpers,
Ik ben sinds kort begonnen met OOP in PHP en ik vind het behoorlijk tegenvallen. Ik vind het erg moeilijk om te bepalen hoe ik iets moet maken (welke classes, op welke manier etc.)
Zouden jullie misschien kunnen zeggen wat er beter kan, maar ook wat goed is?
Het zijn verschillende classes voor een website die draait op mijn CMS. De onderstaande classes worden gebruikt om de pagina's op te halen uit de database.
Regel 1 in OOP: elke class heeft maar 1 verantwoordelijkheid.
Dat is in jouw opzet absoluut niet het geval. Schrijf eens op wat voor verantwoordelijkheden de class Page allemaal heeft.
De reden van deze scheiding van verantwoordelijkheden is dat je elke verandering die je door wilt voeren, altijd maar op 1 plek hoeft te maken. Denk, na het bovenstaande lijstje gemaakt te hebben, wat je moet doen als je:
- een andere database systeem wilt gaan gebruiken
- de routes (en parameters) van je site wilt veranderen
- een ander analytics pakket wilt gaan gebruiken
- een andere menu structuur wilt hebben
- van HTML4 naar HTML5 gaat
- een andere error pagina wilt hebben
Bedenk dan ook nog eens dat je meerdere websites hebt (dit is natuurlijk maar 1 voorbeeld). Moet je nu voor elke website apart alles gaan aanpassen?
Bedankt voor je (snelle) reactie! Ik begrijp wat je bedoeld denk ik. Ik moet de database class dus een methode query() geven die queries uit kan voeren.
Maar hoe kan ik de routes aanpassen dan? In mijn .htaccess staat ingesteld dat .nl/pagina/subpagina wordt: ?page=pagina&sub=subpagina. Wat moet ik hier aan veranderen?
En hoe zorg ik dat ik met zowel HTML5 als HTML4 kan werken? Moet ik dat aan de constructor van de Website classe meegeven en dan vervolgens overal kijken welke gebruikt wordt?
Ik begrijp wat je bedoeld denk ik. Ik moet de database class dus een methode query() geven die queries uit kan voeren.
Deels ja. Je kan de database class de query laten uitvoeren, maar bijvoorbeeld nog andere classes kunnen maken om de queries te kunnen bouwen.
Maurice vB op 20/02/2013 14:47:37
Maar hoe kan ik de routes aanpassen dan? In mijn .htaccess staat ingesteld dat .nl/pagina/subpagina wordt: ?page=pagina&sub=subpagina. Wat moet ik hier aan veranderen?
Daar ga je dus al. Je cms is nu gebouwd om met die htaccess instelling te kunnen werken. Elke andere instelling is dus al niet meer mogelijk. Dat is dus precies wat ik bedoel. Je systeem is niet flexibel. Wat als iemand drie niveaus nodig heeft?
Maurice vB op 20/02/2013 14:47:37
En hoe zorg ik dat ik met zowel HTML5 als HTML4 kan werken? Moet ik dat aan de constructor van de Website classe meegeven en dan vervolgens overal kijken welke gebruikt wordt?
Je presentatie laag los halen van je data laag. Dus je hebt een set aan componenten die op basis van de requests de data genereren (uit een database, vanuit bestanden, vanuit externe calls etc) en die geven die data door aan een set van componenten die de visuele pagina genereren. Wil je dan van HTML4 naar HTML5 dan hoef je in elk geval die hele data laag niet te veranderen. Net zo min als dat je bij een database verandering niet de hele presentatie laag hoeft te veranderen.
Je presentatie laag los halen van je data laag. Dus je hebt een set aan componenten die op basis van de requests de data genereren (uit een database, vanuit bestanden, vanuit externe calls etc) en die geven die data door aan een set van componenten die de visuele pagina genereren. Wil je dan van HTML4 naar HTML5 dan hoef je in elk geval die hele data laag niet te veranderen. Net zo min als dat je bij een database verandering niet de hele presentatie laag hoeft te veranderen.
Wow, klinkt lastig allemaal! Ik ga nog eens op internet kijken hoe anderen het aanpakken.
Maar er is toch geen andere manier dan .htaccess? Als ik dat niet gebruik, gaat hij het zien als mappen?
Klopt de visibility wel wel in de classes? Of had ik dit ook anders moeten doen?
Maar er is toch geen andere manier dan .htaccess? Als ik dat niet gebruik, gaat hij het zien als mappen?
Ten eerste hoef je geen mod rewrite te gebruiken, ten tweede heb je 1001 mogelijkheden in htaccess. Dus jij hebt nu een manier gebruikt, maar dat wil niet zeggen dat dit ook werkbaar is in je volgende applicatie.