DevTrain Startseite Visual Studio 1 Magazin  
  
  
SUCHEN:  
ARTIKEL ONLINE: 525   

Kategorien
.NET
Datenbanken
Web
XML

Allgemein
Camp
Foren
Events
Persönliche Einstellungen
Registrieren
Prämien Shop
Kontakt
Impressum
Über DevTrain

Autoren


   Autor: Bernhard Elbl Artikel Drucken
        
Interfaces, Klassen und OOP in VB6

OOP hat nichts mit Krankenhäusern zu tun und ist eigentlich ganz etwas anderes als programmieren in VB6. Trotzdem wurde in VB ein objekt-orientiertes Feeling geschaffen. Jeder Programmierer einer OOP-Sprache wird vielleicht drüber schmunzeln; VB und Interfaces, Weihnachten und Osterhasen. VB ist grundsätzlich einmal NICHT OO. Wer mit VB programmiert und noch keine Interfaces kennt, der kann sich ins letzte Kapitel wagen und weiterlesen.

Warum ist VB nicht objekt-orientiert?
die Länge einer Variable in VB:
x = len(strVar)
in Länge einer Variable in OOP:
x = strVar.Length
diese Liste könnte 1000 Seiten lang werden. Wer bietet mehr?

Kennen Sie Klassen?
Davon gehe hier aus.
Und Interfaces?
Übersetzt Schnittstelle, ist da, wenn in Ihrer Klasse "Public" Methoden, Eigenschaften deklariert sind. Also schreiben Sie in einen Klassen Modul einmal "Public Sub...", und schon ist besitzt diese Klasse ein Interface. Wenn Sie es nicht tun hat die Klasse kein Interface und Sie können Sie nicht benutzen. Ausser Sie definieren ein Interface und implementieren es. Weil Klassen mit benutzerdefinierten Schnittstellen keine "Public..." M/E enthalten sollen, muss das Interface "Public..." M/E enthalten. Bzw Interfaces bestehen nur aus "Public " Methoden und Eigenschaften.

Simple Interface Example:
Klassen Modul: IEins
Option Explicit

Public Function DoThis(ByVal sPar As String)
   
End Function


Klassen Modul: CWorker
Implements IEins

Private Function DoThis(ByVal sPar As String)
    DoThis = "kommt zurück von CWorker: " & sPar
End Function

Private Function IEins_DoThis(ByVal sPar As String) As Variant
    IEins_DoThis = DoThis(sPar)
End Function


Form: Form1
Private Sub Form_Load()
    Dim oWorker As IEins
    Set oWorker = New CWorker
    MsgBox oWorker.DoThis("mach das")
    Set oWorker = Nothing
End Sub

Nach dem Starten der Form1 kommt als Ergebnis:
kommt zurück von CWorker: mach das

Das Objekt wird also in der Form eine Variable deklarariert vom Typ (Interface) IEins. Instantiiert wird diese allerdings mit der eigentlichen funktionellen Klasse "CWorker". Also doppelt-gemobbelt; Interface schreiben und Interface implementieren, Interface deklarieren und Klasse instantiieren.

Finden Sie das toll?
Nein? OK was bringt das? Wenn ich Ihnen jetzt sage, dass Sie so ihr laufendes Projekt erweitern können bis zum Umfallen, und dafür auch noch Ihren bestehenden und hoch komplexen Code wiederverwenden können, ihn also nicht kopieren müssen und ihn in ein neues "Public Sub" kopieren und modifizieren müssen, was halten Sie dann davon! Um das zu erkären muss man etwas ausholen und von Gott und den ActiveX-en sprechen.

Grundwissen:
Stichwort:
- Binär-Kompatiblität
Sie kompilieren ihre ActiveX neu und alle Anwendungen, die diese DLL verwenden, können die neu kompilierte Version verwenden, bzw Sie werden Sie verwenden.

Warum, wie geht das?
Beim ersten kompilieren werden UUID´s für die DLL neu generiert. Für alle Schnittstellen und alle "Public" M,E werden UUID´s erzeugt, Über diese die Client-Anwendung zugriff auf Methoden und Eigenschaften erhält. Mit Binär-Kompatiblität bleiben die bestehenden UUID´s einer DLL vollständig erhalten. Damit ist Sie vollkompatibel zu seinen Vorgangern.
Was muss ich bei Binär Kompatiblität beachten:
die Definitionen aller Public M und E dürfen nicht verändert werden.
Beispiel:
aus der Methode...
Public Function DoThis(byVal SPar as String)
wird...
Public Function DoThis(byRef SPar as String)
--> nicht mehr binär-kompatibel
oder...
Public Function DoThis(byVal SPar as String, byVal sStringOrXML as String)
--> nicht mehr binär kompatibel

