welchen Gewinn hätte man davon in diesem Falle?

Edit by ErfinderDesRades: --> unnötiges Vollzitat entfernt.

Man arbeitet doch nur wirklich ungerne mit Modulen. Sogar ich bevorzuge dann doch die statische / shared Variante

Dassis keine Antwort auf die Frage nach dem Vorteil von Klassen als Ersatz für Module, sondern nur die netter formulierte Wiederholung der "HurrDurr-Clusterfuck" - Abqualifikation.

Ich denke das wird hier zu sehr Off topic aber hier mein letzter beitrag dazu.
Bei Modulen schwirren Funktionen frei herum.
Bei Klassen habe ich Funktionen nur in der Klasse.
Beispiel:

Ich will Funktion XYZ aus Klasse A.
Ich will aber auch Funktion XYZ auf Klasse B.
Mal angenommen ich habe XYZ so (ohne Klasse, im Modul),
das würde (für mich) für eine riesen Verwirrung sorgen.

Module sind ein Rudiment aus grauer Vorzeit, die gab es schon zu VB3-Zeiten.
Aus Kompatibilitätsgründen werden die von MS noch supportet.
Die einzige Daseinsberechtigung in VB.NET habe Module für eine Befehlserweiterung.

Während du bei Shared Klassenmethoden zum Aufruf immer den Klassennamen angeben mußt, musst du dieses bei Modulen nicht - kannst es aber.

Auch könntest du um verschiedene Module (mit gleichnamigen Methoden) einen geeigneten Namespace legen, das würde dann beim Aufruf ebenso aussehen wie beim Aufruf von Shared Klassenmethoden.

Aber ich will garnicht Module verfechten - ob man nun Modul-Methoden verwendet oder Shared Class-Methoden ist annähernd schnurz, und die Strukturierung via KlassenDefinition ist stärker eingebürgert.
Nur die Abqualifikation als "Hurr-Durr-ClusterFuck" findich unhaltbar.

@Rod: nur weils dieses Konstrukt schon vlt. länger gibt als selbst die Klassen - deswegen ist ein Konstrukt noch nicht schlecht.
Wenn alles was alt ist schlecht sein soll - was machstedann mittm If - Schlüsselwort?

.NET-Intern werden Module so oder so in das umgewandelt, was in C# eine Klasse mit staticsealed-Modifier ist. Zusätzlich werden alle Methoden als static markiert. Danach wird die Klasse mit 'nem Attribut versehen.

Mal ausprobiert:

Wird doch zu einer sealed (NotInheritable) Class, nicht static. Naja, ist ja fast das gleiche. ;)
Wenn man sich das Attribut wegdenkt, hat man 'ne ganz normale Klasse, ohne irgendetwas besonderes.