Энтузиазм в стане разработчиков xBASE-приложений, вызванный появлением CA-VisualObjects, похоже, несколько приутих. И дело здесь вовсе не в качестве нового продукта, а в том, что наивные ожидания простаков, связанные с выходом якобы "Clipper for Windows", не оправдались. VisualObjects как современный продукт, не чуждый последним веяниям моды в области ООП, заставляет программистов осваивать принципиально новые методы работы, подтверждая старые предположения о том, что простого перехода от традиционного программирования к объектному не получится.

Computer Assiciates приложила максимум усилий при разработке нового, активно продвигаемого на рынке продукта – CA-VisualObjects. При этом были учтены пожелания большого количества пользователей и прикладных программистов. Однако тех, кто считает процесс перехода с привычной xBase-платформы на рельсы VisualObjects легким занятием, ждет разочарование. Да, с синтаксической точки зрения СА-VisualObjects почти на 90 процентов совпадает с CA-Chpper. Но, увы, тем, кто предпочитает Clipper, это не даст почти никаких преимуществ. Так что сразу договоримся: не стоит считать Visual-Objects каким бы то ни было "продолжением Clipper" или "Chpper'oM для Windows". Правда, с аналогичными трудностями при появлении новых релизов пакетов встречаются и приверженцы других платформ в области СУБД среднего класса.

Конечно, при работе с VisualObjects можно использовать конструкции Clipper и включать разработанный ранее код в новую систему приложений. Однако самого быстрого эффекта добьются именно те, кому хорошо знакомы C/C++ и средства фоновой разработки в Windows.

В значительной степени проблемы перехода к программированию в VisualObjects являются психологическими – они основаны на подготовке и полученных ранее знаниях. Чтобы разработка имела смысл, здесь необходимо четко понимать особенности и преимущества объектно-ориентированного подхода, иметь представление о динамически компонуемых библиотеках (DLL) и принципах программирования в Windows.

Один из главных вопросов, волнующих каждого в процессе выбора программной системы, – необходимое оборудование. Понятно, что "чем лучше – тем лучше". А уж своеобразный закон, согласно которому "памяти никогда не бывает много", действует в случае с VisualObjects безотказно. Однако по сравнению с продуктами-"одноклассниками" VisualObjects далеко не так прожорлив Как минимум требуются: 386-я машина с 8 Мб оперативной памяти и установленная Windows 3.1, а также примерно 40 Мб свободного дискового пространства. Но чтобы сделать работу комфортабельной, лучше иметь 486-й процессор и 16 Мб памяти. И наконец, для создания приложений в среде GUI рекомендуется использовать сопроцессор.

Ясно, что описанная выше конфигурация необходима именно для разработчика, конечный же пользователь, применяющий готовые приложения, написанные в VisualObjects, не нуждается в таком мощном оборудовании. И это оказывается существенным фактором при использовании продукта для разработки коммерческих систем.

Программисты, предпочитающие Clipper, всегда считали достоинством этой платформы наличие огромного числа дополнительных библиотек, предлагаемых как правило третьими фирмами и независимыми разработчиками. Необходимость в привлечении иных продуктов в случае с VisualObjects практически отпадает. Пригодится разве что библиотека для работы с графикой. Так что, купив продукт, вы можете подумывать только о модернизации техники, а не о предстоящих поисках очередных Tools'os.

Для закоренелых "клипперистов" вряд ли будет большой потерей отсутствие любимого NortonGuides: его задачи даже на более высоком уровне реализации гипертекста выполняет стандартная для Windows система подсказки.

В отличие от прежних сред программирования, в области Visual-Objects простое изучение синтаксиса не влечет за собой быстрого автоматического старта (при наличии, естественно, некоторой алгоритмической подготовки). Приходится знакомиться и с новой терминологией.

Прежде всего, речь идет о "репозитории". Это понятие чрезвычайно важно при разработке приложений и выпадает из практики мышления в терминах файлов, привычной поСА-Chpper Вместо операций с .PRG- и .СН-файлами в VisualObjects используются модули, каждый из которых состоит, возможно, из нескольких функций, определений классов, методов, называемых компонентами (entity, и хотя специалисты по базам данных стремятся переводить этот термин как "сущность", во избежание недоразумений следует придерживаться понятия "компонент"). Итак, приложения, модули и компоненты хранятся в репозитории – своего рода глобальной базе данных.

У репозитория есть еще одна важная функция – управление всеми частями приложения до компонентов самого низкого уровня. Автоматически поддерживаются связи между различными модулями и компонентами всех приложений Репозито-рию всегда "известно", был ли исходный код модифицирован или откомпилирован, так что отпадает необходимость в make-файлах и файлах, так или иначе описывающих процесс компоновки.

