[disc] Refactoring to Functional Programming

[BtM909]

Leuk "gesprek": http://hadihariri.com/201...g-to-functionalwhy-class/

[PdeBie]

haha herkenbaar.
Ik doe vooralsnog ook alles alleen in classes.

Tot ik laatst de MVC tutorial ben begonnen uit een boek ASP.NET MVC 4. Daarin begonnen ze ook ineens over interfaces en dependency injection. I was like WTFuzzle?

Interfaces zie ik overigens het nut nog wel van in en zal ik nog wel gaan gebruiken, maar DI gaat mij vooralsnog even te ver qua kennis.

[ Voor 8% gewijzigd door PdeBie op 25-11-2013 14:22 ]

[Ryur]

pdebie schreef op maandag 25 november 2013 @ 14:21:
haha herkenbaar.
Ik doe vooralsnog ook alles alleen in classes.

Tot ik laatst de MVC tutorial ben begonnen uit een boek ASP.NET MVC 4. Daarin begonnen ze ook ineens over interfaces en dependency injection. I was like WTFuzzle?

Interfaces zie ik overigens het nut nog wel van in en zal ik nog wel gaan gebruiken, maar DI gaat mij vooralsnog even te ver qua kennis.

Hmm.. ik ben ook nog niet echt thuis in DI, maar moet het wel leren.
Ik zit nu in de LOB-apps wereld van WinRT, en daar gebruiken wij Prism voor (MVVM-framework van Microsoft zelf). En Prism werkt vooral met DI.

HMS schreef op maandag 25 november 2013 @ 14:24:
Grappig, ik wil niet meer zonder DI . Ik vind het heerlijk om te gebruiken. En het geeft een leuke indicator als je code te veel gaat doen: je constructor krijgt heel veel dependencies/geinjecteerde objecten.

Wordt DI eigenlijk gegeven op de Informatica opleidingen?
Op mijn opleiding (Informatica aan Saxion Enschede) komt het volgens mij alleen langs bij 1 specialisatie icm Spring.

[ Voor 26% gewijzigd door Ryur op 25-11-2013 14:26 ]

[HMS]

Grappig, ik wil niet meer zonder DI . Ik vind het heerlijk om te gebruiken. En het geeft een leuke indicator als je code te veel gaat doen: je constructor krijgt heel veel dependencies/geinjecteerde objecten.

[PdeBie]

Nee, inderdaad. Dat is het hem bij mij ook. Ben er nog niet in thuis. Ben nu bezig met dat boek MCV 4 en daarin leren ze je het echt te gebruiken.

Dus vooralsnog is het een groot zwart gat waar ik in zit te staren. Zie nog niet wat de voordelen ervan zijn en wanneer je het wel/niet moet toepassen.

Wie weet zie ik het licht ooit nog wel eens

[ Voor 14% gewijzigd door PdeBie op 25-11-2013 14:30 ]

[Alex)]

DI klinkt moeilijk maar valt in de praktijk best wel mee. Wat van belang is is dat je een mogelijkheid hebt om een bepaalde dependency (zoals een repository) uit te wisselen voor een andere, zonder dat dit de code in je class raakt. Dit kun je doen door in je constructor de mogelijkheid te geven om een instance van een object mee te geven, of door een DI-container te gebruiken om je dependency te resolven.

Voorbeeldje:

C#:

public class MyHaxController : Controller
{
    ICustomerRepository customers = DiContainer.Resolve<ICustomerRepository>();

    [HttpGet]
    public ActionResult Index()
    {
        return View(customers.GetAll());
    }
}

De implementatie van GetAll kan dan afhankelijk zijn van de gekozen repository: een TestCustomerRepository zal een statische lijst retourneren, een ProductionCustomerRepository zal queries uitvoeren op een database. De genoemde DiContainer kan dan weer a.d.h.v. configuratie bepalen welke ICustomerRepository moet worden geladen.

[PdeBie]

Naja, daar gaat het bij mij dus al mis. Die termen als Repository etc. zijn nu nog abracadabra voor mij. Kom ze wel tegen in het boek, maar de echte know-how mis ik er nog van.

