Schattenpolymorphie

Jochen — Fri, 08 Sep 2006 08:17:34 GMT

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...

Das My Schlüsselwort in Visual Basic .NET

Jochen — Tue, 05 Sep 2006 14:21:34 GMT

Zum Leidwesen von Microsoft hat sich herausgestellt, dass extrem viele Visual Basic Programmierer den Sprung nach .NET verpasst haben. Die meisten hiervon absichtlich. Der Grund? Visual Basic .NET ist zu kompliziert, der Umstieg auf das (im Vergleich zur VB Runtime) komplexere .NET Framework dauert zu lange und lohnt sich nicht.

Mit Visual Basic 2005 will Microsoft dies ändern und die Stärke des "alten VB" wieder in den Vordergrund stellen: Einfachheit.

Ein großes Problem bei .NET stellen (für Visual Basic Veteranen) die vielen verschachtelten Namespaces dar. Unter Visual Basic 5/6 gab es eine Handvoll von Namespaces, oder sagen wir lieber "Gruppen", in denen eingentlich die komplette VB-Runtime Platz fand und trotzdem nicht unübersichtlich wurde.

Aber auch die nun erzwungene und Lehrbuch-konforme Objektorientierung stößt bei vielen "VBlern" auf Unverständniss. Erinnen Sie sich an die Forms aus VB 5/6? Klassen waren das ja eigentlich nicht wirklich, von der Verwendung her eher Objekte... aber naja... mehrere Instanzen konnte man dann ja doch erstellen und überhaupt... es war irgendwie komisch, aber funktioniert hat's trotzdem... Nur verständlich dass der Umstieg auf UML-konforme Objektorientierung da ein Problem darstellt.

"Was machen wir nun, um aus dieser Kiste wieder heil herauszukommen?", dachten sich nun die VB-Designer bei Microsoft. Und die Lösung heißt "My".

My wenn Sie "My" gefolgt von "." in Visual Studio 2005 eintippen begrüßt Sie ein IntellySense Fenster, welches erst mal vermuten läßt, dass es sich bei My um einen Namepspace handelt. Ist es eigentlich auch! My soll die wichtigsten Funktionen aus dem .NET Framework herauspicken und zentral zur Verfügung stellen. Sie finden in My wiederum Namespaces wie z.B.:

Application
Computer
Settings
User

und einige mehr. Diese Namespaces fassen einige der wichtigsten Funktionen und Klassen kurz zusammen, um diese ohne große Umwege zugänglich zu machen.

Sie möchten zum Beispiel auf den aktuell angemeldeten Benutzernamen zugreifen können? Kein Problem:

My.User.Name

Einfacher ging's auch mit dem alten VB nicht...

Und um nochmal auf die Forms zurückzukommen: Ihre Fenster finden Sie jetzt alle direkt unter My.Forms. Das erinnert schon ein wenig an frühere Visual Basic Anwendungen, oder?

VB.Net

Schattenpolymorphie

Das My Schlüsselwort in Visual Basic .NET