Virusscanner tips?
OOP constructor wanneer wel en wanneer niet?
Alleen nu vraag ik me af. Wat is nou mooier OOP:
Versie 1
De constructor om de naam, wachtwoord, enz. al vast te stellen
Code (php)
Versie 2
Of is dit mooier? En gebruik je een constructor alleen om bepaalde variabelen toe te voegen, connectie te maken met de db, enz.?
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Gewijzigd op 20/12/2011 17:53:26 door Wouter J
In de constructor zet ik altijd datgene waarvan het object afhankelijk van is (bijvoorbeeld een database) en een setter gebruik ik voor de rest.
Niels
Die set() methods zijn meer om later nog dingen bij te werken, zoals je wachtwoord in jouw voorbeeld.
Een beetje zoals Niels dus ook zegt.
Ik kan er ook naast zitten hoor maar mocht dit zo zijn dan hoor ik dat graag want je bent nooit uitgeleerd :P
In dit voorbeeld, een user heeft altijd een username en een password. Je kunt niet een user hebben zonder een naam. Dus je zal user wel meenemen in de constructor en de password niet? Aangezien het password alleen nodig is bij het inloggen en je daar een aparte class voor nodig is?
In C++ en andere object-georiënteerde talen waar memory management wel belangrijk is heb je RAII als vuistregel. RAII houdt ongeveer in dat wanneer je een object aanmaakt, je het ook direct kan gebruiken. En daarvoor moet je dus bij het aanmaken alle afhankelijkheden meegeven.. via de constructor. Als je dat consequent afdwingt heb je nooit een object dat wel bestaat, maar nog niet gebruikt kan worden. En dat scheelt ook weer een boel checks in het object zelf schrijven (kan dit object gebruikt worden? zijn alle bronnen aanwezig?)
(edit: het slaat niet helemaal op PHP, maar het idee dat wanneer je een object hebt, je het ook daadwerkelijk al direct kan gebruiken is voor mij wel het grote voordeel van constructors goed gebruiken in PHP.)
Gewijzigd op 21/12/2011 09:45:31 door Jelmer -