Komt mede ook doordat ik hier de enige ontwikkelaar binnen het bedrijf ben, waardoor ik niet echt iemand heb om mee te sparren en kennis uit te wisselen. Moet een heleboel op eigen houtje leren. Best lastig soms.

[cenix]

@pdebie: en daarom ben je hier

[kenneth]

pdebie schreef op maandag 25 november 2013 @ 14:29:
Wie weet zie ik het licht ooit nog wel eens

Dit boek deed mij het licht zien

Alex) schreef op maandag 25 november 2013 @ 14:30:

Voorbeeldje:

Dat is een DI Container misbruiken als Service Locator, geen Dependency Injection.

C#:

public class MyHaxController : Controller
{
    private readonly ICustomerRepository customers;
    
    public MyHaxController(ICustomerRepository customers)
    {
        this.customers = customers;
    }

    [HttpGet]
    public ActionResult Index()
    {
        return View(customers.GetAll());
    }
}

Sowieso probeer je met DI loose coupling voor elkaar te krijgen, dat bereik je zeker niet met een hardcoded verwijzing naar je DI container

[Alex)]

Dat is waar. Maar aan de andere kant, hoe vaak wissel je van DI container?

[Verwijderd]

BtM909 schreef op maandag 25 november 2013 @ 14:14:
Leuk "gesprek": http://hadihariri.com/201...g-to-functionalwhy-class/

Erg leuke post!

[HMS]

Repositories gebruik ik zelden meer, heb er welgeteld 1 van in mijn applicatie. De rest doe ik via Query en Command objecten d.m.v. een Mediator. Zo kan je bijvoorbeeld met het decorator pattern zaken als caching toevoegen, zonder dat je daar je classes van afhankelijk maakt.

Alex) schreef op maandag 25 november 2013 @ 14:35:
Dat is waar. Maar aan de andere kant, hoe vaak wissel je van DI container?

Zijn wel meer punten die je moet overwegen: http://blog.ploeh.dk/2010...eLocatorisanAnti-Pattern/
Maar in bepaalde gevallen is een Service Locator gewoon het makkelijkst.

[Korben]

Alex) schreef op maandag 25 november 2013 @ 14:35:
Dat is waar. Maar aan de andere kant, hoe vaak wissel je van DI container?

Het gaat niet alleen om het wisselen; als je vanuit je code niet verwijst naar je DI-container maar constructor injection of (als het echt niet anders kan) property injection doet, is je code sowieso veel flexibeler. Je hoeft namelijk dan geen volledige DI-container te gebruiken, bijvoorbeeld in een unit test.

[Alex)]

Korben schreef op maandag 25 november 2013 @ 14:38:
[...]

Het gaat niet alleen om het wisselen; als je vanuit je code niet verwijst naar je DI-container maar constructor injection of (als het echt niet anders kan) property injection doet, is je code sowieso veel flexibeler. Je hoeft namelijk dan geen volledige DI-container te gebruiken, bijvoorbeeld in een unit test.

Klopt, goed punt.

Mijn code was meer bedoeld om een idee te geven van hoe het werkt, niet hoe je het daadwerkelijk implementeert.

[PdeBie]

cenix schreef op maandag 25 november 2013 @ 14:33:
@pdebie: en daarom ben je hier

haha juist

[.Gertjan.]

kenneth schreef op maandag 25 november 2013 @ 14:33:
[...]

Dit boek deed mij het licht zien

[...]
Dat is een DI Container misbruiken als Service Locator, geen Dependency Injection.

C#:

public class MyHaxController : Controller
{
    private readonly ICustomerRepository customers;
    
    public MyHaxController(ICustomerRepository customers)
    {
        this.customers = customers;
    }

    [HttpGet]
    public ActionResult Index()
    {
        return View(customers.GetAll());
    }
}

Sowieso probeer je met DI loose coupling voor elkaar te krijgen, dat bereik je zeker niet met een hardcoded verwijzing naar je DI container

