Re: Aber,

ich denke, ich habe verstanden.
Bei der 'normalen' Programmierung ist es doch auch so,
daß ich verschiedene Unterprogramme zur Verfügung stelle, die
spezielle Teile der Software ausgliedert bzw. spezielle
Datenbereiche verarbeitet.

Hier hast du als Programmierer aber immer von überall Zugriff auf die Variablen, sei denn, du versteckst die Datenfelder gezielt, z.B. im "Implementationsteil" (der ist quasi nicht-öffentlich) eigener Bibliotheken, die vom Hauptprogramm eingebunden werden. Die Bibliothek "veröffentlicht" dann entsprechende Unterprogramme, die auf die Daten zugreifen können. Hier bleibt aber das Problem bestehen, daß bestimmte Daten "zusammengehören", so wie Position und Geschwindigkeit eines Fahrzeugs aus dem vorigen Beispiel, und auch zusammen prozessiert werden müssen. Jetzt kann man dazu entweder immer alle benötigten Parameter an die Routinen übergeben - dazu muß man immer wissen, welche - oder man definiert Verbunddaten-Strukturen (Records). Dann hat man wieder Probleme, wenn man eine Gruppe von Zügen verwalten will. Mit der Parameterübergabe von Gruppen ist dann die Kapselung nicht mehr gewährleistet, weil innerhalb der Routine Zugriff auf alle übergebenen Parameter besteht. Auch das läßt sich konventionell noch lösen, wird aber schon vertrackt.

Die Daten selbst werden in fachlich definierten Tabellen
abgelegt.
Das ist doch letztendlich fast
die gleiche Logik? Nur anders realisiert.

Sehr abstrakt gesehen hast du recht. Der Aufwand und die Übersichtlichkeit beider Vorgehensweisen ist jedoch nicht vergleichbar.

Wenn du nun ein Programm erhältst, daß schon eine Zugverwaltung realisiert und sollst es anpassen auf ein Zugsystem von Materialzügen in einem Logistikzentrum, fangen die wirklichen Probleme jedoch erst an. Es ist sehr schwer, dieses vorhandene Programm so umzustrukturieren, daß es den etwas anderen Anforderungen gerecht wird. Viel einfacher ist es, wenn du hergeht, die "Zugobjekte" nimmst und da nur die entsprechenden, neuen Eigenschaften dazuprogrammierst. Dazu kann dir der Quellcode für das Zugobjekt absolut egal sein - du muß ihn nicht kennen!

Das geht nun "konventionell" eben nicht. Dazu kommt noch, das hatte ich zuvor nicht erwähnt, die Möglichkeit der POLYMORPHIE (Vielgestaltigkeit). Sagen wir, das Objekt "Zug" hat die Methode "Abfahrt", die dafür sorgt, daß nach der Überprüfung Sicherheitsrelevanter Aspekte und des Status des betreffenden Haltesignals die Geschwindigkeit langsam auf die Reisegeschwindigkeit zu setzen. Betrachten wir die "sicherheitsrelevanten Aspekte". Die sind für jeden Zugtyp sicherzustellen, bei einem Personenzug sind es jedoch teilweise andere als für einen Güterzug. Eine Rangierstation oder ein Bahnhof, der viele Züge zu koordinieren hat, sagt nun einfach "Zug 5: losfahren" ohne sich zu kümmern, was das für ein Zug ist. Der Zug selbst ist vielleicht ein Personenzug und wird auf den Befehl "losfahren" hin seine Personenzugspez. Sicherheitsaspekte checken, ein Güterzug hingegen seine. Also: Das Programm ruft "Zug X: losfahren" auf und wen Zug X ein Personenzug ist, ruft er damit sein "Personenzug: losfahren" auf. Das Programm muß nicht wissen, was für ein Zug das ist und was für seine Sicherheit wichtig ist. Das so einfach mit nicht-OOP zu realisieren, ist nicht möglich.

Wobei ich nicht genau weiß, wie es objektorientiert realisiert
wird.
Von daher ist der Vorteil momentan nicht transparent.

Der Vorteil liegt in der Einfachheit und Übersichtlichkeit und der Möglichkeit, durch Objekthierarchien dynamische, flexible und ausbaufähige Strukturen zu schaffen, die sich ohne intime Kenntnis des Quelltextes weiterverwenden und modifizieren lassen.

Kannst Du noch versuchen mir das etwas näher zu bringen?

Hab's versucht...

OOP ist bei komplexen Programmen einfacher, flexibler und übersichtlicher. Um genau zu verstehen, warum, solltest du vielleicht mal ein Buch über OOP lesen. Ich kann hier leider nicht alle Details genau darlegen.

Gruß
Jochen