und objektorientierter Softwareentwicklung.
Wer kann mir in ein paar Sätzen die groben Unterschiede nennen?
Vielen Dank!
Gruß
Caro
Im Ggs. zur Nicht - OOP werden bei der OOP Variablen mit Prozeduren bzw. Funktionen zusammengefaßt, die diese Variablen bearbeiten. Die Variablen nennt man dann Felder, die Prozeduren und Funktionen nennt mann dann Methoden.
Wenn du eine automatische Eisenbahnsteuerung programmierst, hast du ja Variablen für Züge (Ort, Geschwindigkeit, usw.), für die Signale (rot, grün), für Weichen (links, rechts, geradeaus) usw.usf. Die OOP stellt sicher, daß die Variable „Geschwindigkeit“ sich eben auf den Zug beziehen *muss* und man nicht in Verlegenheit kommt, so ein Unsinn zu programmieren, daß dem Zug z.B. „rot“ zugeordnet werden kann. Der Zug - das Zug-OBJEKT- hat also ganz bestimmte EIGENSCHAFTEN, deren Werte in den Feldern gesichert sind. Die Geschwindigkeit des Zuges wird über eine Zug-eigene Methode eingestellt. Diese Methode kann (und sollte) vor der Zuweisung des Wertes an die Feld-Variable die Gültigkeit des Wertes überprüfen (z.B. sthet das Signal auf rot ? ist die geforderte Geschwindigkeit kleiner der zul. Höchstgeschw. ? usw.). Objekte sollten so konstruier t sein, daß man nicht unkontrolliert ihre Felder manipulieren kann. das nennt man KAPSELUNG.
Daraus ergibt sich ein wesentlicher Vorteil bei der Programmierung, den die nicht-OOP nicht ausgleichen kann:
Objekte können ihre Eigenschaften VERERBEN. Man kann von bestehenden Objekten andere Objekte ableiten. So könnte man ein Objekt „Fahrzeug“ definieren, mit den Eigenschaften Ort und Geschwindigkeit, Höchstgeschw. usw. Davon kann man dann - ohne die Details von „Fahrzeugen“ kennen zu müssen, die Objekte „Zug“ und „KFZ“ ableiten. Die neuen Eigenschaften für einen Zug sind dann z.B. max. Wartungsintervall, Anzahl Waggons, usw. Hiervon ließe sich ein Objekt „Personenzug“ oder „Güterzug“ ableiten. Der Personenzug erhält neue Eigenschaften für Streckennetz (Regional, Intercity usw.), Boardrestaurant u.ä., während der Güterzug Eigenschaften für die Art und Menge der Beladung erhält.
Trotz der Vielfalt und Komplexität des ganzen Systems mit seinen vielen Signalen, Weichen, Zügen usw. bleibt durch die Verwendung von Objekten die Programmierung relativ übersichtlich und man läuft kaum Gefahr, irgendwelche Sachen zu verwechseln oder falsch Zuzuweisen.
Frag nochmal konkret nach, wenn das zu schwammig war.
Gruß
Jochen
Alle Achtung ! SO anschaulich habe ich das noch niemanden erklären gehört. Dafür gibt’s 'ne Sternchen !
und objektorientierter Softwareentwicklung.
Wer kann mir in ein paar Sätzen die groben Unterschiede
nennen?
Im vorhergehenden Mail wurde schön erklärt was objektorientierte Programmierung bedeutet.
Unter objektorientierter Softwareentwicklung fast man allerdings nicht nur die eigentliche Entwicklung sondern auch OOA und OOD (Objektorientierte Analyse und objektorientiertes Design) zusammen.
Das sind dann Methoden zur Analyse des Umfelds und der Anforderungen an ein System (OOA) und zum Entwurf eines Systems (OOD).
Die bekannteste Sammlung aus OO-Methoden ist UML (Unified Modeling Language) bzw. der Unified Process.
Informationen findest du z. B. auf der Homepage von Rational (http://www.rational.com). Rational ist eine Firma bei der glaube ich zwei der drei UML-Erfinder arbeiten und die Tools für UML bzw. den Unified Process zur Verfügung stellt.
Grüße, Robert
Danke,
Wirklich eine super Erklärung!
Vielen Dank für Deine Mühe!!!
Grüße
Caro
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.
Die Daten selbst werden in fachlich definierten Tabellen abgelegt.
Das ist doch letztendlich fast
die gleiche Logik? Nur anders realisiert.
Wobei ich nicht genau weiß, wie es objektorientiert realisiert wird.
Von daher ist der Vorteil momentan nicht transparent.
Kannst Du noch versuchen mir das etwas näher zu bringen?
Danke!
Grüße
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
Link-Tipp
Hi Carolin,
schau Dir mal http://www.guidetocsharp.de/guide/guide11.html an, da geht’s genau um Einführung in OOP und es ist sehr ausführlich beschrieben.
Was in den bisherigen Beispielen nämlich gefehlt hat, war beispielsweise der Unterschied zwischen Objekt und Klasse … das wird da erklärt.
Außerdem waren die bisherigen Erklärungen teilweise falsch, da beispielsweise nicht ein Objekt seine Eigenschaften vererbt, sondern seine zugehörige Klasse …
Viele Grüße,
Golo
Anmerkung
Was in den bisherigen Beispielen nämlich gefehlt hat, war
beispielsweise der Unterschied zwischen Objekt und Klasse …
das wird da erklärt.
Ich wollte es nicht unnötig kompliziert machen. Zum Verständnis der Prinzipien braucht man diese Unterscheidung - glaube ich - nicht, auch wenn natürlich ein Objekt keine Klasse ist. Der Unterschied ist Vergleichbar mit dem eines Typs und einer Variable bestimmten Typs. Für die gegebene Erklärung war das irrelevant.
Außerdem waren die bisherigen Erklärungen teilweise falsch, da
beispielsweise nicht ein Objekt seine Eigenschaften vererbt,
sondern seine zugehörige Klasse …
s.o.
Klär’ mich aber bitte auf, wenn ich total daneben liege (lerne gerne dazu!).
Liebe Grüße
Jochen
Vielen Dank für Deine Erklärungen!!!
Du weißt sicher, wovon Du sprichst!
Um den wahren Vorteil erkennen zu können,
muß ich mich sicher etwas mehr damit beschäftigen.
Es gibt ja auch nicht ohne Grund jede Menge Literatur.
Aber nochmal vielen Dank für Deine Infos!!!
Grüße