Начнем с объектов Office 2000

Программный код большинства примеров данной лекции можно найти в проектах, доступных для просмотра: BookOne, BookThree, BookFive, Dex1, DocFive, DocThree.

VBA и объекты. Обзор

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

Office - это среда, в которой многие задачи можно решать без всякого программирования. Office 2000 - это среда, в которой класс таких задач существенно расширился. Но для программиста ценность офисной среды состоит в том, что все задачи, решение которых может быть получено "руками", можно получить и программно. И все, что нельзя сделать руками, можно сделать программно. Для программирования используется язык VBA (Visual Basic for Applications), представляющий расширение ядра языка VB (Visual Basic) объектами, определяющими приложения Office 2000.

Процесс работы в Office 2000 может быть, конечно, разным, - все зависит от того, работает ли профессионал - одиночка, или коллектив исполнителей разрабатывает большой проект. Но давайте будем представлять его следующим образом:

• В работе участвуют специалисты в проблемной области и программисты. Целью работы является создание системы "живых" документов офиса или предприятия. Работа строится на мощной основе, которую составляют документы, предоставляемые средой Office 2000. Документами могут быть бланки, отчеты, справки, базы данных, запросы к ним, графики, диаграммы. Документы мы называем живыми, поскольку в процессе работы конечных пользователей (специалистов) они могут изменяться. Эти изменения являются результатом выполнения различных функций над данными, размещенными в документах.
• Библиотека объектов Office 2000 представляет собой каркас документов (чуть позже мы определим более точно этот термин). Открывая впервые одно из приложений Office 2000, например Word, специалист получает готовый каркас некоторого документа, - для Word это документ, в котором основным типом данных будут тексты. Затем специалист берется за дело и наполняет этот каркас плотью и кровью, создавая уже реальный документ, входящий в общую систему. Однако, как бы ни увеличивались стандартные возможности среды, всегда для оживления документа чего-нибудь да не хватает, (вспомните, мечту о дефиците одного из героев Райкина). И тогда приходит время программиста.
• В процессе создания "живых" документов программист будет работать на VBA, едином языке программирования, объединяющем мир объектов среды Office 2000. VBA представляет мощный, универсальный язык программирования и на нем можно делать все, или почти все, что и на любом другом языке программирования. Но главное его достоинство состоит в том, что в нем определены и доступны для программиста все объекты Office 2000. Это значит, что доступны все документы, все их части, и части этих частей, вплоть до символа, рисунка, ячейки. Это и позволяет программисту легко проводить настройку системы документов с учетом их специфики. (В английском языке для этой деятельности есть хороший термин - customization, но, может быть, и термин "настройка" не хуже).

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

Библиотека объектов Office 2000 - каркас приложений

В тех книгах, которые мы написали последнее время по Visual C++ и по Офисному программированию, большая часть достаточно солидного введения посвящалась основам объектно-ориентированного программирования. Мы полагаем, что каждый программист должен владеть этим аппаратом, поскольку без четкого осознания таких понятий, как класс, интерфейс класса, полиморфизм, наследование, встраивание, невозможно проектирование и разработка сколь либо серьезной системы документов. В этой книге мы не будем останавливаться на этих понятиях, полагая, что читатели с ними знакомы, если же нет, то можно порекомендовать обратиться к нашим книгам по Visual C++ и Офисному программированию, или к любым другим, где эти вопросы хорошо изложены.

Но на одном термине стоит все-таки остановиться подробнее. Речь пойдет о понимании совокупности библиотек классов, как каркаса приложений (каркаса документов). Когда программист вводит собственный класс объектов, то чаще всего он рассматривает его, как специфический тип данных, расширяющий возможности типов данных, встроенных в язык. Первые библиотеки классов, предоставляемые системой программисту, по существу, представляли расширенный набор типов данных. Но затем стало понятным, что объектный подход может быть полезным и при построении самого приложения. Само приложение стало рассматриваться, как совокупность объектов со своими свойствами, методами и событиями. Более того, стало ясно, что можно строить приложения различной архитектуры и стандартных скелетов приложений не так уже и много. При работе в среде Visual C++ , например, классической является архитектура Документ - Облик (Document -View).

В современных программных средах большую часть классов, входящих в библиотеку (совокупность библиотек), составляют классы, предназначенные для построения самого приложения, его основы или каркаса. В соответствии с этим такие библиотеки называются каркасом приложений (FrameWork Applications). Такую роль играют библиотеки Visual C++, Delphi и других программных сред.

Как же обстоит дело в Office 2000? Для программиста Office 2000 - это ничто иное, как обычная совокупность библиотек классов. И так же, как и для других программных сред, их классы представляют собой каркас приложений, или, что может быть точнее с содержательной точки зрения, - каркас документов.

Дело в том, что изменились цели программиста, работающего в среде Office 2000. Ранее целью программиста было создание приложения, понимаемого как программа, программный проект. Теперь программист является одним из участников (возможно единственным) создания системы документов. Документ, а не программа, становится целью разработки. Программный проект - это лишь часть документа. В Office 2000 программный проект неразрывно связан с документом, хранится, как часть документа, и не может существовать независимо от него. Отсюда становится понятным, что и библиотека классов Office 2000 содержит каркасы основных документов - текстовых документов, документов, основу которых составляют электронные таблицы, презентации, базы данных. Всякий раз, когда создается новый документ, его каркас составляют объекты библиотек, отобранных для построения этого конкретного каркаса документа.

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

Встраивание вместо наследования

