Unterschied zwischen objektorientierter und strukturierter Pogrammierung in C++

[otze2000]

Hallo,

ich programmiere noch in den Anfängen und so langsam bekomme ich den Durchblick.
Glaube ich. Ich denke die Überschrift sagt schon alles aber ich hab noch nicht so richtig geblickt wo die Grundlegenden Unterschiede sind.

Also soweit ich das bis jetzt verstanden habe sind bei der objektorientierter
grundlegende Funktionen in Klassen gepackt und bei strukturierter werden die Funktionen direkt "reingeschrieben"

Was gibt es da den noch so an grundsätzlichen Unterschiede.

Also bis zur Antwort

Markus

[thordk]

OO ist ne andere herangehensweise an probleme als rein funktionale programmierung. einfach alle methoden in irgendwelche klassen zu kloppen ist noch kein OO. lies mal paar tutorials zu dem thema, ist schwer in zwei sätze zu packen

[Werner Salomon]

Diese Frage ist nicht so einfach zu beantworten. Oder anders gesagt: man braucht vielleicht lange Zeit - bzw. viel Erfahrung - bis man die Antwort wirklich versteht.

Ich will's mal von einer etwas anderen Seite probieren. Mal angenommen, Du hast einen Haufen Software, die zusammenarbeitet - gemeinhin als Programm bekannt. Dieser Haufen ist aber noch nicht fertig, sondern existiert nur in Deiner Vorstellung. Und um der Sache Herr zu werden, denkst Du darüber nach, aus welchen Teilen die Software besteht.

Es gibt jetzt die unterschiedlichsten Möglichkeiten diesen diffusen Haufen aufzuteilen - oder besser gesagt, zu organisieren und zu strukturieren. Genauso wie man ein Blatt beschriebenes Papier mit senkrechten oder waagerechten Schnitten zerschneiden kann.

Eine Möglichkeit ist es, die Software in Eingabe, Ausgabe und Verwaltung aufzuteilen. Oder man unterteilt erstmal in Daten und Funktionen. Für die Daten denkt man sich Strukturen (struct) aus und für die Funktionen eben Funktionen, die auf diesen Strukturen arbeiten.
Oder man unterteilt ganz anders, nach den sogenannten Entitäten. D.h. man sucht nach Dingen, die in der Modellwelt vorkommen. Die typischen Beispiele sind z.B. Konten, Konteninhaber und Transaktionen bei einem Bankprogramm oder Motor, Lenkung und Getriebe bei einer Autosimulation.

Wenn man sich überlegt, dass jede Entität über eine Eingabe, Ausgabe und Verwaltung verfügen kann und jede Entität sowohl Daten als auch Funktionen beinhaltet, so wird vielleicht klar, dass beide Arten der Aufteilung des Gesamtproblems quasi orthogonal aufeinander stehen. Und genau das macht den Unterschied zwischen strukturierter und objektorientierter Programmierung aus.

Gruß
Werner

[C++ Forumbot]

Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

[halloich]

Ähm, objektorientierte Programmierung schließt doch strukturierte Programmierung ein. http://de.wikipedia.org/wiki/Strukturierte_Programmiersprache

[Kenner der Scene 2]

halloich schrieb:

Ähm, objektorientierte Programmierung schließt doch strukturierte Programmierung ein. http://de.wikipedia.org/wiki/Strukturierte_Programmiersprache

Neinein, in C++ sollte man besser nicht strukturiert programmieren.

[Wesley67]

Einfach gesagt, liegen bei der strukturierten Programmierung Daten und Funktionrn offen herum, während bei der OOP die Sachen gekapselt sind - d.h. konkret: die Funktionen sind an die Daten gebunden, die sie ver-/bearbeiten sollen.

OOP bietet damit die Grundlage der modularen Programmierung. Objekte können verhindern, dass Daten falsch behandelt oder verarbeitet werden, weil sie die dazu nötigen Funktionen bereits selbst mitbringen. Die Daten sind somit auch gekapselt und von aussen her nicht willkürlich manipulierbar.

Objekte können einfacher erweitert werden. Nimm zum Beispiel einen Taschenrechner A mit den 4 Grundrechenarten als ein Objekt an. Ein wissenschaftlicher Taschenrechner B wird auch ein eigenes Objekt sein, baut aber zu 100% auf dem Taschenrechner A auf, erbt also praktisch alle Eigenschaften und Methoden von ihm. Einige Dinge muss man vielleicht anpassen, wie die Anzeige zum Beispiel, aber trotzdem beleibt die interne Funktionsweise von Taschenrechner A unverändert. Man braucht nicht nochmal alles neu zu erfinden, sondern erweitert einfach ein bestehendes Objekt, ohne es zu verändern.

[halloich]

Kenner der Scene 2 schrieb:

halloich schrieb:

Ähm, objektorientierte Programmierung schließt doch strukturierte Programmierung ein. http://de.wikipedia.org/wiki/Strukturierte_Programmiersprache

Neinein, in C++ sollte man besser nicht strukturiert programmieren.

Also, so wie ich das verstanden habe, geht es bei der Strukturierten Programmierung darum, dass der Programmablauf strukturiert ist. Also keine goto, sondern Schleifen und Funktionen mit klaren Ein- und Ausgängen. So ist aber jede Methode einer Klasse doch auch aufgebaut.

[nep]

Letztendlich kommt es sowieso darauf an, wie man herangegangen ist, sprich wie man das ganze "designt" hat.
Man kann z.B. durchaus auch ohne OOP einige Design Patterns (welche ja wohl schon für gutes OOP stehen) implementieren, d.h. OOP an sich heißt noch lange nicht, dass man etwas gut programmiert hat. Es macht einem das Leben allerdings schon einfacher.

