BigBastis Blog

Tod den Modulen in VB.NET

Introduction

user

Sebastian Gross

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


LATEST POSTS

Handling too long scrollspy menus 10th June, 2015

Java: Create ZIP archive 23rd March, 2015

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

profile

Sebastian Gross

http://www.bigbasti.com

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

Comments
user

Author bigbasti87

Posted at 21:53 12. August 2010.

Bloggd: Tod den Modulen in VB.NET – http://blog.bigbasti.com/tod-den-modulen

user

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! 🙂

user

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.

user

Author Ruthie Belgard

Posted at 13:18 14. Februar 2011.

Tolle Seite! Liebe Grüße

user

Author Trudi

Posted at 13:28 1. März 2011.

Genau danach habe ich gesucht! Perfekt !

user

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.

user

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

user

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?

user

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

Kommentar verfassen

View Comments (9) ...
Navigation