Objecten doorgeven, zo min mogelijk afhankelijk

Door Write Down op 05-02-2013 22:57

2.303 views

Hi,

Ik zit me af te vragen hoe ik op een transparante manier object het best kan doorgeven. Echter wil ik er voor zorgen dat de klassen niet afhankelijk van mekaar worden. Ik denk dat ik daar momenteel vrij goed in slaag. Alleen, ik ben er nog niet geheel uit. Ik zoek dus meningen, en eventuele alternatieven.

Ik ben bezig met het ontwikkelen van een klein simpel framework. Het framework is opgebouwd volgens het MVC principe. Alle requests komen binnen op mijn 'FrontController'. Deze bepaalt dan welke end controller er gebruikt moet worden, welke actie er uit gevoerd moet worden, paramaters...

Om de resources netjes te gebruiken, heb ik in mijn FrontController gebruik gemaakt van een Service Container. Deze houdt o.a. de log-service bij en de database-service. Deze worden dan overgedragen naar de uiteindelijke controllers, dus volgens mij zit dat goed qua afhankelijkheden en resources.

Verder heb ik ook gebruik gemaakt van interfaces. Bijvoorbeeld, de klasse database verwacht een parameter (via de constructor) ConfigInterface, zodanig dat ik vrij ben wat soort config object ik nu eigenlijk meegeef. Zolang het maar de ConfigInterface implementeert. Hierdoor creëer ik volgens mij voldoende flexibiliteit.

Ik vraag me af of dit dus een nette manier is.

Wouter J

05-02-2013 22:59

ja, dat is het. :) (veel meer valt hier niet op te reageren naar mijn mening)

Write Down

05-02-2013 23:05

Ok, mooi.

En ik vermoed dan dat de volgende opzet ook degelijk is:

Ik heb een abstract klasse, die alle controllers (behalve de front controller) uitbreiden. In deze abstracte controller, heb ik ook weer een service container. Deze houdt momenteel een service bij om formulieren te verwerken en om template-functies uit te voeren.

Wouter J

05-02-2013 23:05

Nee, als het goed is heeft je hele applicatie toegang tot 1 en dezelfde service container waar dus alle services van de hele applicatie instaan. Dit geeft je de mogelijkheid het framework te kunnen aanpassen in de applicatie code.

Write Down

05-02-2013 23:13

Is het dan bv een goed idee om de service container, die dus in de front controller wordt gemaakt, door te geven? Met doorgeven bedoel ik dan, dat de abstracte controller deze krijgt. In de abstracte controller kan ik dan alsnog extra services aan de container toevoegen.

Wouter J

05-02-2013 23:45

Nee, services moet je op 1 plek toevoegen en dat is bij het opzetten van je applicatie. Dan stel je doormiddel van configuratie bestanden of ServiceProvider klassen in welke services er allemaal zijn, dit moet niet 'run time' gebeuren.

Met het eerste deel van je reactie (doorgeven van container) ben ik het wel eens. Totdat je van je controller services gaat maken, sommige devs houden daarvan, dan mag je alleen weer de services injecteren die je in de controller nodig hebt. Je moet je namelijk aan de regel houden: Als een klasse een service is mag het alleen andere services krijgen, niet de hele container. In elk ander geval moet de klasse juist de hele container (of niks) krijgen.

Write Down

06-02-2013 00:06

Ok, bedankt :-)

Jasper DS

06-02-2013 09:36

Dus alle mogelijke services zitten op voorhand in een config bestand? Tijdens het lopen van de applicatie kunnen er geen services worden toegevoegd? Dat lijkt met niet echt flexibel?

Wouter J

06-02-2013 09:38

Het hoeft ook helemaal niet flexibel te zijn. Als je services 'on run time' aanmaakt weet je nooit of je nu nou wel of niet toegang hebt tot die service, door alles in 1 keer te registeren, voordat de rest van de code wordt uitgevoerd, zorg je dat je altijd toegang hebt tot alle mogelijk services.

Waarom zou je je services willen aanpassen 'on run time'?

Jasper DS

06-02-2013 09:42

Oke dus voor je je app runt moet je alle mogelijk servises van alle mogelijke scenarios in een xml bestand of een ander config bestand hebben staan?

Wouter J

06-02-2013 09:43

Ja, of je gebruikt ServiceProviders klasses die de services instellen. Of je gebruikt ze allebei :)

Reageren

Inloggen om te reageren