nicht angemeldet
fischlakHallo encoder,
Ich hab gute Erfahrungen gemacht und meine Hausnummer ist größer als 7 - der Zusammenhang ist ähnlich 😁 Soll heißen OOP hat nichts mit der Anzahl Personen zu tun.
OOP kann sehr bei der Strukturierung von Code helfen. Man sieht direkt wo eine Funktion oder Methode zu finden ist, nämlich in der Klasse mit der sie aufgerufen wird.
Ich hab ganz andere Erfahrungen gemacht. Wenn ich alleine arbeite, erreiche ich mit OOP nur noch mehr Fragmentierung. Für Solo-Entwickler (gerade auch in JavaScript-Projekten) kann ein prozeduraler/funktionaler/modularer Ansatz deutlich effizienter sein. OOP entfaltet seine Stärken erst, wenn Teams an komplexen Systemen arbeiten, bei denen Kapselung wichtiger ist als Code-Schlankheit.
Die Tatsache, dass OOP den Code unnötig aufbläht, ist in der Softwareentwicklung doch gut dokumentiert! Studien und Expertenanalysen deuten darauf hin, dass OOP-Code im Vergleich zu rein prozeduralen Ansätzen etwa 17 % bis 38 % umfangreicher ist:
0–20 % mehr Code bei pragmatischer, einfacher OOP und 20–80 % mehr Code bei klassischer stark abstrahierter OOP.
Dieser "Aufbläheffekt" entsteht vor allem durch strukturellen Overhead und die Art der Abstraktion. OOP erfordert zusätzliche Definitionen für Klassen, Interfaces, Konstruktoren und Zugriffsmethoden. Allein die Definition von Klassen fügt oft eine zusätzliche "Einrückungsebene" hinzu, was die Lesbarkeit bei kleineren Skripten erschweren kann.
Anstatt Daten direkt zu verarbeiten, werden sie in Objekten gekapselt. Dies führt zu mehr Funktionsaufrufen (oder von mir aus Methodenaufrufen – 2 Namen für de facto den gleichen Effekt) und so gut wie immer zu einer fragmentierteren Struktur, was neben der größeren Unübersichtlichkeit des Codes bei leistungskritischen Anwendungen durchus spürbar sein kann. Aber zu der stärkeren Fragmentierung hab ich ja nun genug geschieben.
Man sagt auch "Bananen-Gorilla-Dschungel"-Problem dazu: Wie Joe Armstrong (Erfinder von Erlang) treffend formulierte: "Du wolltest eine Banane, aber was du bekamst, war ein Gorilla, der die Banane hält, und den gesamten Dschungel dazu".
Die aktuelle Forschung, hier mal ein Beispiel:
legt nahe, dass es kein "besseres" Paradigma gibt, sondern die Wahl von der Projektgröße abhängt. Bei kleinen/mittleren Projekten ist prozedural oft effizienter, schneller zu schreiben und leichter zu überblicken. Bei großen/komplexen Systemen überwiegen die Vorteile der Kapselung und Wiederverwendbarkeit von OOP.
Welcher Programmierer verbraucht nicht deutlich mehr als die Hälfte seiner Zeit an Fehlersuche und Debugging? Und ich rede hier nicht von Anfängern, sondern duraus von Fortgeschrittenen. Aus dieser Nummer wird Dich keine OOP dieser Welt herausziehen!
Aber so weit wollte ich gar nicht gehen. Ich wollte mich eigentlich über Erfahrungen bezüglich der Folding-Implementation heutiger Editoren austauschen und keine Grundsatzdiskussion Prozedual vs. OOP anreißen.
Gruß, fischlak
Rolf B
Julius
Gunnar Bittersmann
MudGuard