setten in __construct of in aparte functie

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Ozzie PHP

Ozzie PHP

05/01/2013 00:25:03
Quote Anchor link
Hallo mensen,

Ik vraag me af of het iets uit maakt of je properties via een functie set of direct in de constructor.
Zelf set ik ze vaak direct in de constructor. Maar ik zie dat anderen het ook via een aparte set functie doen.

Ik doe het vaak zo:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?php
public function __construct() {
  $this->iets = 'iets';
}
?>


Ik zie dat anderen het ook wel eens zo doen:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
<?php
public function __construct() {
  $this->setIets();
}

private function setIets() {
  $this->iets = 'iets';
}
?>


Is het een beter dan het ander, of maakt het niets uit?
Gewijzigd op 05/01/2013 00:25:33 door Ozzie PHP
 
PHP hulp

PHP hulp

24/11/2024 01:39:51
 
Wouter J

Wouter J

05/01/2013 00:42:17
Quote Anchor link
Ik reageer even, omdat ik waarschijnlijk bedoelt wordt met 'anderen'... ;)

Allereerst: Het maakt geen verschil en is gewoon wat jou style is, ik ga hier dus niet verder over in discussie en vertel alleen maar wat mij er toe gezet heeft om van voorbeeld 1 over te stappen naar voorbeeld 2.

Eerst gebruik ik gewoon altijd de properties binnen mijn klassen en gebruikte ik altijd protected. Ik was van mening dat ik deze properties gewoon mocht gebruiken en de getters en setters voor buiten de klasse waren.

Toen kwam ik ooit wat meningen tegen over aparte setters en private properties, van oa Erwin en Fabien Potencier. Daarom startte ik een topic: http://www.phphulp.nl/php/forum/topic/setters-doen-of-niet/85843/ (waarin jij ook reageerde trouwens...)

Sindsdien ben ik setters en getters en private properties gaan gebruiken en het beleid daarvan maak ik steeds strenger. Tegenwoordig geef ik maar 2 methods toegang tot de property en dat is de setter en de getter, de andere (zelfs een hasser of isser) gebruiken deze getters en setters.

Wat ik nog meer doe is dat ik error handling compleet naar de setter of getter overhevel, bijv:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
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
<?php
// niet
class Foo
{
    protected $dbal;

    public function __construct(\PDO $dbal)
    {
        $this->dbal = $dbal;
    }
}

// maar
class Foo
{
    private $dbal;

    /**
     * @param \PDO $dbal
     */
    public function __construct($dbal)
    {
        $this->setDbal($dbal);
    }

    public function setDbal\PDO $dbal)
    {
        $this->dbal = $dbal;
    }
}
?>

Je ziet dat ik hier meteen ook PHPdoc gebruik om toch duidelijk te krijgen welke types er verwacht worden.
 
Ozzie PHP

Ozzie PHP

05/01/2013 00:53:38
Quote Anchor link
Thanks Wout... (en ja, ik had het over jou :-))))))

Ik twijfel of ik dit ook zo moet gaan doen. Via constructor is het snel, maar via aparte setters is ook wel weer heel erg duidelijk. Zeker als er nog iets met de input moet gebeuren voordat de property geset wordt. Nadeel is alleen dat het wat meer werk is, en meer regels code... wat in theorie weer vertragend werkt. Pfff, het is wel een dag van de keuzes vandaag zeg :)
 
Wouter J

Wouter J

05/01/2013 00:56:38
Quote Anchor link
Ozzie, het is vooral handig voor uitbreiding. Stel ik besluit het heel anders te gaan aanpakken, dan hoef ik alleen de setter of getter aan te passen.

Of als ik straks de dbal niet meer ga gebruiken en uit mijn code sloop, dan is het soms onmogelijk om alle children aan te passen, bijv. in een open-source applicatie, en dan behoudt ik gewoon de getter en laat die een dummy dbal klasse teruggeven.
 
Ozzie PHP

Ozzie PHP

05/01/2013 01:01:11
Quote Anchor link
Ja, heb je wel gelijk in. Ik denk dat ik het dan ook maar in ga voeren. Nja, beter nu dan als ik straks 2 maanden verder ben. En dan ga ik ook die request class nog aanpassen met jouw tips. Ja... genoeg te doen... werk aan de winkel!
 
Wouter J

Wouter J

05/01/2013 01:02:12
Quote Anchor link
En DI en Unit Testing gebruiken, je hebt een druk weekend :)
 
Ozzie PHP

Ozzie PHP

05/01/2013 01:05:23
Quote Anchor link
Ja, DI ga ik gebruiken... maar ik moet eerst m'n unbound requests afvangen. Daar heb ik DI nog niet voor nodig... Unit testen... wie weet ooit :) Eerst maar eens aan het programmeren gaan slaan. Zie tegen dit gedeelte wel een beetje op. Container maken, misschien zo'n parameter zak... zal allemaal wel weer een hoop tijd kosten. Maar ja, je wilt wat en dan moet je niet zeuren ook ;-)
 
Erwin H

Erwin H

05/01/2013 10:56:18
Quote Anchor link
Wouter J op 05/01/2013 00:56:38:
Ozzie, het is vooral handig voor uitbreiding. Stel ik besluit het heel anders te gaan aanpakken, dan hoef ik alleen de setter of getter aan te passen.

Of als ik straks de dbal niet meer ga gebruiken en uit mijn code sloop, dan is het soms onmogelijk om alle children aan te passen, bijv. in een open-source applicatie, en dan behoudt ik gewoon de getter en laat die een dummy dbal klasse teruggeven.

Laatst kwam ik (in mijn eigen code...) nog een reden tegen om altijd via getters en setters te werken. Als je protected geruikt waar het kan en private waar het moet, dan kom je op zeker moment op een punt waarin je simpelweg niet meer weet welke je nu gebruikt in welke class. Ik heb bijvoorbeeld een view factory die in principe in alle view classes beschikbaar is. Alleen door nog oude code te gebruiken sprak ik die in sommige situaties aan als $this->getFactory(), in andere als $this->factory. In het tweede geval dus een protected property inderdaad. Maakt het werk een stuk lastiger, omdat je elke keer weer moet checken hoe het ook weer zat.
Anyway, nog een reden dus om mijn eigen regel echt 100% door te voeren.
Gewijzigd op 05/01/2013 10:56:57 door Erwin H
 
Ozzie PHP

Ozzie PHP

05/01/2013 17:14:54
Quote Anchor link
Thanks Erwin, ik ga het ook maar doen. Genoeg redenen gehoord nu!
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.