Objektmethode

Die Objektorientierung, kurz OO, ist ein Ansatz zur Entwicklung von Software, der darauf beruht, die zu verarbeitenden Daten anhand ihrer Eigenschaften und der möglichen Operationen zu klassifizieren. Im Vergleich zu Ansätzen, bei denen Eigenschaften und Funktionen nicht gemeinsam betrachtet werden, erhebt dieses Programmierparadigma den Anspruch, entsprechende menschliche Organisationsmethoden aus der realen Welt besser nachzubilden.

Ein Objekt wird im Programmcode als Instanz beziehungsweise Inkarnation einer Klasse definiert. Als Weiterentwicklung von Datenstrukturen (aus mehreren Komponenten - auch unterschiedlichen Datentyps - zusammengesetzte Variablen) können Objekte auch noch über Eigenschaften und Methoden verfügen, die durch Programmcode in der Klasse festgelegt sind. Auf Eigenschaften kann wie auf Variablen zugegriffen werden, der zurückgegebene Wert wird jedoch ggf. durch den Programmcode einer in der Klasse festgelegten Prozedur bestimmt. Methoden sind Funktionen, die Daten in Form von Parametern entgegennehmen und in Form eines Rückgabewertes zurückgeben können. Sie werden in der Regel auch verwendet, um die Werte interner Objektvariablen zu manipulieren.

Der Objektorientierung liegt demnach eine Aufteilung der zu beschreibenden Welt in Objekte mit ihren Eigenschaften und Operationen zugrunde. Ergänzt wird dies durch das Konzept der Klasse, bei dem Objekte aufgrund ähnlicher Eigenschaften zusammengefasst werden. Die Struktur eines Objekts wird durch die Attribute (auch Eigenschaften) seiner Klassendefinition festgelegt. Das Verhalten des Objekts wird von den Methoden der Klasse bestimmt.

Objektorientierung wird hauptsächlich im Rahmen der objektorientierten Programmierung verwendet, um die Komplexität der entstehenden Programme zu verringern. Der Begriff existiert jedoch auch für andere, der Programmierung vorgelagerte Phasen der Softwareentwicklung, wie die objektorientierte Analyse und den objektorientierten Entwurf von Software. Die Konzepte der Objektorientierung lassen sich zudem auf persistente Daten anwenden. Dabei spricht man von Objektdatenbanken.

Vererbung

Klassen können von anderen Klassen abgeleitet werden (Vererbung). Dabei erbt die Klasse die Datenstruktur (Attribute) und die Methoden von der vererbenden Klasse (Basisklasse).

In der Regel ist in objektorientierten Ansätzen das Konzept der Vererbung zu finden, bei dem Eigenschaften und Methoden zwischen Klassen hierarchisch ausgetauscht bzw. ergänzt werden können. Seltener ist das Konzept der Mehrfachvererbung, welches das nichthierarchische Austauschen von Eigenschaften erlaubt. Vererbung heißt vereinfacht, dass eine abgeleitete Klasse die Methoden und Objekte der Basisklasse ebenfalls besitzt, also „erbt“. Somit kann die abgeleitete Klasse auch darauf zugreifen. Neue Arten von Objekten können auf der Basis bereits vorhandener Objekt-Definitionen festgelegt werden. Es können neue Bestandteile hinzugenommen werden oder vorhandene überlagert werden. Wird keine Vererbung zugelassen, so spricht man zur Unterscheidung oft auch von Objektbasierung.

Polymorphie

Das Konzept der Polymorphie (Vielgestaltigkeit) bewirkt, dass Eigenschaften oder Methoden einer Klasse von Objekten referenziert werden können, ohne dass die konkrete Ausprägung in einem angesprochenen Objekt bekannt sein muss.

Hinzu kommt mit der Aggregation die Unterscheidung zwischen dem Ganzen und seinen Teilen. Jedes Objekt im System kann als ein abstraktes Modell eines Akteurs betrachtet werden, der Aufträge erledigen, seinen Zustand berichten und ändern und mit den anderen Objekten im System kommunizieren kann, ohne offenlegen zu müssen, wie diese Fähigkeiten implementiert sind (vgl. abstrakter Datentyp, ADT).

Kapselung

Die Datenkapselung erlaubt das Abschotten der internen Implementierung vor direktem externen Zugriff. Dieser darf nur über eine explizit definierte Schnittstelle erfolgen, um ihn unabhängig von den Implementierungsdetails zu machen.

Vereinfachte Sichtweise der realen Welt

Eine Klassifizierung ist im allgemeinen eine Einschränkung/Vereinfachung der realen Welt in einem ganz speziellen Kontext. Es wird also niemals "die" Klassifizierung geben. Sie ist immer abhängig vom Ziel, das mit der Klassifikation erreicht werden soll. Während beispielsweise eine Klasse "Auto" im Kontext eines Autobauers möglicherweise Attribute, wie Räder und Farbe besitzen wird und seine Bauteile (in Form von Attributen oder Beziehungen) kennen wird, hat eine Klasse "Auto" im Kontext eines Händlers Attribute wie Produktnummer, Preis, Verbrauch und Erstzulassungsdatum. Im Kontext einer Zulassungsstelle wird es Attribute, wie Kennzeichen, zulässiges Maximalgewicht und den Halter geben.

Darüber hinaus ist nicht immer eindeutig und objektiv entscheidbar, ob eine Eigenschaft in Form eines Attributes des Objektes oder in Form einer Beziehung zu einem anderen Objekt dargestellt werden sollte. So kann etwa die Eigenschaft "Farbe" des Autos aus obigem Beispiel entweder als Textattribut (zum Darstellen einer textuelle Farbbeschreibung, etwa einer RAL- oder DIN-Farbnummer) oder als Beziehung zur Klasse "Farbe" modelliert werden. Letzteres ist dann sinnvoll, wenn für die Klasse Farbe wiederum spezielle Eigenschaften modelliert werden sollen. Darüber hinaus kann es notwendig werden, dass nicht für das ganze Auto die Eigenschaft Farbe modelliert wird, sondern für die einzelnen Bauteile (etwa, weil die Farbe von Stoßfänger, Spiegel und Motorhaube möglicherweise nicht identisch zur Karossieriefarbe sein müssen).

Gerade dieser letzte Aspekt ist oftmals vom Zeitpunkt der Modellierung abhängig: Während der Hersteller heute das ganze Auto mit einer einzigen Farbe assoziiert, möchte er vielleicht morgen tatsächlich jedes Bauteil mit einer eigenen Farbe versehen. Die Vereinfachung, die heute noch zur Lösung eines Problems ausreichend ist, ist morgen möglicherweise nicht mehr ausreichend.

Siehe auch

• Komponentenbasierte Entwicklung