Name von Aufzähltypen

[Niesi]

...

Naja mittlerweile geht man wieder weg von OOP, denn OOP bringt auch extrem viele Nachteile. Z.b. durch das verwenden von abstrakten Methoden weiß man nur vom anschauen des Codes nicht welcher code wann ausgeführt wird, was es unfassbar schwer macht nachzuvollziehen was code tatsächlich macht.

...

.

Ich weiß jetzt grad nicht, aus welcher Ecke diese allen anderen Erkenntnissen widersprechende Verlautbahrung kommt.

Ich fürchte, es ist wie immer: Die, die mit irgendwas nicht klarkommen, wollen es dann auch runtermachen ...

Ohne OOP sind wirklich komplexe Projekte gar nicht mehr möglich.

Ballerspiele und so sind keine solchen.

[fliegermichl]

Ohne OOP sind wirklich komplexe Projekte gar nicht mehr möglich.

Ich bin grosser Fan von OOP. Aber in dem Punkt gebe ich Warf Recht. Da werden abstrakte Basisklassen definiert, von denen später abgeleitet wird. Nur vom Studium des Quellcodes alleine ist es dann fast unmöglich, den genauen Programmablauf zu ermitteln.

Erst wenn man im Debugger an entsprechenden Stellen Haltepunkte setzt und sich den Aufrufstack anschaut, kann man erkennen, welche Instanz da dann tatsächlich ans werkeln gekommen ist.

Das ist mir schon mehrfach heftig beim debuggen von Lazarus aufgefallen.

[Warf]

Ich weiß jetzt grad nicht, aus welcher Ecke diese allen anderen Erkenntnissen widersprechende Verlautbahrung kommt.

Ich fürchte, es ist wie immer: Die, die mit irgendwas nicht klarkommen, wollen es dann auch runtermachen ...

Ohne OOP sind wirklich komplexe Projekte gar nicht mehr möglich.

Ballerspiele und so sind keine solchen.

Gibt diverse Studien Designs, entweder Analyse großer Projekte, z.B. gibt es viele C Projekte (procedural) die auf C++ (OOP) umgestiegen sind, also selbe Entwickler, selbe Code Base direkter Vergleich der C und C++ Komponenten. Alternativ kann man zwischen Projekten ähnlicher Komplexität vergleichen, z.b. verschiedene Projekte des selben Unternehmens.

Bei diesen Experimenten wird meist in die Versionskontrolle geschaut und nachgeschaut wie oft dort über einen gewissen Zeitraum Fehler behoben wurden.

Dann gibt's noch die dritte art an experimenten dort gibt man einem Haufen Studenten Komponenten einmal OOP und einmal Procedural und schaut wie schnell sie mit den Komponenten vertraut sind, wie gut sie darin Fehler finden, etc.

Da ich Grade am handy bin und keine Lust habe die Studien alle rauszusuchen, hier mal woran ich mich erinnere:
Moderne OOP sprachen sind produktiver und weniger fehleranfällig als alte prozedurale sprachen. Insbesonders C++ gewinnt gegen C ziemlich eindeutig.
Moderne prozedurale bzw. Hybrid sprachen wir go oder rust sind aber wiederum besser als ältere OOP sprachen wir C++ oder Java. Moderne OOP sprachen wie swift oder kotlin sind aber auch besser als alte OOP sprachen wie Java oder Objective C.
Aber grundsätzlich kann man sagen, modernere sprachen sind oftmals besser als ältere, was ja auch zu erwarten ist, da moderne sprachen von den fehlern der alten Sprachen lernen, während ältere sprachen wegen rückwärts Kompatibilität die alten Laster nicht einfach ablegen kann

Am interessantesten fand ich eine Studie die praktisch sich angeschaut hat wie einfach es ist mit Komponenten mit verschiedener Vererbungstiefe zu arbeiten. Ergebnisse waren das bis zu 3 Level an Vererbung die wartbarkeit von code erhöht, während es danach runter geht und Komponenten mit Vererbungstiefe von 5 sogar schlechter sind als welche ohne Vererbung. Grund dafür ist das man ab einer gewissen Ebene nicht mehr zuordnen kann welcher code wo ausgeführt wird.

Das ist übrigens auch genau der Effekt warum viele Sprachen von Vererbung auf Komposition wechseln. Komposition vermeidet diese ewig langen Vererbungshierarchien und abstrakte Methoden. Man gewinnt die Kapselung, ohne das man durch die Eingeweide der Vererbungshierarchie sich wühlen muss um rauszufinden was wann ausgeführt wird

Sonstige interessante Erkenntnisse, wenn man sich durch die Literatur wühlt:
Funktionale sprachen verkürzen Entwicklungszeit und Anzahl Fehler sehr stark (Eriksson hat einen produktivitatsboost von Faktor 4-10 gemessen), und werden daher sehr gerne für prototypische Entwicklung verwendet.

