Wenn die beste Freundin von allen erklärt, sie wolle Visual Basic lernen, verunsichert das, wenn man sich selbst in der außergewöhnlichen Situation wiederfindet, ausgerechnet Bücher zu diesem Thema zu schreiben. Wenn die beste Freundin von allen erklärt, sie wolle Visual Basic mit deinem Buch lernen, löst das dann sogar große Panik aus! Die drohende Verantwortung wird geradezu erdrückend! Wie macht man aus „Schatz, das ist aber kein Einsteigerbuch“ am besten einen Euphemismus, mit dem man gut wegkommt? „Schatz, du bist nicht die Zielgruppe“. Vergisett. „Schatz, das Buch ist zu schwer für die Badewanne!“. Hmm. Die Ausrede ist zu offensichtlich. Geniestreich: Man bestellt ein Einsteigerbuch, Pardon, ein target-audiance-didaktisch geeignetes Buch, zudem von einem anderen Autor. Und man ist raus aus der Nummer, verantwortlich für falsche oder widersprüchliche Erklärungen zu sein, denn bis zu diesem Zeitpunkt hatte die beste Freundin von allen, die natürlich alle noch so euphemistisch formulierten Ratschläge in den Wind geschlagen hat, und dennoch mit dem eigenen Buch zu lernen begonnen hatte, auf den ersten 50 Seiten bereits 2 fette Fehler in eben diesem Buch gefunden.
Man ist raus aus der Nummer? Denkste! Der Schreiberlingkollege erklärte der besten Freundin von allen gerade, wozu das Schlüsselwort „Me“ gut sei. Und auch wenn eine Krähe der anderen kein Auge auskratzt: Er erklärte es nicht nur schlecht, er erklärte es zudem im falschen Kontext. Es gibt nämlich nur einen Grund, Me wirklich verwenden zu müssen – alle weiteren Verwendungen von Me sind nämlich nicht nur optional, sondern in vielen Fällen überflüssig. Immerhin schreibt er an der Stelle, dass man Me in seinem Beispiel auch weglassen könne, aber er schreibt nicht, wozu dann Me überhaupt erforderlich ist. Aber die beste Freundin von allen will es doch wissen! Und womit? Mit Recht!
Die kurze Erklärung, wann man Me (zu deutsch: mich) wirklich braucht, steht in der Überschrift: „Mach mich mal ne Stulle“ – wie wir im Sauerland sagen. Nicht verstanden? OK. Dann hier die etwas ausführlichere.
Wenn wir wissen wollen, wozu Me da ist, müssen wir wissen, was eine Klasse ist. Und wir müssen wissen was im Unterschied dazu die Instanz einer Klasse ist. OK. Als Denkhilfe verwenden wir Peter. Darf ich vorstellen: Das ist Peter:

Peter ist ein Knetäffchengenerator. Peter hält ein Förmchen in den Händen. Ein Förmchen nennen wir ab sofort nicht mehr Förmchen, sondern Klasse. (Klasse, nicht?) Und mit seinem Förmchen, in das wir Knete geben, macht Peter ganz viele Knetäffchen. Die sehen alle gleich aus, naja ähnlich, sie unterscheiden sich eigentlich nur durch ihre Farb-Eigenschaften – wie auch im Bild zu sehen. Und diese Knetäffchen nennen wir ab sofort Instanzen.
Das Gleiche passiert, wenn Sie mit Klassen programmieren. Schon wenn Sie ein Formular verwenden, dann benutzen Sie im Grunde genommen schon eine Instanz eines Formulars. Und Sie können aus einer Formularklasse (zum Beispiel mit dem Namen KlasseForm) viele Formularklassen machen:

