Objektorientierung
Unter Objektorientierung (kurz OO) versteht man in der Entwicklung von Software eine Sichtweise auf komplexe Systeme, bei der ein System durch das Zusammenspiel kooperierender Objekte beschrieben wird. Der Begriff Objekt ist dabei unscharf gefasst; wichtig an einem Objekt ist nur, dass ihm bestimmte Attribute (Eigenschaften) und Methoden zugeordnet sind und dass es in der Lage ist, von anderen Objekten Nachrichten zu empfangen beziehungsweise an diese zu senden. Dabei muss ein Objekt nicht gegenständlich sein. Entscheidend ist, dass bei dem jeweiligen Objektbegriff eine sinnvolle und allgemein übliche Zuordnung möglich ist. Ergänzt wird dies durch das Konzept der Klasse, in der Objekte aufgrund ähnlicher Eigenschaften zusammengefasst werden. Ein Objekt wird im Programmcode als Instanz beziehungsweise Inkarnation einer Klasse definiert.
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 objektorientiertes Design (Synonym objektorientierter Entwurf) von Software. Die Konzepte der Objektorientierung lassen sich zudem auf persistente Daten anwenden. Dabei spricht man von Objektdatenbanken.
In Programmiersprachen, die nicht auf Objektorientierung eingerichtet sind, werden Daten und Programmteile bewusst getrennt; sie müssen separat deklariert werden. Im Vergleich hierzu erhebt das objektorientierte Programmierparadigma den Anspruch, Daten und zugehörige Programmteile zu einer Einheit zusammenzufassen und somit Organisationsstrukturen aus der realen Welt besser nachzubilden.
Fast alle höheren Programmiersprachen unterstützen objektorientierte Programmierung.
Vererbung
[Bearbeiten | Quelltext bearbeiten]In der Regel ist in objektorientierten Ansätzen das Konzept der Vererbung zu finden, bei dem Eigenschaften und Methoden zwischen Klassen hierarchisch ausgetauscht beziehungsweise ergänzt werden können.
Vererbung bedeutet vereinfacht, dass eine abgeleitete Klasse die Methoden und Attribute 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.
Seltener ist das Konzept der Mehrfachvererbung, welches das nichthierarchische Austauschen von Eigenschaften erlaubt.
Wird keine Vererbung zugelassen, so spricht man zur Unterscheidung oft auch von Objektbasierung.
Polymorphie
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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.
Abstraktion
[Bearbeiten | Quelltext bearbeiten]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 textuellen 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 Farben von Stoßfänger, Spiegel und Motorhaube möglicherweise nicht identisch zur Karosseriefarbe 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.