Nachteile von OOP

Ich lese gerade den Artikel über die Objektorientierte Programmierung und mich würde intereressieren was ihr von den Nachteil von OOP haltet. Also im speziellen geht es mit um diese Abschnitte des Wikipedia-Artkels hier:

OOP und Kontrollfluss

Häufig genannte Vorzüge des OOP-Paradigmas sind eine verbesserte Wartbarkeit und Wiederverwendbarkeit des statischen Quellcodes.[10] Hierzu werden jedoch die Kontrollflüsse und das dynamische Laufzeitverhalten den Daten/Objekten im Allgemeinen untergeordnet, abstrahiert und weggekapselt. Die Kontrollflüsse bilden sich nicht mehr für den Entwickler transparent direkt in den Codestrukturen ab (wie z. B. bei prozeduralen Sprachen), eine Umsetzung in dieser Hinsicht wird dem Compiler überlassen. Hardware-nähere Sprachen wie das prozedurale C oder Assembler bilden den echten Kontrollfluss und das Laufzeitverhalten transparenter ab.[11] Mit der wachsenden Bedeutung von paralleler Hardware und nebenläufigem Code wird jedoch eine bessere Kontrolle und Entwickler-Transparenz der komplexer werdenden Kontrollflüsse immer wichtiger – etwas, das schwierig mit OOP zu erreichen ist.[12][13]
OOP und relationale Datenbanken

Ein häufig genannter Bereich, in dem OOP-Techniken als unzureichend gelten, ist die Anbindung von relationalen Datenbanken. OOP-Objekte lassen sich nicht direkt in allen Aspekten mit relationalen Datenbanken abbilden. Umgekehrt können über OOP die Stärken und Fähigkeiten von relationalen Datenbanken ebenfalls nicht vollständig ausgeschöpft werden. Die Notwendigkeit, eine Brücke zwischen diesen beiden Konzeptwelten zu schlagen, ist als object-relational impedance mismatch bekannt. Hierzu existieren viele Ansätze, beispielsweise die häufig verwendete objektrelationale Abbildung, jedoch keine allgemeingültige Lösung ohne den einen oder anderen Nachteil.[14]
Laufzeitverhalten und Energieeffizienz

Die Effektivität des Laufzeitverhaltens von Anwendungen, die auf OOP-Techniken basieren, wird seit jeher kontrovers diskutiert. Alexander Chatzigeorgiou von der Universität Makedonien verglich die Laufzeiteffektivität und die Energieeffizienz von typischen Algorithmen (Gauß-Jordan-Algorithmus, Trapez-Integration und QuickSort) von prozeduralen Ansätzen und OOP-Techniken, implementiert als C- und C++-Software. Auf dem verwendeten ARM-Prozessor ergab sich für drei Algorithmen im Mittel eine um 48,41 % bessere Laufzeiteffektivität mit den prozeduralen C-Algorithmusvarianten. Es ergab sich außerdem eine im Mittel um 95,34 % höhere Leistungsaufnahme der C++-Varianten zu den C-Varianten.[15] Für Anwendungen auf mobilen Geräten, wie Handys oder MP3-Spielern mit begrenzten Leistungs- und Energiespeichervermögen, sind derartige Unterschiede signifikant, allerdings machen derartige Algorithmen in der Regel nur einen Bruchteil der Applikationen aus. Als Grund für den Unterschied in Effektivität und Energieeffizienz werden in dem Artikel generelle Abstraktions-Leistungseinbußen und die deutlich größere Anzahl von Zugriffen auf den Arbeitsspeicher durch OOP-Techniken genannt.
Kritik
Modularisierung und andere Prinzipien nicht ausgereift

Luca Cardelli untersuchte 1996 für das DEC Systems Research Center die Effizienz von OOP-Ansätzen in dem Artikel Bad Engineering Properties of Object-Oriented Languages mit den Metriken Programmablaufgeschwindigkeit (economy of execution), Kompilationsgeschwindigkeit (economy of compilation), Entwicklungseffizienz für große und kleine Teams (economy of small-scale development und economy of large-scale development) und die Eleganz des Sprachumfangs selbst (economy of language features). Er kam zu dem Schluss, dass das objektorientierte Sprachdesign noch viel aus dem prozeduralen Sprachendesign lernen müsste, insbesondere im Bereich der guten Modularisierung, der Datenabstraktion und des Polymorphismus, um die hochgesteckten Erwartungen zu erfüllen.[16]
Keine Erhöhung der Produktivität gegenüber prozeduralen Ansätzen

