Klasse (OOP): Unterschied zwischen den Versionen

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
 
(69 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
=Definition (von W. Kowarschick)<ref>[[Kowarschick, W.: Multimedia-Programmierung]]</ref>=
{{Qualität
Eine '''Klasse''' dient (im Sinne des [[objektorientierte Programmierung|objektorienten Paradigmas]]) dazu, die [[Schnittstell]]en und evtl. auch eine oder gar mehrere [[Implementierung]]en von „gleichartigen“ [[Objekt (OOP)|Objekt]]en ganz oder zumindest teilweise festzulegen.
|correctness        = 4
|extent              = 5
|numberOfReferences  = 2
|qualityOfReferences = 3
|conformance        = 4
}}
==Definitionen (OMG: UML 2.3)==
 
===Classifier<ref name="UML 2.3 Infrastructure">[http://www.omg.org/spec/UML/2.3/Infrastructure/PDF/OMG Unified Modeling Language (OMG UML), Infrastructure, Version 2.3, May 2010]</ref>===
A '''classifier''' is a classification of instances — it describes a set of instances that have features in common.
 
Übersetzung (von W. Kowarschick): <br />
Ein Klassifikator [Classifier] ist eine Klassifikation von Objekten — er beschreibt eine Menge von Objekten, die Eigenschaften gemein haben.{{Absatz}}
===Class<ref name="UML 2.3 Infrastructure"/>===
A [[Klasse (OOP)|class]] describes a set of objects that share the same specifications of features, constraints, and semantics.
 
Übersetzung (von W. Kowarschick): <br />
Eine Klasse beschreibt eine Menge von Objekten, die sich dieselben Spezifikationen von Eigenschaften, [Integritäts-]Bedingungen und Semantik teilen. {{Absatz}}
===Abstract Classifier, Abstract Class<ref name="UML 2.3 Infrastructure"/>===
Laut UML-2.3-Standard hat jeder Klassifikator und damit auch jede Klasse ein Attribut <code>isAbstract</code>. Für dieses gilt folgende Bedingung:


Eine '''Klasse''' besteht aus folgenden Teilen:
If true, the Classifier does not provide a complete declaration and can typically not be instantiated.


*einer [[Klassenextension]]: Die Klassenextension enthält zu jedem Zeitpunkt alle Objekte, die der Klasse zugeordnet sind.
Übersetzung (von W. Kowarschick): <br />
Falls [dieses Attribut den Wert] wahr [hat], bietet der Klassifikator keine vollständige Deklaration und kann typischerweise nicht instanziiert werden. {{Absatz}}
===Interface<ref>[http://www.omg.org/spec/UML/2.3/Superstructure/PDF/ OMG Unified Modeling Language (OMG UML),
Superstructure, Version 2.3, May 2010]</ref>===
An '''interface''' is a kind of classifier that represents a declaration of a set of coherent public features and obligations. An
interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract.


*einem [[Klassenschema]]: Das Klassenschema umfasst eine (endliche) Menge von [[Integritätsbedingung]]en, die alle zugehörigen Objekte (d.h. alle in der Klassenextension enthaltenen Elemente) zu jedem Zeitpunkt erfüllen müssen. Das Schema [[deklariert]] insbesondere die [[Methoden]], die für jedes Objekt der Klassenextension jederzeit als [[Schnittstelle|Kommunikationsschnittstelle]] zur Verfügungstehen müssen.  
Übersetzung (von W. Kowarschick): <br />
 
Eine Schnittstelle [ein Interface] ist eine [spezielle] Art eines Klassifikators [Classifiers], der die Deklaration einer Menge von kohärenten offentlichen Eigenschaften und Verpflichtungen [im Sinne von Constraints] definiert. Eine Schnittstelle spezifiziert einen Vertrag; jedes Objekt eines Klassifikators, das die Schnittstelle realisiert, muss diesen Vertrag erfüllen.
*beliebig vielen (0, 1, 2, ...) [[Klassenimplementierung]]en: Diese implementieren die im Klassenschema deklarierten Methoden teilweise oder vollständig und garantieren dabei die stete Erfüllung aller im Klassenschema definierten Integritätsbedingungen. Unterschiedliche Implementierungen können sich in Hinblick auf Performanz-Aspekte unterscheiden.


*den [[Klassenmethode]]n ([[statische Methode]n]): Eine Klasse verhält sich wie ein spezielles [[Objekt (OOP)|Objekt]]) und kann daher eigene (Klassen-)Methoden und (Klassen-)Attribute enthalten. Überlicherweise gibt es zumindest Methoden zur Verwaltung der Klassenextension, d.h. zum Erzeugen ([[Konstruktor]]en) und evtl. auch zum  Zerstören ([[Destruktor]]en) von zugeordneten Objekten.
==Definitionen (von W. Kowarschick)<ref>[[Kowarschick, W.: Multimedia-Programmierung]]</ref>==
===Klasse===
[[Datei:UMLClass.jpg|links|gerahmt|UML-Klassen-<br/>diagramm: Eine Klasse und ein Klassen-Template]]


==Abstrakte Klasse==
Eine '''Klasse''' dient (im Sinne des [[objektorientierte Programmierung|objektorienten Paradigmas]]) dazu, die [[Schnittstell]]en und evtl. auch eine oder gar mehrere [[Implementierung]]en von „gleichartigen“ [[Objekt (OOP)|Objekt]]en ganz oder zumindest teilweise festzulegen.


Eine Klasse, für es Klassenimplementierungen gibt, die die im Klassenschema definierten Methoden nicht vollständig implementieren, heisst '''abstrakte Klasse'''.
Eine '''Klasse''' besteht aus folgenden Teilen:


==Schnittstelle (Interface)==
*einer [[Klassenextension]]: Die Klassenextension ist eine (i. Allg. endliche) Menge, die zu jedem Zeitpunkt genau diejenigen Objekte, die der Klasse zugeordnet sind, enthält.  
Eine Klasse, für die es keine Klassenimplementierung gibt, heißt '''Schnittstelle''' oder '''Interface'''.


==Singleton-Klasse==
*einem [[Klassenschema]] (einer [[Klassenspezifikation]]): Das Klassenschema umfasst eine (endliche) Menge von [[Integritätsbedingung]]en, die alle zugehörigen Objekte (d.h. alle in der Klassenextension enthaltenen Elemente) zu jedem Zeitpunkt erfüllen müssen. Das Schema [[deklariert]] insbesondere die [[Methoden]], die für jedes Objekt der Klassenextension jederzeit als [[Schnittstelle|Kommunikationsschnittstelle]] zur Verfügungstehen müssen.
Eine Klasse, deren Extension genau ein Objekt enthält, heißt '''Singleton-Klasse''' oder kurz '''Singleton'''.
 
*beliebig vielen (0, 1, 2, ...) [[Klassenimplementierung]]en: Diese implementieren die im Klassenschema deklarierten Methoden teilweise oder vollständig und garantieren dabei die stete Erfüllung aller im Klassenschema definierten Integritätsbedingungen. Unterschiedliche Implementierungen können sich in Hinblick auf Performanz-Aspekte unterscheiden.


==Subklasse==
*den [[Klassenmethode]]n ([[statische Methode]]n): Eine Klasse verhält sich wie ein spezielles [[Objekt (OOP)|Objekt]]) und kann daher eigene (Klassen-)Methoden und (Klassen-)Attribute enthalten. Überlicherweise gibt es zumindest Methoden zur Verwaltung der Klassenextension, d.h. zum Erzeugen ([[Konstruktor]]en) und evtl. auch zum  Zerstören ([[Destruktor]]en) von zugeordneten Objekten.{{Absatz}}
Eine Klasse B heißt '''Subklasse''' A, wenn die Extension von B eine Teilmenge der Extension von A ist und wenn
===Subklasse===
[[Datei:UMLSubclass.jpg|links|gerahmt|UML-Klassen-<br>diagramm: Eine Superklasse und zwei Subklassen]]
Eine Klasse B heißt '''Subklasse''' der Klasse A, wenn die Extension von B eine Teilmenge der Extension von A ist und wenn
die Integritätsbedingungen der Klasse A logisch aus den Integritätsbedingungen der Klasse B folgen:
die Integritätsbedingungen der Klasse A logisch aus den Integritätsbedingungen der Klasse B folgen:


