Unterschied zwischen objektorientierter und strukturierter Pogrammierung in C++

[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.

[halloich]

Konrad Rudolph schrieb:

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.

Ein if und for kann ich noch in nem Struktogramm darstellen. Wie stellt man Exceptions strukturiert dar?

[Konrad Rudolph]

halloich schrieb:

Konrad Rudolph schrieb:

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.

Ein if und for kann ich noch in nem Struktogramm darstellen. Wie stellt man Exceptions strukturiert dar?

Gar nicht. Ist aber irrelevant: Wie stellt man Klassen und virtuelle Methodenaufrufe in einem Struktogramm dar? Ebenfalls nicht. Das Struktogramm ist in dieser Hinsicht einfach nicht vollständig. Trotzdem würde niemand auf die Idee kommen zu sagen, virtuelle Methodenaufrufe seien unstrukturiert.

[halloich]

Es geht ja nicht darum, dass es sowas im Struktogramm nicht gibt. Bei nem virtuellen Methoden Aufruf bin ich wieder genau da wo ich die Methode aufgerufen habe, wenn sie beendet wurde. Wenn aber ne Exception geworfen wurde, dann bin ich irgendwo wo die Exception gefangen wird und das kann einige Methoden weiter oben sein. Wenn man es so sieht, dass jede Methode die Exception "verarbeitet" und weiter wirft, dann kann man schon sagen, dass es einigermaßen strukturiert abläuft.

[rüdiger]

loks schrieb:

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)

In C++ kannst du doch eh nicht wirkliche den Programm Verlauf bestimmen, da Exceptions von jedem externen Programm-Code aufgerufen werden können oder schreibst du (hoffentlich nicht!!) deine Funktionen immer mit einem try/catch drum rum gewrapt?

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

Destruktoren ermöglichen dir hier automatische Ressourcenverwaltung. Aber klar, wenn jemand schlechten Code schreibt dann ist der Code schlecht.