Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
1 Einführung
2 Grundlagen der Sprachsyntax
3 Klassendesign
4 Weitere Datentypen
5 Multithreading
6 Collections und LINQ
7 Eingabe und Ausgabe
8 Anwendungen: Struktur und Installation
9 Code erstellen und debuggen
10 Einige Basisklassen
11 Windows-Anwendungen erstellen
12 Die wichtigsten Steuerelemente
13 Tastatur- und Mausereignisse
14 MDI-Anwendungen
15 Grafiken mit GDI+
16 Drucken
17 Entwickeln von Steuerelementen
18 Programmiertechniken
19 WPF – Grundlagen
20 Layoutcontainer
21 WPF-Steuerelemente
22 Konzepte von WPF
23 Datenbankverbindung mit ADO.NET
24 Datenbankabfragen mit ADO.NET
25 DataAdapter
26 Offline mit DataSet
27 Datenbanken aktualisieren
28 Stark typisierte DataSets
A Anhang: Einige Übersichten
Stichwort

Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Visual Basic 2008 von Andreas Kuehnel, Stephan Leibbrandt
Das umfassende Handbuch
Buch: Visual Basic 2008

Visual Basic 2008
3., aktualisierte und erweiterte Auflage, geb., mit DVD
1.323 S., 49,90 Euro
Rheinwerk Computing
ISBN 978-3-8362-1171-0
Pfeil 3 Klassendesign
Pfeil 3.1 Objektorientierung
Pfeil 3.1.1 Einführung
Pfeil 3.1.2 Vorteile
Pfeil 3.1.3 Klassenimplementierung in .NET
Pfeil 3.1.4 Klassen in Visual Basic
Pfeil 3.1.5 Projekttyp »Klassenbibliothek«
Pfeil 3.1.6 Bemerkung zu den Codefragmenten
Pfeil 3.1.7 Objekte durch New
Pfeil 3.1.8 Ausnahmen mit Throw auslösen
Pfeil 3.1.9 Datentypen
Pfeil 3.1.10 Sichtbarkeit der Klasse
Pfeil 3.1.11 Aufteilung der Definition mit Partial
Pfeil 3.1.12 Grafikbibliothek: Beispiel für Kapitel 3 und 4
Pfeil 3.2 Kapselung
Pfeil 3.2.1 Kombinationen
Pfeil 3.2.2 Private
Pfeil 3.2.3 Sichtbarkeitsmodifikatoren
Pfeil 3.2.4 Lokale Variablen
Pfeil 3.2.5 Softwareschutz
Pfeil 3.2.6 Grafikbibliothek: private Größe des Rechtecks
Pfeil 3.3 Verhalten (Methoden)
Pfeil 3.3.1 Prinzip
Pfeil 3.3.2 Verlassen der Methode
Pfeil 3.3.3 Parameter
Pfeil 3.3.4 Überladung (Overloads)
Pfeil 3.3.5 Rückgabewert
Pfeil 3.3.6 Reine Deklaration mit Partial
Pfeil 3.3.7 Grafikbibliothek: Zugriffsmethoden auf die Größe des Rechtecks
Pfeil 3.4 Bindung
Pfeil 3.4.1 Klassenbindung mit Shared
Pfeil 3.4.2 Klassenkonstruktoren
Pfeil 3.4.3 Externe Funktionen
Pfeil 3.4.4 Grafikbibliothek: Rechteckübergreifendes
Pfeil 3.5 Objektinitialisierung mit Konstruktoren
Pfeil 3.5.1 Objektkonstruktoren
Pfeil 3.5.2 Nichtöffentliche Konstrukturen
Pfeil 3.5.3 Grafikbibliothek: Initialisierung des Rechtecks
Pfeil 3.6 Zustände (Felder)
Pfeil 3.6.1 Deklaration und Initialisierung
Pfeil 3.6.2 Sichtbarkeit
Pfeil 3.6.3 Konstanten: ReadOnly und Const
Pfeil 3.6.4 With
Pfeil 3.6.5 Grafikbibliothek: Konstanten des Rechtecks
Pfeil 3.7 Eigenschaften
Pfeil 3.7.1 Kontrolle beim Aufrufer
Pfeil 3.7.2 Zugriffsmethoden
Pfeil 3.7.3 Getter und Setter: Property
Pfeil 3.7.4 Indexer
Pfeil 3.7.5 Standardeigenschaft: Default
Pfeil 3.7.6 Schreibschutz und Leseschutz: ReadOnly und WriteOnly
Pfeil 3.7.7 Sichtbarkeit
Pfeil 3.7.8 Klammern
Pfeil 3.7.9 Grafikbibliothek: Eigenschaften des Rechtecks
Pfeil 3.8 Innere Klassen
Pfeil 3.8.1 Beziehung zur äußeren Klasse
Pfeil 3.8.2 Sichtbarkeit
Pfeil 3.8.3 Grafikbibliothek: Position des Rechtecks
Pfeil 3.9 Dynamisches Verhalten: Delegate und Function
Pfeil 3.9.1 Funktionszeiger: Delegates
Pfeil 3.9.2 Automatisch generierter Code
Pfeil 3.9.3 Mehrere Aktionen gleichzeitig
Pfeil 3.9.4 Asynchrone Aufrufe
Pfeil 3.9.5 Funktionsobjekte: Function (λ-Ausdrücke)
Pfeil 3.9.6 Umwandlungen
Pfeil 3.9.7 Grafikbibliothek: Vergleich von Rechtecken
Pfeil 3.10 Ereignisse
Pfeil 3.10.1 Ereignis: Event und RaiseEvent
Pfeil 3.10.2 Statische Methodenbindung WithEvents und Handles
Pfeil 3.10.3 Dynamische Methodenbindung: AddHandler und RemoveHandler
Pfeil 3.10.4 Benutzerdefinierte Ereignisse: Custom Event
Pfeil 3.10.5 Umwandlungen
Pfeil 3.10.6 Grafikbibliothek: Größenänderungen von Rechtecken überwachen
Pfeil 3.11 Benutzerdefinierte Operatoren
Pfeil 3.11.1 Prinzip
Pfeil 3.11.2 Überladung
Pfeil 3.11.3 Vergleich
Pfeil 3.11.4 Typumwandlung mit CType: Widening und Narrowing
Pfeil 3.11.5 Wahrheitswerte: IsTrue und IsFalse
Pfeil 3.11.6 Grafikbibliothek: Addition und Umwandlung von Rechtecken
Pfeil 3.12 Alle Klassenelemente
Pfeil 3.12.1 Der Namensraum My
Pfeil 3.13 Vererbung
Pfeil 3.13.1 Klassenbeziehung durch Inherits
Pfeil 3.13.2 Sichtbarkeitsmodifikatoren
Pfeil 3.13.3 Zugriff auf Eltern mit MyBase
Pfeil 3.13.4 Modifikation: Shadows und Overloads (Overrides)
Pfeil 3.13.5 Abstrakte Klassen: MustInherit und MustOverride
Pfeil 3.13.6 Spezifische Catch-Blöcke
Pfeil 3.13.7 Eigene Ausnahmen
Pfeil 3.13.8 Arrays
Pfeil 3.13.9 Grafikbibliothek: neue Vielecke
Pfeil 3.14 Polymorphie
Pfeil 3.14.1 Virtuelle Methoden: Overridable und Overrides
Pfeil 3.14.2 Unterbrechen: Overloads, Shadows und Overrides
Pfeil 3.14.3 Unterbinden: NotInheritable, NotOverridable und MyClass
Pfeil 3.14.4 Konstruktoren
Pfeil 3.14.5 Equals
Pfeil 3.14.6 ToString
Pfeil 3.14.7 Grafikbibliothek: Objektsammlungen
Pfeil 3.15 Schnittstellen: Interface und Implements
Pfeil 3.15.1 Benennungen und Parameter
Pfeil 3.15.2 Schnittstellen und Vererbung
Pfeil 3.15.3 Schnittstellenvererbung
Pfeil 3.15.4 Schnittstelle oder abstrakte Klasse?
Pfeil 3.15.5 Grafikbibliothek: Flächen
Pfeil 3.16 Lebensende eines Objekts
Pfeil 3.16.1 Garbage Collector
Pfeil 3.16.2 Destruktoren
Pfeil 3.16.3 Dispose und Using


