Objektorientierung vs. (z.B.) Prozeduale Programmierung

Neue Frage »

Auf diesen Beitrag antworten »
Robert93 Objektorientierung vs. (z.B.) Prozeduale Programmierung

Meine Frage:
Hallo Leute,

möglicherweise ist die Frage die ich hier gleich stelle kompletter nonsense aber ich würde das schon gerne grundsätzlich verstehen:

Ich habe in der Vergangenheit C gelernt und nun habe ich mit JAVA angefangen.
Ebenso meine ich auch verstanden zu haben welche Philosophie hinter objektorientierter Programmierung steckt.

Meine Frage ist nun:
Welchen "Vorteil" erkauft man sich nun bei der Benutzung von OOP?
Steckt mehr dahinter als einfach nur "platzsparender" zu programmieren?

Gibt es Programme die nur mit OOP programmierbar sind und dafür absolut unmöglich wenn es prozedual geschrieben wird?
Oder vielleicht doch, aber mit immensen aufwand? (Also mehr Code-Zeilen?)



Meine Ideen:
Bitte diese Frage aus Sicht eines kompletten Anfängers betrachten.
Meine Zeiten mit C liegen lange zurück und auch da nur absolute basics.
 
Auf diesen Beitrag antworten »
as_string

Hi!

Mit platzsparend hat das nicht viel zu tun. Erstmal schreibt man ja auch viel mehr Code sogar. Ich hab da zwar noch keine Studien oder ähnliches dazu gesehen, aber ich würde gefühlt sagen, dass wenn man ein und dasselbe Programm einmal objektorientiert und einmal prozedural schreibt, meistens die OOP-Version länger sein wird.
Es geht auch nicht darum, dass man irgendetwas mehr machen könnte, was ohne OOP nicht oder nur schwer machbar wäre. Programmieren kann man an sich in jeder Programmiersprache alles. Der einzige Unterschied mag sein, wie stark man auf die Hardware zugreifen kann oder auch Teile des Betriebssystems und so. Aber das hat nichts mit der Art zu Programmieren zu tun.

Es geht (in meinen Augen zumindest...) nur um Wartbarkeit bei tendenziell größeren Projekten, die über einige Zeit weiter entwickelt und gepflegt werden müssen. Dabei hat man solche Effekt wie:
  1. Änderungen an einer Stelle können zu Fehlern an ganz anderen Stellen des Programms führen
  2. Wenn man Dinge erweitern will, braucht man Wissen darüber, wie Details im bisherigen Code implementiert wurden
  3. Wenn viele Leute an einem Projekt arbeiten muss man häufig an derselben Datei was ändern, was zu Konflikten kommt, wenn man am Ende die parallelen Weiterentwicklungen wieder zusammen bringen will.
  4. Gleiche Programmlogik sollte man nur einmal schreiben müssen. Wenn ich z. B. eine abstrakte Datenstruktur habe, wie z. B. eine Liste von Dingen, dann gibt es dafür ja verschiedene Implementierungsmöglichkeiten mit unterschiedlichen vor und Nachteilen. An vielen Stellen des Codes will man solche Listen verwenden. Da ist es günstig, wenn man die Logik der Verwaltung einer solchen Liste allgemein programmieren kann, egal welche Art von Objekten in dieser Liste drin sind.

Da gibt es sicherlich noch einige Punkte mehr, aber diese 4 fallen mir gerade so im Moment ein. Teilweise überschneiden sich die Punkte in mancher Hinsicht auch. Sicherlich gibt es solche Listen von Motivationen für OOP im Internet schon sehr viele, die vermutlich besser ausgearbeitet sind. Du kannst ja mal Google benutzen.
Um den ersten Punkt in den Griff zu bekommen (aber auch wichtig für die anderen beiden Punkte), hat man sich in der OOP die Kapselung einfallen lassen: Daten und der Programmcode, der mit diesen Daten arbeitet, soll in einer Klasse direkt miteinander zusammen "verpackt" werden. Es gibt also eine abgeschlossene Einheit mit Daten und Code, der nach außen (also "public") ein klares Interface definiert hat, alles andere aber "private" ist, also von außen nicht erreichbar. So kann man sich sicher sein, dass Änderungen an den privaten Daten nur Änderungen innerhalb der eigenen Klasse erzwingen. So lange man das öffentliche Interface unverändert lässt, müsste der Rest vom Programm davon nicht betroffen sein. Aber auch der zweite Punkt wird dadurch unterstützt, weil man bei Erweiterungen nur das öffentliche Interface und nicht die internen Implementierungs-Details kennen muss, wenn man die Klasse in der Erweiterung verwenden will. Und der dritte Punkt kann dadurch auch unterstützt werden, weil die Dateien häufig kleiner sind (wenn nur immer eine Klasse drin definiert ist) und Themenbereiche besser gegeneinander abgegrenzt sind, so dass Änderungen aufgrund Weiterentwicklung im einen Bereich selten dieselben Klassen betreffen, wie andere Weiterentwicklungen zu ganz anderen Themen.
Ein weiterer Punkt ist die Vererbung: Durch eine kluge Klassen-Hierarchie kann man erreichen, dass das Programm leicht erweiterbar ist. Das Ziel ist es, dass man für viele Erweiterungen am bestehenden Code nichts ändern muss und möglichst noch nicht mal den bestehenden Code anschauen muss, außer die öffentlichen Interfaces. So kann man erreichen, dass mehr allgemeinere Klassen (häufig abstrakte Klassen dann) unabhängig erstellt, gepflegt, optimiert, etc. werden können von den spezielleren Klassen, die auf den allgemeinen aufbauen. Beides kann unabhängig voneinander entwickelt und gewartet werden.
Vererbung und Generics (in Java) oder Templates (in C++) unterstützen den letzten Punkt, dass man allgemeine Datentypen definieren kann, in denen aber unterschiedliche Arten von Objekten verwaltet werden können.

Also es geht insgesamt eher darum, wie man Code verwaltet und, besonders bei größeren Projekten an denen mehrere Leute arbeiten, eine Wartbarkeit und Erweiterbarkeit ermöglichen kann, ohne dass jeder den kompletten Überblick über alle Details benötigt.

Gruß
Marco
 
Neue Frage »
Antworten »


Verwandte Themen

Die Beliebtesten »
Die Größten »
Die Neuesten »