Door
Ozzie PHP
op 11-02-2019 17:08
gewijzigd op 11-02-2019 17:12
3.995 views
Stel ik heb een User class en ik wil die laten samenwerken met een UserModel, wat is dan de beste manier om dat UserModel als property in de User class te krijgen?
Zelf dacht ik aan zoiets als dit:
<?php
$id = $_SESSION['userid'];
$model = new UserModel($db_conn);
$user = new User($id, $model);
?>
Is het bovenstaande een gebruikelijke manier? Ik zie namelijk ook wel eens dit:
<?php
$id = $_SESSION['userid'];
$model = new UserModel($db_conn);
$user = new User($id);
$user->loadModel($model);
?>
Weet iemand dit toevallig?
En nog een laatste vraag ... "mag" je het ID ook meegeven aan het UserModel in plaats van aan de User class?
<?php
$model = new UserModel($id, $db_conn);
?>
Of is dat niet gebruikelijk?
Ik vraag dat omdat als ik het ID mee zou geven aan het UserModel, ik in de constructor van het model meteen alle gegevens zou kunnen ophalen uit de database en die als property zou kunnen opslaan. Als ik het ID meegeef aan de User class zelf (zoals nu het geval is) dan moet de User class het ID eerst doorgeven aan het UserModel en moet er vanuit de User class een functie in het UserModel worden aangeroepen die de data ophaalt.
Hoe verschilt het User object van het UserModel object?
Als het dan toch nodig is om op een of andere manier een soort van combinatie te hebben of dat er een verband is, zou het dan niet logischer zijn dat de User class extend van de Model class?
>> ... zou het dan niet logischer zijn dat de User class extend van de Model class?
Nope ... een 'extend' wil zeggen een "is een" relatie. Bijv. Admin extend User ... een admin is een user.
Door te werken met een model scheidt je de "intelligentie" van de class zelf. Je kan het model dan wisselen door een ander model terwijl de functionaliteit hetzelfde blijft. In dit geval geef je via de User class aan WAT er moet gebeuren, en het model regelt vervolgens HOE dat gebeuert. De User class heeft daar geen weet van.
Zelf gebruik ik dit meer als:
- 90% van de tijd is alles gewoon precies hetzelfde (in alle projecten). Ipv DI kun je dan gewoon extenden, want je wijzigt toch nooit het achterliggende model (ook gewoon een DI container - hoef je bijna nooit te injecten).
- Als je dan eens een keer wat anders wilt "in de basis" leg je er gewoon een trait overheen die de juiste methods modificeert (als jet het al niet met een tussenlaag kunt: normaal User extends UserModel; uitzondering: User extends SpecialUser extends UserModel).
Er worden allerlei abstractie-lagen op elkaar gestapeld, maar uiteindelijk wil je de gebruikersgegevens uit de database in een variabele, toch?! Enfin, doe dat en als je twijfelt bekijk dan het resultaat van je code (echo, var_dump, print_r, ...)
Een User is gewoon een User class, een representatie van een User. Het model is het model dat bepaalt hoe de data wordt opgehaald. Door een ander model aan de User class te koppelen, kan data op een andere manier worden opgehaald. De User class praat dus als het ware met het model (geef mij de username, geef mij de voornaam enz.), maar weet verder niet hoe het model die data ophaalt, laat staan waar die data vandaan komt. Dat is toch het idee van een model?
Maar een model IS niet een User.
Vaak zie je constructies als User extends Database, omdat men in de User class een database nodig heeft. Ook dit klopt weer niet, want een User IS geen database, en ook geen model.
Wat ik bedoel is dat je normaal gesproken bij het ontwerp van software eerst gaat bepalen welke objecten je nodig bent en welke Classes je daarvoor gaat inrichten. Kortom, net in omgekeerde volgorde van jouw vraagstelling. Anders schiet je aan het doel van OOP voorbij. Code die volgens OOP invalshoek is ontwikkeld zou namelijk makkelijk(er) leesbaar, interpreteerbaar en uitbreidbaar moeten zijn.
