Quelltext der Seite Ruby/Vererbung

== Die Vererbung ==

Hier geht es nun speziell um die Überschrift, bzw. dessen Inhalt.
Natürlich kommt nun zunächst die Frage auf: "Was bringt mir Vererbung?!".

Um das zu verstehen sollte man nocheinmal über den Sinn von Klassen denken:
Klassen sind dazu da ein Muster von Eigenschaften und Fähigkeiten zu gruppieren, um jene so strukturierter und übersichtlicher verwenden zu können. Wenn man sich jedoch vorstellt, man schreibe eine große Klasse, ähnlich wie Window in RGSS(2) mit all' seinen "anderen Scripten", so muss man sich eingestehen, dass selbst die Klasse dann ZU groß und ZU unübersichtlich wird. Wenn dann noch ein Fehler d'rin steckt, beginnt das spaßige Suchen.
Um dieses Problem zu umgehen, und um einen weiteren Vorteil zu erlangen, nutzt man die Vererbung.


== Vorteile der Vererbung ==

Über die Vererbung lassen sich nicht nur Klassen stutzen. Dies wäre auch sehr unspektakulär, da das Größenproblem beispielsweise in der Scripts.rxdata dadurch gelöst wurde, dass man die Scripte mehrfach untereinander schrieb (z.B. Interpreter1-7).
Der wichtigste Punkt ist der Grund, weshalb es Methoden gibt. Methoden haben die Aufgabe, Doppelcodes zu vermeiden, also Programmmuster, die immer wieder auftauchen (wie z.B. im Maker einen Schritt mit dem Helden machen). Warum tut man dies? Sicher, ein einzelner Codeblock ohne Methoden usw., stur runtergerattert ist in der Maschine zwar - Wenn auch unter normalen Bedingungen minimal - schneller, doch sollte eines dieser Codeabschnitte einen Fehler haben, oder sollte jenes verbessert werden, so gilt es, JEDES dieser Muster einzeln zu ändern. Durch das Auslagern auf Methoden muss man nur den Inhalt der Methode einmal ändern, und schon gilt dies für sämtliche Aufrufe.
Ähnliches gibt es bei Klassen. Viele Scripte haben ähnliche Eigenschaften/Fähigkeiten, wie bestimmte andere Scripte. So erstellen die Hilfe-Fenster und das Schritte-Fenster (?) und das normale Nachrichten-Fenster und andere aus RGSS(2) schlicht ein Fenster aus einer Bilddatei und schreiben darauf einen Text. Um jetzt viele Doppelcodes aus denselben Gründen wie bei den Methoden zu ersparen, erstellt man eine art "Grundklasse", auch "Elternklasse" oder "Superklasse".


== Wie (ver)erben Klassen? ==

Zunächst brauchen wir unsere Klassen, die was können sollen. Diese sollen nun gänzlich verschieden sein, jedoch einige Gemeinsamkeiten haben. Ich nahm mir mal Beispiele aus dem Tierreich:

<source lang="ruby">class Hund
  @@beine = 4
  def pinkeln()
    print("Welch' Erleichterung...!")
  end
  def bellen()
    print("miau")
  end
end

class Katze
  @@beine = 4
  def pinkeln()
    print("Welch' Erleichterung...!")
  end
  def miauen()
    print("wuff")
  end
end
</source>
Wenn man nun genauer hinschaut, haben die Tiere was gemeinsam, und das trotz unterschiedlicher Spezien: Beide können pinkeln, und beide haben vier Beine! Man könnte diese Tiere also gruppieren. Nur wie? Man könnte nun aufgrund der Tatsache, dass fast alle Haustiere in Deutschland Hunde und Katzen sind, eine Klasse "Haustier" als Oberklasse erdenken. Doch welche Eigenschaften hätte diese nun? Richtig! Pinkeln und vier Beine! Also erstellen wir unsere Oberklasse:

<source lang="ruby">class Haustier
  @@beine = 4
  def pinkeln()
    print("Welch' Erleichterung...!")
  end