Zeile 30: Zeile 57:
Das heißt, jedes Objekt aus der Extension von B liegt nicht nur auch in der Extension von A, sondern erfüllt auch alle Integritätsbedingungen von A.
Das heißt, jedes Objekt aus der Extension von B liegt nicht nur auch in der Extension von A, sondern erfüllt auch alle Integritätsbedingungen von A.


=Bemerkungen=
Die Subklasse B erbt alle Implementierungen der Superklasse A, kann diese jedoch „überschreiben“ (ersetzen).  
==Klassenextension==
Die meisten objektorientierten Programmiersprachen verwalten die Klassenextension nur intern. Das heißt, ein Programmierer kann nicht direkt darauf zugreifen. Es ist allerdings problemlos möglich, die Verwaltung einer Klassenextension mit Hilfe von Klassenzustandsvariablen und -methoden zu realisieren.


[[Objektorientiertes Datenbanksystem|Objektorientierte Datenbanksysteme]] machen die Klassenextension dagegen immer allen Benutzern zugänglich, die die entsprechenden Rechte haben. In derartigen Systemen wird an Stelle des Begriffs [[Klassenextension]] üblicherweise der Begriff [[Tabelle]] verwendet. Die dauerhafte Speicherung von Daten in Tabellen ist die wesentliche Aufgabe eines jeden [[Datenbanksystem]]s.
Siehe auch: [[Vererbung (OOP)|Vererbung]]
{{Absatz}}


