Nachteile von OOP

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.