Hi!
Meine Meinung, allerdings nicht unbedingt aus dem Lehrbuch:
Bei der Programmierung geht es eigentlich immer darum vorgegebene Daten zu manipulieren. Selbst einfache Aufgaben wie "Gib eine Zahl auf dem Bildschirm aus" oder "drück eine Taste" lassen sich darauf zurückführen (die Zahl ist hier ein einzelnes Datenfeld und die Manipulation ist das Anzeigen auf dem Bildschirm; im zweiten Beispiel ist das Datenfeld eine Byte und die Manipulation das Warten das eine Taste gedrückt wird).
Das geht so auch mit komplexen Datenstrukturen. Die Sortierung von Adressdaten ist auch so ein Beispiel (Daten sind alle Adressen und die Manipulation ist die Sortierung).
Die Manipulation erfolgt in Programmen. Programmroutinen werden als Funktionen bezeichnet. Im Folgenden stehen Funktionen daher immer für eine Folge bzw. Gruppe von Programmcode.
Die Funktionen nutzen Datenstrukturen um die Daten intern abzulegen und verarbeiten zu können.
In der Softwareentwicklung gibt es zwei verschiedene Ansätze an diese Sache ranzugehen: einmal stelle ich die Funktionen in den Mittelpunkt (und bestimme die Datenstrukturen dann danach, was in den Funktionen benötigt wird). Dies ist die Funktionale-Programmsicht.
Die andere Sichtweise ist die Datenstrukturen in den Mittelpunkt zu stellen. Hier lege ich zuerst fest, was ich an Daten verwalten will. Dann lege ich die Funktionen fest, die diese Daten bearbeiten werden. Dies ist die Objektorientierte-Programmsicht.
Akademiker haben da immer eine Unterschwellige Befürchtung: wenn ich etwas anders mache, nimmt das keiner erst, wenn es nicht ganz neu aussieht.
Ich behaupte hier, dass das bei der Namensgebung "Objektorientierung" der Fall war. Hätte ich das festgelegt, wäre das eine "Funktionsbasiert" gewesen und das andere "Datenstrukturbasiert".
Auf den Idee jemanden zu erklären dass alles neu ist, weil man nun Objekte manipuliert, muss man erstmal kommen. (Konsequenterweise nennen die da Funktionen nun nicht mehr Funktionen, sondern sprechen von "Methoden".)
Die Entwicklung von der Funktionalen Programmierung zur Objektorientierung ist aus meiner Sicht evolutionär fast zwingen. Ich bin da selbst durch: erst hatte ich grosse Mengen an Funktionen, die keinen formalen (syntaktische) Bezug zu ihren Datenstrukturen hatten. Die Idee Datenstrukturen syntaktisch um Funktionen zu erweitern ist fast zwingend. Die Sichtweise die Daten in den Mittelpunkt zu stellen ist auch so nicht neu. Wenn ich eine Adressverwaltung programmieren will, weiss ich, dass ich Adressdaten im Mittelpunkt haben werde. Die Objektorientierung unterstützt das dann auch formal (syntaktisch im Programm).
Die Serviceoriontierung (SOA) ist keine Alternative oder anderer Betrachtungswinkel. Sie setzt übergeordnet auf. Hier betrachtet man Prozesse (i.d.R. solche in Unternehmen). Z.B. bei einem Verkauf in einem Unternehmen:
- ich erfasse den Kunden
- ich erfasse den Auftrag
- ich produziere die Ware
- ich liefere die Ware
- ich stelle eine Rechnung
- ich verbuche die Zahlung
Diese einzelnen Prozesse kann man in der EDV-Abbilden. Man kann leicht erkennen, dass man es hier wieder mit Datenstrukturen und Funktionen zu tun hat. (Kundendatensatz, Auftragsdatensatz, Artikel=Ware; Rechnungsdaten; Zahlungseingänge; das ganze muss in die dicke Datenbank rein und dort passend verrührt werden, ergo: grosser Bedarf an Programmcode; an die Umsetzung kann man dann wieder funktional oder objektorientiert herangehen).
Bis dann
Andreas
PS: Vorsicht: ich musste das nie in einer Prüfung vertreten. ;-)
ChrE
erna9000
Borlander
Andreas42