Rheinwerk Computing - Zum Seitenanfang

3.2 Kapselung Zur nächsten ÜberschriftZur vorigen Überschrift

Was nicht ist, kann noch werden.

Diese mahnenden Worte sind letztendlich die Motivation dafür, nicht alle Definitionen einer Klasse öffentlich zu machen. Wenn Sie irgendetwas aus der Hand geben, wissen Sie nie, was damit passiert. In der Praxis passiert das z. B. bei der Erweiterung eines Projektes. In den neu hinzugekommenen Klassen setzen Sie Objektzustände nach Bedarf. Wenn Sie die Anwendung dann starten, passiert es sehr schnell, dass die Programmlogik früherer Teile nicht mehr stimmt. Was ist passiert?

Frühere Teile des Projekts gehen von bestimmten Annahmen über die Zustände von Objekten aus. Durch den direkten Zugriff auf diese in späteren Teilen des Projekts stimmen die Annahmen nicht mehr, und niemand hat die früheren Teile über die geänderten Voraussetzungen informiert. In einer solchen Situation ist es wünschenswert, Änderungen nur über klar definierte Kanäle zuzulassen. Die einfachste Art ist es, eine öffentliche Funktion zum Ändern bereitzustellen und den Zugriff auf die Zustände selbst zu unterbinden. Die Zugriffsfunktionen können sich dann um Seiteneffekte kümmern. Dadurch, dass man sie benutzen muss (nur sie sind öffentlich), kann man Nebenschauplätze nicht vergessen.

