Was sind die Vorteile der OOP vs. Prozeduraler Prog.?

Hi Zusammen,

habe bisher in C programmiert und möchte nun auf C++ umsteigen. Aber mal eine grundlegende Frage: Was sind eigentlich die Vorteile von objektorientierter Programmierung gegenüber prozeduraler Programmierung?

Thx
OOP-Newbie

gomberl

Eigentlich ist es die Aufteilung der Abläufe, die Wiederverwendbarkeit und die Darstellung der reelen Welt.

Mit Objekten kannst du die Umwelt (die das Programm unterstützt) darstellen und damit efiiziente und leichter lesbare und erweiterbare Software herstellen

Du wirst mit der Zeit merken das das ein großer Vorteil ist.

Gomberl

Beerbong

Der größte Vorteil der OOP ist sicherlich die kapselung von Daten, bzw. Programmcode.
Das heißt, du hast zB ein Objekt "Auto" und ein Objekt "Strasse".
Die Strasse muss sich nicht darum kümmern wie das Auto die Reifen bewegt,
und dem Auto ist egal ob die Strasse auf Zement oder Rasen gebaut ist.

Ausserdem entwickeln Objekte dank ihrer Konstuktoren und Dekonstruktoren sozusagen ein Eigenleben,
also Speicherfreigabe etc.

Sicherlich kann man auch ohne OOP (gut ?) gekapselte Programme schreiben,
aber bei der OOP wird man eben dazu gezwungen.

@DocJunior: Ich denke wenn man schon mal weiß was ein Struct ist, lernt man eigentlich recht schnell.
So ging's zumindest mir.

"...bei Spielen nur wenig..."
Hmm, kann ich nicht so viel zu sagen,
aber ist DirectX nicht auch OOP ?
Ich denke jedenfalls das ein Programm ohne Objekte nicht wesentlich schneller läuft.

Das Ding ist nur: Meistens greift man auf vorhandene Klassenbibliotheken zu (MFC, OWL...) zu.
Diese ganzen Klassen müssen natürlich in das Programm mit aufgenommen werden,
wodurch ein Programm nicht gerade kleiner und schneller wird.

Bjarne Stroustrup hat einen Artikel geschrieben, der besagt, dass OOP NICHT
langsamer ist.

Außerdem würden 10% heutzutage auch nichts ausmachen, da sich die Hardware schneller entwickelt als die Anforderungen, die an sie gestellt werden.

@gfx: Das mit der massenhaft vorhandenen Rechenleistung stimmt aber allenfalls beim "klassischen" Home-PC. Im Bereich der Embedded Systems wird nach wie vor mehrheitlich in reinem C (und Assembler natürlich) programmiert. Ich habe es noch nicht direkt vergleichen können, aber scheinbar ist das Kompilat aus C-Code eben doch um einiges effizienter als wenn man wirklich C++ nimmt.

------------------
mfg

Oxygenic

Visit http://www.AudioCutter.de

Zitat:

Original erstellt von Oxygenic:
**@gfx: Im Bereich der Embedded Systems wird nach wie vor mehrheitlich in reinem C (und Assembler natürlich) programmiert. Ich habe es noch nicht direkt vergleichen können, aber scheinbar ist das Kompilat aus C-Code eben doch um einiges effizienter als wenn man wirklich C++ nimmt.
**

@Oxigenic,
ich denke,daß sich der Verwaltungsaufwand fürs OO (Klassen, Polymorphismus, Überladung) im Ressourcenverbrauch und letztlich in der Geschwindigkeit niederschlagen muß. Einfache Überlegung wie baue ich einen Mechanismus wie Überladen von Operatoren in C nach.

@OOP-Newbie
Ab einer gewissen Projektgröße (hab mal eine Zeilenzahl gewußt) kann man mit OO einfach + besser + effizienter entwickeln.
Was ich elegant finde ist, das die Datenobjekte gleich ihre eigenen Operatoren/Methoden mitbringen, sowie ein int implizit +,-,+,/ besitzt. Also Datenkapselung und Klassen.

Die Konzepte der Vererbung, des Polymorhismus sind sehr mächtige Werkzeuge. So etwas in C nachzustellen, kostet viel Schweiß.

Zum Einstieg würde ich Dir empfehlen etwas zu OOD (Design)und OOP (Programmierung) zulesen.
Einer der Päpste ist Bosch. Ach ja und Stoustrup für C++ <g>
Jedenfalls findet sich eine Menge interessanter Lesestoff zu den Stichworten Objetorientiertes Programmieren un Design im Netz
Eine spezielle Einführung für erfahrene C-Programmier findet sich bei http://info.baeumle.com/cplusplus/index.html
(Vorsicht das Ding ist ein Teebeutel: viel heißes Wasser(== Schweiß) gibt einen guten aromatischen Tee)
oder http://www.uni-koeln.de/RRZK/kurse/unterlagen/CPPKURS/

Ach ja noch ein Tip,vermeide die ekligen Mischungen aus C und C++-Elementen. Also wenn man schon Objekt nutzt wie cin benutzt, dann sollte man fopen und Gefolge vergessen und die entsprechenden C++-Objekte bemühen.
Ein schleichender Übergang ist zwar möglich. Besser ist jedoch ein Neuanfang.
Und wenn es ganz hart wird, immer daran denken:C++ ist der eleganteste Präprozessor der Welt für C.
So log
w

