Ответ.

Модули (Module) в Visual Basic исторически используются для хранения процедур, функций и переменных, доступных во всем проекте без явного создания экземпляра. С введением классов, их роли частично пересекаются, однако существенные различия сохранились.

История вопроса:

В классическом Visual Basic (VB6) модули были единственным способом группировки общих функций и глобальных переменных. В VB.NET модули остались, но с расширенными возможностями классов.

Проблема:

Разработчик может не понимать различия между модулем и классом, что приводит к ошибочному выбору способа хранения логики, случайному дублированию кода или неожиданному поведению переменных.

Решение:

Выбор между модулем и классом зависит от целей:

Модули предназначены для хранения процедур и переменных, которые должны быть доступны во всем приложении без создания экземпляра
Классы пригодны для инкапсуляции состояния и поведения объектов с возможностью наследования

Пример кода:

' Модуль
Module MathUtils
    Public Function Add(x As Integer, y As Integer) As Integer
        Return x + y
    End Function
End Module

' Использование
Dim result = MathUtils.Add(5, 10)

Ключевые особенности:

Все члены модуля всегда Shared и доступны без экземпляра
Модуль не поддерживает наследование или создание экземпляров
Модуль нельзя объявить как Friend/Protected внутри класса

Вопросы с подвохом.

Если объявить переменную в модуле как Public, будет ли она общей для всех форм/классов приложения?

Да. Public переменные в модуле являются по сути глобальными. Они доступны из любого кода проекта, что удобно, но может привести к ошибкам при многопоточности или случайной перезаписи значений.

Можно ли создать экземпляр модуля с помощью New?

Нет. Модули не инстанцируются. Весь их функционал доступен статически.

Можно ли унаследовать модуль или объявить модуль с модификаторами доступа Protected или Private?

Нет. Модули не наследуемы и объявляются только на уровне пространства имен (namespace), не могут быть вложенными или иметь другие модификаторы доступа, кроме Public или Friend.

Типовые ошибки и анти-паттерны

Использование глобальных переменных без контроля доступа
Хранение состояния пользователя в модуле вместо класса (невалидно для многопоточности)
Объявление дублирующих функций в разных модулях

Пример из жизни

Негативный кейс

В проекте все переменные состояния пользователя объявляются как Public в модуле. С любым изменением значения в одной форме оно мгновенно становится новым для всех остальных.

Плюсы:

Быстрый глобальный доступ к переменным

Минусы:

Перезапись и трудноуловимые баги
Не работает в многопоточных сценариях — race condition
Сложная поддержка

Позитивный кейс

Модуль используется только для хранения вспомогательных утилит (например, функций преобразования), а состояние пользователя хранится в классах с инкапсуляцией.