Eine Studie von Potok et al. aus dem Jahre 1999 zeigte keine signifikanten Produktivitätsunterschiede zwischen OOP und prozeduralen Ansätzen.[17]

Die Autoren definieren „Produktivität“ in der Einheit „Entwickelte/Geänderte Programmzeilen pro Zeiteinheit“ und untersuchen insbesondere den Einfluss von Code Reuse auf diese Metrik. Sie weisen darauf hin, dass eine Konzentration auf Code Reuse unter Umständen der objektorientierten Programmierung nicht gerecht wird, da sie sich noch auf andere Weisen positiv auf die Produktivität auswirken könnte (beispielsweise durch ein einfacheres Design).

Die Autoren führen mehrere Gründe an, weshalb die Ergebnisse ihrer Studie verzerrt sein könnten:

Es könnte sein, dass als „objektorientiert“ deklarierte Software in Wirklichkeit prozedural entwickelt wurde.
Sie analysierten nur zwei Generationen objektorientierter Software, was ihrer Aussage nach zu wenig sein könnte.
Es könnte sein, dass die Qualifikation der verschiedenen Entwicklungsteams unterschiedlich war. Insbesondere wäre es möglich, dass die objektorientierte Software von geringer qualifizierten Teams entwickelt wurde.

Die Autoren vertreten die Meinung, diese Punkte träfen nicht zu.

Marthog

Kann ich nachvollziehen und aus diesem Grunde halte ich mich auch vom "rein objektorientierten" fern.
Das Problem ist, dass Objektorientierung auf sehr gute Dokumentation angewiesen ist, weil man bei grossen Strukturen auf mehreren Objekten immer wieder die Querbeziehungen zwischen verschiedenen Objekten hat.

Bei Containerklassen ist OOP sehr gut. Man trennt die Anordnung der Daten vom Inhalt und kann dadurch sehr einfach einen Container durch einen anderen ersetzen. Bei anderen Dingen entsteht aber viel Mist.

Danke und ich dachte schon, dass ich der einzige bin dem es schwer fällt in einem Quellcode mit viel OOP den Überblick zu bekommen. Wenn ich den Artikel also recht verstehe, dann:

- ist OOP wirklich meist schwerer zu durchschauen.
- bringt OOP Performanceverluste bzw. erhöhten Leistunganspruch mit sich, ohne dabei die Wiederverwertbarkeit im Vergleich zu anderen Paradigmen zu erhöhen.
- es können wohl auch gar nicht alle Probleme mit OOP abgebildet werden(Elipse-Kreis-Problem)

Also ist es gar nicht immer angebracht alles in OOP zu machen?

Marthog

NochEineFrage schrieb:

Danke und ich dachte schon, dass ich der einzige bin dem es schwer fällt in einem Quellcode mit viel OOP den Überblick zu bekommen. Wenn ich den Artikel also recht verstehe, dann:

- ist OOP wirklich meist schwerer zu durchschauen.
- bringt OOP Performanceverluste bzw. erhöhten Leistunganspruch mit sich, ohne dabei die Wiederverwertbarkeit im Vergleich zu anderen Paradigmen zu erhöhen.
- es können wohl auch gar nicht alle Probleme mit OOP abgebildet werden(Elipse-Kreis-Problem)

Also ist es gar nicht immer angebracht alles in OOP zu machen?

1. U.A. bei GUIs hat man die schoene Analogie, dass jedes GUI-Element auch ein Objekt ist. Ebenso bei Containern: Man hat ein Containerobjekt, dass voellig unabhaengig vom Inhalt lediglich den Speicher verwaltet und darin befindet sich eine Menge von Objekten. Das ist wesentlich uebersichtlicher als alle Alternativen.

2. Richtig gemacht erhoeht OOP Wiederverwertbarkeit und Performance, z.B. erspart man sich durch eine generische Hashtable die mehrfache implementierung und kann diese eine dafuer nebenbei ausreichend testen und auf performance optimieren.
Wenn man alles ueber Type erasure macht, baut man sich natuerlich zusaetzliche Indirektionen ein. Leider bevorzugt der quasi-standard Java und damit ein Grossteil der Programmierer diese falsche Vorgehensweise.

3. Objekte stellen nur die Datenstruktur dar, aber nicht den Algorithmus. Methoden sind ja nicht anders als freie Funktionen mit zusaetzlicher und teilweise impliziter this- oder self-Referenz und koennen dementsprechend den gleichen Code enthalten. Das Elipse-Kreis-Problem tritt ausserdem nur bei mutable-Objekten auf, also laesst es sich sehr wohl umgehen.

