Setters, doen of niet?
Code (php)
Alleen nu kwam ik in de Symfony source dit tegen:
Code (php)
Eigenlijk vind ik dit wel mooi. Je verdeelt zo de verantwoordelijkheden, de constructor moet niet van de properties beslissen hoe ze worden opgeslagen, daar hebben ze een eigen setter voor. En als je nou iets daarin wilt aanpassen, zoals dat een username altijd met een hoofdletter begint, hoef je alleen de setter aan te passen.
Maar aan de andere kant bezorgt dit je ook weer wat extra werk en een extra method call. Wat vinden jullie mooier/wat gebruiken jullie altijd?
Zeer handig en gewoon mooier. En er is niks mis met wat extra werk :-P
Code (php)
Gewijzigd op 24/07/2012 21:27:46 door Jan Koehoorn
Deze getters/setters zijn alleen bedoelt om speciale set/get gevallen te kunnen maken, zoals opties opslaan in een array. Hetzelfde geldt voor al die andere magic methods, je voegt ook niet dit toe:
Pim, dat ben ik ook met je eens. Alleen wat noem je logica. Stel ik verwacht een array met opties, wat doe je dan:
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
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
<?php
// afhandelen in constructor
class Foo
{
protected $options = array();
public function __construct(array $options = array())
{
$this->options = $options;
}
}
// afhandelen in setter
class Foo
{
protected $options = array();
public function __construct($options = array())
{
$this->setOptions($options);
}
public function setOption(array $options)
{
$this->options = $options;
}
}
?>
// afhandelen in constructor
class Foo
{
protected $options = array();
public function __construct(array $options = array())
{
$this->options = $options;
}
}
// afhandelen in setter
class Foo
{
protected $options = array();
public function __construct($options = array())
{
$this->setOptions($options);
}
public function setOption(array $options)
{
$this->options = $options;
}
}
?>
En hetzelfde geldt voor het typecasten wat ik altijd gebruik of het checken of de parameter wel van de juiste interface is.
In Java doe ik het niet altijd (meestal wel), maar daar is voor mij de reden dat je zelf de naam van de constructor kan kiezen.
Wouter J op 24/07/2012 19:47:57:
Eigenlijk vind ik dit wel mooi. Je verdeelt zo de verantwoordelijkheden, de constructor moet niet van de properties beslissen hoe ze worden opgeslagen, daar hebben ze een eigen setter voor. En als je nou iets daarin wilt aanpassen, zoals dat een username altijd met een hoofdletter begint, hoef je alleen de setter aan te passen.
Maar aan de andere kant bezorgt dit je ook weer wat extra werk en een extra method call. Wat vinden jullie mooier/wat gebruiken jullie altijd?
Maar aan de andere kant bezorgt dit je ook weer wat extra werk en een extra method call. Wat vinden jullie mooier/wat gebruiken jullie altijd?
Dat is dus in essentie waarom ik properties altijd als private definieer en dus ook de kind classes een propertie via de setter laat werken ;-)
En wat extra werk betreft, volgens mij valt dat wel mee. Alleen als je normaal gesproken geen setter zou hebben voor de betreffende property is het meer werk. In alle andere gevallen niet.
Gewijzigd op 25/07/2012 08:55:28 door Erwin H
Toevoeging op 25/07/2012 12:19:56:
Kris Peeters op 25/07/2012 12:07:05:
Ik ben geneigd het een goed idee te vinden om eigenschappen aan te spreken via de setter (en eventueel getter).
Een eigenschap aanspreken via de setter... jaajaa... Da's erg bijzonder :)
Jan Koehoorn op 24/07/2012 21:25:49:
Er wordt ook vaak gebruik gemaakt van de magic methods __get en __set. Dan hoef je namelijk niet voor elke membervariabele een aparte setter en getter te schrijven. Opzetje:
Dit gebruik ik zelf ook vaak, erg fijn!
Echter niet in high-performance applicaties. Dit is namelijk zo traag als dikke stront door een trechter.. omhoog :')
Dit geldt voor veel 'magic methods' overigens.
Note ook dat dit ook niet kan voor static properties.
Quote:
Note ook dat dit ook niet kan voor static properties.
En ook niet voor public properties.
En wat is er eigenlijk zo fijn aan? Het voegt naar mijn mening niks meer toe dan de normale omstandigheden?
Wouter J op 25/07/2012 15:26:19:
En ook niet voor public properties.
Tuurlijk wel, waarom zou dat niet kunnen?
Code (php)
Wat denk je dat er geprint wordt?
Daarom kan je dus geen magic setter gebruiken voor een public property.
Als je een eigenschap als public zet, weet je dat ze kan overschreven worden.
Als je niet wil dat dit kan, moet je ze maar op private/protected zetten.
Of het nu kan of niet (die magic set en get), lijkt me meer een discussie die niet echt ter zake is.
Gewijzigd op 25/07/2012 17:30:25 door Kris Peeters
Erwin H op 25/07/2012 12:44:13:
Je spreekt hem aan via de setter en leest hem uit via de getter. Dat is de normale gang van zaken inderdaad....
Nee, je stelt een property in via een setter en je spreekt deze property aan (je leest de waarde van die property uit) via een getter.
Definitie aanspreken:
Quote:
1) beginnen te praten tegen (iemand)
2) zo zijn dat iemand het mooi of aangenaam vindt
3) (een reserve) gaan gebruiken
2) zo zijn dat iemand het mooi of aangenaam vindt
3) (een reserve) gaan gebruiken
Als je de eerste als uitgangspunt neemt dan kan je het uitleggen als iets geven, iets 'setten' dus.
Als je de derde neemt kan je het lezen als iets opnemen, als iets 'getten'.
Volgens mij spreek je een property dus aan via de setters EN de getters :-)
het wordt nu inderdaad vrij zinloos :-D