Модули и модули классов
Программные компоненты ActiveX реализованы в Visual Basic в виде модулей классов. Модули существуют в Visual Basic еще с его первой версии. Они содержат объявления переменных и подпрограмм (функций и процедур), которые доступны всем другим компонентам приложения. Многие примеры, приведенные в предыдущих главах, имеют собственные модули. Функция ConvertTemperature (degrees As Double) может быть вызвана из нескольких мест кода и из многих форм, если ее определить в модуле. Процедуры, хранимые в модуле, могут быть вызваны из любого места приложения. Это также справедливо и для переменных, которые должны быть доступны многим процедурам. Это один из способов, благодаря которому формы и процедуры различных форм могут обмениваться информацией.
Можно рассматривать процедуры, как методы модуля, однако нет потребности предварять их вызов суффиксом в виде имени модуля. Общедоступные (public) переменные, которые находятся в модуле, также могут рассматриваться как свойства модуля. Таким образом, модуль очень похож на класс. В Visual Basic классы реализованы как модули специального типа, называемые модулями классов.
Здесь может возникнуть вопрос: "Зачем беспокоиться о классах, если модуль может предоставить функциональные возможности, необходимые для создания приложения?" Если необходимо создать всего лишь несколько процедур и глобальных переменных для одного проекта, то, возможно, лучше разместить их в одном модуле. Однако, если планируется использовать эти же процедуры в
различных проектах, то необходимо конструирование модуля класса. Допустим, несколько функций были реализованы в модуле и протестированы в составе проекта А. Их реализация оказалась вполне удовлетворительной. Если потом создается другой проект — В, который использует тот же модуль, то логика подсказывает, что функциям модуля необходима некоторая переделка. Тогда модуль дополняется несколькими новыми переменными типа public, в результате чего с проектом В он уже работает прекрасно. Но при этом проект А, скорее всего, перестает быть работоспособным. Даже если приказать себе больше не трогать модуль, то как быть в случае групп разработчиков, работающих над общим проектом? Позволить многим программистам иметь доступ к одному модулю из своих проектов, значит ожидать катастрофы. Один из них неизбежно изменит программу и испортит некоторые из существующих проектов.
Другой потенциальной опасностью является конфликт имен. Если добавить в проект модуль с несколькими глобальными переменными, некоторые из них могут иметь имена, совпадающие с теми, которые используются в других проектах. В этом случае правила видимости определяют, какая переменная имеется в виду (она может не совпадать с той переменной, которую хотелось бы использовать). Свойства в модуле классов не могут быть доступны только по их имени. Они должны использоваться посредством выражения типа
ClassName.VariableName, которое делает свойство уникальным не только в текущем проекте, но и в операционной системе.