Обычно, классы, входящие в библиотеку, связаны между собой. Типично, на классах вводится отношение наследования, так что в иерархически связанном семействе классов есть родительские классы и классы - потомки. Наследование - мощный и естественный механизм порождения новых классов. Прародитель семейства может задавать некоторые общие, наиболее фундаментальные свойства и поведение объектов этого семейства, а его многочисленные потомки задают то или иное специализированное поведение. Кроме того, отметим, что наследование позволяет модифицировать поведение объектов - потомков, не меняя поведения объектов исходного родительского класса. Это важный принцип - "не разрушай то, что создано ранее". Ценность такого подхода, в частности, состоит и в том, что каркас конкретного приложения составляют классы - потомки, чьи родители находятся в библиотеке. Поэтому можно добавлять новые свойства, изменять и добавлять новое поведение у приложения, - все это никак не сказывается на родительских классах, хранящихся в библиотеке.

Наследование, конечно же, не единственно возможное отношение между классами. Программистам хорошо известно встраивание - еще один способ построения нового класса, использующий ранее созданные классы. Пусть построен класс А, тогда при определении нового класса В его элементами - переменными (свойствами класса В ) могут быть объекты класса А. В этом случае говорят, что объекты класса А встроены (вложены) в класс В. Встраивание, как и наследование, - транзитивное отношение. Реально это означает, что возможна сколь угодно высокая степень вложенности объектов. Следует отличать непосредственную вложенность от вложенности уровня n. Так, в новый класс С можно встроить объект класса В, и он будет непосредственно вложен в класс С, а объект класса А, встроенный в объект В, будет иметь уровень вложенности 2 по отношению к классу С.

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

Class Mother
{
	'Раздел атрибутов
	Chromosome XX;
'Другие объявления свойств и методов
....
}
Class Father
{
	'Раздел атрибутов
	Chromosome XY;
'Другие объявления свойств и методов
....
}

В классы Mother и Father встроены объекты XX и XY ранее определенного класса Chromosome. Используя множественное наследование, можно создать новый класс, наследующий свойства и поведение его родителей:

Class Child : Parents Mother, Father
{
	'Наследует свойства XX, XY и другие свойства и методы своих родителей
	'Раздел атрибутов
	String 	NewProperty;
	'Другие новые свойства и методы
}

Рассмотрим теперь создание класса, основанное на встраивании объектов:

Class MyChild
{
	'Раздел атрибутов
	Father	F;
	Mother	M;
	String	NewProperty;
	'Другие новые свойства и методы
}

Вот объявление объектов этих классов:

Child 	Son;
MyChild	Daughter;

Объекты Son и Daughter обладают одинаковыми свойствами и поведением. И в этом случае мы будем говорить, что классы Child и MyChild подобны. Есть некоторая синтаксическая разница - у объекта Son свойства XX и XY доступны непосредственно, а у объекта Daughter они доступны через вложенные объекты F и M, так что в первом случае мы пишем Son.XX и Son.XY, а во втором - Daughter.F.XY и Daughter.M.XX.

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

Если происходит переопределение родительских методов в производном классе, то в общем случае, используя встраивание, нельзя построить класс, подобный наследуемому. В нашем примере с классами Child и MyChild встраивание используется при построении класса MyChild как альтернатива наследованию. С другой стороны, в этих классах применяется, и "обычное" встраивание. Заметьте: свойства XX и XY в классах Child и MyChild - это встроенные объекты ранее определенного класса Chromosome. Так что этим примером мы демонстрируем обе ипостаси встраивания.

Мы так подробно остановились на встраивании по одной простой причине: этот механизм лежит в основе объектной модели в Office 97 и Office 2000. Здесь нет наследования в истинном смысле этого слова, и хотя этот термин иногда и используется, но фактически всегда речь идет лишь о встраивании. Все приложения Office 2000 с объектной точки зрения построены одинаково. Всегда существует задающий приложение корневой объект Application ( Word.Application, Excel.Application и т. д.), в который встроены все остальные объекты данного приложения.

Когда в объект Application вложен объект X, говорят, что у объекта Application есть свойство X, и запись Application.X означает обращение к объекту X. Сам объект X может быть не менее сложен: в него могут быть встроены другие объекты, например объект Y, а в него в свою очередь - объект Z. Эта цепочка вложенности может быть продолжена. Для приложений Office 2000 типична ситуация, при которой нужно указать 6-7 уровней вложенности, чтобы добраться до объекта, свойство или метод которого будет использовано. Вложенный объект, который является свойством объекта, его содержащего, называют иногда участником (accessor).

Длинные цепочки, возникающие при именовании объектов, являлись бы большим недостатком, если бы их пришлось выписывать вручную. Но вот пример того, как недостатки можно обращать в достоинства. Частью, используемой в Office 2000 всюду, где можно, технологии интеллектуальной поддержки (intellisense) является поддержка автоматического выписывания длинных имен. Как только после имени объекта ставится точка, автоматически раскрывается список с перечислением всех свойств этого объекта, так что остается только выбрать имя из списка, поставить точку и продолжить этот процесс. Если, поставив точку, Вы не видите списка, то это значит, что-то сделано неправильно, например, не задан класс объекта в операторе объявления или неверно понимается его структура, в любом случае это сигнал, заставляющий задуматься.

Подводя итог, отметим, что для программиста большинство библиотек Office 2000 задают совокупность "толстых" объектов - объектов Application. В каждый такой корневой объект вложены другие объекты, устроенные не менее сложно. С методами, свойствами и событиями, происходящими в мире этих объектов, и работает программист.

В заключение взгляните, как я представляю себе "толстый" объект Application.

Рис. 1.1. Вложенность объектов