.NET
Tod den Modulen in VB.NET
Posted on .In diesem Beitrag möchte ich ein paar Worte über Module unter VB.NET verlieren. Wie ihr dem Titel vielleicht auch schon entnehmen könnt steh ich diesen nicht allzu freundschaftlich gegenüber. Deswegen möchte ich in diesem Artikel erklären warum man keine Module benutzen sollte.
Wenn man Module nicht benutzen sollte warum gibt es sie dann?
Module gibt es in VB.NET nur aus einem Grund, nämlich um VB6 Programmierern den Umstieg auf die .NET Plattform zu erleichtern. Denn .NET ist komplett Objektorientiert und hier haben Module keinen Platz. Aber um es den Entwicklern einfacher zu machen bestehende Projekte auf die .NET Plattform zu porten wurden die Module mitgenommen.
Modul, Klasse wo ist eigentlich der Unterschied?
Wenn man sich so ein Modul anschaut hat es eine Enorme Ähnlichkeit mit einer gewöhnlichen Klasse, unterscheidet sich aber dennoch gewaltig von ihr.
Im Prinzip sind Module auch Klassen, die aber vielen Beschränkungen unterliegen. Hier die Hauptpunkte:
- Alle Methoden und Variablen eines Moduls sind automatisch Shared, was bedeutet, dass man auf diese Methoden/Variablen zugreifen kann ohne eine Instanz der Klasse bilden zu müssen.
- Alle Methoden und Variablen eines Moduls sind in dem gesamten Projekt verfügbar und sind somit Global – was nicht im Sinne von OOP ist. Der Programmierer kann dabei direkt auf die Methoden und Variablen zugreifen, dies erzeugt das Bild von Globalen Objekten und steht dabei im Gegensatz zu dem Klassischen Objektzugriff Object.Member.
- Module sind automatisch NonInheritable, was die Instanzierung verhindert, desweiteren kann ein Modul auch nicht mit weiteren Schnittstellen wie z.B.: Interfaces erweitert werden.
- Module sind zur Laufzeit einzigartig. Das bedeutet, dass alle Programmteile immer auf die selben Werte zugreifen, anders als bei einer Klasse wo jede Instanz eigene Werte hat.
- Ein weiterer Punkt ist, dass Module nicht nach Außen hin sichtbar sind und somit eine Wiederverwendung ausschließen, was im totalen Gegensatz der OOP ist.
Warum werden Module dann so häufig benutzt?
Im Normalfall ist es entweder Unwissenheit oder Faulheit, oder beides. Denn viele Einsteiger (und auch alte VB6 Hasen) haben Probleme damit das Objektorientierte Prinzip zu verstehen, und da kommen die Module wie gerufen, denn diese ersparen die korrekte Deklarierung, man muss keine Namespaces beachten, die Instanzierung kann man sich auch sparen und man muss sich nicht mit Properties herumschlagen! Also geht im Endeffekt alles schneller aber dafür wird lauter Spaghetticode erzeugt!
Schlusswort
Wenn du noch relativ neu in der Objektorientierten Programmierung bist oder ein umsteiger von VB6, lass dich nicht davon verleiten schnellen unsauberen Code zu schreiben. Lass dir lieber etwas mehr Zeit um das OOP Konzept zu verstehen und mach es dann richtig. Je länger man diesen Pakt mit dem Teufel eingeht, desto schwieriger wird es dann später die alten Gewohnheiten los zulassen.
Ein weiterer Punkt ist, dass es unter C# keine Module gibt, daher wird man spätestens dann Probleme bekommen wenn man an einem C# Projekt mitarbeitet und dann gezwungen ist sauberer zu programmieren!
Sebastian Gross
http://www.bigbasti.comSebastian Gross arbeitet in Bielefeld als Softwareentwickler für .NET und Java im Bereich Web.Als Fan der .NET-Plattform lässt er sich kein Userguppen Treffen und Community Event im Raum OWL entgehen.Dabei hat er eine besondere Vorliebe für das ASP.NET MVC Framework und für das Test Driven Development (TDD) entwickelt.
Author bigbasti87
Posted at 21:53 12. August 2010.
Bloggd: Tod den Modulen in VB.NET – http://blog.bigbasti.com/tod-den-modulen…
Author Frank Hell
Posted at 09:51 17. August 2010.
Danke! Hab mich schon immer gewundert, was das mit den Modulen auf sich hat – weiter so! 🙂
Author GambaJo
Posted at 16:29 16. November 2010.
So weit ich weiß, gibt es Module auch in C#. Nur sind es dort statische Klassen bzw. Module sind eigentlich statische Klassen. Und diese gibt es sogar im Framework selbst.
Author Ruthie Belgard
Posted at 13:18 14. Februar 2011.
Tolle Seite! Liebe Grüße
Author Trudi
Posted at 13:28 1. März 2011.
Genau danach habe ich gesucht! Perfekt !
Author ErfinderDesRades
Posted at 07:54 22. Juni 2011.
enthält einige falsche aussagen, und kein Argument.
1) alle member seien global verfügbar – deklariere sie doch Private oder Friend
2) sind nicht nach aussen sichtbar – k.A., was du meinst. Ah – du weißt vmtl. nur nicht, dass Module defaultmäßig „Friend“ deklariert sind – willst du sie in annere Dlls einbinden, musstes explizit Public Module … deklarieren
mein faszit: Module sind das VB-Äquivalent zur Shared Class in c#.
Tatsächlich gebraucht man es selten.
Zwingend notwendig sind sie allerdings, um Extension-Methods zu schreiben.
Aber wenn man eine Code-Einheit haben will mit nur Shared membern (viele leuts strukturieren ihre DB-Zugriffe so) – kann man (muß nicht) Module nehmen – das tut niemandem weh.
Author greenmanmax
Posted at 13:39 10. September 2011.
Hi Basti,
cooler Artikel! Ich denke, dass es sich die MS-Jungs mit den alteingesessenen VB-Programmierern nicht verscherzen wollten und daher so manches beibehalten haben.
Ich habe meinerseits auch mal was zum Thema „Altlasten bei VB.NET“ geschrieben:
http://www.extremeprogrammer.de/visual-basic-altlasten-i-ruckgabewerte/
Ich bin da ähnlicher Meinung wie Du: Man sollte sich lieber beim Umstieg die neuen Pattern angewöhnen. Trotzdem sollte VB kein zweites JAVA werden, dess auch da gibt es Punkte, die VB besser macht (z.B. die ByVal / ByRef Variablen- Übergabe).
Author Anton
Posted at 22:18 22. März 2012.
Ich habe Module eine Zeit lang für DLL-Deklarationen benutzt.
Wenn es sehr viele waren, haben diese in der Klasse einfach gestört.
Gibt es eine Möglichkeit, die DLL-Deklarationen, aber auch Konstanten, objektorientiert unterzubringen, ohne dass sie stören?
Author Sebastian Gross
Posted at 08:01 23. März 2012.
Hallo Anton,
wo ist das Problem? Dann erstell einfach eine Klasse extra für diese DLL Deklarationen. zb eine Win32API-Klasse dann kannst du die methoden bequem aufrufen: Win32API.MeineMethode() – das lässt sich schön lesen und ordnet sich sehr gut in eine Objektorientierte Projektstruktur einordnen.
Für Konstanten kann man hier genauso vorgehen, der Name der Klasse ist hier entscheidend für die Lesbarkeit des Codes später.
Gruß Sebastian