[oop] constructor als "uitvoerder"?
Een Processor/Core/Kernel class doorloopt allerlei stappen. Mag de consructor deze stappen triggeren/uitvoeren? Even een heeeeel erg versimpeld voorbeeldje met 3 fictieve functies.
Code (php)
Zou de constructor deze functies mogen triggeren? Is dat oké volgens het OOP principe?
De vraag is meer of het handig is. En dat kan jij alleen beantwoorden. Als jij denkt dat het handig is dat die class direct methods etc aanroept op het moment dat jij daar een instantie van aanmaakt, dan is dat goed.
Ik zou overigen wel aan type hinting doen wanneer dat kan, Dus:
Code (php)
1
Public function __construct ( IRequest $request ) { }
Dan weet je zeker dat het object dat jij binnen krijgt beschikt over bepaalde methods.
Gewijzigd op 18/05/2014 17:28:23 door D Vivendi
Oké... ik vroeg me dus af of zoiets oké is, omdat de constructor dan het hele proces "aanstuurt".
Je zou bijvoorbeeld ook dit kunnen doen:
Code (php)
Nu stuurt de "execute" method alles aan, maar volgens mij is dit eigenlijk een "schijn"-constructie omdat de "execute" method alsnog door de constructor wordt aangeroepen en het in feite dus een verlengstuk van de constructor is. Mee eens?
Gewijzigd op 18/05/2014 17:32:25 door Ozzie PHP
Ik dacht dat je het eerst over public methods had.
D Vivendi op 18/05/2014 17:41:11:
Oneens. Het kan wel handig zijn om private methods aan te roepen vanuit je constructor. Maar alleen zodat je niet veel logica in een constructor hoef te hebben. Stukken logica verhuis je dan naar methods die je een goed omschrijvende naam geeft.
Ik dacht dat je het eerst over public methods had.
Ik dacht dat je het eerst over public methods had.
Private of public heeft hier niets mee te maken. Het mag beiden vanuit de constructor.
Toevoeging op 18/05/2014 18:00:15:
Ozzie PHP op 18/05/2014 17:31:45:
Nu stuurt de "execute" method alles aan, maar volgens mij is dit eigenlijk een "schijn"-constructie omdat de "execute" method alsnog door de constructor wordt aangeroepen en het in feite dus een verlengstuk van de constructor is. Mee eens?
Ja en Nee. die execute method kan ook later nog worden aangeroepen vanuit een andere method. Hierdoor is het geen verlengstuk meer van de constructor. Wanneer er echt geen reden valt te bedenken onder welke omstandigheden deze functie later nog eens aangeroepen zou kunnen worden dan is het inderdaad niets meer dan een verlengstuk van de constructor maar als dat dan de leesbaarheid van de code verbeterd ben ik een voorstander om het alsnog te gebruiken. Uiteraard moeten de namen van je methods zo goed mogelijk omschrijven wat de taak is van de method zoals D Vivendi opmerkt.
>> Wat mij betreft hoort dus alleen $this->initializeRequest(); in de constructor thuis.
Oké... maar ik wil dus niet handmatig de "executeRequest" method aanroepen, die moet dus ergens door worden aangeroepen. In de constructor zelf? Of de constructor een soort van "execute" method laten aanroepen die vervolgens alle methods aanroept? Volgens mij schiet ik daar eigenlijk weinig mee op.
Misschien nog eens nalezen wat het doel van een constructor is?
Kun je ook uitleggen waarom Dos? Ik roep geen enkele functie van buiten de class aan. Dus alles moet vanuit de class zelf worden gestart. Hoe kan ik dat dan volgens jou het beste doen?
Ik vind het leuk dat je reageert... maar het is dan ook wel handig als je aangeeft hoe het volgens jou dan wel moet :-)
Dos Moonen:
Misschien nog eens nalezen wat het doel van een constructor is?
Heb je dat al gedaan?
Een optie is om de constructor private te maken en het meeste van wat nu in de constructor gebeurt verplaatsen naar een public static method.
Je moet dit soort dingen gewoon nooit bij aanmaken doen :)
Ik weet wat het doel is. En daar stelde ik dus een vraag over:
Ozzie PHP op 18/05/2014 17:09:16:
Zou de constructor deze functies mogen triggeren? Is dat oké volgens het OOP principe?
Volgens Frank mag ik dat doen. Volgens Dos niet?
Wat is dan volgens Dos wél de juiste manier?
@Dos:
>> Een optie is om de constructor private te maken en het meeste van wat nu in de constructor gebeurt verplaatsen naar een public static method.
Wat is dan het wezenlijke verschil als ik vragen mag? En waarom een static method?
Toevoeging op 18/05/2014 20:52:12:
>> Je moet dit soort dingen gewoon nooit bij aanmaken doen :)
Maar dan moet ik het handmatig triggeren dus?
Omdat je een object met private constructor niet kunt aanmaken.
>> Maar dan moet ik het handmatig triggeren dus?
Ja, erg hè? :P
Oké... maar net zeg je nog dat ik geen static method moet gebruiken :-s
>> Ja, erg hè? :P
Alle gekheid op een stokje. Het gaat er niet om of het wel of niet erg is.
Waar het om gaat is het volgende. En ik hoop dat je dan even kunt meedenken met me ;)
Het enige wat die class kan doen, is een request afhandelen. Niks meer en niks minder. Ward vertelde ooit op het forum dat als je een bepaalde functie hebt die je altijd aanroept na het initialiseren van een class, dat je dan die functie net zo goed in de constructor kunt stoppen, aangezien de functie blijkbaar altijd moet worden aangeroepen. Goed punt toch? Dus vanuit dat oogpunt zou ik de execute functie vanuit de constructor kunnen aanroepen.
Is dit dan wel oké?
Het maakt niks uit als hij het uitvoeren naar een andere functie verplaatst en het vervolgens aanroept. Dan gebeurd het nog steeds tijdens de constructie periode.
Ik zou niet eens die Request meegeven als constructor argument, waarom zou je niet 2 verschillende requesten mogen afhandelen met hetzelfde object?
Nogmaals: Is het erg als je 2 requesten afhandelt? Nee toch? Waarom zou je je dan gaan beperken?
Omdat je per pagina-aanroep maar 1 request kunt afhandelen.
Maar oké... dus jij zegt: niks aanroepen vanuit de constructor.
Ben jij het dan niet eens met de opmerking van Ward? Dus dat wanneer je altijd dit doet:
Code (php)
1
2
3
4
2
3
4
<?php
$core = new Core($request);
$core->execute();
?>
$core = new Core($request);
$core->execute();
?>
Dat je dan net zo goed die execute method kunt aanroepen vanuit de constructor?