Fluent programming

[Chris_147]

Hey,

op verscheidene projecten ben ik nu Fluent programming tegengekomen.
Dit maakt de top level code meer leesbaar, gemakkelijker te schrijven met de hulp van de AutoComplete van de IDE, maar ik heb problemen om van scratch dit juist te implementeren.
Is er ergens een goede uitleg hoe je dit moet doen?
Liefst eigenlijk programmeertaal onafhankelijk, anders in Scala, Java en/of C#.

/Rant:
Ik heb het gevoel dat men, om de top level code wat meer leesbaar te maken, men de implementatie daarvan veel ingewikkelder en uitgebreider maakt.
Ik heb nu een project waar men met Scala en Serenity-BDD een fluent implementatie gebruikt voor de leesbaarheid.
Echter vind ik het wat dubbelop:
- feature files zijn reeds goed leesbaar
- maar nu wil men de step definitions ook goed leesbaar maken. Maar voor wie? PO of gebruikers gaan die niet bekijken.
Dus als het enige oordeel beter leesbare code is, dan ben ik niet overtuigd van het nut van fluent programming. Want ondertussen vind ik het wel zeker moeilijker te debuggen, de implementatie wordt uitgebreider en de compiler vind minder problemen, het moet ook runtime gecontroleerd worden.

Maar ik geef direct toe dat ik er te weinig van ken om zeker te zijn van deze kritiek. Dus ik vroeg me af of dit door mijn tekort aan kennis komt, of dat anderen deze problemen ook ondervinden.

[Sandor_Clegane]

Chris_147 schreef op vrijdag 18 oktober 2019 @ 12:40:
Hey,

op verscheidene projecten ben ik nu Fluent programming tegengekomen.
Dit maakt de top level code meer leesbaar, gemakkelijker te schrijven met de hulp van de AutoComplete van de IDE, maar ik heb problemen om van scratch dit juist te implementeren.
Is er ergens een goede uitleg hoe je dit moet doen?
Liefst eigenlijk programmeertaal onafhankelijk, anders in Scala, Java en/of C#.

/Rant:
Ik heb het gevoel dat men, om de top level code wat meer leesbaar te maken, men de implementatie daarvan veel ingewikkelder en uitgebreider maakt.
Ik heb nu een project waar men met Scala en Serenity-BDD een fluent implementatie gebruikt voor de leesbaarheid.
Echter vind ik het wat dubbelop:
- feature files zijn reeds goed leesbaar
- maar nu wil men de step definitions ook goed leesbaar maken. Maar voor wie? PO of gebruikers gaan die niet bekijken.
Dus als het enige oordeel beter leesbare code is, dan ben ik niet overtuigd van het nut van fluent programming. Want ondertussen vind ik het wel zeker moeilijker te debuggen, de implementatie wordt uitgebreider en de compiler vind minder problemen, het moet ook runtime gecontroleerd worden.

Maar ik geef direct toe dat ik er te weinig van ken om zeker te zijn van deze kritiek. Dus ik vroeg me af of dit door mijn tekort aan kennis komt, of dat anderen deze problemen ook ondervinden.

Is dat dat object.Methode().Methode().Methode()?

Je geeft na elke methode aanroep gewoon this terug en dan kun je volgende methode op het object weer aanroepen.

Naar mijn idee is het overrated. Maar ja, dat ben ik.

[BertS]

Ik vind het wel voordelen hebben, maar lang niet overal. Vooral in configuraties vind ik het zelf wel lekker werken.
ObjectBuilders bijvoorbeeld, gebruik ik zelf veel in UnitTests om niet in mijn test allerlei properties te zetten maar een leesbare weergave te hebben van wat ik als uitgangspunt nodig heb. Dan krijg je zoiets:

C:

var order = new PurchaseorderBuilder().WithStockProduct()
                                      .WithDeliveryAddress()
                                      .WithoutBatch()
                                      .Build();

Voor uitleg kun je zoeken op Builder-pattern, dan vind je het wel.

Fluent is wel breder dan dit, maar dit vind ik persoonlijk een erg krachtige toepassing.
In essentie is het zoals @Sandor_Clegane zegt: elke method geeft 'this' terug.

[ Voor 17% gewijzigd door BertS op 18-10-2019 13:50 ]

[Chris_147]

Het framework dat ik nu gebruik, Serenity-BDD, doet bvb hetvolgende:

Java: filename

    @Test
    public void items_left_counter_should_be_decremented_when_an_item_is_completed() {

        givenThat(james).wasAbleTo(OpenTheApplication.onTheHomePage());
        andThat(james).wasAbleTo(AddTodoItems.called("Walk the dog", "Put out the garbage"));

        when(james).attemptsTo(
                Complete.itemCalled("Walk the dog")
        );

        then(james).should(seeThat(TheRemainingItemCount.value(), is(1)));
    }
    // end::items_left_counter_should_be_decremented_when_an_item_is_completed

    @Test
    public void completed_items_should_not_appear_in_the_active_list() {

        givenThat(james).wasAbleTo(OpenTheApplication.onTheHomePage());
        andThat(james).wasAbleTo(AddTodoItems.called("Walk the dog", "Put out the garbage"));

        when(james).attemptsTo(
                Complete.itemCalled("Walk the dog"),
                FilterItems.byStatus(Active)
        );

        then(james).should(seeThat(theDisplayedItems, not(contains("Walk the dog"))));
    }

