Funktionale vs Objektorientierte Programmierung, was ist besser?
Ich selbst habe eine klare Meinung, dass OOP 1980-2000 ein gutes Programierparadigma war, heute aber nicht mehr.
Funktionaler Code ist vielleicht deutlich schwieriger zu schreiben (Haskell gehört auch nicht zu den leichtesten Sprachen) dafür aber auch zB viel einfacher zu testen und zu warten.
Häufig sind ältere OOP Programme kaum mehr vernünftig zu lesen, wenn immer mehr auf sie draufgesetzt wird.
Das Ergebnis basiert auf 15 Abstimmungen
11 Antworten
Das ist wie "gute Wohnlage vs. gute Wärmedämmung" bei der Wohnungssuche. Also unabhängige Begriffe.
Auch funktional programmierte Projekte sind kaum noch zu warten, wenn an allen Seiten Zusatzfeatures angeklebt worden sind. Das hat mit strukturiertem Programmieren zu tun, also mit Selbstdisziplin der Programmierer (pardon, ein klein wenig Selbstdisziplin der Programmierer und sehr viel Verständnis des Managements für "heute 10% Zeitbedarf mehr statt 300% mehr Zeitbedarf in 5 Jahren").
Lies dir mal https://de.wikipedia.org/wiki/Funktionale_Programmierung durch und schau dir ein paar altehrwürdige LISP-Projekte an ... Selbstmodifizierende Algorithmen sind notorisch schwer zu warten. Dass Haskell einen so guten Ruf in Puncto Verifizierbarkeit hat, dürfte daran liegen, dass es (noch?) nicht in der Software-Industrie ("Kurzfristiger Gewinn - gibt es wirklich Phantasten, die glauben, es könnte ein anderes Ziel geben?") angekommen ist.
Warum muss das ein Entweder-Oder sein?
Häufig sind ältere OOP Programme kaum mehr vernünftig zu lesen, wenn immer mehr auf sie draufgesetzt wird.
Sind funktionale Programme vernünftig zu lesen, wenn immer mehr auf sie draufgesetzt wird?
Auch FP ist nur ein Werkzeug von vielen, mit Komplexität umzugehen - das lernst du, wenn du mal länger Erfahrung gesammelt hast. Brooks' Essay "No Silver Bullet" gilt nach wie vor uneingeschränkt (und wenn du davon noch nichts gehört hast, ist es höchste Zeit).
Mal ehrlich, hast du überhaupt schon etwas größere Software (wir reden hier wenigstens von ein paar 10 kLOC) funktional entwickelt und gewartet, am besten in einem verteilten Team, wie es in der Realität vorkommt?
Dokumentation ist immer nur die letzte Verteidigungslinie. Die Eigenschaft "seiteneffektfrei" ist zweifellos sehr schön, aber letztlich verschiebt sich damit auch nur, wo der veränderliche Zustand der Applikation durchgeschleust wird. Spätestens wenn Closures durch die Gegend geschickt werden und es (nicht offensichtliche!) zyklische Abhängigkeiten zwischen Funktionen gibt wird's dann genauso mühsam und schlecht testbar wie in einem übermodellierten OOP-Design. Wie gesagt: dafür muss die Software halt deutlich größer werden als die Projekte, die man auf der Uni hat.
Den echten Unterschied macht dann das Architekturmanagement, nicht OOP oder FP.
Mit einer vernünftigen Dokumentation die dir sagt was eine Funktion genau macht definitiv.
Wie viele Dokumentationen hast Du gesehen, die auch tatsächlich vernünftig sind, ausreichend ausführlich sind - und nach ein paar Jahren immer noch? ;)
Dokumentation ist immer das erste, was veraltet - nicht gut, darauf zu bauen.
Was man mMn. dokumentieren sollte, sind grundlegende Konzepte und Ziele hinter der der Architektur und natürlich die Funktionen der Software.
Nicht lesbarer Code: Das bekommst Du überall (oop/func) hin und ist nur ein Zeichen schlechten Handwerks und insbesondere schlechten Desgins.
Im ordentlichem Design bekommst du mit OOP deutlich größere Probleme vernünftig in den Griff.
Hab keine klare Meinung aber funktionaler Code ist definitiv nicht pauschal einfacher zu lesen. Bei Haskell ist das richtig schlimm
Naja mit einer Dokumentation die dir sagt was eine Funktion genau macht schon.
Funktionen (sollte man funktional programmieren) produzieren keine Seiteneffekte, de4 gleiche Input führt immer zum gleichen Output.
Aber es macht halt viele triviale Sachen deutlich schwere und ist bei größeren Codebases auch echt nicht easy zu verwalten. Außerdem gibts Lambda Funktionen Pattern Matching und sowas auch mittlerweile integriert in vielen OOP Sprachen
Mit Composition > Inheritance ist OOP eigentlich immer noch ganz vernünftig. Und funktionale Elemente sind ebenso immer wieder praktisch. Ich denke nicht, dass das Eine besser als das Andere ist, sondern man kann beides relativ gut in Kombination nutzen.
Mit einer vernünftigen Dokumentation die dir sagt was eine Funktion genau macht definitiv.
Du hast dann ja keine Seiteneffekte also alles der gleiche Input führt immer zum gleichen Output.