Delen via

Functioneel programmeren versus imperatieve programmering (LINQ naar XML)

Dit artikel vergelijkt en contrasteert functionele programmering met traditionelere imperatieve (procedurele) programmering.

Functioneel programmeren versus imperatief programmeren

Het functionele programmeerparadigma is expliciet gemaakt ter ondersteuning van een pure functionele benadering van het oplossen van problemen. Functioneel programmeren is een vorm van declaratieve programmering. Daarentegen zijn de meeste reguliere talen, waaronder OOP-talen (objectgeoriënteerd programmeren), zoals C#, Visual Basic, C++en Java, ontworpen om voornamelijk imperatieve (procedurele) programmering te ondersteunen.

Met een imperatieve benadering schrijft een ontwikkelaar code die de stappen aangeeft die de computer moet uitvoeren om het doel te bereiken. Dit wordt ook wel algoritmeprogrammering genoemd. Een functionele benadering omvat daarentegen het opstellen van het probleem als een set functies die moeten worden uitgevoerd. U definieert zorgvuldig de invoer voor elke functie en wat elke functie retourneert. In de volgende tabel worden enkele algemene verschillen tussen deze twee benaderingen beschreven.

Karakteristiek Imperatieve benadering Functionele benadering
Focus programmeur Taken (algoritmen) uitvoeren en wijzigingen in status bijhouden. Welke informatie gewenst is en welke transformaties vereist zijn.
Status wijzigen Belangrijk. Niet aanwezig.
Uitvoeringsvolgorde Belangrijk. Lage urgentie.
Primaire stroombesturing Lussen, voorwaarden en functie-aanroepen (methode). Functie-aanroepen, waaronder recursie.
Primaire manipulatie-eenheid Exemplaren van structuren of klassen. Functies als eersteklas objecten en gegevensverzamelingen.

Hoewel de meeste talen zijn ontworpen ter ondersteuning van een specifiek programmeerparadigma, zijn veel algemene talen flexibel genoeg om meerdere paradigma's te ondersteunen. De meeste talen die functiepointers bevatten, kunnen bijvoorbeeld worden gebruikt om functioneel programmeren ongelooflijk te ondersteunen. Bovendien bevatten C# en Visual Basic expliciete taalextensies ter ondersteuning van functioneel programmeren, waaronder lambda-expressies en typedeductie. LINQ-technologie is een vorm van declaratief, functioneel programmeren.

Functioneel programmeren met XSLT

Veel XSLT-ontwikkelaars zijn bekend met de pure functionele benadering. De meest effectieve manier om een XSLT-opmaakmodel te ontwikkelen, is door elke sjabloon te behandelen als een geïsoleerde, samenstelbare transformatie. De uitvoeringsvolgorde wordt volledig gedeacgradeerd. XSLT staat geen bijwerkingen toe (met uitzondering dat het ontsnappen van mechanismen voor het uitvoeren van procedurele code bijwerkingen kan veroorzaken die leiden tot functionele onzuiverheden). Hoewel XSLT echter een effectief hulpmiddel is, zijn sommige kenmerken ervan niet optimaal. Het uitdrukken van programmeerconstructies in XML maakt code bijvoorbeeld relatief uitgebreid en daarom moeilijk te onderhouden. Bovendien kan de zware afhankelijkheid van recursie voor stroombeheer leiden tot code die moeilijk te lezen is. Zie XSLT-transformaties voor meer informatie over XSLT.

XSLT heeft echter de waarde bewezen van het gebruik van een zuivere functionele benadering voor het transformeren van XML van de ene shape naar de andere. Pure functionele programmering met LINQ naar XML is op veel manieren vergelijkbaar met XSLT. Met de programmeerconstructies die door LINQ zijn geïntroduceerd in XML, C# en Visual Basic, kunt u echter pure functionele transformaties schrijven die beter leesbaar en onderhouden zijn dan XSLT.

Voordelen van pure functies

De primaire reden voor het implementeren van functionele transformaties als pure functies is dat pure functies samenstelbaar zijn: dat wil gezegd, zelfstandig en staatloos. Deze kenmerken hebben een aantal voordelen, waaronder de volgende:

  • Verbeterde leesbaarheid en onderhoudbaarheid. Dit komt doordat elke functie is ontworpen om een specifieke taak uit te voeren op basis van de argumenten. De functie is niet afhankelijk van een externe status.
  • Eenvoudigere reiteratieve ontwikkeling. Omdat de code eenvoudiger te herstructureren is, zijn wijzigingen in het ontwerp vaak eenvoudiger te implementeren. Stel dat u een gecompliceerde transformatie schrijft en u vervolgens realiseert dat sommige code meerdere keren in de transformatie wordt herhaald. Als u herstructureert via een pure methode, kunt u uw pure methode op wille wijze aanroepen zonder dat u zich zorgen hoeft te maken over bijwerkingen.
  • Eenvoudiger testen en foutopsporing. Omdat pure functies gemakkelijker geïsoleerd kunnen worden getest, kunt u testcode schrijven die de pure functie aanroept met typische waarden, geldige randcases en ongeldige edge-aanvragen.

Om de hierboven beschreven redenen is functioneel programmeren zeer geschikt voor de architectuurstijl van microservices.

Overstappen voor OOP-ontwikkelaars

In traditionele objectgeoriënteerde programmering (OOP) zijn de meeste ontwikkelaars gewend aan programmeren in de imperatieve/procedurele stijl. Om over te schakelen naar ontwikkelen in een pure functionele stijl, moeten ze een overgang maken in hun denken en hun benadering van ontwikkeling.

Voor het oplossen van problemen ontwerpt OOP-ontwikkelaars klassehiërarchieën, richt u zich op de juiste inkapseling en denkt u na over klassecontracten. Het gedrag en de status van objecttypen zijn van cruciaal belang, en taalfuncties, zoals klassen, interfaces, overname en polymorfisme, worden geboden om deze problemen op te lossen.

Functionele programmering benadert daarentegen rekenproblemen als oefening in de evaluatie van pure functionele transformaties van gegevensverzamelingen. Functionele programmering voorkomt status- en veranderlijke gegevens en benadrukt in plaats daarvan de toepassing van functies.

Gelukkig hebben C# en Visual Basic niet de volledige sprong naar functioneel programmeren nodig, omdat ze zowel imperatieve als functionele programmeermethoden ondersteunen. Een ontwikkelaar kan kiezen welke benadering het meest geschikt is voor een bepaald scenario. In feite combineren programma's vaak beide benaderingen.

Zie ook