Bashar

Containerklassen haben jetzt mit OOP nicht wirklich viel zu tun... das sind abstrakte Datentypen. Natürlich realisiert man die in einer OOP-Sprache mit Klassen und Objekten. Es wäre* traurig, wenn solche Serviceklassen das beste Argument für OOP wären.

bzw. ist, aber so weit häng ich mich jetzt mal nicht aus dem Fenster...

Marthog

Bashar schrieb:

Containerklassen haben jetzt mit OOP nicht wirklich viel zu tun... das sind abstrakte Datentypen. Natürlich realisiert man die in einer OOP-Sprache mit Klassen und Objekten. Es wäre* traurig, wenn solche Serviceklassen das beste Argument für OOP wären.

bzw. ist, aber so weit häng ich mich jetzt mal nicht aus dem Fenster...

Im Prinzip geht das alles auch prozedural, aber mir ist jetzt aber keine prozedurale Sprache bekannt, die solche generischen Funktionen anbietet, insofern kann ich nicht bewerten, ob der Code trotzdem noch uebersichtlich ist. Go macht das zwar so aehnlich, hat aber map und string als eingebaute Datentypen mit operatoren dabei und hat auch sonst nur eingeschraenkt generische Typen.
In Haskell gibt es das zwar alles, aber es ist halt auch was voellig anderes und damit kaum vergleichbar.

Gregor

Bashar schrieb:

Containerklassen haben jetzt mit OOP nicht wirklich viel zu tun... das sind abstrakte Datentypen. Natürlich realisiert man die in einer OOP-Sprache mit Klassen und Objekten.

Ich finde schon, dass man einen starken Bezug zwischen abstrakten Datentypen und OOP sehen kann. Ich meine, die Objektorientierung bietet einem konzeptuell eine sehr direkte Umsetzung von abstrakten Datentypen.

Nicht jeden Programmiersprache die OOP anbietet arbeitet auch mit Klassen.

Wie programmiert man etwas prozedural und nicht OOP? Wenn ich irgendeine Listen Klasse habe, sieht das prozedural doch auch nicht viel anders aus. Die Klasse ist dann eine andere Datenstruktur und die Methoden sind Funktionen die diese Datenstruktur als Parameter bekommen. Eigentlich nur ein bischen andere Schreibweise aber nichts groß unterschiedlich.

volkard

malsogefragt schrieb:

Wie programmiert man etwas prozedural und nicht OOP?

Da verweise ich mal auf MMIXWare.

Mechanics

NochEineFrage schrieb:

Danke und ich dachte schon, dass ich der einzige bin dem es schwer fällt in einem Quellcode mit viel OOP den Überblick zu bekommen.

Gerade das ist für mich überhaupt kein Argument (für/gegen OOP). Komplexe Software ist komplex. Natürlich kann es schon mal passieren, dass man bei einem Programm, in dem man sich nicht 100% auskennt, an einen Punkt kommt, wo ein virtual function call ist und man sich denkt, Mist, wo gehts denn hier jetzt weiter??? Ja und? Sowas wäre auch "nicht-objektorientiert" nicht einfacher. Ich rede jetzt nicht unbedingt von diesen typischen Java Projekten wie Tomcat, wo man irgendwo bei einer Exception landet und der Callstack 300 Aufrufe enthält, weil alles an irgendwelche Schnittstellen immer weiter delegiert wird. Aber bei einem halbwegs vernünftigen Aufbau ist der nicht sofort durchschaubare OOP Overhead mit einer zusätzlichen Flexibilität verbunden, und dann kann man viele zusätzliche Anforderungen völlig transparent lösen, ohne dass der Code voll von Sonderfällen wäre. Das ist dann nämlich meist die Alternative, die sich die Leute vorstellen, die meinen, sie würden in OOP Code den Durchblick verlieren.

TyRoXx

Ich habe die Vor- und Nachteile von OOP mal kurz zusammengefasst:

struct klass
{
  int a;
};

void add(klass *k, int b)
{
  k->a += b;
}

voll schnell
voll Profi-mäßig in C-Style
nicht OOP

class klass
{
public:
  //! \brief adds a number
  //! \param b a number
  //! \returns void
  void add(int b)
  {
    a += b;
  }

private:
  int a;
};

leicht zu verstehen und zu dokumentieren
mit OOP
0% Fett
leider 27,64129% langsamer :p

hustbaer

häö? schrieb:

TyRoXx schreibt öfter mal einfach so kompletten Topfen. Das musst du nicht verstehen denn da gibt's nichts zu verstehen.