[oop] services... in de knoop
Op advies van enkelen van jullie leek het me een goed idee om van iedere service een apart object te maken wat je vervolgens toevoegt aan een container. Dus we hebben zeg maar een service met wat instellingen en die voegen we toe aan een container.
Code (php)
1
2
3
4
2
3
4
<?php
$container->add(new Service($instellingen, 'foo'));
$container->add(new Service($instellingen, 'bar'));
?>
$container->add(new Service($instellingen, 'foo'));
$container->add(new Service($instellingen, 'bar'));
?>
Als ik dan een service nodig heb, doe ik:
Code (php)
1
2
3
2
3
<?php
$foo = $container->get('foo');
?>
$foo = $container->get('foo');
?>
Omdat ik met losse Service objecten werk, weten die niet van elkaars bestaan af. En daar komt mijn "probleem". Stel nu dat de service 'foo' gebruik maakt van de service 'bar', hoe krijg ik dat dan voor elkaar?
Het lijkt mij dan dat het service object 'foo' toegang moet hebben tot de container waar het object in zit. Houdt dit dan in dat ik op het moment dat ik een service object toevoeg aan de container, ik de container als parameter moet meegeven aan het service object, dus zoiets:
Code (php)
1
2
3
2
3
<?php
$container->add(new Service($instellingen, 'foo', $container));
?>
$container->add(new Service($instellingen, 'foo', $container));
?>
Of is er een betere oplossing waardoor de service objecten gebruik kunnen maken van elkaar?
Ozzie PHP op 29/08/2014 00:50:17:
Als ik dan een service nodig heb, doe ik:
Code (php)
1
2
3
2
3
<?php
$foo = $container->get('foo');
?>
$foo = $container->get('foo');
?>
Aha, als ik een $container->get() zie, vermoed ik dat er een $container->set() in de buurt is. Dáár haalt je 'foo' dus de 'bar' vandaan.
Symfony kent bijvoorbeeld vergelijkbare parameter accessors:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$container->setParameter('mailer.transport', 'sendmail');
$container->getParameter('mailer.transport');
$container->hasParameter('mailer.transport');
?>
$container->setParameter('mailer.transport', 'sendmail');
$container->getParameter('mailer.transport');
$container->hasParameter('mailer.transport');
?>
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<?php
$mailer = new Service('Ozzie\Mail\Mailer');
$container->set('ozzie.mailer', $mailer);
$newsletter = new Service('Ozzie\Newsletter\SendManager', array(
new Reference('ozzie.mailer'),
));
$container->set('ozzie.newsletter.manager', $newsletter);
?>
$mailer = new Service('Ozzie\Mail\Mailer');
$container->set('ozzie.mailer', $mailer);
$newsletter = new Service('Ozzie\Newsletter\SendManager', array(
new Reference('ozzie.mailer'),
));
$container->set('ozzie.newsletter.manager', $newsletter);
?>
Wat ik wil bewerkstelligen is dat een service object alle informatie bevat om de service aan te maken. Dus het service object bevat de properties "class" en "parameters". Dat complete object voeg ik dan toe (add) aan de container. Op het moment dat ik een service opvraag, wordt er een instance (object) van de class aangemaakt op basis van de parameters. Bij de parameters wil ik aangeven of er een andere service moet worden gebruikt, bijv. door een $-teken voor die parameter te zetten. Dus bijv. parameters: foo = 10, bar = $bar. Het $-teken bij $bar geeft dan aan dat het om een andere service gaat. Het service object ziet nu dus dat er een $bar service moet worden gebruikt als parameter, maar het service object zelf beschikt niet over de container waar $bar in zit. Dat is het probleem.
@Wouter
Hoe haalt jouw new Reference dan 'ozzie.mailer' op? Dat Reference object moet dan toch ook toegang hebben tot de container?
Ik zie trouwens in jouw voorbeeld dat je de ID 'ozzie.mailer' toch meegeeft aan de container en niet aan het object zelf. Waarom toch die keuze? Of was dit gewoon een voorbeeldje?
Waarom ik IDs gebruik is omdat symfony dat simpelweg doet, maar ook om de reden die ik in je andere topic heb geschreven
Ik snap 'm even niet. Zit in zo'n service object dan alleen een definitie? Ik dacht namelijk dat het service object ook de class instance aanmaakt. Dat was toch de bedoeling van die afzonderlijke objecten? Of begrijp ik het verkeerd?
Wat hoort er dan in zo'n los service object te zitten? Alleen de definitie gegevens? Of bouwt het service object ook de instance op... of doet juist de container dat en is het service object dus niet meer dan een data object (en kan ik het wellicht beter definition object noemen ipv service object)?
Graag jullie hulp. Alvast dank.
"Een definitie is alleen de definitie, niks meer. Het mag dus geen acties uitvoeren. Dat doet de container (of een service processor die door de container wordt gebruikt)."
Ik snap niet hoe ik het nu moet oplossen eerlijk gezegd. Het probleem is dat wanneer service A service B nodig heeft, ze elkaar (via de container) moeten kunnen aanspreken. Als je complete service objecten gebruikt, dan gaat dat niet want die hebben geen toegang tot de container.
Ik vind het een beetje lastig uitleggen. Snap je wat ik bedoel te zeggen?
Er is hier geen goed of fout. Het hangt ervan af wat je met die services wilt doen.
- Het ene uiterste is: ik zet de services alvast voor je klaar, zodat ze op afroep beschikbaar zijn.
- Het andere uiterste is: mocht je een service nodig hebben, dan kun je die hier vinden.
Code (php)
1
2
3
4
5
2
3
4
5
<?php
$foo = new Service(['class' => 'Foo', 'params' => ['foo' => true, 'bar' => '$bar']]);
// Bij de parameters zie je '$bar' staan. Het $ teken geeft aan dat het om een andere service gaat.
$container->add($foo, 'foo_service');
?>
$foo = new Service(['class' => 'Foo', 'params' => ['foo' => true, 'bar' => '$bar']]);
// Bij de parameters zie je '$bar' staan. Het $ teken geeft aan dat het om een andere service gaat.
$container->add($foo, 'foo_service');
?>
Op het moment dat ik de foo service aanroep, moet er dus een instance worden aangemaakt. Voor het aanmaken van die instance heb ik de bar service nodig. Om die bar service te kunnen gebruiken, moet je die kunnen aanroepen vanuit de container. Stel nu dat ik de instance aanmaak vanuit het foo service object, dan heb ik geen toegang tot de container. Tenzij ik op het moment dat ik de foo service aanmaak, ik de container als 3e parameter meegeef. Dan krijg je dit, maar dat lijkt me niet echt de bedoeling:
$foo = new Service(['class' => 'Foo', 'params' => ['foo' => true, 'bar' => '$bar']], $container);
Het alternatief is dan dat je de instance vanuit de container zelf aanmaakt, maar dan is een service object dus niets meer dan een data object waarin je een paar properties opslaat.
Wat is nu precies de bedoeling van zo'n service object en wat is wijsheid?
Gewijzigd op 30/08/2014 16:42:42 door Ozzie PHP
- je kunt iets dat uit twee stappen bestaat soms beter uit twee lagen opbouwen en
- je hebt soms een singleton nodig terwijl je hebt gelezen dat je dit nooit mag gebruiken ;-)
>> Op het moment dat ik de foo service aanroep, moet er dus een instance worden aangemaakt.
Precies, tenzij je al een foo had en de logica gebiedt dat er maar één foo mag zijn.
Vereenvoudigd:
- Je hebt bedrijfskritieke services die je áltijd nodig hebt. Die kun je alvast instantiëren.
- Je hebt services die je niet altijd nodig hebt maar die wel kritiek zijn. Daarvan wil je op afroep een instantie hebben.
- Je hebt services die moeten kunnen worden hergebruikt. Die horen in een cache.
- Je hebt services die niet kritiek zijn maar "gewoon handig". Die horen op een extra laag die de andere services niet in gevaar brengt.
Stel we hebben een Ward service met als class => Ward en als parameters name => Ward en status => Put.
Deze gegevens stoppen we in een apart object(X). Dit object stoppen we vervolgens weer in een container(Y), zodat ik de Ward service kan ophalen uit de container op het moment dat ik daar behoefte aan heb. Dus op het moment dat ik de Ward service nodig heb, spreek ik de container aan en krijg ik een Ward object terug: $ward = $container->get('Ward');
Mijn enige vraag is nu... wie gaat (op basis van de class-naam en de parameters) het Ward object aanmaken? Maakt het losse object(X) dit aan, of maakt het container object(Y) dit aan?
Dat mag je zelf bepalen. 't is jouw code, er zijn geen regels, er is geen OO wetboek. Je probeert opnieuw te zoeken naar regels en je wordt opnieuw duizelig omdat je ontdekt dat 2 mensen het op 2 verschillende manieren aanpakken. Ik kan je vertellen, haal er een 3de persoon bij en je hebt 3 plannen van aanpak.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<?php
class Container
{
// ...
public function get($id)
{
if (isset($this->instances[$id])) {
return $this->instances[$id];
} elseif (isset($this->services[$id])) {
$service = $this->serviceProcessor->process($this->services[$id], $container);
if ($this->services[$id]->isShared()) {
$this->instances = $service;
}
return $service;
} else {
throw new UnknownServiceException::serviceNotAvailable();
}
}
}
?>
class Container
{
// ...
public function get($id)
{
if (isset($this->instances[$id])) {
return $this->instances[$id];
} elseif (isset($this->services[$id])) {
$service = $this->serviceProcessor->process($this->services[$id], $container);
if ($this->services[$id]->isShared()) {
$this->instances = $service;
}
return $service;
} else {
throw new UnknownServiceException::serviceNotAvailable();
}
}
}
?>
Code (php)
Op deze manier kun je een custom service processor gebruiken, maar default je tot een processor voor service definitions.