Dat is goed leesbaar.
Maar zij gebruiken ook het ScreenPlay pattern, waar je Question (wat kan ik bvb zien op de website: welke user ben ik, welke waarde heeft een veld, ...) en Tasks (wat kan ik doen op de website, bvb: nieuwe gebruiker maken, nieuwe post maken, ...).
Dat volgend (en het Single Responsibility Principle) betekent dat ik voor CRUD operaties meerdere taken ga hebben. Create, Update, Delete.
Nu zijn Create en Update grotendeels hetzelfde. Bij Create klik ik echter eerst op de create new knop en vul ik de velden in. Bij Update zoek ik eerst de juiste, klik ik op de opdate knop en pas ik dezelfde velden aan.
In het gewone programmeren kan ik dit perfect maken, zeer eenvoudig.
In Fluent programmeren weet ik dit echter niet.

[BertS]

En waarom zou je het bij CRUD-operaties willen toepassen?

[Hydra]

Chris_147 schreef op vrijdag 18 oktober 2019 @ 12:40:

Ik heb het gevoel dat men, om de top level code wat meer leesbaar te maken, men de implementatie daarvan veel ingewikkelder en uitgebreider maakt.

Alles is 'ingewikkeld' als je het niet begrijpt. Er is niks ingewikkeld aan builder patterns en fluent API's zijn daar eigenlijk een afgeleide van. Kwestie van je design patterns kennen.

De achtergrond van fluent API's kun je hier vinden. Over het builder pattern in Java kun je honderden pages vinden op Google.

Dus als het enige oordeel beter leesbare code is, dan ben ik niet overtuigd van het nut van fluent programming. Want ondertussen vind ik het wel zeker moeilijker te debuggen, de implementatie wordt uitgebreider en de compiler vind minder problemen, het moet ook runtime gecontroleerd worden.

Euh, nee? Dit slaat echt helemaal nergens op.

[Chris_147]

Martin Fowler's blog post heb ik natuurlijk gelezen alsook tientallen anderen.
Ook verscheidene met, volgend mij, valide kritiek op Fluent, zoals deze: https://www.yegor256.com/...rfaces.html#disqus_thread

Zoals ik zei ben ik de eerste om toe te geven dat ik er niet genoeg van ken.
Maar we hebben net met 2 wat code geschreven en ik vind toch dat er heel dat classes geschreven worden en boilerplate code om ocharme via Selenium een pagina met 5 elementen te schrijven. En dit om dan write en update netjes te scheiden.

[armageddon_2k1]

Ligt dat aan fluent of aan Selenium? De vraag is of het zonder een fluent interface minder ogenschijnlijk complex zou zijn.

[Sandor_Clegane]

Hydra schreef op vrijdag 18 oktober 2019 @ 16:51:
[...]


Alles is 'ingewikkeld' als je het niet begrijpt. Er is niks ingewikkeld aan builder patterns en fluent API's zijn daar eigenlijk een afgeleide van. Kwestie van je design patterns kennen.

Niks is ingewikkeld als je het snapt.

[Hopscotch]

“If you can't explain it simply, you don't understand it well enough.” - Albert Einstein

In de context die jij schetst zie ik er vooral waarde in dat je eigenlijk gedwongen wordt je testen op gedrag te schrijven en niet op technische implementatie. Heb je ook een voorbeeld van een achterliggende implementatie die ingewikkelder is geworden omdat je dit wilt toepassen?

[Hydra]

Chris_147 schreef op vrijdag 18 oktober 2019 @ 17:19:
Martin Fowler's blog post heb ik natuurlijk gelezen alsook tientallen anderen.
Ook verscheidene met, volgend mij, valide kritiek op Fluent, zoals deze: https://www.yegor256.com/...rfaces.html#disqus_thread

Yegor is een complete idioot die redelijk uitgekakt is in de Java community. Diezelfde kerel vindt dat vrouwen niet kunnen programmeren bijvoorbeeld.

Zoals ik zei ben ik de eerste om toe te geven dat ik er niet genoeg van ken.
Maar we hebben net met 2 wat code geschreven en ik vind toch dat er heel dat classes geschreven worden en boilerplate code om ocharme via Selenium een pagina met 5 elementen te schrijven. En dit om dan write en update netjes te scheiden.

Dat heeft niks met Fluent API's te maken maar gewoon dat jullie dat systeem aan het overengineering zijn.

[ Voor 31% gewijzigd door Hydra op 19-10-2019 11:37 ]

[mulder]

Chris_147 schreef op vrijdag 18 oktober 2019 @ 12:40:
[...]
Dus als het enige oordeel beter leesbare code is, dan ben ik niet overtuigd van het nut van fluent programming. [...]

Voor wie of wat schrijven we code?

[R4gnax]

armageddon_2k1 schreef op vrijdag 18 oktober 2019 @ 17:37:
Ligt dat aan fluent of aan Selenium? De vraag is of het zonder een fluent interface minder ogenschijnlijk complex zou zijn.

"When in doubt: blame Selenium."

Iets als Cypress bewijst trouwens dat browser UI integration tests met een fluent API niet moeilijk hoeven zijn om te schrijven.

De crux is dat er vanuit het framework zelf al in de vorm van 'pipelines' aan opeenvolgende asynchrone callbacks - zeg bijv. promises - gedacht wordt.

Dat is met Cypress bijv. wel het geval. Alle in-built operaties zijn in feite abstracties bovenop een asynchrone queue die stap voor stap geleegd wordt, en de "then" functie die een open user-specified callback neemt is haast letterlijk de then van een promise.