Ein anderes Szenario betrifft die Wartung Ihrer Software. Stellen Sie sich vor, eine Funktion, die Sie nur als Hilfsmittel für sich in aller Eile geschrieben haben, wird ohne Ihr Wissen von den Benutzern Ihrer Software entdeckt und in deren Programmen verwendet. Nun stellen Sie fest, dass eine Änderung der Funktion Ihre Software besser macht. Da es ja nur eine Hilfsfunktion ist und kein wesentlicher Bestandteil der Anwendung, passen Sie die Funktion entsprechend Ihren Erfordernissen an, ohne das groß zu dokumentieren. Nach der nächsten Aktualisierung Ihrer Software bei den Anwendern hagelt es Beschwerden, weil die Programme der Benutzer durch die Änderungen nicht mehr richtig laufen. In einer solchen Situation wünscht man sich, man hätte die Funktion nie geschrieben. Um das zu verhindern, sollte man Hilfsfunktionen vor dem Zugriff Fremder schützen. So kann die beschriebene Situation gar nicht auftreten, da eine Benutzung durch den Schutz von vornherein ausgeschlossen ist.

Diesen beiden Beispielen könnte man noch sehr viele hinzufügen, die nichts an dem Wunsch nach einer Zugriffskontrolle ändern würden. Daher bietet Visual Basic die Möglichkeit, den Grad der Sichtbarkeit einer Klasse oder eines Klassenmitglieds über Modifikatoren zu steuern. Wir haben uns schon einmal kurz in Abschnitt 2.5.5, »Sichtbarkeit und Lebensdauer«, damit auseinandergesetzt. Mit diesen Modifikatoren können Sie Kontrolle über Ihr Werk behalten. Jedes Klassenmitglied, wie zum Beispiel Felder und Methoden, kann mit einer der Spezifikationen in Tabelle 3.2 kontrolliert werden (die vererbungsbezogenen Modifikatoren mit Protected werden in Abschnitt 3.13.2, »Sichtbarkeitsmodifikatoren«, besprochen).


Tabelle 3.2 Sichtbarkeitsmodifikatoren eines Klassenmitglieds

Modifikator Sichtbarkeit

Private

innerhalb derselben Klasse

Friend

