Odpowiedź.

Moduły (Module) w Visual Basic historycznie służą do przechowywania procedur, funkcji i zmiennych, dostępnych w całym projekcie bez konieczności jawnego tworzenia instancji. Wraz z wprowadzeniem klas ich rola częściowo się pokrywa, jednak istotne różnice pozostały.

Historia zagadnienia:

W klasycznym Visual Basic (VB6) moduły były jedynym sposobem grupowania wspólnych funkcji i globalnych zmiennych. W VB.NET moduły pozostały, ale z rozszerzonymi możliwościami klas.

Problem:

Programista może nie rozumieć różnicy między modułem a klasą, co prowadzi do błędnego wyboru sposobu przechowywania logiki, przypadkowego dublowania kodu lub nieoczekiwanego zachowania zmiennych.

Rozwiązanie:

Wybór między modułem a klasą zależy od celów:

Moduły są przeznaczone do przechowywania procedur i zmiennych, które powinny być dostępne w całej aplikacji bez tworzenia instancji
Klasy są odpowiednie do enkapsulacji stanu i zachowania obiektów z możliwością dziedziczenia.

Przykład kodu:

' Moduł
Module MathUtils
    Public Function Add(x As Integer, y As Integer) As Integer
        Return x + y
    End Function
End Module

' Użycie
Dim result = MathUtils.Add(5, 10)

Kluczowe cechy:

Wszyscy członkowie modułu są zawsze Shared i dostępni bez instancji
Moduł nie obsługuje dziedziczenia ani tworzenia instancji
Moduł nie może być deklarowany jako Friend/Protected wewnątrz klasy

Pytania podchwytliwe.

Czy deklarując zmienną w module jako Public, stanie się ona wspólna dla wszystkich formularzy/klas aplikacji?

Tak. Zmienne Public w module są w zasadzie globalne. Są dostępne z dowolnego kodu projektu, co jest wygodne, ale może prowadzić do błędów w wielowątkowości lub przypadkowego nadpisywania wartości.

Czy można utworzyć instancję modułu za pomocą New?

Nie. Moduły nie są instancjonowane. Cała ich funkcjonalność jest dostępna statycznie.

Czy można odziedziczyć moduł lub zadeklarować moduł z modyfikatorami dostępu Protected lub Private?

Nie. Moduły nie są dziedziczone i są deklarowane tylko na poziomie przestrzeni nazw (namespace), nie mogą być zagnieżdżane ani mieć innych modyfikatorów dostępu, z wyjątkiem Public lub Friend.

Typowe błędy i antywzorce

Używanie zmiennych globalnych bez kontroli dostępu
Przechowywanie stanu użytkownika w module zamiast w klasie (niewłaściwe dla wielowątkowości)
Deklarowanie dublujących funkcji w różnych modułach

Przykład z życia

Negatywny przypadek

W projekcie wszystkie zmienne stanu użytkownika są deklarowane jako Public w module. Przy każdej zmianie wartości w jednym formularzu natychmiast staje się ona nowa dla wszystkich pozostałych.

Zalety:

Szybki globalny dostęp do zmiennych

Wady:

Nadpisanie i trudne do uchwycenia błędy
Nie działa w scenariuszach wielowątkowych — race condition
Trudna do utrzymania

Pozytywny przypadek

Moduł jest używany tylko do przechowywania pomocniczych narzędzi (na przykład funkcji konwersji), a stan użytkownika jest przechowywany w klasach z enkapsulacją.