Funktionelle sprog er tilbage efter års automatisk brug af objektorientet programmering

Objektorienteret programmering havde omkring årtusindskiftet fortrængt de funktionelle sprog, men i dag er funktionel programmering tilbage. Objektorienteret er nemlig ikke altid bedst.

Nye studerende på datalogistudiet på Københavns Universitet er fra dette studieår blevet introduceret til programmeringsfaget med sproget F#.

Tidligere bestod pensum af to kurser baseret på henholdsvis ML og Java. Tanken er, at F# både kan bruges til funktionel og objektorienteret programmering, og dermed bliver det nemmere at slå en vigtig pointe fast.

»De starter med funktionel programmering, så imperativ og så objektorienteret. Med F# kan man bedre vise forskellene mellem tilgangsvinklerne. Det kunne ellers drukne i forskellig syntaks og typesystemer mellem sprogene,« forklarer lektor og studieleder Torben Mogensen fra Datalogisk Institut på Københavns Universitet til Version2.

Det er nemlig en væsentlig del af datalogifaget at kende til de forskellige tilgange til programmering, og specielt funktionel programmering har fået en genopblomstring, efter der i mange år hovedsageligt har været fokus på objektorienterede sprog som C++ og Java.

Det er imidlertid problematisk at fokusere på sprog, der i praksis udelukker nogle af de forskellige grundlæggende programmeringsparadigmer, og eksempelvis på forhånd definere, at en applikation til en smartphone skal skrives i Java.

»Noget af det, vi fortæller de studerende, er, at først skal de identificere problemet, og derefter skal de vælge den passende løsning,« siger professor Olivier Danvy fra Institut for Datalogi ved Aarhus Universitet til Version2.

Netop smartphone-platformene har åbnet for flere programmeringssprog, ligesom flere af de traditionelt objektorienterede sprog har fået udvidelser, der gør det muligt at programmere funktionelt.

Som udvikler bør man altså altid være opmærksom på lektionen fra datalogistudiet om, at selvom man er vant til at programmere i Java, så er det ikke sikkert, at objektorienteret er den bedste måde at løse det næste problem på.

Identificer først problemet - find programmet senere, siger professor Olivier Danvy fra Institut for Datalogi ved Aarhus Universitet

»Det er stort problem, hvis programmøren ikke har frihed til at vælge,« siger Olivier Danvy.

Objektorienteret er overbrugt

Med objektorienterede sprog som en de facto-standard, så løber man ind i, at objektorienteret ikke altid er den bedste fremgangsmåde.

»Objektorienteret programmering er efter min mening blevet overbrugt og oversolgt. Hvis man eksempelvis laver et API til en grafisk brugerflade, så er det ikke nødvendigvis det mest fornuftige, at et museklik skal være et objekt,« siger Torben Mogensen.

Den objektorienterede tilgang har sin berettigelse, når objekter er den bedste måde at løse problemet på.

Men det er en udfordring, at mange problemer kan beskrives ud fra objekter, men det er i sig selv ikke ensbetydende med, at objektorienteret programmering er det bedste svar.

Et klassisk eksempel er banksystemet, hvor man kan betragte hver konto som et objekt, der indeholder en saldo og har metoder til at lægge et beløb til saldoen eller få oplyst saldoen.

Tilsvarende vil en transaktion kunne være et objekt, som indeholder to kontonumre, et beløb og oplysningen om, hvorvidt transaktionen er gennemført.

Det er eksempel på stateful programmering og kan være en god løsning. Men man kunne også designe banksystemet som stateless.

Eksempelvis kunne der være en funktion til renteberegning, som modtager et beløb og en rentesats. Selve funktionen indeholder kun metoden til at beregne et nyt beløb og er ikke knyttet til en bestemt konto.

En af fordelene ved at vælge sådan en stateless tilgang er, at den er forholdsvis let at skalere til mange parallelle processer for store datamængder.

»Objektorienteret programmering er er elegant til at løse modulære problemer. Funktionel programmering kan let køre parallelt, og det er én af grundene til, at det blevet populært,« siger Olivier Danvy.

Udnytter ikke nedarvning

Mange nyere sprog som C# giver mulighed for at programmere funktionelt, selvom sproget primært er objektorienteret. Man skal dog stadig som udvikler vælge den rigtige model til sin applikation.

»Især nybegyndere kan svært ved objektorienteret programmering. Mange programmerer i Java, men forstår ikke, hvad der sker, og udnytter for eksempel ikke nedarvning,« siger Torben Mogensen.

Noget af det vigtigste i objektorienteret programmering er ikke, hvorvidt man kan opdele sit problem i objekter, men lige så meget muligheden for nedarvning.

I banksystemet kan man således have en overordnet klasse kaldet Konto, og så kan nye kontotyper oprettes som nedarvende klasser, der tilføjer særlige egenskaber til kontoen.

En opsparingskonto kunne eksempelvis have en rente, der er variabel, snarere end en fast rente, eller en lønkonto kunne have en kassekredit.

F# tilbydes som en del af Microsoft Visual Studio

Både opsparingen og lønkontoen ville arve egenskaber som saldo og muligheden for at få oplyst saldoen.

Nedarvning kan derfor være med til at gøre et stort system mindre komplekst, fordi hierarkiet med klasser giver en vis struktur i sig selv.

Tilsvarende kan der også være fordele ved at programmere efter et stateful paradigme, hvor de enkelte objekter husker på deres tilstand.

Svært at teste

Omvendt kan det også give problemer. Eksempelvis kræver parallelisering, at man holder nøje øje med, hvilke processer der afsluttes hvornår, og hvilke der stadig kører eller venter. Ellers risikerer man race conditions.