Для того чтобы вести профессиональные разработки на VisualObjects, необходимо освоить и смысл того, что принято называть "видимостью". Правда, именно здесь прежний опыт процедурного программирования сослужит добрую службу, поскольку принципы видимости переменней констант используются уже давно. То же самое относится и к областям действия переменных.

Компилятор

Обратимся теперь к компилятору. Как ни печально, опыт предыдущего программирования на Clipper вряд ли пригодится и здесь. Выбор опций компиляции в VisualObjects абсолютно иной. По умолчанию устанавливается режим low – отображение лишь самых серьезных ошибок. Однако вы можете выбирать между такими опциями, как none (предупреждения не выводятся, видимыми оказываются лишь сообщения об ошибках), med (только важные предупреждения и серьезные ошибки), high (вывод всех предупреждений и ошибок) и уже упомянутой low.

Приятно, что существует "проверка рабочего времени" – своего рода программный переключатель, позволяющий предупреждать возникновение ошибок выполнения (именно с ними и приходится бороться особенно ожесточенно). Здесь можно заказать проверку переполнений, диапазонов(например, доступ к элементам массива вне указанной размерности) и контроль корректности принадлежности объекта к тому или иному классу.

Но есть чему порадоваться и воспитанникам "Clipper-школы". В VisualObjects реализован целый список переключателей компилятора, используемых для обеспечения совместимости с CA-Chpper и задания ее уровня. Так, можно "разрешить" применение переменных в стиле Clipper (без предварительного объявления, хотя этот стиль хорошим не назовешь), объявить правила использования оператора присваивания "=" или ":=", а также обеспечить применение функций ProcName() и ProcLmef).

Кроме того, компилятор Visual-Objects позволяет проводить оптимизацию кода по размеру и скорости. И наконец, есть возможности смешанной проверки, что очень полезно в процессе конвертирования Clipper-программы в VisualObjects.

Библиотеки

Не буду вдаваться в теоретизирование относительно той пропасти, которая лежит между традиционной трактовкой библиотек и принципами их использования в Windows-приложениях, хотя, конечно, есть здесь и много общего.

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

Остановимся вкратце на наиболее интересных библиотеках.

В первую очередь, это GUI Classes – совокупность почти 100 классов. Именно здесь описаны классы для формирования окон, списков, кнопок, линеек прокрутки и прочих атрибутов GUI.

DBF-библиотека поддерживает стандартные для xBase-архитектуры команды и функции обработки данных. Средства ООП – методы, классы – позволяет реализовать библиотека DBF Classes. Полагаю, ее полезность особенно оценят те, кому придется разрабатывать приложение, параллельно открывающее в нескольких окнах одну и ту же базу данных.

Доступ через ODBC к таблицам обслуживает библиотека SQL Classes, интерфейс ООП для генератора отчетов – Report Classes, ввод/вывод в традиции xBase – Terminal, а функции прикладного программирования для Windows – Windows API Центральное место занимает библиотека System Library, содержащая все системные средства.

Программирование и GUI

При работе с VisualObjects существует два варианта программирования в графическом интерфейсе – использование программы эмуляции.

терминала или применение библиотеки классов CommonView. В первом случае вы получаете возможность использовать созданные ранее Clipper-приложения как программы Windows, хотя, конечно, это будет все то же DOS-приложение, просто работающее в окне Windows. За счет эмуляции терминала у вас, к несчастью, не получится (по известным причинам), как по мановению волшебной палочки, превратить DOS-программу в полноценное приложение Windows, но зато вы сможете получить некоторый выигрыш в скорости исполнения за счет использования расширенной памяти.

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

CA-VisualObjects дает возможность применять мощный набор средств визуального программирования. Так, доступны редакторы меню, окон, отчетов, исходных текстов программ и пиктограмм. Их использование-тема для отдельного разговора. Скажу лишь, что при наличии некоторого опыта они оказываются чрезвычайно эффективными и позволяют создавать великолепные приложения.

Освоение

Увы, в небольшой статье трудно дать какие-то развернутые советы. Да это и не нужно. Речь идет о том, что разработчикам, осознавшим необходимость перехода на рельсы Windows, приходится выбирать между массой заманчивых предложений производителей software и близких по возможностям продуктов. Надо понимать, что "просто так" ничего не бывает. И приложить определенные усилия для изучения принципов разработки систем в среде Windows так или иначе придется.

Сегодня часто можно услышать не самые лестные отзывы относительно легкости освоения VisualObjects. Даже представители Computer Associates открыто говорят об этом. Но, на мой взгляд, проблема состоит не в "тяжелом характере" VisualObjects, а в традиционной ломке представлений и привычек, происходящей на пути от процедурного программирования к ООП. В общем, смело можно предположить, что скоро мы увидим большое количество весьма привлекательных программных систем, созданных на базе VisualObjects и реализующих все достоинства информационных систем в архитектуре "клиент-сервер".