==Klassenschema==
===Superklasse===


Ein Klassenschema ist laut Definition nichts weiter, als eine Menge von [[Integritätsbedingung]]en, die jedes Objekt erfüllen muss, dass der
Eine Klasse A heißt '''Superklasse''' der Klasse B genau dann wenn die Klasse B '''Subklasse''' der Klasse A ist.
zugehörigen Klasse angehört.  


Eine [[Signatur|Methoden-Signatur]] ist eine spezielle Integritätsbedingung, bestehend aus [[Zugriffsbeschränkung]]en (public, private, protected, internal etc.), [[Methode]]nnamen, [[Parameter|Eingabeparametern]] samt zugehörigen [[Datentyp]]en sowie den Datentypen der Methodenergebnisse.
Siehe auch: [[Vererbung (OOP)|Vererbung]]
{{Absatz}}


Das Vorhandensein einer Methoden-Signatur in einem Klassenschema definiert eine [[Invariante]]: Eine Methode,
===Abstrakte Klasse===
die dieser Signatur genügt, muss dauerhaft zur Kommunikation mit den Objekten der Klasse, die gemäß der Zugriffsbeschränkung Zugriff haben, zur Verfügung stehen.  
[[Datei:UMLAbstractClass.jpg|links|gerahmt|UML-Klassendiagramm: Abstrakte Klasse]]
Eine Klasse, für die es keinen [[Konstruktor]] gibt, der direkt (und nicht nur vom Konstruktor einer Subklasse aus) aufgrufen wernden kann,
heisst '''[[abstrakte Klasse]]'''. Die Klassenimplementierungen, die einer abstrakten Klasse direkt (d.h. nicht indirekt in Subklassen) zugeordnet sind, können unvollständig sein. {{Absatz}}
===Schnittstelle (Interface)===
[[Datei:UMLInterface.jpg|links|gerahmt|UML-Klassen-<br>diagramm: Interface]]
Eine Klasse, für die es keine Klassenimplementierung gibt, heißt '''Schnittstelle''' oder '''Interface'''.
{{Absatz}}
====Anmerkung====
Jede '''Schnittstelle''' ist auch eine abstrakte Klasse.