Dat is ook de manier waarop ik ook DI ken. Dat geklooi met die containers maakt het voor een beginner absoluut onleesbaar en onbegrijpelijk. Dat is iets wat mij bij veel boeken en tutorials tegenstond. Ze leggen vaak het principe niet echt uit maar mikken meteen DI containers en resolvers erin (het liefst ook nog 3rd party). Ik mis dat sowieso bij veel tutorials, ze gooien een oplossing naar binnen maar leggen vaak de basis niet uit en onderbouwen vaak de keus voor de oplossing ook niet echt (zodat je niet weet waarom er voor X is gekozen).

[EddoH]

Ik wist niet eens dat er een officiële term 'DI' voor bestond. Dit is toch gewoon 1 van de basisprincipes uit OO programmeren? Waar dienen interfaces anders voor?

[Ryur]

EddoH schreef op maandag 25 november 2013 @ 15:08:
Ik wist niet eens dat er een officiële term 'DI' voor bestond. Dit is toch gewoon 1 van de basisprincipes uit OO programmeren? Waar dienen interfaces anders voor?

Nou ik zou het zeker geen basisprincipes noemen, want het wordt niet bij les 1 OO gegeven .
Maar nu ik er iets langer ingedoken ben vind ik het wel een van de belangrijkste steunpunten van OO.

[kenneth]

.Gertjan. schreef op maandag 25 november 2013 @ 15:06:
[...]


Dat is ook de manier waarop ik ook DI ken. Dat geklooi met die containers maakt het voor een beginner absoluut onleesbaar en onbegrijpelijk. Dat is iets wat mij bij veel boeken en tutorials tegenstond. Ze leggen vaak het principe niet echt uit maar mikken meteen DI containers en resolvers erin (het liefst ook nog 3rd party). Ik mis dat sowieso bij veel tutorials, ze gooien een oplossing naar binnen maar leggen vaak de basis niet uit en onderbouwen vaak de keus voor de oplossing ook niet echt (zodat je niet weet waarom er voor X is gekozen).

Herken me helemaal in je kritiek. "Druk op dit en dat knopje en nu heb je een RAID-array gebouwd, gefeliciteerd!!" en dan nog niet fatsoenlijk uitgelegd gekregen wat RAID is, wat de afwegingen zijn die je moet maken, wanneer je überhaupt RAID moet overwegen, enzovoort. Alleen de trucjes, niet de ideeën.

Dat boek van Seemann dat ik aanhaalde is een prettige uitzondering, pas in het laatste deel gaat hij diep in op een paar containers, in de eerste drie delen gaat het om de concepten, toepasbaarheid en patterns. Dat een DI container het leven soms(!) eenvoudiger maakt, is leuk maar secundair.

[Caelorum]

EddoH schreef op maandag 25 november 2013 @ 15:08:
Ik wist niet eens dat er een officiële term 'DI' voor bestond. Dit is toch gewoon 1 van de basisprincipes uit OO programmeren? Waar dienen interfaces anders voor?

DI is wel iets meer dan alleen maar tegen interfaces aan programmeren.

[steffex]

En interfaces is wel voor meer dingen dan alleen voor DI

[EddoH]

Hmm. dan zal ik wel iets missen. In mijn hoofd is het logisch dat je bij gebruik van interfaces deze via de constructor (of eventueel met een setter, of globale provider) aan classes doorgeeft zodat ze de implementatie niet hoeven te kennen, en je de implementatie ook niet in de class zelf instantieert.

[.Gertjan.]

Caelorum schreef op maandag 25 november 2013 @ 15:13:
[...]

DI is wel iets meer dan alleen maar tegen interfaces aan programmeren.

Klopt DI gaat puur over de manier waarop je werkt met je dependencies. Het is altijd goed om tegen een interface aan te bouwen (hoewel je soms kunt over-interfacen), maar nog moet de implementor/instance ergens aangemaakt worden. Vaak gebeurt dat in de laag/class die hem gebruikt, maar met DI leg je die verantwoordelijkheid elders (volgens mij komt InversionOfControl hier ook bij kijken).

