Klasse (OOP): Unterschied zwischen den Versionen
Kowa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Kowa (Diskussion | Beiträge) |
||
Zeile 92: | Zeile 92: | ||
In der Definition des UML-Standards, klingen die Begriffe „Klassenextension“ („set of objects“) und „Integritätsbedingungen“ („constraints“) an, sind aber recht vage gehalten. Methoden („features“ einschließlich der zugehörigen „semantics“) werden als eigenständige Konstrukte aufgefasst, 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. | In der Definition des UML-Standards, klingen die Begriffe „Klassenextension“ („set of objects“) und „Integritätsbedingungen“ („constraints“) an, sind aber recht vage gehalten. Methoden („features“ einschließlich der zugehörigen „semantics“) werden als eigenständige Konstrukte aufgefasst, 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. | ||
Die | Schnittstellen werden in UML 2.3 als spezielle Klassifikatoren definiert. Kowarschick definiert sie dagegen als spezielle Klassen (die gemäß UML-Standard allerdings auch spezielle Klassifikatoren sind). Das heißt, die Definition von UML 2.3 ist etwas allgemeiner (aber auch etwas schwammiger). | ||
Die von Kowarschick verwendenten Begriffe [[Klassenschema]] und [[Klassenextension]] haben ihren Ursprung in der Datenbankwelt: | |||
Diese Bezeichnungen betonen die Verwandschaft | Diese Bezeichnungen betonen die Verwandschaft | ||
zwischen [[Objektorientiertes Paradigma|objektorientierten Systemen]] und [[Datenbanksystem]]en: | zwischen [[Objektorientiertes Paradigma|objektorientierten Systemen]] und [[Datenbanksystem]]en: |
Version vom 13. März 2011, 12:01 Uhr
Definitionen (von OMG: UML 2.3)[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.
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.
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]
miniatur|rechts|300px|UML-Klassendiagramm: 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.
- einem Klassenschema (einer Klassenspezifikation): Das Klassenschema umfasst eine (endliche) Menge von Integritätsbedingungen, 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 Kommunikationsschnittstelle zur Verfügungstehen müssen.
- 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.
Abstrakte Klasse
miniatur|rechts|300px|UML-Klassendiagramm: Abstrakte Klasse Eine Klasse, für die es Klassenimplementierungen gibt, die die im Klassenschema definierten Methoden nicht vollständig implementieren, heisst abstrakte Klasse.
Schnittstelle (Interface)
miniatur|rechts|300px|UML-Klassendiagramm: 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
miniatur|rechts|300px|UML-Klassendiagramm: 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
miniatur|rechts|300px|UML-Klassendiagramm: Singleton-Klasse Eine Klasse, deren Extension genau ein Objekt enthält, heißt Singleton-Klasse oder kurz Singleton.
Subklasse
miniatur|rechts|300px|UML-Klassendiagramm: 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.
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
Bemerkungen
In der Definition des UML-Standards, klingen die Begriffe „Klassenextension“ („set of objects“) und „Integritätsbedingungen“ („constraints“) an, sind aber recht vage gehalten. Methoden („features“ einschließlich der zugehörigen „semantics“) werden als eigenständige Konstrukte aufgefasst, 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.
Schnittstellen werden in UML 2.3 als spezielle Klassifikatoren definiert. Kowarschick definiert sie dagegen als spezielle Klassen (die gemäß UML-Standard allerdings auch spezielle Klassifikatoren sind). Das heißt, die Definition von UML 2.3 ist etwas allgemeiner (aber auch etwas schwammiger).
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
- Kowarschick, W.: Multimedia-Programmierung
- Kowarschick, W. (2002): Multimedia-Programmierung - Objektorientierte Grundlagen
- Kowarschick, W. (2002): Skriptum zur Vorlesung Multimedia Softwareentwicklung II
Siehe auch
Wikipedia: Klasse (objektorientierte Programmierung)
- ↑ 1,0 1,1 [http://www.omg.org/spec/UML/2.3/Infrastructure/PDF/OMG Unified Modeling Language (OMG UML), Infrastructure, Version 2.3, May 2010]
- ↑ [http://www.omg.org/spec/UML/2.3/Superstructure/PDF/ OMG Unified Modeling Language (OMG UML), Superstructure, Version 2.3, May 2010]
- ↑ Kowarschick, W.: Multimedia-Programmierung