Danke an alle. Jetzt sehe ich schon ein bissl klarer.
@write
Danke für die Links. Werd sie mir gleich mal ansehen.

Gruß
OOP-Newbie

tunichtgut

Es ist wohl die allgemeine meinung das C für strukturierte programmierung und C++ für OOP steht. Naja, es ist nicht unbedingt ganz richtig.

Zuerst einmal kann ich in C++ hervorragend struktutiert programme schreiben. Alles OOP-relevante kann ich weglassen, C und C++ programme sollten sich dann in größe und laufzeit nicht oder nur unwesentlich unterscheiden (hängt eher vom compiler ab).

Auf der anderen seite kann ich OOP in eingeschränkter form auch unter C programmieren. Der typ struct ist vorhanden und sogar polymorphie kann man über funktionszeiger selber implementieren. Bei konstruktoren und destruktoren sieht es schon schlecher aus. Es ist halt die frage wie weit ich gehen kann. Die ersten C++ compiler waren auch nur pre-compiler, die den C++ code in C code übersetzt haben. Dieser konnte dann von einem 'richtigen' C compiler zu einem lauffähigen programm übersetzt werden. Viele programme die in C geschrieben wurden beruhen tatsächlich auf (minimalen) objektorientierten ansätzen. Ein beispiel dafür ist die FILE-struktur. Es gibt methoden zum erzeugen, manpulieren, datenübergabe usw. , vieles also was OOP ausmacht. Alles aber in sehr eingeschränkter form.

C bietet nur nicht so viele möglichkeiten wie C++ für eine effektive OOP-programmiertechnik.

Viele neue möglichkeiten unter C++, die man mit OOP in verbindung bringt, sind nicht OOP-typisch. Das überladen von funktionen und operatoren ist z.b. keine typisch OOP-sache. Es ist nur unter C nicht möglich. Es ist nicht in die compiler eingebaut worden, warscheinlich um abwärtskompatibel (vor allem in den libs und objects, stichwort: name mangling) zu bleiben. Auch das prinzip der templates; eigentlich nicht OOP, naja solange keine klassen beteiligt sind. Aber eine einfache templatefunktion wie max<T> z.b. wäre auch unter C denkbar - geht aber nicht weil das kein compiler kann.

Warum sind programme die mit C++ und seinen OOP ansätzen geschrieben wurden meistens langsamer und größer als die von C ? In C++ wird vieles automatisch erzeugt, durchgeführt und angelegt, was vieleicht garnicht notwendig ist. Ein guter optimierer kann allerdings an dieser stelle viel bewegen. Und da wie gerade beim optimieren sind - in einer prozedualen umgebung ist es meist einfacher als in einer objektorientierten. Viele C++ compiler sind in dieser hinsicht nicht so weit wie die meisten C compiler. Will ich unter C++ ein framework oder eine bibliothek benutzen soll diese benutzung einfach und intuitiv sein. Auch das wird meist mit einem mehraufwand bei der implementation und demzufolge auch meist mit mehraufwand an rechenzeit erkauft. Als letzter punkt ist noch anzumerken, das viele standardbibliotheken aus C++ von denen aus C abgeleitet wurden (bzw. noch sind). Es wurde nur ein überwurf über die C-funktionen gelegt, was natürlich wieder rechenzeit kostet. Ein paradebeispiel ist hier printf() und cout. Die benutzung von printf() läuft unter den meisten systemen schneller als die von cout aus dem grund, weil cout nur nach printf() umgeleitet wird. Dabei sollte cout potentiell schneller sein! Bei printf() muß erst der formatstring zur laufzeit ausgewertet werden, was wirklich sehr aufwendig ist. Das wäre für cout garnicht notwendig, der compiler weiß ja schon während der laufzeit wie die ausgabe zu behandeln ist. Das sollte bei richtiger programmierung (und nicht nur umleitung) auf jeden fall schneller sein.

Im allgemeinen gilt, das in ca 20% des sources ca. 80% der rechenzeit verbracht wird. Es gibt auch beispiele mit anderen größenordnungen, aber es geht hier eher um das ungefähre verhältnis. Es bringt nichts überall auf absolute effizienz hin zu programmieren. Man muß die richtigen stellen finden, wo wirklich einsparungen etwas bringen. In bestimmten fällen (gerade bei hochperformanten systemen) ist es sicher notwendig die pfade der OOP manchmal zu verlassen und entsprechend zu 'tricksen' evtl. ein paar zeilen assembler-code einfügen. Aber große projekte (auch spiele wie z.b. Black&White...) sind ohne objetorientierte basis kaum zu bewältigen. Und wie schon bemerkt wurde , DirectX ist auch OOP.

Es gibt heute kaum ein größeres projekt, was nicht im rahmen von OOP entwickelt wird. Embedded systeme gehören in der hinsicht eher zu den kleinen projekten. Sie sind meißt noch sehr überschaubar und daher auch meiß kein problem strukturiert zu programmieren.

Das OOP zu größeren und langsameren programmen führt, muß heutzutage eigentlich nicht mehr sein, aber es wird wohl noch etwas dauern, bis dieser zustand erreicht ist. Der RICHTIGE einsatz von OOP zahlt sich aber trotzdem heute schon aus.