end
</source>
Nun haben wir alle Gemeinsamkeiten zusammengefasst. Doch wie gebe ich diese nun an die Haustiere Hund und Katze weiter? Dies geht ganz schnell mit dem "<"-Operator.

<source lang="ruby">class Tochterklasse < Elternklasse</source>

Mit diesem Code übernimmt die Tochterklasse ausnahmslos alle Eigenschaften und Funktionen der entsprechenden Elternklasse. Somit müssen unsere Haustiere wie folgt umgeschrieben werden:

<source lang="ruby">class Hund < Haustier
  def bellen()
    print("miau")
  end
end

class Katze < Haustier
  def miauen()
    print("wuff")
  end
end
</source>
Es fällt auf, dass die Klassen um Einiges kleiner geworden sind. Dies bedeutet jedoch nicht, dass diese nun weniger können! Ruft man nun als Befehl folgendes auf...
<source lang="ruby">wanwan = Hund.new()
wanwan.pinkeln() #Selbes gilt auch für die Katze ;)
</source>
... so stellt man fest, dass "wanwan" eine große Erleichterung hat.


== Methoden bei Vererbung erweitern ==

Es wäre natürlich höhst unspektakulär, wenn dies schon alles wäre, was die Vererbung zu bieten hätte...
Schauen wir uns doch noch einmal unsere Haustiere an. Beide Haustiere können pinkeln. Doch wenn man selbst Hund und Katze hat, oder zumindest bekannte, so dürfte schnell auffallen, dass beide Spezien unterschiedliche "Vorgehensweisen" bei ihrer Erleichterung haben. Katze geht auf's Klo, Hund hebt das Bein.
Sollte nun alles unsprichwörtlich für die Katz' sein? Müssen wir nun doch die Methoden für jede Spezies neu schreiben? Glücklicher Weise nicht! Die Vererbung bietet Grundmuster. Unser Grundmuster ist die Erleichterung nach einem Stuhlgang. Jeder hat dies, auch wenn das Verhalten zum Ziel unterschiedlich ist. Wir müssen also nur das alte Muster erweitern. Hierbei hilft uns eine besondere Methode:
<source lang="ruby">super()</source>
Wie der Name erahnen lässt, greift super() auf die entsprechende Superklasse zu. Das klingt jetzt erstmal kompliziert. super() alleine jedoch kann nichts. Die Methode muss innerhalb einer anderen Methode aufgerufen werden, um eine gleichnamige der Superklasse auszuführen. Zur besseren Verständnis hier ein Beispiel:
<source lang="ruby">class Hund < Haustier
  def pinkeln()
    super()
  end
  def bellen()
    print("wuff")
  end
end
</source>
Es fällt zunächst auf, dass die Methode pinkeln() plötzlich wieder d'rin steckt. Lässt man nun unseren "wanwan" pinkeln, so stellen wir fest, dass sich jedoch nichts verändert hat, "wanwan" ist nach wie vor erleichtert. Was genau ist also passiert? Die Methode "super()" steckte derzeit innerhalb der Methode "pinkeln()". Beim Aufruf von "super()" wird nun die Superklasse gesucht (Haustier), und dessen Methode "pinkeln()" ausgeführt.
So weit, so gut, doch unser Hund kann immernoch kein Bein heben, und die Katze kein Klo nutzen. Wir wissen jedoch, dass super() immer die Originalmethode der Superklasse - also hier das Erleichtern - aufruft. Wir können nun also das Beinheben oder Klonutzen VOR dem Aufruf von Super einbauen:
<source lang="ruby">class Hund < Haustier
  def pinkeln()
    print("*Bein heb'*")
    super()
  end
  def bellen()
    print("miau")
  end
end

class Katze < Haustier
  def pinkeln()
    print("*auf's Klo geh'")
    super()
  end
  def miauen()
    print("wuff")
  end
end
</source>
Testet man nun diese beiden Tiere, so stellen wir fest, dass sie nun ihr natürliches Verhalten aufweisen.


== Parameter bei super() ==

