Vanaf dag 1 van mijn programmeercarrière ben ik begonnen met objectgeoriënteerd programmeren. Ik ben echter geïnteresseerd in het leren van andere paradigma’s (iets dat ik hier op SO een aantal keer heb gezegd, is een goede zaak, maar ik heb er geen tijd voor gehad). Ik denk dat ik niet alleen klaar ben, maar ook de tijd heb, dus ik ga functioneel programmeren met F#.
Ik weet echter niet hoe ik veel minder ontwerptoepassingen moet structureren. Ik ben gewend aan de ideeën van één klasse per bestand en klasse-zelfstandig naamwoord/functie-werkwoord in OO-programmering. Hoe ontwerp en structureer je functionele applicaties?
Antwoord 1, autoriteit 100%
Lees de SICP.
Er is ook een PDF-versiebeschikbaar.
Antwoord 2, autoriteit 74%
Misschien wil je een recent blogbericht van mij lezen: Hoe heeft functioneel programmeren invloed op de structuur van uw code?
Op een hoog niveau is een OO-ontwerpmethodologie nog steeds erg handig voor het structureren van een F#-programma, maar je zult merken dat dit minder wordt (meer uitzonderingen op de regel) als je naar lagere niveaus gaat. Op fysiek niveau zal “één klasse per bestand” niet in alle gevallen werken, omdat wederzijds recursieve typen in hetzelfde bestand moeten worden gedefinieerd (typeClass1 = … enClass2 = …), en een stukje van je code kan in “vrije” functies zitten die niet gebonden zijn aan een bepaalde klasse (dit is waar F# “modules” goed voor zijn). De beperkingen voor het ordenen van bestanden in F# zullen je ook dwingen kritisch na te denken over de afhankelijkheden tussen typen in je programma; dit is een tweesnijdend zwaard, omdat het misschien meer werk/denken kost om afhankelijkheden op hoog niveau te ontwarren, maar het zal programma’s opleveren die zo zijn georganiseerd dat ze altijd benaderbaar zijn (omdat de meest primitieve entiteiten altijd eerst komen en je kunt lees een programma altijd van ‘boven naar beneden’ en laat nieuwe dingen één voor één introduceren, in plaats van gewoon een map vol codebestanden te gaan zoeken en niet te weten ‘waar te beginnen’).
Antwoord 3, autoriteit 32%
Programma’s ontwerpengaat hier allemaal over (vermoeiend, met behulp van Schema in plaats van F#, maar de principes worden overgedragen). Kortom, uw code weerspiegelt uw datatypes; dit idee gaat terug op ouderwets “gestructureerd programmeren”, alleen functioneel programmeren is er explicieter over, en met liefhebber datatypes.
Antwoord 4, autoriteit 26%
Aangezien moderne functionele talen (dus geen lisps) standaard vroeggebonden polymorfe functies (efficiënt) gebruiken en dat objectoriëntatie slechts een bepaalde manier is om polymorfe functies te ordenen, is het niet echt heel anders, als je weet hoe je goed ingekapselde klassen ontwerpt.
Lisps gebruiken late binding om een soortgelijk effect te bereiken. Om eerlijk te zijn, is er niet veel verschil, behalve dat je de structuur van typen niet expliciet aangeeft.
Als je uitgebreid hebt geprogrammeerd met C++-sjabloonfuncties, dan heb je waarschijnlijk al een idee.
In ieder geval is het antwoord kleine “klassen” en in plaats van de interne status te wijzigen, moet u een nieuwe versie met een andere status retourneren.
Antwoord 5, autoriteit 11%
F# biedt de conventionele OO-benaderingen voor grootschalige gestructureerde programmering (bijv. interfaces) en probeert niet de experimentele benaderingen te bieden die zijn ontwikkeld in talen als OCaml (bijv. functors).
Daarom is de grootschalige structurering van F#-programma’s in wezen hetzelfde als die van C#-programma’s.
Antwoord 6, autoriteit 5%
Functioneel programmeren is zeker een ander paradigma. Misschien is de gemakkelijkste manier om je hoofd eromheen te wikkelen, erop aan te dringen dat het ontwerp wordt opgemaakt met behulp van een stroomschema. Elke functie is verschillend, geen overerving, geen polymorfisme, verschillend. De gegevens worden van functie naar functie doorgegeven om verwijderingen, updates, invoegingen en nieuwe gegevens te maken.
7
Het gaat allemaal om pure functies en hoe ze kunnen samenstellen om grotere abstracties te bouwen. Dit is eigenlijk een moeilijk probleem waarvoor een robuuste wiskundige achtergrond is nodig. Gelukkig zijn er verschillende patronen met diep formeel en praktisch onderzoek beschikbaar. Op functionele en reactieve domeinmodellering Debasish Ghosh verkent dit onderwerp verder en Zet verschillende praktische scenario’s bij die pure functionele patronen toepassen:
Functionele en reactieve domeinmodellering leert u hoe te bedenken
het domeinmodel in termen van pure functies en hoe ze kunnen samenstellen
bouw grotere abstracties. Je begint met de basis van
Functionele programmering en geleidelijk vooruitgang naar de geavanceerde concepten
en patronen die u moet weten om complexe domeinmodellen te implementeren.
Het boek toont aan hoe geavanceerde FP-patronen zoals algebraïsche gegevens
Typen, gebaseerd ontwerp, en isolatie van bijwerkingen kunnen maken
Uw model componeert voor leesbaarheid en verifieerbaarheid.