Statische Typisierung Gegenüber dynamischer Typerkennung (wie in vielen scriptsprachen) reduziert massiv die Fehlerquote.
Compilezeit polymorphismus (z.b. generics, Funktionsüberladung, etc.) reduziert Fehler Gegenüber Laufzeit polymorphismus (Vererbung, if-then-else), und generell mehr statische Compiler Checks bedeuten normalerweise weniger Fehler

[Warf]

Ohne OOP sind wirklich komplexe Projekte gar nicht mehr möglich.

Ballerspiele und so sind keine solchen.

Und nur so als Punkt, der Linux Kernel ist komplett in C geschrieben als nicht OOP und gilt generell als extrem sauberer code (was ich aus persönlicher Erfahrung sogar bestätigen kann, ist sehr einfach dort was zu finden und reinzukommen).

Und wenn ich mir so die credits von manchen AAA Ballerspiele anschaue, an denen z.t. hunderte Leute gearbeitet haben, würde ich die auch nicht als unkomplex bezeichnen. Tatsächlich sind große Spiele vermutlich mit die komplexeste Software auf dem Planeten.
Und lustigerweise sind spiele engines eine von den Sachen für die OOP wirklich ausgesprochen gut ist, und das wirklich eine der Domains ist in der OOP absolut unangefochten ist

[af0815]

OOP schön, gut und passt soweit - Nur die Kunst ist den Punkt zu finden, wo man OOP abbrechen sollte und zB. über Interfaces gehen soll. Oft ist es nötig ein redisign zu machen und das OOP aufzubrechen. Ist vom Gefühl her ähnlich wie bei der sinnvollen länge von Funktionen/Prozeduren. Jeder hat da andere Erfahrungswerte. Weil OOP alleine ist nicht die letze Weisheit alleine. Und vor allen Testbarkeit und Wartbarkeit sollte man dabei berücksichtigen.

[Niesi]

OOP schön, gut und passt soweit - Nur die Kunst ist den Punkt zu finden, wo man OOP abbrechen sollte und zB. über Interfaces gehen soll. Oft ist es nötig ein redisign zu machen und das OOP aufzubrechen. Ist vom Gefühl her ähnlich wie bei der sinnvollen länge von Funktionen/Prozeduren. Jeder hat da andere Erfahrungswerte. Weil OOP alleine ist nicht die letze Weisheit alleine. Und vor allen Testbarkeit und Wartbarkeit sollte man dabei berücksichtigen.

Das ist halt wie immer: Die vor der Tastatur Sitzenden müssen es richtig machen ...

Es ist absolut möglich, auch ohne OOP gute komplexe Software zu entwickeln, keine Frage. Das passiert allerdings sehr selten ...

Und klar, mit OOP kann der letzte Stuss zusammengebastelt werden - passiert auch. Zu oft.

Wenn ich an mein erstes Berechnungsprogramm für Schraubenverbindungen denke, dann bekomme ich Tränen in die Augen - weil es jetzt OOP gibt. Das habe ich im letzten Jahrtausend auf einem CPC 464 in Basic entwickelt. Hat funktioniert, aber möchte ich nicht wieder machen.

OOP ist eine sehr gute Möglichkeit, die Softwareentwicklung einfacher, sicher und übersichtlich zu gestalten - aber eben auch, das Gegenteil zu tun. Durch zum Beispiel sinnfrei viele Vorfahren oder unzählige abstrakte Methoden kann ich die Sourcen komplett undurchschaubar gestalten, da stimme ich Warf unbedingt zu.

Wie schon geschrieben: Die Entscheidung dazu wird von denen vor der Tastatur getroffen ...

[m.fuchs]

Ich bin grosser Fan von OOP. Aber in dem Punkt gebe ich Warf Recht. Da werden abstrakte Basisklassen definiert, von denen später abgeleitet wird. Nur vom Studium des Quellcodes alleine ist es dann fast unmöglich, den genauen Programmablauf zu ermitteln.
Erst wenn man im Debugger an entsprechenden Stellen Haltepunkte setzt und sich den Aufrufstack anschaut, kann man erkennen, welche Instanz da dann tatsächlich ans werkeln gekommen ist.

Aber einer bestimmten Projektgröße kommt man ohne vernünftige Architektur (und dazu gehört auch deren Dokumentation und Benennungs-Konventionen) nicht mehr weiter. Damit sollte sich die Frage welche Instanz jetzt die richtige ist leicht beantworten lassen.

[Mathias]

Tatsächlich sind große Spiele vermutlich mit die komplexeste Software auf dem Planeten.

CAD-Programme können da sicher auch trumpfen.

[m.fuchs]

Und wenn ich mir so die credits von manchen AAA Ballerspiele anschaue, an denen z.t. hunderte Leute gearbeitet haben, würde ich die auch nicht als unkomplex bezeichnen.

Die Frage ist wie viele davon sind Entwickler? Heutzutage brauchst du Massen von Grafikern, (Level-)Designern, etc.

[Warf]

Die Frage ist wie viele davon sind Entwickler? Heutzutage brauchst du Massen von Grafikern, (Level-)Designern, etc.