[Strukturierte Begründung]

halloich schrieb:

Kenner der Scene 2 schrieb:

halloich schrieb:

Ähm, objektorientierte Programmierung schließt doch strukturierte Programmierung ein. http://de.wikipedia.org/wiki/Strukturierte_Programmiersprache

Neinein, in C++ sollte man besser nicht strukturiert programmieren.

Also, so wie ich das verstanden habe, geht es bei der Strukturierten Programmierung darum, dass der Programmablauf strukturiert ist. Also keine goto, sondern Schleifen und Funktionen mit klaren Ein- und Ausgängen. So ist aber jede Methode einer Klasse doch auch aufgebaut.

Strukturierte Programmierung: Jede Funktion nur ein return, gar kein break, und am besten nur while.

Objektorientiertes C++: So viel return wie möglich, break is aber auch OK.

Grund: In C++ gibts DDESTRUKTOOREN! In Pascal nicht.

[loks]

Strukturierte Begründung schrieb:

Objektorientiertes C++: So viel return wie möglich,...

Schwachfug. Sowas führt früher oder später nur zu beschissenem Code. EIN return pro Funktion sollte die Regel sein, mehrere nur eine Ausnahme. VIELE returns in einer Funktion = schlechtes Design. (Ausnahme es ist ein switch wo pro case ein return steht)

Daher, wenn überhaupt: So viel return wie NÖTIG... und nicht mehr.

Abgesehen davon, was hat das mit Destruktoren zu tuen? Die retten Dich auch nicht vor schlechtem Code... Beispiel:

int func()
   char* x = new char[10000];

   if( wasauchimmer==true)
   {
      return;
   }

   delete x;

   return;
}

[halloich]

Strukturierte Begründung schrieb:

Strukturierte Programmierung: Jede Funktion nur ein return, gar kein break, und am besten nur while.

Objektorientiertes C++: So viel return wie möglich, break is aber auch OK.

Ich dem Wikipedia Artikel steht:

Beispiele für strukturierte Programmiersprachen [Bearbeiten]

* Algol
* C

und in C kann ich auch mehrere return in eine Funktion einbauen.

Was ich eher als Problem sehe, ist das werfen von Exceptions, weil man damit den strukturierten Ablauf aufbrechen kann und fast wie beim goto plötzlich ganz wo anders sein kann.

Grund: In C++ gibts DDESTRUKTOOREN! In Pascal nicht.

Was soll das für ein Grund sein. In Java gibts auch keine.

[ganztoll]

halloich schrieb:

Grund: In C++ gibts DDESTRUKTOOREN! In Pascal nicht.

Was soll das für ein Grund sein. In Java gibts auch keine.

Java ist ja auch keine C++-artige Objektorientierung.

[halloich]

ganztoll schrieb:

halloich schrieb:

Grund: In C++ gibts DDESTRUKTOOREN! In Pascal nicht.

Was soll das für ein Grund sein. In Java gibts auch keine.

Java ist ja auch keine C++-artige Objektorientierung.

Och ne, jetzt unterscheidet sich objektorientiertes und strukturiertes Programmieren auch noch von Sprache zu Sprache.

[Konrad Rudolph]

Strukturierte Begründung schrieb:

Grund: In C++ gibts DDESTRUKTOOREN! In Pascal nicht.

Das ist nicht OO sondern RAII.

[nep]

halloich schrieb:

Was ich eher als Problem sehe, ist das werfen von Exceptions, weil man damit den strukturierten Ablauf aufbrechen kann und fast wie beim goto plötzlich ganz wo anders sein kann.

Unsinn.

[halloich]

nep schrieb:

halloich schrieb:

Was ich eher als Problem sehe, ist das werfen von Exceptions, weil man damit den strukturierten Ablauf aufbrechen kann und fast wie beim goto plötzlich ganz wo anders sein kann.

Unsinn.

Was Wann Wo???

[Konrad Rudolph]

halloich schrieb:

nep schrieb:

halloich schrieb:

Was ich eher als Problem sehe, ist das werfen von Exceptions, weil man damit den strukturierten Ablauf aufbrechen kann und fast wie beim goto plötzlich ganz wo anders sein kann.

Unsinn.

Was Wann Wo???

Du meintest, Exceptions seien unstrukturiert. Das Konzept heißt aber nicht ohne Grund „strukturierte Ausnahmebehandlung“.

[halloich]

Konrad Rudolph schrieb:

halloich schrieb:

nep schrieb:

halloich schrieb:

Was ich eher als Problem sehe, ist das werfen von Exceptions, weil man damit den strukturierten Ablauf aufbrechen kann und fast wie beim goto plötzlich ganz wo anders sein kann.

Unsinn.

Was Wann Wo???

Du meintest, Exceptions seien unstrukturiert. Das Konzept heißt aber nicht ohne Grund „strukturierte Ausnahmebehandlung“.

Naja, man kann ja nicht wieder nach oben springen und wenn mas es so sieht, dass sie von Methode zu Methode weiter geworfen werden, dann kann man schon sagen, dass sie strukturiert sind. Aber ein bisschen was von einem "goto next error label" haben sie schon.

[Konrad Rudolph]

halloich schrieb:

Naja, man kann ja nicht wieder nach oben springen und wenn mas es so sieht, dass sie von Methode zu Methode weiter geworfen werden, dann kann man schon sagen, dass sie strukturiert sind. Aber ein bisschen was von einem "goto next error label" haben sie schon.

Nicht mehr oder weniger, als ein 'if' oder ein 'for' etwas von 'goto label' haben.