De PHPhulp kroeg
Oop in PHP 5
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()
Gewijzigd op 01/01/1970 01:00:00 door Jan geen
StatisticsService->instanceForPage($page)->registerRequestOfUser($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.
Klik
Heb het al;
http://www.phpfreaks.com/tutorials/150/0.php
... tis jammer dat ie in PHP4 gemaakt is. (Edit: Nouja, sommige gedeelten dan)
Gewijzigd op 01/01/1970 01:00:00 door Gerben Jacobs
Hij geeft ook aan dat sommige dingen voor php4 zijn, maar geeft ook (meestal) de php5 variant.
Edit:
Ik vind het voorbeeld wat daar gebruikt wordt ook wel leuk. Een tastbaar en bekend ding, waar je jezelf een beeld bij kan maken.
Ik vind het voorbeeld wat daar gebruikt wordt ook wel leuk. Een tastbaar en bekend ding, waar je jezelf een beeld bij kan maken.
Gewijzigd op 01/01/1970 01:00:00 door Robert Deiman
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.
Op die manier zal ik er toch wel uit moeten komen denk ik :) De gewone PHP syntax ken ik wel al, dit is een nieuwe stap, die ik vind ik onderhand wel eens zal mogen/ moeten maken.
Edit:
Ok, ben al even aan het kijken geslagen. Ik zie dat het framework de includes gewoon als PHP bestand opslaat en niet (zoals velen wel doen) als .inc.php
Het ziet er op het 1e gezicht vrij onduidelijk uit, maar dat komt door de vele losse bestandjes. Ik kan het in ieder geval al wel lezen.. Ga er eens rustig mee verder, en kijken of ik het ga snappen.
Zoals voor Currency ben ik al verder aan het kijken geweest. Ik begrijp dat die via de "locale.php" controleerd welke regio je bent, stelt via de data.php een aantal dingen in (uit een XML bestand voor de taal) en gebruikt dat door het hele systeem, dus ook voor het Currency symbool
Het ziet er op het 1e gezicht vrij onduidelijk uit, maar dat komt door de vele losse bestandjes. Ik kan het in ieder geval al wel lezen.. Ga er eens rustig mee verder, en kijken of ik het ga snappen.
Zoals voor Currency ben ik al verder aan het kijken geweest. Ik begrijp dat die via de "locale.php" controleerd welke regio je bent, stelt via de data.php een aantal dingen in (uit een XML bestand voor de taal) en gebruikt dat door het hele systeem, dus ook voor het Currency symbool
Gewijzigd op 01/01/1970 01:00:00 door Robert Deiman