Red dead redemption 2, was ein Spiel mit relativ großem Profil und afaik eigener engine ist, hatte laut IMDb über 50 Entwickler.
Das gesagt, Level Designer und viele Leute aus dem art Department haben auch überlap mit Programmierern. Level progression konditionen, RP scripts, etc. Sind im Endeffekt auch nix anderes als programmlogiken nur eben in visuellen Editoren. Aber es ist ja egal ob man ein if-then-else schreibt oder konditionale blöcke in ein diagram einfügt, Logik ist die selbe am Ende

Und wenn man das alles zusammen nimmt kommt man ziemlich schnell in die hunderte

[Warf]

Aber einer bestimmten Projektgröße kommt man ohne vernünftige Architektur (und dazu gehört auch deren Dokumentation und Benennungs-Konventionen) nicht mehr weiter. Damit sollte sich die Frage welche Instanz jetzt die richtige ist leicht beantworten lassen.

Ich habe an genug großen "Enterprise" Projekten gearbeitet um zu wissen das Projekt Größe und Qualität der Dokumentation nicht unbedingt korreliert.
Gibt genug Projekte wo die Dokumentation nix anderes ist als ein leeres doxygen was auf dem Code selbst generiert wird mit ein paar nix sagen den doc Kommentaren die einen auch nicht weiter helfen

Tatsächlich ist schlechte Dokumentation eine Fehlerquelle für sich in größeren langlebigen Projekten, da outdatete Dokumentation den Entwickler zu falschen annahmen führen kann und damit Fehler machen kann.
Gibt einige Studien die zeigen das unter bestimmten Umständen nicht dokumentiert er Code besser wartbar ist als dokumentiert er Code

[Zvoni]

Tatsächlich ist schlechte Dokumentation eine Fehlerquelle für sich in größeren langlebigen Projekten, da outdatete Dokumentation den Entwickler zu falschen annahmen führen kann und damit Fehler machen kann.
Gibt einige Studien die zeigen das unter bestimmten Umständen nicht dokumentiert er Code besser wartbar ist als dokumentiert er Code

Es sei denn, du hast dann so Kommentare wie bei der berühmten "Fast Inverse Square Root"-Funktion von Quake
https://en.wikipedia.org/wiki/Fast_inverse_square_root

Code: Alles auswählen

float Q_rsqrt( float number )
{
	long i;
	float x2, y;
	const float threehalfs = 1.5F;

	x2 = number * 0.5F;
	y  = number;
	i  = * ( long * ) &y;						// evil floating point bit level hacking
	i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
	y  = * ( float * ) &i;
	y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//	y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

	return y;
}

Jedesmal wenn ich Zeile 10 sehe, bekomme ich nen Lachanfall

oder einen Kommentar aus dem Linux-Kernel in Datei "/drivers/video/backlight/pwm_bl.c" (war für Kernel 5.14)

Code: Alles auswählen

/*
     * If the driver is probed from the device tree and there is a
     * phandle link pointing to the backlight node, it is safe to
     * assume that another driver will enable the backlight at the
     * appropriate time. Therefore, if it is disabled, keep it so.
     */

"It's safe to assume".... muss wohl ein ehemaliger Microsoft-Mitarbeiter gewesen sein.....

[m.fuchs]

Aber einer bestimmten Projektgröße kommt man ohne vernünftige Architektur (und dazu gehört auch deren Dokumentation und Benennungs-Konventionen) nicht mehr weiter. Damit sollte sich die Frage welche Instanz jetzt die richtige ist leicht beantworten lassen.

Ich habe an genug großen "Enterprise" Projekten gearbeitet um zu wissen das Projekt Größe und Qualität der Dokumentation nicht unbedingt korreliert.
Gibt genug Projekte wo die Dokumentation nix anderes ist als ein leeres doxygen was auf dem Code selbst generiert wird mit ein paar nix sagen den doc Kommentaren die einen auch nicht weiter helfen

Da hab ich mich vielleicht ungenau ausgedrückt, aber Dokumentation im Architekturbereich ist (oder sollte) eher Documentation by Code (sein). Das hand-geschriebene Textdokumentation irgendwann "verrottet" ist natürlich ein Problem. Die nimmt man dann nur noch für Erklärungen und Begründungen (Stichwort: ADR).

Leider ist das aber nicht bei allen Projekten angekommen. Man sieht immer noch zuviel "Dokumentation" dieser Art:

typical_code_comment_2.jpg (91.14 KiB) 2530 mal betrachtet

[af0815]

m.fuchs

+1 !

hehe, you made my day, guy

.
.
.
Und wie soll man den Zusatztext im schnellen vorbeifahren lesen können. SCNR

[PascalDragon]

OOP schön, gut und passt soweit - Nur die Kunst ist den Punkt zu finden, wo man OOP abbrechen sollte und zB. über Interfaces gehen soll.

Interfaces zählen als Teil von OOP, da Interfaces letztlich nichts anderes als Objekte mit rein abstrakten Methoden sind.