Ik ben net weer begonnen met het mezelf proberen (via tuts en dergelijke) aan te leren van Object Geörienteerd Programmeren (OOP). Zoals ik het lees moet je het zo zien: De klasse is het overkoepelende van de functies die erin staan.
Zie je de class als een boom, dan vormen alle functies die in de class staan samen in het geheel die boom. (of de eigenschappen daarvan)
Een boom heeft bijvoorbeeld wortels-> Daar zou je een functie voor kunnen maken binnen die classe. Takken -> Ook een functie, bladeren ook, enz..
Als ik het idee goed begrijp zit het zo in elkaar:
<?php
// je begint met een naam van de klasse. In dit geval een boom.
class cBoom{
private $sBladtype;
private $sBladkleur;
private $sBoomtype;
private $iBladaantal;
private $iBoomhoogte;
private $sResultaat;
//wanneer je de boom class aanroept moet er een instantie van een boom gemaakt worden waar we mee verder kunnen werken
function __construct($sBoomtype,$iBoomhoogte){
$this->sBladtype = 'standaard';
$this->sBladkleur = 'groen';
$this->sBoomtype = $sBoomtype;
$this->iBladaantal = 500;
$this->iBoomhoogte = $iBoomhoogte;
$this->sResultaat = 'De boom van het type '.$this->sBoomtype.' heeft een hoogte van '.$this->iBoomhoogte;
return $this->sResultaat;
}
function __destruct(){//maakt het resultaat weer leeg als de klasse is afgesloten
$this->sResultaat = "";
return $this->sResultaat;
}
function kleurblad($sBladkleur){
$this->sResultaat = 'Het is herfst, de bladkleur van de boom is nu '.$sBladkleur;
return $this->sResultaat;
}
function boomgroei($iBoomhoogte){
$this->sResultaat = 'De boom is gegroeid, hij is nu '.$iBoomhoogte.' groot.';
return $this->sResultaat;
}
function bladval($iBladaantal){
$this->sResultaat = 'Door de harde wind is de boom bladeren kwijt. Er zitten nu nog maar'.$iBladaantal.' bladeren aan de boom.';
return $this->sResultaat;
}
}
?>
Via deze class kan ik nu een boom aanmaken en deze laten groeien en dergelijke. Zit ik zo goed met het principe, de opbouw en het idee erachter?
private - alleen aanspreekbaar vanuit de klasse zelf
protected - ook aanspreekbaar vanuit klassen die erven uit deze klasse
public - overal aanspreekbaar
In principe zijn je instantie variabelen altijd private of protected. Methoden die alleen binnen een klasse gebruikt worden zijn private en methoden die ook buiten je klasse worden gebruikt zijn public. Lijkt mij dat je login, logout, activate enz ook buiten je klasse wil aanspreken (bijv. in je login script) dus die moeten public zijn.
[edit] Kijk ook eens naar __get() en __set() [/edit]
Een klasse hoeft eigenlijk alleen maar methods te hebben die direct invloed hebben op de data van het object zelf, en het object alleen. Anders zou je ook methods als 'postTopic' en 'requestsPage' kunnen maken. Maar die methods hebben geen invloed op User, ze gebruiken informatie van User.
De klasse StatisticsService roept dan in registerRequestOfUser() zelf wel $user->id() aan, aangezien dat de data is die nodig is.
Authentificatie zou ik ook niet in een User-klasse doen, mede om dezelfde reden. Daarnaast kan je meerdere, verschillende instanties van User hebben, maar kan er maar 1 user tegelijkertijd zijn ingelogd. Het gaat immers om de gebruiker, de bezoeker van de site. Die is niet meerdere personen tegelijk. Authentificatie zou je als een aparte klasse, of beter gezegd service kunnen beschouwen denk ik. (Met service bedoel ik een klasse, een object waar maar 1 instantie van kan bestaan. Zoek maar op het singleton design pattern)
De method activate() hoort wel thuis in User, aangezien deze een directe eigenschap van User aanpast.
Authentificatie -> Het inloggen van een user is inderdaad handiger om appart te houden, omdat het geen directe invloed heeft op de eigenschappen van de user.
Sendmail -> is ook niet direct op de user, mail moet ook een andere class zijn die het e-mail adres van de Userclass (waarin een nieuwe user kan worden aangemaakt) meeneemt.
Logout -> Zelfde als bij Authentificatie. -> Geen directe invloed op de user
Subscribe -> Kan wel in de class, met het aanmaken van een nieuwe user oefen je eigenlijk direct invloed uit op een user.. Aan de andere kant denk ik dat een class voor het hele inschrijf gebeuren (waarin username/ pass controle, mail controle enz.. komen) niet zou misstaan hier
Setlevel -> Wel blijven staan in de class, omdat je direct 1 van de eigenschappen van user verandert.
Activate -> Ook een directe aanpassing van 1 van de uservariabelen, dus wel blijven staan.
Authenticatie (= inloggen) is een aparte class, authorisatie ook (= rechten, mag deze user wel updaten? etc), mail ook, subscribe is eigenlijk gewoon een simpele query dus dat is een functie in je data-(access-)model. Je hoeft niet overal een klasse voor te maken, sommige dingen zijn gewoon databasehandelingen, ga ook eens kijken naar Model View Controller (vooral Model).
Het was ook niet de bedoeling om overal een aparte class voor te maken, maar meer dat een aantal dingen niet in de class komen. -> authorisatie enzo wel als class snap ik. ('t ging nu puur nog ff om de user class, waar zo heel wat minder van overblijft :s)
Dingen die ik zei dat uit die class mochten -> Kan inderdaad gewoon in een andere class. (zoals subscribe als functie in m'n data-(acces)model zou kunnen.
Wat vinden jullie eigenlijk van deze tutorial? (tjah.. 'k ben nog niet zo heel ver ermee, maar de opbouw lijkt me wel een juiste)Het is dan wel Engels, maar als ICT-er moet dat een makkie zijn :P
Ik vind het eigenlijk een beetje waardeloze tutorial. Deze tutorial leert je eigenlijk de syntax en werkt weer met hond-dier-voorbeelden, dat is niet praktisch. Dit gaat dus weer over syntax en niet echt over OOP naar mijn mening. Al snap je dit helemaal dan ben je nog steeds niet in staat goed object georienteerd te werken waarschijnlijk.
Ik denk dat de beste manier ook hier weer is om een beetje te klooien met wat er al bestaat. Ik zou zelf bijvoorbeeld eens naar Zend Framework kijken (je hoeft het niet te gebruiken, alleen kijken), dan zie je wanneer men nieuwe objecten maakt en wanneer niet en hoe deze in elkaar zitten.
