Abstrakte Klasse
aus Wikipedia, der freien Enzyklopädie
Abstrakte Klasse ist ein Begriff aus der objektorientierten Programmierung.
Jede Klasse beschreibt genau die Eigenschaften all derjenigen Objekte, die eben dieser Beschreibung gemäß aus ihr hervorgehen würden.
Solche Klassen, aus denen tatsächlich Objekte hervorgehen, werden konkrete Klassen genannt. Als abstrakte Klassen bezeichnet man hingegen solche Klassen, aus denen keine Objekte hervorgehen können.
Das führt zu der Frage, welchen Sinn eine Klasse haben kann, wenn von vornherein feststeht, dass aus ihr keine Objekte hervorgehen können.
Die Antwort: Sinn ergibt das dann, wenn die in der objektorientierten Programmierung üblichen Vererbungsmechanismen ausgenutzt werden. Denn wenn nebeneinander verwandte Klassen existieren, deren Attribute/Methoden eine verwandtschaftsbedingte (!) Schnittmenge haben, dann gebietet es die Vernunft, diese Schnittmenge in einer gemeinsamen Oberklasse zu definieren. Da diese Oberklasse wirklich ausschließlich zu dem Zweck eingerichtet wird, die verwandtschaftsbedingte Schnittmenge der Attribute/Methoden zu definieren und weiter zu vererben, gehen aus ihr keine eigenen Objekte hervor, sie ist also eine abstrakte Klasse. Für den Fall, dass sicherheitshalber verhindert werden soll, zu einer als abstrakt vorgesehenen Klasse entwurfswidrig doch Objekte zu erzeugen, verfügen Programmiersprachen über Mechanismen, das (evtl.versehentliche) Erzeugen von Objekten zu unterbinden. (Solche Attribute/Methoden, die sich nur zufällig gleichen, nicht aber verwandtschaftsbedingt, dürfen natürlich nicht in die Oberklasse übernommen werden, das wäre ein schwerer Entwurfsfehler.)
Beispiel: Die Leitung eines Bauernhofs mag vorhaben, den Viehbestand (Rinder und Schweine) objektorientiert zu verwalten. Das wird zunächst zu einer Programmstruktur mit zwei Klassen führen, Klasse "Rind" und Klasse "Schwein". Aus der Klasse "Rind" wird später für jedes einzelne Rind genau ein Objekt mit den Individualdaten (Alter, Körpermasse, Milchleistung usw.) erzeugt, und genauso auch aus der Klasse "Schwein" je gehaltenem Tier genau ein zugehöriges Objekt.
Wenn man es bei dieser Programmstruktur belässt, dann wird sich die Unschönheit ergeben, dass eine Reihe gleicher Attributdefinitionen in beiden Klassen nebeneinander gepflegt werden müssen, hier beispielsweise das Alter des Tieres und die Körpermasse.
In solchem Fall bietet es sich an, zusätzlich zu den Klassen "Rind" und "Schwein" eine Oberklasse "Tier" einzurichten, die genau all diese Schnittmengenattribute enthält, die ansonsten in beiden Unterklassen getrennt gepflegt werden müssten, hier also die Attribute "Alter", "Körpermasse" usw. Das ist deshalb entwurfstechnisch geboten, weil es Arbeit spart, Redundanz vermeidet und somit die Zahl der Fehlermöglichkeiten verringert.
Die beiden konkreten Klassen "Rind" und "Schwein" werden dann so geschrieben, dass sie jeweils Erben der Oberklasse "Tier" sind. Damit erhalten sie "automatisch" den dort gepflegten Attributesatz. In der konkreten Klasse wird der Attributesatz um artspezifische Attribute erweitert, beim Rind also z.B. um das Attribut "Milchleistung" (Schweine geben keine Milch). Alles für die Attribute Gesagte gilt natürlich genau so für die Methoden: Auch hier werden diejenigen, die zur (verwandtschaftshierarchiebedingten!) Schnittmenge gehören, in die Oberklasse verlagert.
Und nun ist genau der Effekt entstanden, von dem oben die Rede war: Sämtliche Objekte, die wir jemals haben werden, gehen ausnahmslos aus den konkreten Klassen "Rind" und "Schwein" hervor. Darüber haben wir aber aus programmorganisatorischen Gründen eine Oberklasse "Tier" geschaffen, von der wir gewiss niemals eigene Objekte bilden werden - die würden hier keinen Sinn ergeben. Damit bleibt hier die Klasse "Tier" ohne Objekte, ist also eine abstrakte Klasse.
