Nachteile von OOP

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.