innerhalb derselben Anwendung (Projekt)

Protected

innerhalb von Kindklassen

Protected Friend

innerhalb derselben Anwendung (Projekt) / innerhalb von Kindklassen

Public

überall



Hinweis
Ohne Sichtbarkeitsmodifikator sind Felder Private und alle anderen Klassenmitglieder Public.



Rheinwerk Computing - Zum Seitenanfang

3.2.1 Kombinationen Zur nächsten ÜberschriftZur vorigen Überschrift

Um das Geheimnisprinzip zu wahren, gilt eine allgemeine Regel:


Ein Element (Variable, Methode, Typ, …) hat höchstens die Sichtbarkeit des umgebenden Elements.


Sie können sich das als einen Stapel von Folien vorstellen, durch den Sie hindurchsehen. Ist nur eine Folie im Stapel undurchsichtig, ist der ganze Stapel nicht mehr transparent. Wenn zum Beispiel eine Klasse als Friend deklariert ist und ein als Public gekennzeichnetes Feld hat, kann man nicht von außerhalb der Anwendung auf das Feld zugreifen, da die Klasse durch ihre Beschränkung die restriktivere Sichtbarkeit hat und damit die Sichtbarkeit dominiert. Das folgende Codefragment zeigt einen weiteren Fall, der nicht sofort offensichtlich ist:


'...\Klassendesign\Kapselung\Schnittmenge.vb

Option Explicit On 
Namespace Klassendesign

  Friend Class Anwendung 
  End Class

  Public Class Umgehung 
    'Public Jeder As Anwendung 
  End Class

End Namespace

Die auskommentierte Zeile in Umgehung würde einen Compilerfehler erzeugen, da versucht würde, über das öffentliche Feld Jeder der öffentlichen Klasse Umgehung die auf die Anwendung beschränkte Klasse Anwendung öffentlich zur Verfügung zu stellen.


Rheinwerk Computing - Zum Seitenanfang

3.2.2 Private Zur nächsten ÜberschriftZur vorigen Überschrift

Wie in Tabelle 3.2, »Sichtbarkeitsmodifikatoren eines Klassenmitglieds«, steht, sind private Klassenmitglieder von innerhalb der Klasse verwendbar. Es ist wichtig zu sehen, dass es hier um Klassen und nicht um Objekte geht. Ein Objekt kann auf die privaten Teile eines anderen Objekts zugreifen, wenn beide den gleichen Datentyp haben. Das folgende Codefragment zeigt, dass über die Referenz nullpunkt das private Feld wert in Addieren() benutzt wird.


'...\Klassendesign\Kapselung\Schnittmenge.vb

Option Explicit On 
Namespace Klassendesign

  Class MitPrivatemFeld 
    Private wert As Integer = Now.Millisecond 
    Public nullpunkt As MitPrivatemFeld 
    Sub Addieren() 
      Console.WriteLine("Summe {0}.", nullpunkt.wert + wert) 
    End Sub 
  End Class

  Module Privat 
    Sub Zugriff() 
      Dim p As MitPrivatemFeld = New MitPrivatemFeld() 
      p.nullpunkt = New MitPrivatemFeld() 
      p.Addieren() 
      Console.ReadLine() 
    End Sub 
  End Module

End Namespace

In diesem Kontext gelten Objekte als typgleich, wenn der Operator TypeOf Objekt Is Typ den Wert True ergibt (vergleiche Abschnitt 3.13.1, »Klassenbeziehung durch Inherits«).


Hinweis
Private beschränkt den Zugriff, indem es ein Klassenmitglied gegenüber anderen Klassen unsichtbar macht (siehe zum Beispiel Abschnitt 3.13.4, »Modifikation: Shadows und Overloads (Overrides)«).



Rheinwerk Computing - Zum Seitenanfang

3.2.3 Sichtbarkeitsmodifikatoren Zur nächsten ÜberschriftZur vorigen Überschrift

