Module überholt in VB 2010?

  • VB.NET

Es gibt 7 Antworten in diesem Thema. Der letzte Beitrag () ist von GambaJo.

    Module überholt in VB 2010?

    Hallo,
    ich nutze derzeit ein Modul, damit ich die dort definierten Variablen / Instanzen applikationsweit (in allen Forms) verwenden kann:

    VB.NET-Quellcode

    1. Module moduleA2
    2. Public MC As MCOM= New MCOM ' separat definierte Klasse
    3. Public logfile As New ApplicationLogFile(ApplicationLogFile.DateEncodingType.YYYYMMDD, True)
    4. End Module



    Nun lese ich in "Das Visual Basic 2008 Codebook", dass Module aus Visual Basic stammen, überholt sind und nicht mehr verwendet werden sollten. Aber sie schreiben nicht, wie es in .NET dann gemacht werden soll.

    Wie macht ihr sowas denn? Sollte ich das wirklich nicht mehr so machen?

    darfichdir ein anneres Buch empfehlen? ;)
    Zumindest überprüfma, ob dein Buch den Kriterien, die ich im Link aufstelle, genügt.

    Zur Frage:
    Dem VB-Modul entspricht in c# die static class (mit einem kleinen Unterschied).

    eine static class ist eine, in der nur static (vb: Shared) Methoden enthalten sein können.

    Das wäre auch eine Möglichkeit in VB - eine Klasse zu proggen, die nur Shared Methoden enthält. Nur kann man in VB eben eine Klasse nicht gleich komplett als Shared deklarieren - stattdessen nimmt man Module. Ein VB-Modul wird übrigens direkt in eine static class übersetzt, und das besondere am VB-Modul ist eben, dass dort jede Methode automatisch static (Shared) ist.
    Während wenn du es über die Klasse löst, mußt du für jeden Member das Schlüsselwort Shared explizit angeben.

    Der kleine Unterschied zw. Klasse mit nur shared Membern und Modul mit automatisch alle Member Shared ist, dass man um auf eine Shared Methode in einer Klasse zuzugreifen, muß man den KlassenNamen voranstellen.

    Kann man als Vor- oder Nachteil sehen: Vorteil: die volle Qualifizierung des Namens macht den Code strukturierter - du siehst, wo die Methode herkommt, die du aufrufst. Nachteil: der gesamte MethodenName ist dadurch natürlich länger.

    Ich verstehe die Intention deines Autors nicht: Meint er, Public Shared Methoden sollte man gar nicht mehr verwenden? Das wärja Blödsinn - natürlich haben die gelegentlich ihre Berechtigung.

    In dem Buch steht sicher mehr als nur, dass es aus VB stammt.

    Auszug dotnetpro 3/2003

    Im .NET Framework ist alles eine Klasse.VB.NET ermöglicht zusätzlich die Verwendung so genannter Module, die eigentlich im .NET Framework eine andere Bedeutung haben(siehe dazu den Kasten Module im .NET Framework). Die VB.NET-Module verwässern die konsequente Anwendung objektorientierter Konzepte ein wenig. Innerhalb eines Moduls können Methoden (Subs und Functions) oder auch Variablen definiert werden, die dann im Programm
    wie globale Methoden oder Variablen zur Verfügung stehen.
    Das widerspricht eigentlich dem grundlegenden Gesetz, dass
    es keine globalen Methoden und Variablen geben kann.
    Module sind ein Zugeständnis an die VB6-Entwicklergemeinde. Sie wurden eingeführt, um den Umstieg von VB6 zu erleichtern.
    Module sind eigentlich auch nur Klassen, allerdings mit einigen Einschränkungen. Alle Methoden oder Variablen eines Moduls sind automatisch Shared, das heißt, es muss keine Instanz erzeugt werden. Module sind automatisch NotInheritable, wodurch auch keine Instanz erzeugt werden könnte, selbst wenn das gewollt wäre. Letztendlich müssen die Namen von Modulen nicht beim Aufruf einer darin deklarierten Methode oder der Verwendung einer darin deklarierten Variablen angegeben werden. Das hat zur
    Folge, dass es für den Programmierer so aussieht, als seien diese Methoden und Variablen global verfügbar. Das gilt allerdings nur für das Projekt, in dem das Modul deklariert ist. Nach außen hin sind Module nicht sichtbar, und damit sind auch darin deklarierte Methoden für andere Anwendungen nicht wieder verwendbar. Die
    Tatsache, dass es Module gibt, trägt leider auch dazu bei, dass viele Einsteiger und Umsteiger sich nicht mit den objektorientierten Konzepten beschäftigen, da sie glauben, diese nicht zu benötigen. .NET selbst besteht aber ausschließlich aus Klassen, und die am
    häufigsten verwendeten Datentypen sind Referenztypen. Die Prinzipien der OOP zu verstehen und anzuwenden ist daher per definitionem Pflicht, und die Verwendung von VB.NET-Modulen erschwert dieses Verständnis enorm.


    Kurz gesagt, man kann Methoden und Variablen als shared definieren, und dann genau so nutzen, wie früher in Modulen. Damit ist man auch zu anderen Sprachen, wie C#, konform (da gibt es nämlich gar keine Module sondern nur statische Klassen. VB.NET behandelt Module auch als statische Klassen)
    Grundsätzlich sind globale Variablen in OOP nicht erwünscht. Sie verstoßen nämlich eigentlich gegen das Prinzip von OOP.

    Ja, Du kannst das Modul nutzen, es funktioniert ja anscheinend. Auf Dauer solltest Du dich aber mehr mit OOP auseinander setzen, um Module und vor allem globale Variablen zu vermeiden. Das ist nämlich ganz schlechter Programmierstil, der auch noch viele Fehlerquellen bietet.

    Im Prinzip ist Modul out. Aber eben nur im Prinzip.
    Im Fall einer Befehlserweiterung

    VB.NET-Quellcode

    1. Imports System.Runtime.CompilerServices
    2. ' Modul, Sub
    3. Module StringExtensions
    4. <Extension()> _
    5. Public Sub Print(ByVal aString As String)
    6. Console.WriteLine(aString)
    7. End Sub
    8. End Module
    wird zwingend ein Modul erwartet (das ist in C# eleganter gelöst).
    Befehlserweiterung:

    VB.NET-Quellcode

    1. Dim txt As String = "bla"
    2. txt.Print()
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    cipherwar schrieb:

    Danke für die Erklärung. Statische Klassen werden ja auch in java benutzt. Wenn ich Dein Fazit also richtig verstehe, kann ich das Modul ruhig weiterverwenden und alles beim Alten lassen?


    Ich würde die Aussage das Module out sind in dem Sinne von modulare/prozedurale Programmierung ist out verstehen wollen. Funktionalitäten gehören schlicht und ergreifend unter NET objektorientiert in Klassen gekapselt.

    Für mich persönlich habe ich das so gelöst, das auch die Hilfsfunktionen in Klassen gekapselt sind und dort als Public Shared deklariert sind.

    Da mir aber irgendwann der Schreibaufwand andauernd den vollqualifizierten Namen zu schreiben zuviel/zu dumm wurde, habe ich mir ein kleines Modul angelegt und dort einfach Functionen eingesetzt die nichts anderes machen als die Public Shared Member der Klassen anzusprechen und zurück zu werfen. So habe ich beide Vorteil ... der Code selber ist sauber in Klassen gekapselt aber ich kann auf die paar Hilfsfunktionen mit einem einzigen unqualifizierten Aufruf zu greifen, zu Identifizierung haben diese Funktionen allesamt einen Präfix vor dem Funktionsnamen "gh_" (für global helper) so sehe ich im Code auch sofort woher die Funktion stammt.

    Mancher würde sagen das ist aber "dirty" ... ich sage das ist "quick". *lach*

    Gruß

    Rainer