----> Sie können diese Methode nicht mehr erweitern! Sie können zwar den Inhalt-Code verändern und die Funktion der Methode verändern, aber Sie können die Methode nicht um eine Funktionalität erweitern.

Wenn Sie selbst definierte Interfaces verwenden, können die Funktion "DoThis" erweitern!
Indem Sie ein zweites Interface erstellen und dieses in CWorker implementieren.
Wichtig! Beim implementieren von Interfaces MÜSSEN ALLE Methoden und Eigenschften des I implementiert werden!!!
Klassen Modul: IZwei
'... exact wie IEins

Klassen Modul: CWorker
Implements IEins
Implements IZwei

Private Function DoThis(ByVal sPar As String, ByVal sStringOrXML As String)
    Select Case sStringOrXML
    Case "String"
        DoThis = "kommt zurück von CWorker: " & sPar
    Case "XML"
        DoThis = "<xml> kommt zurück von CWorker:" & sPar & "</xml>"
    End Select
End Function

Private Function IEins_DoThis(ByVal sPar As String) As Variant
    IEins_DoThis = DoThis(sPar, "String")
End Function

Private Function IZwei_DoThis(ByVal sPar As String) As Variant
    IZwei_DoThis = DoThis(sPar, "XML")
End Function


Form: Form2
Private Sub Form_Load()
    Dim oWorker As IZwei
    Set oWorker = New CWorker
    MsgBox oWorker.DoThis("mach das")
    Set oWorker = Nothing
End Sub

--> Sie haben jetzt also die bestehende Methode "DoThis" mit einer Funktionalität erweitert!
Diese unterstützt jetzt die Rückgabe von --- XML Daten :-) ---. Wir mussten den Code der umfangreichen "DoThis"-Funktion nicht kopieren, sondern wir haben Ihn wiederverwendet und sogar erweitert. Für den Zugriff brauchen wir nur ein anderes Interface deklarieren, und so können wir obwohl die Methode im Interface gleichnamig ist, verschiedene Abläufe erzeugen. Wir vermeiden also "fast" identische Funktionen zu erzeugen, und verwenden statt dessen nur EINE Funktion nähmlich "DoThis".
Vorteile:
- kein doppelter Code; nur doppelte Deklaration von Funktionen und Interface-Klassen
- binär Kompatibiliät bleibt erhalten
- in COM+ können Sie auf Interface-Klassen Zugriffsrechte konfigurieren. z.B. eine Datenbank-Klasse implementiert 2 Interfaces. iGet und iSave. Ein Interface zum Daten auslesen und ein Interface zum Speichern. Jetzt können Sie in COM+ der Gruppe "Benutzer" nur Zugriff auf iGet geben und "Administratoren" Vollzugriff auf beide Interfaces.

Interfaces sind notwendig für grosse Anwendungen, die erweitertbar sein sollen. Hier ein kleines Beispiel. Mitarbeiter ihrer Firma arbeiten mit Client-VB-Anwendungen(Presentation-Tier), die auf einem Server (Business/Data-Tier) zugreifen und Daten in Form eines CSV-String-Buffers abholen und dann darstellen. Jetzt soll eine neue Benutzer-App erstellt werden, die XML-String-Buffer unterstützt.
1. Sie erzeugen ein neues Interface
2. Implementieren dieses in die Businessklasse des Servers und kompilieren die Komponente
3. Sie erzeugen eine neue Benutzeranwendung, das das XML-Interface verwendet.
--> die Anwendung ist erweitert, beide User-Interface-Application können dieselbe Server-Anwendung verwenden und unterschiedliche Ergebnisse erhalten.


DevTrain Camp - Schneller zum .NET 3.5 Developer
 
Verwandte Artikel      Verlinkte Dokumente
    Keine verknüpften Dokumente
    Keine Links vorhanden

  Erfasst am: 06.03.2002
  Gültig bis: 05.04.2002
20 Ratings
Bewertung: 65,0%
schlecht    sehr gut  

 
© Copyright 2007 ppedv AG