Um festzustellen, welcher Zugriff von wo aus möglich ist, definieren wir eine Klasse, die Mitglieder mit verschiedenen Sichtbarkeiten hat. In Abschnitt 3.2.1, »Kombinationen«, wurde dargelegt, dass das Element mit der kleinsten Transparenz die gesamte Sichtbarkeit dominiert. Daher wird die Klasse als unbeschränkt (Public) deklariert. In der Klasse ist auch eine Prozedur, die erfolgreich auf alle Klassenmitglieder zugreift (die Prozedur macht »nichts«, hier geht es nur um einen Compilertest). Dies zeigt, dass eine Klasse immer vollständigen Zugriff auf alle ihre Mitglieder hat.


'...\Klassendesign\Kapselung\Kapselung.vb

Option Explicit On 
Namespace Klassendesign 
  Public Class Jeder 
    Public Jeder As Short 
    Friend Anwendung As Short 
    Protected Erbe As Short 
    Protected Friend ErbeUndAnwendung As Short 
    Private Klasse As Short 
    Dim FeldOhne As Short 
    Function MethodeOhne() As Short 
    End Function

    Sub Zugriff() 
      Dim v() As Short = { _ 
        Jeder, Anwendung, Erbe, ErbeUndAnwendung, Klasse, _ 
        FeldOhne, MethodeOhne() _ 
        } 
    End Sub

  End Class 
End Namespace

Schauen wir uns nun an, was eine andere Klasse sehen kann. Wie das nächste Codefragment zeigt, das sich im selben Projekt befindet, ist ein Teil des Zugriffs nicht mehr möglich. Die verbotenen Möglichkeiten sind als Kommentar angegeben. Wir befinden uns außerhalb der Klasse, also sind private Mitglieder (Private und Felder ohne Modifikatoren) nicht sichtbar. Ebenso ist ein Protected-Mitglied, das nur bei Vererbungsbeziehungen genutzt werden kann, außerhalb der Reichweite. Was dabei »Vererbungsbeziehung« bedeutet, ist hier noch uninteressant und wird in Abschnitt 3.13.2, »Sichtbarkeitsmodifikatoren«, erklärt. Hier ist nur wichtig, dass ohne eine solche Beziehung der Zugriff verweigert wird. Die Kombination Protected Friend der Variablen ErbeUndAnwendung erlaubt über Friend den Zugriff innerhalb der Anwendung (die Rechte sind in diesem einen Fall additiv).


'...\Klassendesign\Kapselung\Zugriff.vb

Option Explicit On 
Namespace Klassendesign 
  Module Zugriff 
    Sub Main() 
      Dim obj As Jeder = New Jeder() 
      Dim v1() As Short = { _ 
        obj.Jeder, obj.Anwendung, obj.ErbeUndAnwendung, obj.MethodeOhne() _ 
        } 
      'nicht: obj.Vererbung, obj.Privat, obj.FeldOhne 
    End Sub 
  End Module 
  ... 
End Namespace

Beim Zugriff von einem fremden Projekt sind zusätzlich die mit Friend gekennzeichneten Klassenmitglieder verschlossen, wie das nächste Codefragment zeigt. So bleiben nur die öffentlichen übrig. Bitte achten Sie bei eigenen Tests darauf, das verwendete Projekt mit der Klasse Jeder in den Projekteigenschaften zu referenzieren und beiden Projekten in ihren Eigenschaften denselben Wurzelnamensraum zu geben.


'...\Klassendesign\Fremdklasse\Zugriff.vb

Option Explicit On 
Namespace Klassendesign 
  Module Zugriff 
    Sub Main() 
      Dim jeder As Jeder = New Jeder() 
      Dim v1() As Short = {obj.Jeder, obj.MethodeOhne()} 
      'nicht: obj.Anwendung, obj.Erbe, obj.ErbeUndAnwendung, 
      '       obj.Privat, obj.FeldOhne 
    End Sub 
  End Module 
  ... 
End Namespace

Rheinwerk Computing - Zum Seitenanfang

3.2.4 Lokale Variablen Zur nächsten ÜberschriftZur vorigen Überschrift