Lektor Torben Mogensen, DIKU: Det er væsentlig at kende til forskellige tilgange til programmering

Derudover er stateful-programmer sværere at teste ved hjælp af eksempelvis unit tests, påpeger Torben Mogensen.

»Data i et objekt kan være svært at genskabe i en test. I funktionsprogrammering afhænger det udelukkende af de argumenter, du giver funktionen. Det kan du ikke være sikker på i objektorienteret programmering,« siger han.

Mange nyere programmeringssprog er vanskelige at kategorisere som tilhørende enten det ene eller det andet programmeringsparadigme.

Et sprog som Apples Swift er ligesom F# et sprog, der kan lidt af både objektorienteret og funktionelt.

Det samme gælder Javascript, som har udviklet sig fra primært at være til webbrug til både at blive brugt i mobilapplikationer og på serverdelen af webapplikationer.

Kommentarer (12)

Troels Henriksen

Fra artiklen:

Netop smartphone-platformene har åbnet for flere programmeringssprog

Hvordan hænger det sammen? Jeg ville da tro at det var server-side webprogrammering der åbnede for vilkårlige sprog, da det ikke kræver installation af noget på brugerens system. Bliver det meste datafon-programmering ikke gjort i de sprog producenten selv synes er bedst (hhv. Java og Objective C)?

Jesper Stein Sandal Journalist

Datafonerne giver efterhånden mulighed for at udvikle i eksempelvis Javascript og HTML5 eller Swift. Der er ikke helt frit valg på alle hylder, men som regel kan man vælge mellem 2-3 sprog. Værktøjer som Xamarin og flere andre giver mulighed for nogle flere, selvom de ikke har native understøttelse på mobilplatformene.

Hvor godt det virker med de andre sprog end dem, der var først, er så et godt spørgsmål.

Baldur Norddahl

Er det ikke længere vigtigt at introducere de studerende til flere sprog, så at de ikke eksempelvis tror at programmering == F# ?

Jeg vil mene at man mister noget ved ikke at blive introduceret til forskellige type systemer, da man så kan komme ind i en tankegang om at der kun er en måde at gøre tingene på.

Troels Henriksen

Er det ikke længere vigtigt at introducere de studerende til flere sprog, så at de ikke eksempelvis tror at programmering == F# ?

I løbet af fem år på DIKU kommer man til at stifte bekendtskab med F#, Python, Matlab, C, Haskell, Erlang, Prolog, assemblerkode og Java. Dertil er der valgfri kurser med CUDA og C++ (og sikkert mere jeg har glemt). Man kan sikkert også snige R ind et sted (og slippe for Matlab).

Vi kommer vidt omkring.

Mikkel Lauritsen Blogger

Det er eksempel på stateful programmering og kan være en god løsning. Men man kunne også designe banksystemet som stateless.

Eksempelvis kunne der være en funktion til renteberegning, som modtager et beløb og en rentesats. Selve funktionen indeholder kun metoden til at beregne et nyt beløb og er ikke knyttet til en bestemt konto.

Ja, jeg er i hvert fald interesseret, hvis min bank begynder at tilbyde en stateless udlånskonto :-)

Med forbehold for, at artiklen nødvendigvis må anlægge en forenklet synsvinkel på problemstillingen, og at jeg ikke er den store ekspert i hvordan banker faktisk beregner renter, så forekommer det mig, at problemet måske ikke så meget er objektorientering, men snarere et uhensigtsmæssigt design?

Eller med andre ord: hvis jeg med et objektorienteret sprog skulle implementere et banksystem, så ville jeg ikke lave renteberegningen som en metode på kontoklassen. Det er lidt den samme skævhed, som fx optræder hos Steve Yegge - hvis man laver klassisk OOAD ("find navneordene, find udsagnsordene" osv.) er det ikke kontoen, som beregner renten, men derimod en "renteberegner", hvad det så end er.

Mikkel Lauritsen Blogger

Det er en funktion.

Måske. Det er nok mest et spørgsmål om begreber - der er fx ikke den store forskel på at lave det at beregne en rente for en konto ud fra en given beregningsart som en funktion, der givet arten som input returnerer en ny funktion (closure), der beregner renten (FP), eller om man laver en factorymetode, der givet arten som input returnerer et objekt der implementerer et interface til at beregne renter (OOP).

Men jeg synes stadig, at det lidt er et stråmandsargument at sige, at OOP er uhensigtsmæssigt, fordi man har valgt et suboptimalt design. Det er ikke (kun) sprogets skyld.

Mark Klitgaard

ITU har i flere år undervist i F# på softwareudvikler bacheloren, hvor undervisning i funktionel udvikling kommer meget naturligt efter C#, så de studerende får stiftet bekendskab med fordele og ulemper ved begge tilgange. Mig bekendt underviser DTU også i F#. KU er nok bare lidt bagud på den front?

Troels Henriksen

ITU har i flere år undervist i F# på softwareudvikler bacheloren, hvor undervisning i funktionel udvikling kommer meget naturligt efter C#, så de studerende får stiftet bekendskab med fordele og ulemper ved begge tilgange. Mig bekendt underviser DTU også i F#. KU er nok bare lidt bagud på den front?

KU har undervist i funktionsprogrammering siden før ITU blev grundlagt. Det "nye" er blot skiftet fra Standard ML til F# (og at Java er røget helt ud af førsteåret).

Det er forresten lidt sært at sige at funktionelle sprog "er tilbage". De har aldrig rigtig været mere populære end de er nu, og de har aldrig været noget der ligner mainstream.

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen