Laden...

Lohnt sich umfassende Funktionale Programmierung in C#?

Erstellt von Unfug vor 6 Jahren Letzter Beitrag vor 6 Jahren 2.252 Views
U
Unfug Themenstarter:in
133 Beiträge seit 2006
vor 6 Jahren
Lohnt sich umfassende Funktionale Programmierung in C#?

Guten Morgen zusammen,

Ich habe eine Frage an die Experten hier bzgl. Funktionaler Programmierung. Ich habe schon gesehen, dass einige hier sehr interessante Aussagen gemacht haben. FP ist ja eigentlich nichts neues, doch scheint es aktuell wieder in meinen Kreisen zu neuen Leben gefunden zu haben.

Ich habe mir auch ein paar Informationen und Bücher geholt.
Ich verlinke einfach mal das Buch: https://www.manning.com/books/functional-programming-in-c-sharp
(Bitte löschen von Mod, falls Hinweis nicht erwünscht).
Zu diesem Buch gibt es auch eine 1:1 Library. Die Language-Ext.
Und genau damit beschäftige ich mich derzeit.

Die grundlegenden Prinzipen von FP:

  • Jede Funktion liefert einen Wert zu zurück (kein Void).
  • Funktionen nutzen keine globalen Objekte oder verrändern Daten außerhalb der Funktion
  • Versuchen so viel wie möglich mit Immutable zu realisieren.
  • Definieren von allgemeingültigen Funktionen und BusinessLogik durch Delegates hinzufügen. (Beispiel wie bei : Linq.Where)

habe ich auch soweit verstanden und setze ich eigentlich auch seit Ewigkeiten um. Delegates und Linq gibt es ja schon seit Ewigkeiten.

Nun geht der Author noch einen Schritt weiter.

  1. Es werden statische Funktionen und Klassen genutzt für jeden und alles
  2. Funktionen werden aneinander gekettet F1().F2().F3(), wobei der Output der vorherigen zum Input der nächsten wird und am Ende dann das gewünschte Ergebnis zurückgeliefert wird.
  3. Jede Änderung an einem Objekt führt dazu, dass das Objekt mit den neuen Eigenschaften neu erstellt wird und zurückgeliefert wird.

Ich habe persönlich das Gefühl, dass ich irgendwas noch nicht verstanden habe, da FP eigentlich den Code und Architektur ja schöner machen soll. Allein bei den 3 Punkten (und der Author geht noch wesentlich weiter) empfinde ich das Programmieren allerdings als sehr "anstrengend".

Meine statischen Klassen werden größer und größer und größer und dieses aneinander Ketten von Funktionen kommt mir irgendwie wie klassisches C oder Javascript vor. Dieses datenflussorientierte Denken das Output zum neuen Input wird, kenne ich aus Labview. Und hier habe ich ehrlich gesagt keine super gute Erfahrung in Projekten die ein gewisse Größe haben. Man muss hinterher immer den kompletten Datenfluss sich anschauen, wenn irgendwas nicht funktionierte.

So nach soviel Text zu meiner eigentlichen Frage: Wer von euch nutzt z.B. FP in C# und kann wirklich bestätigen, dass es sich lohnt auch weiter als die grundlegenden Prinzipien von FP in C# zu gehen. Ausschließliche Nutzung von expression bodies, nur immutables, nur Verkettung von Methoden und alles statische Klassen.

Danke und schönen Advent noch.

D
985 Beiträge seit 2014
vor 6 Jahren
  1. Es werden statische Funktionen und Klassen genutzt für jeden und alles
    ...
  2. Jede Änderung an einem Objekt führt dazu, dass das Objekt mit den neuen Eigenschaften neu erstellt wird und zurückgeliefert wird.

Die beiden Punkte widersprechen sich aber. Wenn es nur statische Klassen gibt, wie kann man dann Instanzen (Objekte) haben?

16.806 Beiträge seit 2008
vor 6 Jahren

"Experten" werben doch seit 25 Jahren, dass OOP tot ist und nur FP das wahre Leben darstellt.
Das flacht sich ab und spätestens in X Jahren kommt das auch wieder.

In C# gibt es bereits FP (zB. ist die gesamte Linq-Abteilung so umgesetzt) und es hat auch seine Vorteile; aber nur statische Klassen widerspricht der Art und Weise, wie C# funktioniert.
Hier wäre F# die Wahl.

Ich mixe mittlerweile C# und F# in Projekten; was auch einwandfrei funktioniert.
Beide Arten haben ihre Vor- und Nachteile.
Was ich vermeide: F# in größeren Team Projekte, weil es einfach zu wenig Personen auf dem Markt gibt, die F# verstehen.
Und wenn der Kunde kein Personal für F# hat, dann wird auch kein F# eingesetzt.
C# Entwickler gibt es einfach viel mehr - das darf man bei dem Einsatz dieser Sache auch nicht vernachlässigen - vor allem als Firma nicht!

Leider gibt es aber in allen Lagern dann Personen wie "C# ist nen dreck, nur F# ist gut!" (davon rennen gerade viele auf Twitter rum!) - umgekehrt genauso.