Variablen sind immer in dem Block und den in diesem enthaltenen Blöcken gültig, in dem sie deklariert sind. Sie werden mit Dim oder – bei Datentypen – mit einem der Modifikatoren aus Tabelle 3.2: Sichtbarkeitsmodifikatoren eines Klassenmitglieds deklariert. Darüber hinaus erlauben die For-Schleifen und Using eine besondere Art der Deklaration (siehe Abschnitt 2.10.2, »For«, und Abschnitt 3.16.3, »Dispose und Using«). Die Effekte der Lokalität sind in Abschnitt 2.5.5, »Sichtbarkeit und Lebensdauer«, erläutert. Als Block gelten dabei:

  • Datentypen: Module, Class, Structure
  • Methoden: Sub, Function, Operator, Get, Set
  • Schleifen: Do, While, For, For Each
  • Kontrollstrukturen: If, Select Case
  • Fehlerbehandlung: Try-Catch-Finally
  • Objektzugriff: SyncLock, Using, With

Rheinwerk Computing - Zum Seitenanfang

3.2.5 Softwareschutz Zur nächsten ÜberschriftZur vorigen Überschrift

Die Sichtbarkeitssteuerung kann nicht verhindern, dass sich Hacker Informationen über Ihre Klassen verschaffen. Brauchen Sie einen Schutz Ihrer Software vor neugierigen Blicken, können Sie sogenannte Obfuskatoren einsetzen (siehe zum Beispiel http://de.wikipedia.org/wiki/Obfuscator). Eine einfache Möglichkeit zu sehen, was andere auch sehen könnten, besteht in der Verwendung eines sogenannten Reflektors. Er analysiert ein Programm und stellt es in einer Form dar, die von Menschen gelesen werden kann. Ein relativ weit entwickeltes und kostenloses Produkt stammt von Lutz Roeder (http://www.aisto.com/roeder/dotnet/). Nach der Lektüre und eigenen Experimenten werden Sie feststellen, dass es nicht möglich ist, eigene Programme perfekt gegen Hacker zu sichern. Sie können jedoch die Hürde so hoch legen, dass in der Praxis diese Leute das Interesse verlieren.


Rheinwerk Computing - Zum Seitenanfang

3.2.6 Grafikbibliothek: private Größe des Rechtecks topZur vorigen Überschrift

In diesem Abschnitt erweitern wir die in Abschnitt 3.1.12, »Grafikbibliothek: Beispiel für Kapitel 3 und 4«, eingeführte Grafikanwendung. Jede Geometrie hat eine Ausdehnung, die in ihren Abmaßen definiert ist. Es wäre nicht sinnvoll, eine direkte Manipulation dieser Maße zuzulassen, da sonst schnell der Fall negativer Abmessungen entstehen kann. Daher deklarieren wir im nächsten Codefragment diese Größen mit Private. Damit ist nur ein Zugriff nur aus der Klasse heraus möglich und kann gesteuert werden.


'...\Klassendesign\Graphik\Dimension.vb

Option Explicit On 
Namespace Klassendesign

  Partial Public Class Rechteck 
    Private a As Double = 1 
    Private b As Double = 1 
  End Class

End Namespace

Da wir noch keine weiteren Klassenmitglieder haben, erfolgt der Test in Abschnitt 3.3.7, »Grafikbibliothek: Zugriffsmethoden auf die Größe des Rechtecks«, nach der Einführung von Zugriffsmethoden.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen. >> Zum Feedback-Formular
<< zurück
  Zum Katalog
Zum Katalog: Visual Basic 2008
Visual Basic 2008
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Visual Basic 2012






 Visual Basic 2012


Zum Katalog: Schrödinger programmiert C++






 Schrödinger
 programmiert C++


Zum Katalog: IT-Handbuch für Fachinformatiker






 IT-Handbuch für
 Fachinformatiker


Zum Katalog: Professionell entwickeln mit Visual C# 2012






 Professionell
 entwickeln mit
 Visual C# 2012


Zum Katalog: Windows Presentation Foundation






 Windows Presentation
 Foundation


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2009
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Rheinwerk Computing]

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de