Außerdem definiert jede Signatur eine [[Vorbedingung]] (zum Zeitpunkt des Methodenaufrufes müssen die [[Argument]]e den Bedingungen genügen, die
Interfaces unterstützen i. Allg. auch keine Klassenmethoden.
in der Signatur an die Eingabeparameter gestellt werden) und eine [[Nachbedingung]] (die Methodernergebnisse genügen den in der Signatur geforderten Ergebnisdatentypen).
Dies wurde aber in der obigen Definition nicht explizit gefordert.


===Beispiel===
{{Absatz}}
<source lang="actionscript3">
===Metaklasse===
public class Person
[[Datei:UMLMetaclass.jpg|links|gerahmt|UML-Klassen-<br>diagramm: Eine Metaklasse und eine Metametaklasse]]
{
Eine Klasse, deren Extension zu jedem Zeitpunkt ausschließlich Klassen(objekte) enthält, heißt '''[[Metaklasse]]'''.
  private var v_birthday: Date;
 
  // Method "age"
  public function age(p_date: Date = null): int
  {
    if (p_date == null)
      p_date = new Date();


    return (    (v_birthday.month > p_date.month)
===Metametaklasse===
            || ((v_birthday.month = p_date.month) &&
                (v_birthday.date  > p_date.date)
              )
          )
          ? p_date.fullYear - v_birthday.fullYear - 1
          : p_date.fullYear - v_birthday.fullYear
  }
   
  // Constructor
  public function Person(p_birthday: Date)
  {
    v_birthday = p_birthday;
  }
}
</source>


Jedes Personenobjekt, d.h. jedes Element der Extension der Klasse <code>Person</code>
Eine Klasse, deren Extension zu jedem Zeitpunkt ausschließlich Metaklassen(objekte) enthält, heißt '''[[Metaklasse|Metametaklasse]]'''.
stellt eine Methode <code>age</code> zur Verfügung,   
<source lang="actionscript3">
public function age(p_date: Date = null): int
</source>
auf die jedes (<code>public</code>) andere Objekt zugreifen darf:


<source lang="actionscript3">
===Metametametaklasse===
var wolfgang: Person = new Person(new Date(1961, 5, 5));
     
trace(wolfgang.age());
trace(wolfgang.age(new Date(2011,5,2)));
trace(wolfgang.age(new Date(2011,5,11)));
trace(wolfgang.age('2011-05-11'));  // Fehler (zur Compilezeit),
                                    // da die Vorbedingung
                                    // „das Argument ist vom Typ Date“
                                    // nicht erfüllt ist.
</source>


Der Eingabeparameter muss nicht angegeben werden (Defaultwert <code>null</code>), aber
Und so weiter ...
falls er angegeben wird, muss er vom Typ <code>Date</code> sein (Vorbedingung).
Die Methode <code>age</code> liefert eine Integerzahl zurück (Nachbedingung).  


Dass <code>age</code> (als Nachbedingung!) das Alter der aktuellen Person zu einem bestimmten Datum bzw. zum
{{Absatz}}
aktuellen Datum (falls <code>p_date == null</code>) ermittelt, lässt sich der Signatur dagegen nicht entnehmen.
===Singleton-Klasse===
Hierfür wäre die Angabe von weiteren Integritätsbedingungen notwendig, was aber nur von wenigen Sprachen, wie z.B. [[Eiffel]],
[[Datei:UMLSingleton.jpg|links|gerahmt|UML-Klassen-<br>diagramm: Singleton-Klasse]]
unterstützt wird. Eine weitere (deutlich schwächere) Nachbedingung wäre z.B., dass das Resultat positiv sein muss,
Eine Klasse, deren Extension genau ein Objekt enthält, heißt '''Singleton-Klasse''' oder kurz '''Singleton'''.
wenn das übergebene Datum <code>p_date</code> größer ist, als das Geburtsdatum. Diese Bedingung wird z.B. verletzt,
wenn <code>p_date</code> so groß gewählt wird, dass das Alter größer ist als die größte darstellbare Integerzahl.
Um gerade vor solchen Überraschungen gefeit zu sein, ist der Einsatz von Integritätsüberprüfungen,
die über die Angabe von Signatur-IUnformationen hinaus gehen, sehr emphelenswert.
 
Bislang wurde gezeigt, dass die Signatur der Methode <code>age</code> eine Vor- und eine Nachbedingung formuliert.
Sie formuliert allerdings auch eine Invariante: Die Methode <code>age</code> existiert dauerhaft, d.h. sie kann nicht
entfernt oder verändert werden:
 
<source lang="actionscript3">
wolfgang.age = null; // Fehler (zur Compilezeit)
</source>
 
Dies ist nicht so selbstverständlich, wie es zunächst scheint. Wäre (in ActionScript) die Klasse Person als dynamisch deklariert worden
<source lang="actionscript3">
public dynamic class Person
{
  ...
}
</source>
so könnten jedem Personenobjekt jederzeit neue Methoden zugefügt werden. Und diese können auch wieder entfernt werden:


<source lang="actionscript3">
==Bemerkungen==
wolfgang.ageChristmas2011 = function (): int { return wolfgang.age(new Date(2011,12,24)); };
In der Definition des UML-Standards ist die Klasse ein spezieller Klassifikator. Ein Klassifikator beschreibt eine Menge von Objekten (Instanzen),
die gemeinsame Eigenschaften haben. Hier klingen die Begriffe „Klassenextension“ („set of instances“) und „Integritätsbedingungen“ („features“) bereits an, sind aber recht vage gehalten. Bei der Definition des Begriffes „Klasse“ wird die Extension abermals explizit erwähnt („set of objects“),
daruber hinaus wird auch explizit von „constraints“ gesprochen. Methoden und Attribute  („features“ einschließlich der zugehörigen „semantics“) werden
jedoch gesondert genannt, während sie in der Definition von Kowarschick als spezielle Integritätsbedingungen verstanden werden. Die Methodenimplementierungen sowie die Klassenmethoden fehlen in der UML-Definition vollkommen. Daher unterscheiden sich die beiden Definitionen von
„Classifier“ und „Class“ inhaltlich kaum, obwohl das zweite eine Spezialfall des ersten ist.


trace(wolfgang.ageChristmas2011());
Schnittstellen werden in UML 2.3 als spezielle Klassifikatoren definiert. Kowarschick definiert sie dagegen als spezielle Klassen. Das heißt, die Definition von UML 2.3 ist etwas allgemeiner (aber auch etwas schwammiger).


wolfgang.age = null;                // immer noch ein Fehler (zur Compilezeit)
Abstakte Klassen werden sowohl in UML 2.3, als auch bei Kowarschick als spezielle Klassen aufgefasst. Allerdings ist die Definition
wolfgang.ageChristmas2011 = null;  // kein Fehler
von UML 2.3 missverständlich: Selbstverständlich enthält auch die Klassenextension einer abstrakten Klasse Instanzen. Diese Extension kann allerdings keine Objekte enthalten, die nicht auch Element der Extension einer nicht-abstrakten Subklasse sind. Das heißt,
die Extension einer abstrakten Klasse kann keine „eigenen“ Instanzen enthalten.  


trace(wolfgang.ageChristmas2011()); // jetzt ein Fehler (zur Laufzeit), ageChristmas2011 existiert nicht mehr
Die von Kowarschick verwendenten Begriffe [[Klassenschema]] und [[Klassenextension]] haben ihren Ursprung in der Datenbankwelt:
</source>
Diese Bezeichnungen betonen die Verwandschaft
zwischen [[Objektorientiertes Paradigma|objektorientierten Systemen]] und [[Datenbanksystem]]en:


