Was bedeutet objektorientiert?
In der objektorientierten Softwaremodellierung werden die in der realen Welt vorkommenden konkreten oder abstrakten Gegenstände als Objekte angesehen. Ein Mensch ist ebenso ein Objekt, wie ein Fenster in einer Softwareapplikation oder ein Absatz in einem Dokument. Und diese Objekte bestehen wiederum aus anderen Objekten, z.B. enthält ein Softwarefenster meist eine Bildlaufleiste.
Jedes Objekt hat bestimmte Eigenschaften, die in Datenstrukturen festgelegt werden: Ein Fenster hat z.B. eine bestimmte Größe und Farbe, während für einen Menschen z.B. Geburtsdatum und Beruf typische Eigenschaften sind. Neben den Eigenschaften weist jedes Objekt ein bestimmtes Verhalten auf: Ein Fenster kann geschlossen, vergrößert, verkleinert und geöffnet werden, während ein Absatz in einem Dokument z.B. verschoben, gelöscht und geändert werden kann. Das Verhalten der Objekte wird in den sogenannten Methoden beschrieben. Objekte haben oft Beziehungen untereinander, was auch als Verhalten, bzw. Methode des Objektes zu sehen ist: In der Abbildung unten besteht eine Beziehung zwischen der Klasse "Mensch" und der Klasse "Lied", da der Mensch eine Methode "singen" besitzt, die auf ein Objekt der Klasse "Lied" zugreift:
Nun wäre es müßig, für jedes einzelne Objekt, immer wieder aufs neue seine Eigenschaften und sein Verhalten festzulegen: Um effektiv programmieren zu können, werden gleichartige Objekte zu Gruppen zusammengefasst: Der Programmierer legt einen Bauplan für alle gleichartigen Objekte fest, die sogenannte Klasse. Die konkreten Objekte werden über die Klasse erzeugt. Das Objekt hat dann automatisch alle Datenstrukturen und Methoden, die in der Klasse einmalig festgelegt wurden. Die Objekte werden auch als Instanz ihrer Klasse bezeichnet.
Die Instanzen, also Vera Vollmilch, Elsa Euter und Anja v.d. Alm haben natürlich unterschiedliche Attributwerte. Vera Vollmilch hat ihr eigenes Geburtsdatum, gibt im Durchschnitt mehr Milch als ihre Kollegin Anja v.d. Alm und hat wie wir wissen, einen eigenen Namen.
Jedes Objekt gehört einer Klasse an. Klassen werden in einer hierarchischen Beziehung aufgebaut. Z.B. könnte es eine Klasse Nutztier geben und diese Klasse hat die Unterklassen "Kuh" und "Schwein". Die Unterklassen erben die Eigenschaften und das Verhalten der allgemeineren Klasse "Nutztier" und haben zusätzlich noch andere Eigenschaften und Methoden, die in der allgemeineren Oberklasse nicht enthalten sind. Nutztier ist eine abstrakte Klasse, d.h. von Nutztier kann kein Objekt erzeugt werden. Nutztier dient lediglich dazu, ähnliche Klassen unter einem Oberbegriff zusammenzufügen und gemeinsame Methoden- und Attributnamen zu definieren.
Konzepte und Vorteile der Objektorientierten Programmierung
Abstraktion
Die objektorientierten Methoden verschieben die Modellierung stärker als die strukturierten vom Lösungs- in den Problembereich:
Bei der Systementwicklung konzentriert sich der Entwickler zunächst darauf, welche Objekte er benötigt und welches Objekteigenschaften und -fähigkeiten für die Softwarelösung wichtig sind. Auf diese Art und Weise lässt sich eine zu frühe Festlegung verpflichtender Details verhindern. Der Entwickler kann sich auf das grundlegende Problem konzentrieren und muss; keine Entscheidungen über Entwurf und Implementierung trefffen, bevor das Problem vollständig verstanden wurde.
Kapselung (wird auch Information Hiding genannt)
Objekte, die auf andere Objektmethoden zugreifen, müssen nicht "wissen", wie die genaue Implementierung der Methode aussieht. Bei Veränderungen der Methode, muss die Schnittstelle zwischen den beiden Objekten i.d.R. nicht modifiziert werden. Durch die Kapselung wird also verhindert, dass bereits kleinere Änderungen massive Seiteneffekte auslösen. Die Abhängigkeiten werden so reduziert.
Ganzheitliche Arbeitsgegenstände
Statt der Trennung von Daten und Operationen wird nun durch das Klassenkonzept mit Einheiten aus Daten und Operationen gearbeitet.
Durch die Vererbungsbeziehung zwischen Klassen ist es möglich, dass mehrere ähnliche Unterklassen ohne Redundanz eine gemeinsame Struktur nutzen. Noch wichtiger als die Vermeidung von Redundanzen ist die verbesserte konzeptuelle Klarheit.
Betonung der Objektstruktur und nicht der Prozedurstruktur
In der objektorientierten Modellierung kommt es darauf an, zu spezifizieren, was ein Objekt ist, weniger wie es verwendet wird. Der Datenstruktur wird im Vergleich zur prozeduralen Modellierung ein größeres Gewicht als der Prozedurstruktur beigemessen.
Der Vorteil: Die Verwendung eines Objektes ändert sich häufig, die Merkmale eines Objektes sind langlebiger. Daher sind Softwaresysteme, die auf Objektstrukturen aufbauen, langfristig stabiler.
Im wirklichen Leben, entsteht ein komplexes System, wie z.B. der Mensch, nicht aus einem Guss;, sondern entwickelt sich Schritt für Schritt weiter und passt sich den äußeren Einflüssen an. Evolution findet meist auch innerhalb eines Softwarelebenszyklus statt. Eine komplexe Anwendung wird zunächst teilweise realisiert, dann erweitert und erneut getestet und wieder verändert. In der prozeduralen Programmierung ist es - trotz Modulbildung - meist schwieriger, Software im nachhinein zu ändern und zu erweitern - zahllose Seiteneffekte entstehen, sobald an einem Ende Änderungen stattfinden. Mit der objektorientierten Programmierung hingegen, kann das Prinzip der Evolution auch auf die Softwareentwicklung übertragen werden.
Die Geschichte der Objektorientierung
Die Idee der Objektorientierung ist über 28 Jahre alt und fast ebenso lang liegt die Entwicklung objektorientierter Sprachen zurück. Ende der 60er Jahre entstand mit Simula die erste objektorientierte Sprache. Sie wurde zu Smalltalk weiterentwickelt, aus der wiederum Objective C, Eiffel und CLOS und als derzeit modernste Sprachen letztendlich C++ und Java hervorgingen.
Merkwürdigerweise existieren Bücher über objektorientiere Analyse- und Designmethoden erst seit Anfang der 90er Jahre. Die beiden wichtigsten Werke, beide 1991 erschienen, sind "Objektorientierter Entwurf" von Grady Booch (damals wie heute bei der Firma Rational als Chefwissenschaftler tätig) und "Objektorientiertes Modellieren und Entwerfen" von James Rumbaugh und anderen (ein Team von Forschern des amerikanischen Elektronikriesen General Electric). Die Methoden von Grady Booch und James Rumbaugh waren schnell sehr populär, sie wurden von den Entwicklern am häufigsten benutzt.
1995 begannen Booch und Rumbaugh mit der Zusammenführung ihrer beiden Methoden. Das Ergebnis war zunächst die Unified Method (UM). Als dritter im Bunde stieß wenig später Ivar Jacobson hinzu, von dem die Use Cases (Anwendungsfälle) stammten, die ebenfalls integriert wurden. Die Dreiergruppe gab sich den Namen "Amigos" und nannte ihre Methode Unified Modeling Language (UML). UML erfreute sich hoher Popularität und war bereits ein Quasistandard. Im Januar 1997 reichten die Amigos dann die Version 1.0 der UML zur Standardisierung der Object Management Group (OMG) ein.
Burkhardt, Rainer (1998): "UML - Unified Modeling Language - Objektorientierte Modellierung für die Praxis"; Addison-Wesley Longman, Bonn u.a.
Meyer, B. (1998): "Objektorientierte Softwareentwicklung"; Coedition der Verlage Carl Hanser und Prentice-Hall International
Oestereich, B. (1997): "Objektorienteirte Softwareentwicklung mit der Unified Modeling Language", 3. Auflage, Oldenbourg Verlag, München
Rumbaugh, J., Blaha. M, Premerlnai, W, Eddy, F. und Lorensen, W. (1993): "Objektorientiertes Modellieren und Entwerfen", Coedition der Verlage Carl Hanser und Prentice Hall International
Was bedeutet objektorientiert?