[OOP] Arrays declareren in klassen
Sommigen declareren direct een array in de class properties:
Anderen bewaren het voor de constructor of stellen het uit tot een setter wordt aangeroepen, schematisch:
Code (php)
Wat zijn eigenlijk de voor- of nadelen van beide stijlen? En geldt hiervoor een best practice?
En ik set variabelen altijd via een setter dus niet via de construct, zo voorkom je dubbele code, stel ik wil een directory setten dan controlleer ik eerst of de directory bestaat en anders maak ik hem aan. Als ik dat al in de contructor zou doen en via een setter dan krijg je dubbele code. Daarom set ik altijd alles via een setter en die roep ik aan in de constructor (dit geld ook voor de getters).
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
<?php
class FooBar {
private $foo;
private $bar;
public function __construct($foo, $bar) {
$this->setFoo($foo);
$this->setBar($bar);
}
public function setFoo($foo) {
$this->foo = $foo;
return $this;
}
public function getFoo() {
return $this->foo;
}
public function setBar($bar) {
$this->bar = $bar;
return $this;
}
public function getBar() {
return $this->bar;
}
}
?>
class FooBar {
private $foo;
private $bar;
public function __construct($foo, $bar) {
$this->setFoo($foo);
$this->setBar($bar);
}
public function setFoo($foo) {
$this->foo = $foo;
return $this;
}
public function getFoo() {
return $this->foo;
}
public function setBar($bar) {
$this->bar = $bar;
return $this;
}
public function getBar() {
return $this->bar;
}
}
?>
Gewijzigd op 17/01/2014 11:55:35 door Joakim Broden
Metal Hertog Jan op 17/01/2014 11:55:08:
Als het om een array gaat declareer ik het al in de class properties. Zodat het altijd een array is en de set nog niet gedaan hebt.
Maar dat garandeert niet dat de property een array blijft, want elders zou een ander datatype kunnen worden geset. Dan kun je toch beter setFoo(array $foo) gebruiken?
Welke beter is? Geen van beide (of allebei, net hoe positief je in het leven staan ;) ). Er is geen verschil tussen beide.
Op setter niveau declareren lijkt mij vrij nutteloos.
Ward van der Put op 17/01/2014 12:04:23:
Maar dat garandeert niet dat de property een array blijft, want elders zou een ander datatype kunnen worden geset. Dan kun je toch beter setFoo(array $foo) gebruiken?
Metal Hertog Jan op 17/01/2014 11:55:08:
Als het om een array gaat declareer ik het al in de class properties. Zodat het altijd een array is en de set nog niet gedaan hebt.
Maar dat garandeert niet dat de property een array blijft, want elders zou een ander datatype kunnen worden geset. Dan kun je toch beter setFoo(array $foo) gebruiken?
Theoretisch heb je gelijk, maar in mijn ogen heb je dan een serieuze fout in je class. Je class is als geheel verantwoordelijk voor zijn eigen properties en daarmee moet je binnen een class ervanuit kunnen gaan dat als een property een array moet zijn het dat dus altijd ook is. Binnen een class zou je wat mij betreft niet overal hoeven af te dwingen danwel te checken dat een private property is wat het moet zijn (waarmee ik dus ook maar weer eens impliciet aangeef waarom je bij mijn geen protected en public properties aantreft). Wat betreft declareren ga ik dan ook met Hertog Jan (maar ben ik het ook eens met Wouter dat het een niet per definitie beter is dan het ander).
Gewijzigd op 17/01/2014 22:35:42 door Erwin H
Wanneer je wilt afdwingen dat een property wordt geset zoals de betreffende class verreisd, gebruik je typehinting (in dit geval is het array, ook zal dit vaak een verwijzing zijn naar een interface, en bij gebrek hiervan naar een class zelf), naar mijn mening is dit absoluut niet slecht maar juist goed, daar er wordt voorkomen dat de properties verkeerde waarden hebben.
Local Dev op 18/01/2014 00:08:32:
@Erwin H, wat is er fout aan "typehinting" van een setter?
Niets mis met het typehinten van een setter. Zeker niet als de setter public of protected is. Waar het mij om gaat is dat binnen de class je verder niet meer zou moeten hoeven checken dat het een array is. De setter (of constructor, of definitie) moet bepalen dat het een array is en vervolgens mag je overal in de class ervanuit kunnen gaan dat het ook daadwerkelijk een array is. Check alleen alles wat van buiten komt, niet wat van binnen komt.
Een array kan PHP niet op die manier "type jugglen" naar een string of een int. Bij het omzetten naar een string krijg je "Array", totaal niet wat je verwacht. Bij het omzetten naar een int zal je 0 of 1 krijgen, en als je dat doet doormiddel van rekenoperator krijg je "Fatal error: Unsupported operand types".
Het typehinten van objecten is gewoon volledig omdat dat 1 van de keyprincipes is van OOP.
Maar ergens ook wel een beetje inconsequent...
Hier weet je dus dat $properties een array moet zijn, maar wat is $code? Een int of een string?
Ik denk trouwens dat het in de praktijk voldoende is om alleen objecten te typehinten. Als het goed is kun je aan de naam van de variabele zien of iets een array is, omdat de naam dan meervoud is: properties (array) versus property (string).
Gewijzigd op 18/01/2014 17:00:48 door Ozzie PHP
Dat een argument meervoudig of enkelvoudig heeft ook totaal geen nut, dat weet PHP niet. Het type hinten op classen en arrays heeft de code als doel, niet de documentatie.
Wat is dan het nut van het typehinten van een parameter? Dat is toch om te voorkomen dat je een verkeerd type opgeeft? Want als je dit hebt:
En je geeft een int als argument in plaats van een array, dan krijg je een foutmelding. In die zin is het toch een vorm van documentatie, zodat je zelf weet wat $bar zou moeten zijn?
Met andere woorden een exception.
Offtopic:
Ward, geef je aub even een gil als we te veel afdwalen, of als je nog vragen hebt?
En nee, typehinting is geen documentatie maar het afdwingen van de juiste parameters.
Gewijzigd op 19/01/2014 01:29:58 door Local Dev
Oké... maar als ik dus het verkeerde type opgeef, dan volgt er een error. Het is niet zo dat dit type dan wordt omgezet naar het juiste type. Dat bedoel ik eigenlijk.
Sommige errors wel. Dit is een catchable fatal error, iets wat je kunt opvangen in een catch statement dus.
Pfff, ik blijf iedere dag nieuwe dingen leren. En catch ik die gewoon als een algemene exception? Dus zo:
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
<?php
try {
} catch(Exception $e) {
}
?>
try {
} catch(Exception $e) {
}
?>
Of werkt dat op een andere manier?