PS: Funktionale Programmierung heisst nicht, dass der Code hübscher ist, schneller in der Ausführung oder programmiert ist; geschweige denn, dass er besser wartbar ist.
Hier gibt es genauso wenig Pauschalität wie umgekehrt.

U
Unfug Themenstarter:in
133 Beiträge seit 2006
vor 6 Jahren

Danke für eure Antworten.

Ich meinte natürlich überwiegend statische Klassen in denen dann die statischen Funktionen aufgelistet sind. Objekte werden als States benutzt. Wobei das ja auch nur Objektinstanzen sind. Ändert man ein Property wird davon aber ein neues Objekt zurückgeliefert statt das Objekt selbst.

@Abt, so ähnlich sehe ich es auch. Aktuell, wird bei uns einfach (erneut) wieder diskutiert mehr FP mit c# zu nutzen, weil es ja so toll ist.

Um ehrlich zu sein, weiß ich nur nicht was ich davon halten soll, dass ich statische Funktionen habe. Da die Funktionen keinen direkten Objekt Bezug mehr haben, könnte man eine einzelne .cs Datei erstellen in der dann Funktionen sind wie

int macheDies(Type1 typ)
string machedas (Type2 typ)
IEnumerable<T> unddas (type3 typ)

Ist das wirklich schön? Gerade bei einer Anwendung, die dann ggfs. 100 oder gar 1000 tausende Methoden hat? Das kann doch nicht richtig sein oder? Ich muss da doch etwas übersehen haben.

F# gucke ich mir aber aufjedenfall auch nochmal an. Vielleicht ist das die Besserung Lösung. Jeder der will kann f# nutzen, die anderen c# und dann kombiniert man das anstatt C# "aufzumotzen" wofür es ggfs nicht entwickelt wurde.

Danke

P
1.090 Beiträge seit 2011
vor 6 Jahren

Wenn FP gut Umgesetzt ist, ist es auch Sinnvoll es in C# zu verwenden. Und C# bietet da auch einiges an Möglichkeiten an. Linq ist da sicher ein Parade Beispiel.

Umgekehrt wirst du aber auch Fälle haben, bei denen einen OOP Lösung deutlich sinnvoller ist.

Meines Erachten ist es nicht optimal nur auf OOP oder FP zu Sätzen. Sondern sich im einzelnen Anzuschauen was die Beste Lösung ist.

Was der bei der Entscheidung helfen kann sind Unit-/Intgrationstests zu schreiben (sollte man sowie so).

Statische Extension Methoden wie bei Linq, lassen sich meist recht einfach Testen.

Komplizierter wird es wenn du Klassen hast die sie Verwenden.

Wenn du kein Problem hast Tests für diese Klassen zu schreiben, sind Extension Methoden wahrscheinlich nicht Falsch.

Wird es kompliziert Tests zu schreiben weil du die Extension Methoden eigentlich Mocken musst. Ist es meist sinnvoller einen OOP Ansatz zu wählen und die Abhängigkeiten zu Injizieren (DI).

p.s. Wir verwenden für unsere Extension Methoden eignen .cs Dateien.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

16.806 Beiträge seit 2008
vor 6 Jahren

Man kann einfach nicht pauschal sagen, dass FP besser oder schlechter ist.
Es kommt einfach auf den Anwendungsfall an.

Ich finde auch, das einiges durchaus einfacher mit FP ist; zB. alles was Daten (XML, CSV...) zutun hat.
Bei Business Logik sehe ich es nicht ganz so...

Zu Extension Methods:
Die "Extension Method"-Möglichkeit ist pauschal keine funktionale Programmierung!

Eine Extension Method ist erst dann nach nach FP umgesetzt, wenn die Source nicht verändert wird; also "pure" bleibt"; und das sind gewiss nicht alle.
Sobald das Source modifiziert wird, ist es "impure".
(Impurity vs. Purity)

Linq alleine ist nicht FP; aber es ist so umgesetzt, dass es den FP Sinn verfolgt.

Wer also die Idee verfolgt, was man dann in dem Zusammenhang relativ oft sieht, Business Logik in eine Extension Method zu verschieben: nein. Tut es nicht!

U
Unfug Themenstarter:in
133 Beiträge seit 2006
vor 6 Jahren

Dann lag ich wohl nicht ganz falsch mit meinen Äußerungen und bisherigen Erfahrungen.
Gerade was BusinessLogik anging hatte ich auch immer ein etwas mulmiges Gefühl.
Das Buch selbst z.B. spricht auch gar nicht mehr von Architekturen und Entwürfen. Man müsse quasi sich alles wegdenken und rein auf Funktionen denken, die miteinander kombiniert werden.

Das fand ich interessant - aber irgendwie auch schwierig umzusetzen.

Ich denke ich schaue mir jetzt einmal F# an anstatt C# mit externen Libraries umzubauen. Und dann versuche ich, wie ihr beschrieben habt F# mal in C# zu nutzen, wenn es möglich ist und Sinn macht (z.B bei Daten).
Ich denke damit habe ich einen guten Anfang und erstmal was zu tun.

Schönen Dank