==Metaklassen==
{|class="wikitable"
Eine Klasse, die dazu dient andere Klassen zu definieren, wird [[Metaklasse]] genannt. Eine Klasse, die dazu dient Metaklassen zu definieren,
|-
heißt entsprechend [[Metametaklasse]]. Und so weiter. Die meisten objektorientierten Systeme unterstützen jedoch keine Metaklassen. In diesen Systemen wird eine Klasse als ein spezielles Objekt aufgefasst, das direkt, d.h. ohne Zuhilfenahme einer anderen Klasse, definiert werden muss.
!Objektorientierte Systeme || Datenbanksysteme
Dies stellt jedoch keinen Widerspruch zum hier verwendeten [[Objekt (OOP)|Objektbegriff]] dar (siehe dort insb. den [[Objekt (OOP)#Klassen|Abschnitt „Klassen“]]).
|-
| [[Klasse (OOP)|Klasse]] || [[Relation (DB)|Relation]]/[[Tabelle]]
|-
| [[Klassenschema]] || [[Relationenschema]]
|-
| [[Klassenextension]] || Extension einer Relation (= Menge aller Tupel)
|-
| [[Objekt]] || [[Tupel]]/[[Entität]]
|-
| [[Attribut]]/[[Zustandsvariable]] || [[Attribut]]
|-
|}


=Quellen=
Ja, sogar die in objektorientierten Sprachen so weit verbreitete
Punktnotation (<code>myCar.maxSpeed</code>) wurde aus der Datenbankwelt (SQL) übernommen.


*[[Kowarschick, W.: Multimedia-Programmierung]]
==Quellen==
*[[Kowarschick, W. (2002): Multimedia-Programmierung - Objektorientierte Grundlagen]]
<references/>
*[[Kowarschick, W. (2002): Skriptum zur Vorlesung Multimedia Softwareentwicklung II]]
<ol>
<li value="4">{{Quelle|Kowarschick, W. (2002): Multimedia-Programmierung - Objektorientierte Grundlagen}}</li>
</ol>


=Siehe auch=
==Siehe auch==


[[Wikipedia:Klasse (objektorientierte Programmierung)|Wikipedia: Klasse (objektorientierte Programmierung)]]<noinclude>[[Kategorie:Objektorientierte Programmierung]]
# [[Wikipedia:Klasse (objektorientierte Programmierung)|Wikipedia: Klasse (objektorientierte Programmierung)]]<noinclude>[[Kategorie:Objektorientierte Programmierung]]
[[Kategorie:Glossar]][[Kategorie:Programmierung]]
[[Kategorie:Glossar]]
[[en:Class (OOP)]]
[[en:Class (OOP)]]
[[Kategorie:Kapitel:Multimedia-Programmierung]]
[[Kategorie:Kapitel:Multimedia-Programmierung]]</noinclude>
{{{{SITENAME}}-konformer Artikel}}</noinclude>

Aktuelle Version vom 6. Dezember 2016, 17:47 Uhr

Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:

Korrektheit: 4
(großteils überprüft) 		Umfang: 5
(wesentliche Fakten vorhanden) 		Quellenangaben: 2
(wichtige Quellen fehlen) 		Quellenarten: 3
(gut) 		Konformität: 4
(sehr gut)

Definitionen (OMG: UML 2.3)

Classifier[1]

A classifier is a classification of instances — it describes a set of instances that have features in common.

Übersetzung (von W. Kowarschick):

Ein Klassifikator [Classifier] ist eine Klassifikation von Objekten — er beschreibt eine Menge von Objekten, die Eigenschaften gemein haben.

Class[1]

A class describes a set of objects that share the same specifications of features, constraints, and semantics.

Übersetzung (von W. Kowarschick):

Eine Klasse beschreibt eine Menge von Objekten, die sich dieselben Spezifikationen von Eigenschaften, [Integritäts-]Bedingungen und Semantik teilen.

Abstract Classifier, Abstract Class[1]

Laut UML-2.3-Standard hat jeder Klassifikator und damit auch jede Klasse ein Attribut isAbstract. Für dieses gilt folgende Bedingung:

If true, the Classifier does not provide a complete declaration and can typically not be instantiated.

Übersetzung (von W. Kowarschick):

Falls [dieses Attribut den Wert] wahr [hat], bietet der Klassifikator keine vollständige Deklaration und kann typischerweise nicht instanziiert werden.

Interface[2]

An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract.

Übersetzung (von W. Kowarschick):
Eine Schnittstelle [ein Interface] ist eine [spezielle] Art eines Klassifikators [Classifiers], der die Deklaration einer Menge von kohärenten offentlichen Eigenschaften und Verpflichtungen [im Sinne von Constraints] definiert. Eine Schnittstelle spezifiziert einen Vertrag; jedes Objekt eines Klassifikators, das die Schnittstelle realisiert, muss diesen Vertrag erfüllen.

Definitionen (von W. Kowarschick)[3]

Klasse

UML-Klassen-
diagramm: Eine Klasse und ein Klassen-Template

Eine Klasse dient (im Sinne des objektorienten Paradigmas) dazu, die Schnittstellen und evtl. auch eine oder gar mehrere Implementierungen von „gleichartigen“ Objekten ganz oder zumindest teilweise festzulegen.

Eine Klasse besteht aus folgenden Teilen:

  • einer Klassenextension: Die Klassenextension ist eine (i. Allg. endliche) Menge, die zu jedem Zeitpunkt genau diejenigen Objekte, die der Klasse zugeordnet sind, enthält.
  • beliebig vielen (0, 1, 2, ...) Klassenimplementierungen: Diese implementieren die im Klassenschema deklarierten Methoden teilweise oder vollständig und garantieren dabei die stete Erfüllung aller im Klassenschema definierten Integritätsbedingungen. Unterschiedliche Implementierungen können sich in Hinblick auf Performanz-Aspekte unterscheiden.
  • den Klassenmethoden (statische Methoden): Eine Klasse verhält sich wie ein spezielles Objekt) und kann daher eigene (Klassen-)Methoden und (Klassen-)Attribute enthalten. Überlicherweise gibt es zumindest Methoden zur Verwaltung der Klassenextension, d.h. zum Erzeugen (Konstruktoren) und evtl. auch zum Zerstören (Destruktoren) von zugeordneten Objekten.

Subklasse

UML-Klassen-
diagramm: Eine Superklasse und zwei Subklassen

Eine Klasse B heißt Subklasse der Klasse A, wenn die Extension von B eine Teilmenge der Extension von A ist und wenn die Integritätsbedingungen der Klasse A logisch aus den Integritätsbedingungen der Klasse B folgen:

Integritätsbedingungen(B) ⇒ Integritätsbedingungen(A)

Das heißt, jedes Objekt aus der Extension von B liegt nicht nur auch in der Extension von A, sondern erfüllt auch alle Integritätsbedingungen von A.

Die Subklasse B erbt alle Implementierungen der Superklasse A, kann diese jedoch „überschreiben“ (ersetzen).

Siehe auch: Vererbung

Superklasse

Eine Klasse A heißt Superklasse der Klasse B genau dann wenn die Klasse B Subklasse der Klasse A ist.

Siehe auch: Vererbung

Abstrakte Klasse

UML-Klassendiagramm: Abstrakte Klasse

Eine Klasse, für die es keinen Konstruktor gibt, der direkt (und nicht nur vom Konstruktor einer Subklasse aus) aufgrufen wernden kann,

heisst abstrakte Klasse. Die Klassenimplementierungen, die einer abstrakten Klasse direkt (d.h. nicht indirekt in Subklassen) zugeordnet sind, können unvollständig sein.

Schnittstelle (Interface)

UML-Klassen-
diagramm: Interface

Eine Klasse, für die es keine Klassenimplementierung gibt, heißt Schnittstelle oder Interface.

Anmerkung

Jede Schnittstelle ist auch eine abstrakte Klasse.

Interfaces unterstützen i. Allg. auch keine Klassenmethoden. Dies wurde aber in der obigen Definition nicht explizit gefordert.

Metaklasse

UML-Klassen-
diagramm: Eine Metaklasse und eine Metametaklasse

Eine Klasse, deren Extension zu jedem Zeitpunkt ausschließlich Klassen(objekte) enthält, heißt Metaklasse.

Metametaklasse

Eine Klasse, deren Extension zu jedem Zeitpunkt ausschließlich Metaklassen(objekte) enthält, heißt Metametaklasse.

Metametametaklasse

Und so weiter ...

Singleton-Klasse

UML-Klassen-
diagramm: Singleton-Klasse

Eine Klasse, deren Extension genau ein Objekt enthält, heißt Singleton-Klasse oder kurz Singleton.

Bemerkungen

In der Definition des UML-Standards ist die Klasse ein spezieller Klassifikator. Ein Klassifikator beschreibt eine Menge von Objekten (Instanzen), die gemeinsame Eigenschaften haben. Hier klingen die Begriffe „Klassenextension“ („set of instances“) und „Integritätsbedingungen“ („features“) bereits an, sind aber recht vage gehalten. Bei der Definition des Begriffes „Klasse“ wird die Extension abermals explizit erwähnt („set of objects“), daruber hinaus wird auch explizit von „constraints“ gesprochen. Methoden und Attribute („features“ einschließlich der zugehörigen „semantics“) werden jedoch gesondert genannt, während sie in der Definition von Kowarschick als spezielle Integritätsbedingungen verstanden werden. Die Methodenimplementierungen sowie die Klassenmethoden fehlen in der UML-Definition vollkommen. Daher unterscheiden sich die beiden Definitionen von „Classifier“ und „Class“ inhaltlich kaum, obwohl das zweite eine Spezialfall des ersten ist.

Schnittstellen werden in UML 2.3 als spezielle Klassifikatoren definiert. Kowarschick definiert sie dagegen als spezielle Klassen. Das heißt, die Definition von UML 2.3 ist etwas allgemeiner (aber auch etwas schwammiger).

Abstakte Klassen werden sowohl in UML 2.3, als auch bei Kowarschick als spezielle Klassen aufgefasst. Allerdings ist die Definition von UML 2.3 missverständlich: Selbstverständlich enthält auch die Klassenextension einer abstrakten Klasse Instanzen. Diese Extension kann allerdings keine Objekte enthalten, die nicht auch Element der Extension einer nicht-abstrakten Subklasse sind. Das heißt, die Extension einer abstrakten Klasse kann keine „eigenen“ Instanzen enthalten.

Die von Kowarschick verwendenten Begriffe Klassenschema und Klassenextension haben ihren Ursprung in der Datenbankwelt: Diese Bezeichnungen betonen die Verwandschaft zwischen objektorientierten Systemen und Datenbanksystemen:

Objektorientierte Systeme Datenbanksysteme
Klasse Relation/Tabelle
Klassenschema Relationenschema
Klassenextension Extension einer Relation (= Menge aller Tupel)
Objekt Tupel/Entität
Attribut/Zustandsvariable Attribut

Ja, sogar die in objektorientierten Sprachen so weit verbreitete Punktnotation (myCar.maxSpeed) wurde aus der Datenbankwelt (SQL) übernommen.

Quellen

  1. ↑ 1,0 1,1 1,2 Unified Modeling Language (OMG UML), Infrastructure, Version 2.3, May 2010
  2. ↑ [http://www.omg.org/spec/UML/2.3/Superstructure/PDF/ OMG Unified Modeling Language (OMG UML), Superstructure, Version 2.3, May 2010]
  3. ↑ Kowarschick, W.: Multimedia-Programmierung
  1. Kowarschick (2002a): Wolfgang Kowarschick; Multimedia-Programmierung – Objektorientierte Grundlagen; Hrsg.: Michael Lutz und Christian Märtin; Reihe: Informatik interaktiv; Verlag: Fachbuchverlag Leipzig im Carl Hanser Verlag; ISBN: 3446217002; 2002; Quellengüte: 5 (Buch)

Siehe auch

  1. Wikipedia: Klasse (objektorientierte Programmierung)
Abgerufen von „https://glossar.hs-augsburg.de/w/index.php?title=Klasse_(OOP)&oldid=42062“