В силу того, что Библиотеки Классов (файлы типа .vcx) являются самой значительной (определяющей) частью любого Приложения Visual FoxPro, процесс коллективной разработки указанных важных компонент должен тщательно координироваться. При коллективной работе с Библиотеками Классов обычно применяются стандартные способы отслеживания вносимых изменений в определения Классов, как и прочих Компонент Приложения; однако у Классов имеются следующие специфические особенности:

Как и независимая разработка нескольких Форм и Программных Модулей группой Разработчиков является уже распространенной практикой при создании сложного Приложения, так и при создании независимых Компонент (Классов) может эффективно использоваться труд нескольких Разработчиков. Если один разработчик изменил детали определения некоторого Класса, то данное событие не должно значительно повлиять на работу другиз Разработчиков. В общем случае, несколько разработчиков может эффективно работать с одной библиотекой классов, не замечая того, что данная библиотека расширяется Определениями новых Классов, что не должно критически влиять на уже работающие компоненты Приложения.

Когда некоторый Класс используется в пользовательской Форме, система Visual FoxPro кеширует данный класс на Рабочей станции Пользователя до тех пор, пока указанныя форма Активна и не будет стерта из Памяти. Вы должны явно очистить определение класса, чтобы система Visual FoxPro могла определить что рассматриваемых класс больше не используется. Если рассматриваемый Класс используется в рамках Текущей Сессии Данных (а значит он - кешированв памяти), и вам требуется обновить используемый экземпляр класса из обновленной библиотеки, вам необходимо сначала очистить класс из памяти (сбросить кеш), за тем - перегрузить новое определение Класса из Библиотеки Классов, находящейся в коллективном использовании несколькими Разработчиками.

Размещение Библиотеки Классов под управление подсистемой Source Control

Когда вы размещаете Библиотеку Классов под управление подсистемой Контроля (source control), то только один разработчик может выполнять изменения в деталях определений Классов этой библиотеки. Для остальных разработчиков указанная библиотека стновится доступной исключительно в режиме только-чтение. Как правило, это не создает помех для работающих Приложений и разработке других Коипонент, загружающих существующие экземпляры классов. Пока рассматриваемые классы используются Разработчиками в режиме только-чтение, первый разработчик может изменять определения во всех классах их указанной библиотеки.

Если вы используете описанный способ коллективной разработки, то не рекомендуется использовать данную библиотеку пока не завершен процесс разработки класса и выполняется тестирование. Иначе, пассивные разработчики могут получить незавершенную версию модифицированного класса, и, тем самым, создаваемые ими Компоненты могут быть неработоспособными.

Если Библиотека Классов является достаточно большой и сложной, вы можете разбить ее на несколько малых Библиотек классов. Это позволяет некоторым образом дифференцировать процесс использования Библиотек классов для разработки и использования в Приложениях, к тому же, библиотеки меньшего размера быстрее загружаются. Те не менее, данный вариант позволяет использовать несколько библиотек, как единое целое, при чем в разные моменты времени (по-необходимости).

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

См. также