Seit Version 6.0 hat sich Visual Basic deutlich weiterentwickelt. Hierbei fällt einem vor allem die nun (endlich) richtige Objektorientierung auf.
Inzwischen dürften wohl die meisten Visual Basic (2005) Programmierer mit den grundlegenden Mechanismen der Objektorientierung - Kapselung, Vererbung und Polymorphie - vertraut sein. Aber es gibt noch einige wenig bekannte Mechanismen, welche in Ausnahmesituationen recht hilfreich sein können.
Ein solcher Mechanismus ist "Shadowing". Stellen Sie sich vor, Sie haben eine Klasse A, welche eine Methode "Method()" enthällt. Der Aufruf von Method() erzeugt folgende Ausgabe:
"Eine Nachricht von Klasse A!"
Der passende Code würde so aussehen:
Class A
Public Overridable Sub MyMethod()
Console.WriteLine("Eine Nachricht von Klasse A!")
End Sub
End Class
Nun schreiben Sie eine weitere Klasse namens B, welche von A erbt. Sie überschreiben die Methode "Method()", so dass diese nun folgende Ausgabe vornimmt:
"Eine Nachricht von Klasse B!"
Diese würde wie folgt aussehen:
Class B : Inherits A
Public Overrides Sub MyMethod()
Console.WriteLine("Eine Nachricht von Klasse B!")
End Sub
End Class
Nun könten Sie folgendes tun:
Dim a As New A
a.Method()
Dim b As New B
b.Method()
a = b
a.Method()
Die Ausgabe wäre dank Polymorphie folgende:
"Eine Nachricht von Klasse A!"
"Eine Nachricht von Klasse B!"
"Eine Nachricht von Klasse B!"
Was aber, wenn Sie möchten, dass sich ein Objekt sich wie der Typ verhällt, den die darauf zeigende Referenz hat? Hierzu können Sie sich des "Shadows" Schlüsselwortes bedienen. Schreiben Sie hierzu die Klasse B wie folgt:
Class B : Inherits A
Public Shadows Sub MyMethod()
Console.WriteLine("Eine Nachricht von Klasse B!")
End Sub
End Class
Die Ausgabe des Testcodes sieht nun wie folgt aus:
"Eine Nachricht von Klasse A!"
"Eine Nachricht von Klasse B!"
"Eine Nachricht von Klasse A!"
Shadows bewirkt also, das bei Methodenaufrufen durch eine "A"-Referenz, die Methode der A-Klasse aufgerufen wird, während bei einer "B"-Referenz die Methode von B genommen wird. Man könnte Shadows sozusagen auch als "Antipolymorphie" bezeichnen.
Nun, wann braucht man Shadows? Eigentlich sollte man es gar nicht benötigen, wenn Sie Shadows ernsthaft nutzen deutet dies meist auf einen Design-Fehler hin.
Allerdings gibt es einige wenige Situationen, in denen es sich durchaus als nützlich erweist. Stellen Sie sich vor, Sie entwickeln ein Control, welches andere Entwickler via Visual Studio Designer auf ein Form ziehen können. Anschließend kann der Entwickler via Properties Window die Eigenschaften des Controls bearbeiten.
Nun kann es passieren, dass dieses Control im Properties Window Eigenschaften anbietet, welche es von einer Basisklasse geerbt hat. Sie möchten diese dem Entwickler in Ihrem Control aber nicht anbieten. Durch Shadows können Sie solche Eigenschaften "verstecken", indem Sie beispielsweise das [Browsable(false)] Attribut anhängen.
An diesem Beispiel erkennt man aber schon, dass Shadows eher in Randsituationen benötigt wird und nicht in einem ordentlichen, objektorientierten Entwurf. Hier sollten Sie wirklich Abstand von der "dunklen Seite der Polymorphie" halten...