Als je een BLL laag bouwt is men snel geneigd om binnen die BLL aan te geven hoe de DAL gemaakt moet worden en worden de DAL implementaties daar dus ook aangemaakt, terwijl daar eigenlijk niet de verantwoordelijkheid hoort te leggen.

Als je op een andere plek de DAL maakt en deze vervolgens in de BLL injecteert is de BLL los te gebruiken zonder een harde afhankelijkheid van de DAL. Je zou dan je eigen DAL kunnen bouwen en deze dan inserten. Dit zorgt vaak voor een hogere testbaarheid van code en een lagere coupling van je lagen.

[BikkelZ]

Ik wou net zeggen, ik maakte al veel gebruik van Interfaces voordat ik met DI en IoC ging werken.

Bij basic basic OO kom je dingen tegen als het toepassen van de IComparable interface.

--------

Bij mijn thuisprojectje overgestapt op feature branches in git. Het helpt wel bij de focus om tegen jezelf te zeggen "ik werk nu in branch x en ik implementeer alleen feature x", ook al werk ik altijd in mijn eentje.

[EddoH]

Caelorum schreef op maandag 25 november 2013 @ 15:13:
[...]

DI is wel iets meer dan alleen maar tegen interfaces aan programmeren.

Met de nadruk op 'iets' dan, want óf ik ben retarded en snap het echt niet, óf het betekent echt alleen maar het doorgeven van instance variables (interfaces) aan een class door een ander component.

Ik ben nog op zoek naar het ongrijpbare en magische wat aan de term DI lijkt te hangen.

edit: ah! volgens mij ben ik niet de enige: http://www.jamesshore.com...njection-Demystified.html

[ Voor 11% gewijzigd door EddoH op 25-11-2013 15:40 ]

[Korben]

EddoH schreef op maandag 25 november 2013 @ 15:34:
[...]


Met de nadruk op 'iets' dan, want óf ik ben retarded en snap het echt niet, óf het betekent echt alleen maar het doorgeven van instance variables (interfaces) aan een class door een ander component.

Ik ben nog op zoek naar het ongrijpbare en magische wat aan de term DI lijkt te hangen.

Maar wélke instances? DI is niet zo interessant, behalve wanneer je het combineert met een IoC container. Het voornaamste wat de IoC-container doet is de vraag 'welke instance' beantwoorden, en dat dat gecombineerd wordt met DI is bijna een bonus.

[BikkelZ]

EddoH schreef op maandag 25 november 2013 @ 15:34:
[...]


Met de nadruk op 'iets' dan, want óf ik ben retarded en snap het echt niet, óf het betekent echt alleen maar het doorgeven van instance variables (interfaces) aan een class door een ander component.

Ik ben nog op zoek naar het ongrijpbare en magische wat aan de term DI lijkt te hangen.

Het gaat met name om de testbaarheid. Je wil bijvoorbeeld kunnen testen zonder een browsersessie te hebben of een database om alleen het component te testen.

Dit is een traditionele contstructor:

C#:

public User()
{
// Get some stuff from HttpRequest
// Go to database
// Make user
}

Om deze code te testen moet je een database en een request hebben, kortom de hele boel opstarten en dan debuggen in je browser.

Dit doet IoC:

C#:

public User(IHttpRequest request, IDataBase database)
{
// Get some stuff from IHttpRequest
// Go to database via IDatabase
// Make user
}

In je echte code roep je ze gewoon met de zelfde instance van HttpRequest en DataBase aan die je ook binnen de eerste constructor gebruikte. Echter in je tests geef je een gemockte HttpRequest op basis van IHttpRequest mee die een door jou vastgestelde waarde terug geeft. Zelfde geldt voor DataBase.

Nu test je alleen deze component en niet of je ORM en je browser sessie werkt.

Ander voordeel: je kunt het gedrag van je klasse veranderen alleen door hem met een andere implementatie van de interface die je in je constructor gedefinieerd hebt aan te roepen.

Je keert je klasse als het ware binnenste buiten waarbij heel veel functionaliteit uitgevoerd wordt door andere klasses die makkelijk inwisselbaar zijn.

En probeer je nu weer in te beelden dat die User IUser implementeert dus alle klasses die een User nodig hebben weer niet afhankelijk zijn van waar User weer van afhankelijk was.


Ik heb de laatste tijd meerdere malen meegemaakt dat ik implementaties heb gedaan in eerste instantie via Unit Tests me IoC en DI en dat ik het na twee dagen een keer voor het eerst in de browser opstartte en het gewoon meteen werkte.

----------------

Ik realiseer me dat ik DI en IoC weer eens een keer door elkaar gehaald heb....komt omdat ik ze precies op het zelfde moment geleerd heb en altijd tegelijk gebruik


Het voordeel van DI is dat je dus niet meer een hele rits aan interfaces aan een class meegeeft maar gewoon één keer het object registreert en het automagisch op alle plekken terecht komt waar je het nodig hebt.

Dit zou dus DI zijn:

C#:

public User()
{
// Get some stuff from the registered IHttpRequest component
// Go to database via the registered IDatabase component
// Make user
}

Het voordeel is dat je niet meer overal Interfaces loopt rond te pompen in constructors maar gewoon een instance pakt als je hem nodig hebt en op dat moment ziet welke implementatie er geregistreerd is.

[ Voor 25% gewijzigd door BikkelZ op 25-11-2013 15:57 ]

[IceM]

BikkelZ schreef op maandag 25 november 2013 @ 15:48:
Ik realiseer me dat ik DI en IoC weer eens een keer door elkaar gehaald heb....komt omdat ik ze precies op het zelfde moment geleerd heb en altijd tegelijk gebruikt

:

As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.

Bron: http://martinfowler.com/articles/injection.html (wat verder ook een prima artikel is voor IoC/DI uitleg)

[ Voor 3% gewijzigd door IceM op 25-11-2013 15:55 ]

[EddoH]

Ok, dan is het dus precies wat ik al bedoelde, maar ik heb de termen er nooit aan gehangen. Bedankt voor de uitleg.

[ Voor 11% gewijzigd door EddoH op 25-11-2013 15:59 ]

[kenneth]

BikkelZ schreef op maandag 25 november 2013 @ 15:48:

Dit zou dus DI zijn:

C#:

public User()
{
// Get some stuff from the registered IHttpRequest component
// Go to database via the registered IDatabase component
// Make user
}

Nee, je injecteert helemaal niets hier. Je voorbeeld met public User(IHttpRequest request, IDataBase database) is juist wel DI.
Met een DI container kan je er inderdaad voor zorgen dat het instantiëren met de juiste lifetime/dependencies/interceptors veel makkelijker gebeurt maar je zal alsnog je dependencies expliciet moeten maken. En dan is ctor injection het gebruikelijkst.

Het voordeel is dat je niet meer overal Interfaces loopt rond te pompen in constructors maar gewoon een instance pakt als je hem nodig hebt en op dat moment ziet welke implementatie er geregistreerd is.

Interfaces rondpompen is juist een voordeel: het is gelijk duidelijk welke dependencies een class nodig heeft om te kunnen werken, je kan de class niet instantiëren zonder aan de dependencies te voldoen en op het moment dat je in je ctor een verwijzing naar vijf of meer interfaces hebt moet er een heel grote SRP-bel gaan rinkelen.

[Firesphere]

Het grote voordeel van DI en interfaces rondpompen heeft ook een zwakke kant. Namelijk voor elke scheet gaan afsplitsen, interfacen etc.

[kenneth]

Afsplitsen is het gevolg van je houden aan het SRP en maakt de toekomstige maintainer hopelijk erg blij, voor het maken van interfaces heb je R# of zelfs de ingebouwde refactor-features van VS.

Ik zie het zelf niet als zwakke kanten maar investeren in onderhoudbare code.

[HMS]

