Wenn man über Objektorientierte Programmierung spricht, begibt man sich in ein komplexes Theoriekonstrukt, dass zunächsteinmal sehr abstrakt wirkt. Also pack ich die Sache andersherum an und versuche so praxisnah wie möglich zu schreiben, indem ich einfach davon ausgehe, dass sich der Rest in der Praxis ergibt.

Eines muss hier klar sein und zwar gibt es einen Unterschied, zwischen dem Produzieren von funktionsfähigen Code in einer Objektorientierten Sprache (darum geht es hier) und dem verinnerlichen des “Theoriemonsters”. Letzteres setzt meiner meinung nach ersteres voraus und wird überhaupt erst erreicht, wenn man sich an DesignPattern macht. DesignPattern schöpfen die Macht Objektorientierter Strukturen erst aus, ich plane auch hierzu noch das eine oder andere Tutorial.

Zurück zum Einstieg, hier werde ab und an eine Metapher nutzen, ich hoffe das ist kein Problem. Oder wenn ich etwas zehn mal nacheinander sage – hauptsache es bleibt hängen. In jedem Fall rate ich, sich die Sachen genau vorzustellen, denn eben so wird es am effektivsten hängen bleiben. Ok, dann mal los.

Schon mal Matrix gesehen? Was wäre wenn eine der Maschienen mist gebaut hätte und die Matrix wäre ausgefallen, zack sind all die Menschlein in ihren schleimblasen wach und zappeln rum. Kein Problem, die AdministratorMaschiene kommt herbeigeeilt und drückt auf den Reload Button (den hat auch warnerbrothers gedrückt und wir haben uns den Mist angesehen). Reload läuft, aber jetzt müssen all die virtuellen körper für die ganzen Menschlein erst erstellt werden.
Also bitte, enter the matrix:

Was ist eine Klasse? Ich bin das Produkt einer Klasse, die Lukas heißt und du bist das Produkt von einer, deren Namen später vieleicht in den Kommentaren auftaucht. Jedenfalls kennst den Namen, also lass uns unsere Klassen vergleichen. Ich trinke meinen Kaffee mit Zucker, arbeite gern spät bis in die Nacht hinein und höre Limp Bizkit. Da sollte in der Mehrheit der Fälle schon mal ein Unterschied zu dir bestehen. Ausserdem habe ich zwei Arme mit Händen dran und so ein Teil zwischen meinen Augen, dass aus meinem Gesicht hervorschaut. Mein Gott, du auch!?

Offensichtlich haben unsere Klassen, die nichts anderes darstellen, als der Bauplan für die Objekte, die wir sind, ihre Gemeinsamkeiten und Unterschiede. Das lässt sich sehr simpel begründen. Klassen können ihren Bauplan vererben und unsere Klassen erben auch beide von der selben Klasse: Mensch. Allerdings erben wir nicht direkt von “Mensch”, es gibt schließlich nur zwei Klassen, die das unmittelbar können und zwar “Mann” und “Frau”, das sind die einzigen Klassen von denen unsere Klassen direkt erben. Mann und Frau besitzten alles, was die Klasse “Mensch” zur Verfügung stellt, haben aber auch ihre unterschiede. Dann kommen du und ich in der Hierarchie und haben/können alles was Frau oder Mann uns vererbt hat.

Nur was genau wird hier “zur Verfügung gestellt” wenn meine Klasse von der Klasse Frau oder Mann erbt? Das können nur zwei verschiedene Dinge sein: Eigenschaften und Methoden. Ich habe einige meiner Eigenschaften verraten, zum Beispiel “Limp Bizkit”. Doch diese Eigenschaft wurde direkt durch meine Klasse “Lukas” erstellt, denn weder die Klasse Mensch noch die Klasse Mann, deren Methoden und Eigenschaften in mich eingehen, erachten Limp Bizkit als unabdinglich, für die Objekte die aus ihnen erschaffen werden sollen. Anders die dazugehörige Methode: Das Hören, denn das kommt direkt aus der Klasse Mensch und steht somit allen Objekten zur Verfügung, deren Klasse von dieser Klasse abstammen.

Knock Knock, neo. Zeit den Stecker zu Ziehen und wieder in die Realität Objektorientierter Programmierung einzusteigen:

// Dieser Code wurde "maschinell" erstellt...
public class Mensch {
 
	function hoere(aritst:String)
	{
		trace(artist);
	}
}

// ...um anschließend erweitert zu werden...
public class Mann extends Mensch {
 
	// na? was macht einen echten Mann aus?
}

// ...damit ich neu erstellt werden kann...
public class Lukas extends Mann {
 
	var artist :String = "Limp Bizkit";
}

Alles klar, jetzt muss ich nur noch erstellt werden. Dazu wird eine Variable für mich angelegt, namens luke. Diese Variable repräsentiert den Arbeitsspeicher, in den das Objekt geladen wird, das von der Klasse Lukas erstellt worden ist. Dann kann man bequem über den punkt auf die funktionen oder eigenschaften des Objekts zugreifen.

var luke = new Lukas();
luke.hoere(luke.artist);

Fazit:
Klassen bestehen aus Methoden und eigenschaften, die sie vererben können, bzw. überhaupt erst bekommen, indem sie von klassen erben. Eigenschaften sind werte in form von variablen, methoden sind funktionen, die in aller regel mit diesen Werten abreiten. Doch eine Klasse ist nicht das Objekt selbst, sondern der Bauplan dazu.

In der Praxis
Das populärste Beispiel, man exportiert einen clip aus der Bibliothek, nennt ihn myClip und es wird einem weiter untent Prompt die BasisKlasse angezeigt, von der diese erbt: Der MovieClip. Flash erstellt an dieser stelle eine neue Klasse namens “myClip”. Und so produziert man dann das resultierende Objekt:

var clip = new myClip();

Wenn euch das geholfen hat, oder ihr euch auskotzen wollt: Hinterlasst einen Kommentar.

Euer weises Kaninchen.