DJPD februari: Dependency Injection
- Gast
-
Onderwerp Auteur
- Gebruiker
-
- Gast
-
- Gebruiker
-
29 dec 2014 19:02 #9049
door Gast
Beantwoord door Gast in topic DJPD februari: Dependency Injection
Of we halen wat pizza's of chinees of ander junkfood dat bij developers past 
- RolandD
-
- Gebruiker
-
29 dec 2014 19:02 #9050
door RolandD
Beantwoord door RolandD in topic DJPD februari: Dependency Injection
Wat langer doorgaan kan wel maar ik kan niet veel later blijven omdat ik nog een PLT vergadering heb die avond.
Er is altijd de Indo
Er is altijd de Indo
- Gast
-
- Gebruiker
-
- Gast
-
- Gebruiker
-
29 dec 2014 19:02 #9052
door Gast
Beantwoord door Gast in topic DJPD februari: Dependency Injection
Hi heren,
Ik geniet even van jullie goede stemming, nadat ik net tijdens het op de fiets boodschappen doen helemaal verhageld, versneeuwd en onder geplast ben door BMW-kerels. Nog een ronde-dame nodig?
Grapje, wat jullie gaan doen, reikt mij ver boven de pet.
Veel plezier!
groet,
Lianne
Ik geniet even van jullie goede stemming, nadat ik net tijdens het op de fiets boodschappen doen helemaal verhageld, versneeuwd en onder geplast ben door BMW-kerels. Nog een ronde-dame nodig?
Grapje, wat jullie gaan doen, reikt mij ver boven de pet.
Veel plezier!
groet,
Lianne
- Gast
-
- Gebruiker
-
- Jisse Reitsma
-
- Gebruiker
-
- Oprichter van Yireo, lead ontwikkelaar van diverse Joomla extensies, programmeur, trainer
- slibbe
-
- Gebruiker
-
29 dec 2014 19:02 #9055
door slibbe
Proud participant of jcycle.org
Beantwoord door slibbe in topic DJPD februari: Dependency Injection
Ik eet ook graag mee.
Wat is nu de management summary voor aanvangstijd en plaats?
Wat is nu de management summary voor aanvangstijd en plaats?
Proud participant of jcycle.org
- Gast
-
- Gebruiker
-
29 dec 2014 19:02 #9056
door Gast
Beantwoord door Gast in topic DJPD februari: Dependency Injection
Onveranderd aanvang 14.00 uur, adres: Gorsdijk 36, 3295 XG 's-Gravendeel, zie obix.nl
Na afloop van de middag dus gezamenlijk eten.
Niet de bedoeling om er iets ingewikkelds of abstracts van te maken, maar juist heel praktisch: hoe schrijf je betere code, zodanig dat na een verandering in de code alles blijft werken. 'Loose coupling', het voorkomen van spaghetti-code.
Bericht toegevoegd op 20 februari 2015 om 11:57
Vorige bericht was op 12 februari 2015 om 17:58
Samenvatting en links
Inversion of Control en Dependency Inversion
Als je in je programma van een bibliotheek met algemeen bruikbare stukken software gebruik maakt, dan is je programma afhankelijk van die algemene stukken software. Zodra er iets verandert in die software bibliotheek, dan worden alle programma's die daarvan afhankelijk zijn daardoor beïnvloed. Als je die afhankelijkheid omkeert, dan krijg je betere loosely coupled software.
Die Inversion of Control en Dependency Inversion kun je op verschillende manieren bereiken. Bijvoorbeeld met wat we in Joomla plugins noemen: een observer (of subscriber) pattern. In Drupal is dat het principe van de hooks, beetje vergelijkbaar met de events waar je plugins door laat triggeren in Joomla.
Het verschil tussen een software-bibliotheek en een framework is dat een bibliotheek algemeen bruikbare stukken software bevat, die je vanuit je programma aan kunt roepen, terwijl een framework, zoals de naam al zegt, een raamwerk biedt voor een applicatie en daar hang je je specifieke gedeeltes in.
Een andere manier om Dependency Inversion te krijgen is door middel van Dependency Injection.
Links:
Dependency Inversion is de D in SOLID.
SOLID
SOLID is een acronym voor 5 basisprincipes voor betere OO-software.
Praat alleen met je directe vrienden. Mijn voorbeeld: roep de hond, niet de afzonderlijke poten.
Dependency Injection
Als class A class B nodig heeft, injecteer class B dan in class A. Twee oplossingen die nu vaak gebruikt worden: maak van class B een global (al of niet in disguise) of instantieer class B in class A :$b = new B.
Boek: Modernizing Legacy Applications in PHP door Paul Jones. leanpub.com/mlaphp
Hoofdstuk 5: Replace global With Dependency Injection.
Hoofdstuk 6: Replace new With Dependency Injection.
3 soorten dependency injection:
Links:
Als je de parameter die je meegeeft abstract typeert, dus bijvoorbeeld een interface en niet een concrete implementatie, dan is de dependency niet van die bepaalde implementatie, maar van de interface.
Bijvoorbeeld: __construct(DatabaseInterface $db). Dan kun je iedere $db-implementatie injecteren die aan die DatabaseInterface voldoet.
Dependency Injection Container
Als je veel objecten moet aanmaken en daar ook steeds weer dezelfde objecten in moet injecteren, dan kun je dat automatiseren met een Dependency Injection Container (DIC), die je objecten laat bouwen. Symfony heeft een heel uitgebreide DIC, zie symfony.com/doc/current/components/depen...on/introduction.html , maar er zijn er veel. Een hele eenvoudige, uit dezelfde hoek, ook bruikbaar in een Joomla-applicatie, is Pimple pimple.sensiolabs.org/ . Maar: Joomla Framework heeft zelf ook een DIC, die eenvoudig met composer aan je project toe te voegen is: github.com/joomla-framework/di
Zoals je ziet op github.com/joomla-framework/di/tree/master/src is de eigenlijke container maar 1 file: Container.php. Daarnaast heb je een interface en implementatie van een setter-injection (ContainerAwareInterface.php en ContainerAwareTrait.php) en een interface voor een Service Provider.
Service Provider / Service Container / Service Locator
Soms moet je toch een object instantiëren binnen een ander object. In hoofdstuk 6 van Paul Jones z'n boek wordt dat d.m.v. Een factory gedaan. Een DIC is eigenlijk ook zo'n soort factory. Door een DIC te injecteren in een object, injecteer je dus een factory waarmee een object een ander object kan maken. Dit patroon heet een Service Locator.
Er schuilt echter een heel groot gevaar in: als je een DIC voor je hele applicatie hebt en die in een object injecteert, dan kan dat object dus ieder ander object aanmaken dat in je applicatie voorkomt. Dit soort misbruik van een service locator, dat veelvuldig gebeurt in bijvoorbeeld Symfony applicaties, is een anti-pattern. Zolang je echter de scope van je geinjecteerde Service Locator goed afbakent, kan het een heel nuttige toepassing zijn. In de DIC van Joomla zit een voorziening om heel specifieke service locators te maken. Dat is dus een pluspunt.
Hopelijk geeft dit wat nuance aan de discussies over service locator (anti-)pattern:
Als je de Joomla DIC in actie wil zien , dan kun je kijken naar de Jissues-implementatie. Daar is het Joomla Framework gebruikt om onze tracker te bouwen. De verschillende service provideers: github.com/joomla/jissues/tree/master/src/JTracker/Service en ze in de container plaatsen: github.com/joomla/jissues/blob/master/sr...Application.php#L105
New MVC
Het Joomla Framework heeft ook de nieuwe MVC in zich, dus niet meer de classes die in het CMS zitten. Bijvoorbeeld in het CMS zitten de model-classes die van Jobject afgeleid zijn: JmodelLegacy etc. github.com/joomla/joomla-cms/tree/stagin...braries/legacy/model . In het CMS zitten ook de nieuwe MVC-classes (maar dan zonder namespace zoals in het Joomla Framework), bijvoorbeeld voor het model: github.com/joomla/joomla-cms/tree/stagin...braries/joomla/model
In Jissues kun je ook zien hoe die nieuwe MVC-classes gebruikt kunnen worden om een applicatie te bouwen. Ook kun je daar voorbeelden zien van dependency injection. Bijvoorbeeld in deze implementatie van een model: github.com/joomla/jissues/blob/master/sr...atabaseModel.php#L64 , waar een database-connectie geïnjecteerd wordt in de constructor.
We hebben ook nog wat laten zien van implementaties van dat nieuwe MVC in het huidige CMS, zoals deze 9 lagen diep inherited serie models: github.com/wilsonge/joomla-cms/tree/gsoc14/libraries/cms/model
Als je kijkt naar de legacy MVC-classes, dan zie je dat daar nog veel aan verbeterd kan worden. Het was dan ook een goede zaak dat er in 2011 en 2012 vanuit eBay begonnen is met het opnieuw definiëren van veel eenvoudiger en beter los-gekoppelde classes. Dit kwam ook voort uit een beter native CCK, het Unified Content Model (UCM)
Bericht toegevoegd op 20 februari 2015 om 12:20
Vorige bericht was op 20 februari 2015 om 11:58
Ja. Andere keer weer. Ik geef dinsdag 17 maart nog een presentatie over Design Patterns (niet specifiek voor PHP) in Eindhoven: www.meetup.com/Eindhoven-Developers-Meetup/events/220477660/
[12:15:51] Herman Peeren: 2 stukken wat exotische muziek die gisteren na de maaltijd gedraaid werden: Shpongle - Live In Concert (At the Roundhouse London 2008) en Huun-Huur-To. Mountain voice (da loop trance mix)
Van die laatste merkte PJ op "die vond die kip kennelijk niet zo lekker".
Na afloop van de middag dus gezamenlijk eten.
Niet de bedoeling om er iets ingewikkelds of abstracts van te maken, maar juist heel praktisch: hoe schrijf je betere code, zodanig dat na een verandering in de code alles blijft werken. 'Loose coupling', het voorkomen van spaghetti-code.
Bericht toegevoegd op 20 februari 2015 om 11:57
Vorige bericht was op 12 februari 2015 om 17:58
Samenvatting en links
Inversion of Control en Dependency Inversion
Als je in je programma van een bibliotheek met algemeen bruikbare stukken software gebruik maakt, dan is je programma afhankelijk van die algemene stukken software. Zodra er iets verandert in die software bibliotheek, dan worden alle programma's die daarvan afhankelijk zijn daardoor beïnvloed. Als je die afhankelijkheid omkeert, dan krijg je betere loosely coupled software.
Die Inversion of Control en Dependency Inversion kun je op verschillende manieren bereiken. Bijvoorbeeld met wat we in Joomla plugins noemen: een observer (of subscriber) pattern. In Drupal is dat het principe van de hooks, beetje vergelijkbaar met de events waar je plugins door laat triggeren in Joomla.
Het verschil tussen een software-bibliotheek en een framework is dat een bibliotheek algemeen bruikbare stukken software bevat, die je vanuit je programma aan kunt roepen, terwijl een framework, zoals de naam al zegt, een raamwerk biedt voor een applicatie en daar hang je je specifieke gedeeltes in.
Een andere manier om Dependency Inversion te krijgen is door middel van Dependency Injection.
Links:
- en.wikipedia.org/wiki/Dependency_inversion_principle
- en.wikipedia.org/wiki/Inversion_of_control
- martinfowler.com/bliki/InversionOfControl.html
- www.oodesign.com/dependency-inversion-principle.html
- martinfowler.com/articles/dipInTheWild.html
Dependency Inversion is de D in SOLID.
SOLID
SOLID is een acronym voor 5 basisprincipes voor betere OO-software.
- S ingle Responsibility: een class zou maar 1 verantwoordelijkheid (is niet hetzelfde als 1 taak) moeten hebben. en.wikipedia.org/wiki/Single_responsibility_principle
- O pen-Closed: open voor uitbreiding, gesloten voor modificatie. en.wikipedia.org/wiki/Open/closed_principle
- L iskov Substitution: een typering van bijvoorbeeld een method-parameter moet je door ieder subtype kunnen vervangen. en.wikipedia.org/wiki/Liskov_substitution_principle
- I nterface segregation: een specifieke interface bakent de scope beter af dan een te algemene. en.wikipedia.org/wiki/Interface_segregation_principle
- D ependency inversion: meer flexibiliteit als je afhankelijk bent van abstracties, niet van implementaties. en.wikipedia.org/wiki/Dependency_inversion_principle
Praat alleen met je directe vrienden. Mijn voorbeeld: roep de hond, niet de afzonderlijke poten.
Dependency Injection
Als class A class B nodig heeft, injecteer class B dan in class A. Twee oplossingen die nu vaak gebruikt worden: maak van class B een global (al of niet in disguise) of instantieer class B in class A :$b = new B.
Boek: Modernizing Legacy Applications in PHP door Paul Jones. leanpub.com/mlaphp
Hoofdstuk 5: Replace global With Dependency Injection.
Hoofdstuk 6: Replace new With Dependency Injection.
3 soorten dependency injection:
- constructor injection: met parameters in de constructor
- setter injection: met een setter: kan dan nog later veranderd worden
- interface injection: met een andere interface dan met een set-methode.
Links:
- en.wikipedia.org/wiki/Dependency_injection
- martinfowler.com/articles/injection.html
- fabien.potencier.org/article/11/what-is-dependency-injection
Als je de parameter die je meegeeft abstract typeert, dus bijvoorbeeld een interface en niet een concrete implementatie, dan is de dependency niet van die bepaalde implementatie, maar van de interface.
Bijvoorbeeld: __construct(DatabaseInterface $db). Dan kun je iedere $db-implementatie injecteren die aan die DatabaseInterface voldoet.
Dependency Injection Container
Als je veel objecten moet aanmaken en daar ook steeds weer dezelfde objecten in moet injecteren, dan kun je dat automatiseren met een Dependency Injection Container (DIC), die je objecten laat bouwen. Symfony heeft een heel uitgebreide DIC, zie symfony.com/doc/current/components/depen...on/introduction.html , maar er zijn er veel. Een hele eenvoudige, uit dezelfde hoek, ook bruikbaar in een Joomla-applicatie, is Pimple pimple.sensiolabs.org/ . Maar: Joomla Framework heeft zelf ook een DIC, die eenvoudig met composer aan je project toe te voegen is: github.com/joomla-framework/di
Zoals je ziet op github.com/joomla-framework/di/tree/master/src is de eigenlijke container maar 1 file: Container.php. Daarnaast heb je een interface en implementatie van een setter-injection (ContainerAwareInterface.php en ContainerAwareTrait.php) en een interface voor een Service Provider.
Service Provider / Service Container / Service Locator
Soms moet je toch een object instantiëren binnen een ander object. In hoofdstuk 6 van Paul Jones z'n boek wordt dat d.m.v. Een factory gedaan. Een DIC is eigenlijk ook zo'n soort factory. Door een DIC te injecteren in een object, injecteer je dus een factory waarmee een object een ander object kan maken. Dit patroon heet een Service Locator.
Er schuilt echter een heel groot gevaar in: als je een DIC voor je hele applicatie hebt en die in een object injecteert, dan kan dat object dus ieder ander object aanmaken dat in je applicatie voorkomt. Dit soort misbruik van een service locator, dat veelvuldig gebeurt in bijvoorbeeld Symfony applicaties, is een anti-pattern. Zolang je echter de scope van je geinjecteerde Service Locator goed afbakent, kan het een heel nuttige toepassing zijn. In de DIC van Joomla zit een voorziening om heel specifieke service locators te maken. Dat is dus een pluspunt.
Hopelijk geeft dit wat nuance aan de discussies over service locator (anti-)pattern:
- blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/
- blog.gauffin.org/2012/09/service-locator...not-an-anti-pattern/
Als je de Joomla DIC in actie wil zien , dan kun je kijken naar de Jissues-implementatie. Daar is het Joomla Framework gebruikt om onze tracker te bouwen. De verschillende service provideers: github.com/joomla/jissues/tree/master/src/JTracker/Service en ze in de container plaatsen: github.com/joomla/jissues/blob/master/sr...Application.php#L105
New MVC
Het Joomla Framework heeft ook de nieuwe MVC in zich, dus niet meer de classes die in het CMS zitten. Bijvoorbeeld in het CMS zitten de model-classes die van Jobject afgeleid zijn: JmodelLegacy etc. github.com/joomla/joomla-cms/tree/stagin...braries/legacy/model . In het CMS zitten ook de nieuwe MVC-classes (maar dan zonder namespace zoals in het Joomla Framework), bijvoorbeeld voor het model: github.com/joomla/joomla-cms/tree/stagin...braries/joomla/model
In Jissues kun je ook zien hoe die nieuwe MVC-classes gebruikt kunnen worden om een applicatie te bouwen. Ook kun je daar voorbeelden zien van dependency injection. Bijvoorbeeld in deze implementatie van een model: github.com/joomla/jissues/blob/master/sr...atabaseModel.php#L64 , waar een database-connectie geïnjecteerd wordt in de constructor.
We hebben ook nog wat laten zien van implementaties van dat nieuwe MVC in het huidige CMS, zoals deze 9 lagen diep inherited serie models: github.com/wilsonge/joomla-cms/tree/gsoc14/libraries/cms/model
Als je kijkt naar de legacy MVC-classes, dan zie je dat daar nog veel aan verbeterd kan worden. Het was dan ook een goede zaak dat er in 2011 en 2012 vanuit eBay begonnen is met het opnieuw definiëren van veel eenvoudiger en beter los-gekoppelde classes. Dit kwam ook voort uit een beter native CCK, het Unified Content Model (UCM)
- Dec. 2011: voorstel voor UCM groups.google.com/forum/#!topic/joomla-dev-platform/sqdZ0B_WCiQ , github.com/eBaySF/joomla-platform/tree/c...aries/joomla/content en github.com/eBaySF/joomla-platform/blob/c.../database/object.php
- Maart 2012 nieuw MVC-classes, zie github.com/joomla/joomla-platform/pull/1120 en github.com/eBaySF/joomla-platform/tree/mvc/libraries/joomla
Bericht toegevoegd op 20 februari 2015 om 12:20
Vorige bericht was op 20 februari 2015 om 11:58
Ja. Andere keer weer. Ik geef dinsdag 17 maart nog een presentatie over Design Patterns (niet specifiek voor PHP) in Eindhoven: www.meetup.com/Eindhoven-Developers-Meetup/events/220477660/
[12:15:51] Herman Peeren: 2 stukken wat exotische muziek die gisteren na de maaltijd gedraaid werden: Shpongle - Live In Concert (At the Roundhouse London 2008) en Huun-Huur-To. Mountain voice (da loop trance mix)
Van die laatste merkte PJ op "die vond die kip kennelijk niet zo lekker".
- Gast
-
- Gebruiker
-