Je moet natuurlijk wel in je project een bepaalde structuur afdwingen hoe je je applicatie verdeeld (in folders / projects / solutions / whatever). Anders wordt de volgende maintainer ook helemaal gek omdat alles all over the place staat. Je krijgt met bepaalde patterns namelijk wel een explosie van classes en interfaces.

[BikkelZ]

kenneth schreef op maandag 25 november 2013 @ 16:07:

Interfaces rondpompen is juist een voordeel: het is gelijk duidelijk welke dependencies een class nodig heeft om te kunnen werken, je kan de class niet instantiëren zonder aan de dependencies te voldoen en op het moment dat je in je ctor een verwijzing naar vijf of meer interfaces hebt moet er een heel grote SRP-bel gaan rinkelen.

Persoonlijk ben ik ook niet zo'n fan van classes die ineens ergens automagisch vandaan komen maar het ging even niet om mijn persoonlijke mening. Denk dat ik er wel ongeveer het zelfde over denk als jij.

[Hydra]

pdebie schreef op maandag 25 november 2013 @ 14:32:
Naja, daar gaat het bij mij dus al mis. Die termen als Repository etc. zijn nu nog abracadabra voor mij. Kom ze wel tegen in het boek, maar de echte know-how mis ik er nog van.

Komt mede ook doordat ik hier de enige ontwikkelaar binnen het bedrijf ben, waardoor ik niet echt iemand heb om mee te sparren en kennis uit te wisselen. Moet een heleboel op eigen houtje leren. Best lastig soms.

Misschien een idee een ander bedrijf te zoeken? M.i. is niks belangrijker voor je eigen ontwikkeling dan het hebben van peers waaraan je je op kunt trekken.

BikkelZ schreef op maandag 25 november 2013 @ 17:07:
Persoonlijk ben ik ook niet zo'n fan van classes die ineens ergens automagisch vandaan komen maar het ging even niet om mijn persoonlijke mening. Denk dat ik er wel ongeveer het zelfde over denk als jij.

Er is niks "magisch" aan waar die instances vandaan komen. Dat wordt of door jou vastgelegd, of door het DI framework geresolved aan de hand van logische regels.

DI heeft gewoon voordelen waar je vooral profijt van hebt als je het testen goed aanpakt. Helaas gebeurt dat in de echte wereld meestal te slecht omdat het "te veel tijd kost".

[ Voor 33% gewijzigd door Hydra op 25-11-2013 17:22 ]

[Herko_ter_Horst]

Dependency Injection in een IoC container kan wel heel wat meer zijn dan de gegeven voorbeelden. Dependencies meegeven in een constructor (constructor injection) is slechts één van de manieren (en wel de meest eenvoudige, want statisch en gegarandeerd vanaf het begin beschikbaar) van DI.

Van buitenaf dependencies laten zetten via een methode (setter injection) is al een flink stuk dynamischer (want je weet van tevoren niet óf en zo ja, wanneer die setter aangeroepen gaat worden) en dus complexer. Nog dynamischer (en complexer) wordt het, als dependencies tijdens de levensduur van een object ook weer kunnen verdwijnen, of wijzigen.

Met DI kan je zaken voor elkaar krijgen die je op een "traditionele" manier bijna niet voor elkaar krijgt. Bijvoorbeeld in een hoog-dynamisch systeem op basis van gebruikersconfiguratie services aan elkaar knopen (zonder een compile/deploy-slag).

Interfaces hebben inderdaad niet zoveel met DI van doen. Interfaces zijn in algemeen in OO-land belangrijk voor het specificeren een contract (API) waarvoor meerdere implementaties (kunnen) zijn. Interfaces helpen derhalve bij encapsulation en separation of concerns, twee belangrijke OO-principes. Hoe complexer je code, hoe belangrijker dergelijke principes worden. Niet geheel toevallig is dat ook waarom ze voor DI zo belangrijk zijn. Want ja: DI is zeer krachtig, maar het kan ook zeer complex zijn.

[ Voor 23% gewijzigd door Herko_ter_Horst op 25-11-2013 18:44 ]