Der ein oder andere dürfte sich sicherlich schon gefragt haben, wozu diese leeren Klammern bei "super()" gut sind. Methoden einer Superklasse übernehmen gerne mal auch Parameter. So z.B. übernimmt die Window_Base von RGSS(2) zur Erstellung 4 Zahlen, die Position und Größe darstellen. Die ganzen Tochterklassen werden allerdings auch für bestimmte Größen geschrieben oder sind einstellbar, und dies soll auch so bleiben.
<source lang="ruby">class Basisfenster
  def initialize(x,y,w,h)
    #Viel hässlicher Code
  end
end
</source>
So könnte eine solche Methode aussehen, die unser Fenster nach vorgegebenen Größen erstellt. Nun wollen wir allerdings ein spezielles Fenster haben, das wir oft nutzen. Ein 64*32px großes Fenster an der oberen linken Bildschirmecke z.B.. Da wir dieses Fenster (z.B. für einen HUD) oft benutzen werden, machen wir also dierekt eine neue Klasse, die alles kann, was wir brauchen. Da sie die Eigenschaften eines Basisfensters haben soll, vererben wir also die Klasse. Mit super() müssen wir dann den Inhalt des Constructors (initialize()) übernehmen. Nun hat dieser allerdings vier Parameter. Jeder Parameter einer Methode muss nun in super() in die Klammern geschrieben werden. Das Endergebnis sieht wie folgt aus:
<source lang="ruby">class HUD_Fenster < Basisfenster
  def initialize()
    super(0,0,64,32)
    #Eventuell noch was...
  end
end
</source>
Wie man sieht, habe ich hier in der Klammer an super() Werte übergeben. Diese werden nun an die Superklasse weitergereicht und verwendet. Es wird nun also ein Basisfenster in der oberen linken Ecke mit den Maßen 64*32px erstellt. Danach folgt dann der restliche Code.


== Was man beachten sollte ==

Vererben hat - ebenso wie Methoden - gewisse Vorteile, jedoch auch Nachteile, die in der Geschwindigkeit liegen. Darauf sollte man vor Allem deshalb achten, weil Ruby keine sehr schnelle Sprache ist. Um sich dies besser vorstellen zu können, muss man sich etwas in unseren ach so großen RAM hinein versetzen. Unser laufendes Ruby-Programm liegt in Form von einer Sammlung aus Codeblöcken im Speicher. Jeder dieser Codeblocks hat eine eigene Adresse und entspricht hierbei unseren Methoden. Ein Computer kann nunmal nichts weiter, als die Speicherzellen Byte für Byte durchzukauen. Sobald eine Methode aufgerufen wird, wird dem Prozessor aufgetragen, im RAM zur anderen Codestelle zu hüpfen, und sich die vorherige Adresse zu merken. Bei großen komplexen Methoden ist dies mehr als nur sinnvoll, da dies den gesamten Code kürzer macht. Sollte eine Methode jedoch oft aufgerufen werden, allerdings nur sehr kurz sein (wie z.B. die Methode "pinkeln()" von eben), so muss der Prozessor erst abbrechen und die aktuelle Adresse merken, zum Einzeiler hüpfen, diesen kurz ausführen, wieder zurück zur gemerkten Adresse fliegen, weiter machen, und wieder zur Methode, usw. ... Auf Dauer geht dies stark auf die Rechenleistung ein.
Allerdings kann selbes auch für große Methoden gelten, allerdings harmloser: Man stelle sich im Extremfall eine sehr lange Methode vor, die jedoch nur einmal innerhalb einer anderen Mehode aufgerufen wird. In diesem Fall würde der Prozessor also mehr als unnötig einen Sprung machen. In diesem Fall wäre es sinnvoller, für den Codeblock KEINE neue Methode zu erstellen.
Es gilt: Ein-/zwei-zeilige häufig auftretende Methoden oder riesige selten genutzte Methoden schreibt man am besten - unter Ausnahmen - dierekt zu den anderen, die diese aufrufen, selbst wenn dies Doppelcode bedeutet. (Beim Maker ist dies jedoch nicht sonderlich von Belang)