Der Code, den wir benötigen, um diese Formulare in der angezeigten Form darzustellen, ist vergleichsweise übersichtlich. KlasseForm verfügt über zwei zusätzliche Eigenschaften, die folgendermaßen ausschauen:
Public Class KlasseForm
Private myGeborenAm As Date = Now
Public Property GeborenAm As Date
Get
Return myGeborenAm
End Get
Set(ByVal value As Date)
myGeborenAm = value
'Me ist Überflüssig, GeborenAmLabel ist eindeutig.
Me.GeborenAmLabel.Text = value.ToString("dddd, dd.MM.yy") & " um " &
value.ToString("HH:mm:ss") & " Uhr."
End Set
End Property
Public Property KlasseFormName As String
Get
Return NameLabel.Text
End Get
Set(ByVal value As String)
'Es benötigt kein Me an dieser Stelle - auch NameLabel ist eindeutig.
NameLabel.Text = value
End Set
End Property
End Class
Sobald diese Eigenschaften des Formulars von außen zugewiesen werden, spiegeln Sie sich im Inneren des Formulars wider. Das Hauptformular macht nun nichts anderes, als viele verschiedene Instanzen dieser KlasseForm-Klasse anzulegen, und das macht es auf diese Weise:
Public Class HauptForm
Private Sub ErstelleKlasseFormButton_Click(
ByVal sender As System.Object,
ByVal e As System.EventArgs) Handles ErstelleKlasseFormButton.Click
'Eine neue Instanz der Klasse erstellen und Datum und Namen vergeben
Dim einKlasseForm As New KlasseForm With
{.GeborenAm = Now, .KlasseFormName = NameFürNeuesKlasseFormTextBox.Text}
'Das Formular anzeigen
einKlasseForm.Show()
End Sub
End Class
Wie bei Peter (HauptForm), der mit seinem Förmchen (KlasseForm) ganz viele Knetäffchen (einKlasseForm=New KlasseForm), produziert das Hauptform ganz viele KlasseForm-Instanzen.
Und jetzt kommt der entscheidende Einsatz von Me: Was macht eine Instanz, wenn es sich selbst an eine andere Methode übergeben will? Eine Instanz des Formulars möchte jetzt sagen: „Färb mal meinen Hintergrund Rot ein!“. Es muss sich selbst irgendwie übergeben. Und genau dazu dient Me:
Angenommen, es gibt eine Methode in HauptForm, die es eine Funktionalität für „Mach mir mal ne Stulle“ zur Verfügung stellt. Und diese Methode erlaubt es, für ein KlasseForm diese Stulle zu machen. Dann sähe eine solche Methode wie folgt aus:
Public Shared Sub MachMirMalNeStulle(ByVal wem As KlasseForm)
'Ne Stulle können wir schlecht visualisieren,
'wir färben einfach nur den Hintergrund ein:
wem.BackColor = Color.Red
End Sub
Wie schafft es eine Instanz von KlasseForm nun beim Klick auf die Schaltfläche sich selbst an MachMitMalNeStulle von HauptForm zu übergeben? Ganz einfach – so:
Private Sub MachMirMalNeStulleButton_Click(
ByVal sender As System.Object,
ByVal e As System.EventArgs) Handles MachMirMalNeStulleButton.Click
HauptForm.MachMirMalNeStulle(Me)
End Sub
Es ist, als wenn Sie als Mama oder Papa eine Methode in sich tragen würden, ihren Kindern eine Stulle zu machen: Die Aufforderung “Mach *mir* mal ne Stulle” führt nicht immer zum selben Ergebnis. Je nachdem, welches Ihrer Kinder sie darum gebeten hat, ist Ergebnisempfänger der Methode. War es Lucian, dann war Lucian „Me“, und Lucian bekommt die Stulle. War es Laura-Marie, dann war Laura-Marie „Me“, und sie bekommt die Stulle.
Das ist der Hauptgrund, wieso Sie beim Entwickeln mit Klassen und Instanzen das Schlüsselwort „Me“ benötigen.
Namenskollisionen
Der Vollständigkeit halber: Es gibt einen weiteren Grund, Me zu verwenden, nämlich Namenskollisionen wegen unterschiedlichen Gültigkeitsbereichen von Variablen. Angenommen, Sie haben eine Klasse mit einer Eigenschaft namens Farbe. Und Sie haben ferner eine Methode - das kann auch der Konstruktor sein - die oder der diese Eigenschaft setzen soll, und deswegen einen Parameter erwartet, also etwa so:
Public Class Test
Sub New(farbe As Color)
Me.Farbe = farbe
End Sub
Property Farbe As Color
End Class
Auch wenn farbe als Parameter klein und als Eigenschaft groß geschrieben wurde: Da Visual Basic die Klein-/Großschreibung nicht beachtet, muss man dem Compiler unter die Arme greifen und ihm anzeigen, wann die Eigenschaft und wann die Variable gemeint ist. In C# würde dieses Beispiel übrigens das Äquivalent zu Me - und das lautet in C# this - nicht erforerlich machen, den C#unterscheidet die Groß-/Kleinschreibung.
35335c69-0b69-4c24-924b-056ea362fb13|2|5.0
Tags: me, klassen, instanzen, visual basic 2010 |
Categories: