Functioneel programmeren vs objectgeoriënteerd programmeren

Ik ben tot nu toe vooral in aanraking gekomen met OO-programmering en kijk er naar uit om een functionele taal te leren. Mijn vragen zijn:

• Wanneer kies je voor functioneel programmeren in plaats van objectgeoriënteerd?
• Wat zijn de typische probleemdefinities waarbij functioneel programmeren een betere keuze is?

Antwoord 1, autoriteit 100%

Wanneer kies je voor functioneel programmeren in plaats van objectgeoriënteerd?

Als u een ander soort software-evolutie verwacht:

• Objectgeoriënteerde talen zijn goed als je een vaste set bewerkingenop dingenhebt, en naarmate je code evolueert, voeg je voornamelijk nieuwe dingen toe. Dit kan worden bereikt door nieuwe klassen toe te voegen die bestaande methoden implementeren, en de bestaande klassen worden met rust gelaten.

• Functionele talen zijn goed als je een vaste set dingenhebt, en naarmate je code evolueert, voeg je voornamelijk nieuwe bewerkingentoe aan bestaande dingen. Dit kan worden bereikt door nieuwe functies toe te voegen die met bestaande gegevenstypen rekenen, en de bestaande functies worden met rust gelaten.

Als de evolutie de verkeerde kant opgaat, heb je problemen:

• Voor het toevoegen van een nieuwe bewerking aan een objectgeoriënteerd programma kan het nodig zijn om veel klassedefinities te bewerken om een nieuwe methode toe te voegen.

• Voor het toevoegen van iets nieuws aan een functioneel programma kan het nodig zijn om veel functiedefinities te bewerken om een nieuwe case toe te voegen.

Dit probleem is al jaren bekend; in 1998, Phil Wadler noemde het het “expressieprobleem”. Hoewel sommige onderzoekers denken dat het expressieprobleem kan worden aangepakt met taalfuncties als mixins, moet een algemeen aanvaarde oplossing nog steeds de mainstream bereiken.

Wat zijn de typische probleemdefinities waarbij functioneel programmeren een betere keuze is?

Functionele talen blinken uit in het manipuleren van symbolische gegevens in boomvorm. Een favoriet voorbeeld zijn compilers, waar bron- en tussentalen zelden veranderen (meestal dezelfde dingen), maar compilerschrijvers voegen altijd nieuwe vertalingen en codeverbeteringen of optimalisaties toe (nieuwe bewerkingen op dingen). Compilatie en vertaling zijn in het algemeen “killer-apps” voor functionele talen.

Antwoord 2, autoriteit 15%

Je hoeft niet per se te kiezen tussen de twee paradigma’s. U kunt software schrijven met een OO-architectuur met behulp van veel functionele concepten. FP en OOP zijn orthogonaal van aard.

Neem bijvoorbeeld C#. Je zou kunnen zeggen dat het voornamelijk OOP is, maar er zijn veel FP-concepten en constructies. Als je Linqin overweging neemt, zijn de belangrijkste constructies die het mogelijk maken dat Linq bestaat functioneel van aard: lambda-expressies.

Een ander voorbeeld, F#. Je zou kunnen zeggen dat het voornamelijk FP is, maar er zijn veel OOP-concepten en constructies beschikbaar. U kunt klassen, abstracte klassen, interfaces definiëren, omgaan met overerving. Je kunt zelfs veranderlijkheid gebruiken wanneer het je code duidelijker maakt of wanneer het de prestaties drastisch verbetert.

Veel moderne talen zijn multiparadigma.

Aanbevolen metingen

Zoals ik in dezelfde boot ben (Oop-achtergrond, het leren van FP), zou ik u een aantal metingen voorstellen die ik erg op prijs heb:

• Functionele programmering voor dagelijkse .NET-ontwikkeling , door Jeremy Miller. Een geweldig artikel (hoewel slecht geformatteerd) met veel technieken en praktische, real-world voorbeelden van FP op C #.

• Real-World Functional Programming , door Tomas Petricek . Een geweldig boek dat voornamelijk bezighoudt met FP-concepten, probeert uit te leggen wat ze zijn, wanneer ze moeten worden gebruikt. Er zijn veel voorbeelden in zowel F # en C #. Ook, Petricek’s blog is een geweldige bron van informatie.

Antwoord 3, Autoriteit 3%

Objectgeoriënteerde programmeringaanbiedingen:

1. -inapseling, naar
   • Control mutatie van interne status
   • Beperking koppeling aan interne vertegenwoordiging
2. subtypen, toestaan:
   • Vervanging van compatibele typen (polymorfisme)
   • een ruwe middelen voor het delen van de implementatie tussen klassen (implementatie-erfenis)

Functionele programmering, in Haskell of zelfs in Scala, kan substitutie mogelijk maken door een meer algemene mechanisme van typesklassen. Interne interne toestand is ontmoedigd of verboden. Inkapseling van interne vertegenwoordiging kan ook worden bereikt. Zie Haskell vs Oop voor een goede vergelijking.

Norman’s bewering dat “het toevoegen van een nieuw soort ding aan een functioneel programma mogelijk het bewerken van veel functiedefinities vereist om een nieuw geval toe te voegen.” hangt af van hoe goed de functionele code typeklassen heeft gebruikt. Als Pattern Matching op een bepaald Abstract Data Type verspreid is over een codebase, zul je inderdaad last hebben van dit probleem, maar het is misschien een slecht ontwerp om mee te beginnen.

BEWERKTVerwijzing naar impliciete conversies verwijderd bij het bespreken van typeklassen. In Scala worden typeklassen gecodeerd met impliciete parameters, niet met conversies, hoewel impliciete conversies een andere manier zijn om compatibele typen te vervangen.

Antwoord 4, autoriteit 2%

1. Als u zich in een sterk gelijktijdige omgeving bevindt, is puur functioneel programmeren nuttig. Het ontbreken van een veranderlijke staat maakt concurrency bijna triviaal. Zie Erlang.

2. In een taal met meerdere paradigma’s wil je misschien sommige dingen functioneel modelleren als het bestaan van een veranderlijke toestand een implementatiedetail is, en dus is FP een goed model voor het probleemdomein. Zie bijvoorbeeld lijstbegrippen in Python of std.rangein de programmeertaal D . Deze zijn geïnspireerd op functioneel programmeren.