converted to PDF by BoJIoc

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

Действуя таким образом, приходим к схеме, в которой мы имеем один новый объект для каждого класса системы. Основная функция данного объекта состоит в создании новых экземпляров класса. Чтобы сделать это, он должен поддерживать информацию о размере класса и его методах. В практическом отношении этот объект и есть класс.

20.2.2. Класс Class

Каждый объект должен быть экземпляром некоторого класса, и описанный выше объект не является исключением. Экземпляром какого же класса он является? Ответ для языков Smalltalk, Objective-C, Java и аналогичных им состоит в том, что он является экземпляром класса, называемого Class. На рис. 20.2 показана CRC-карточка (обе стороны) класса Class в системе Little SmallTalk. По соглашению, значение этого объекта содержится в переменной, которая имеет то же самое имя, что и сам класс. То есть переменная Set содержит объект со структурой, аналогичной изображенной на рис. 20.3. Он отвечает за создание новых экземпляров класса.

Создание объекта инициируется сообщением new, которое определено как метод класса Class. Каждый создаваемый объект является экземпляром некоторого класса и содержит указатель на объект, представляющий этот класс. Во время пересылки сообщения упомянутый указатель используется для того, чтобы найти метод, соответствующий селектору обрабатываемого сообщения.

Чтобы понять все это, вы должны различать взаимосвязь подклассов и взаимосвязь экземпляров. Класс Class является подклассом класса Object — тем самым объект Class указывает на объект Object как на свой надкласс. С другой стороны, объект Object является экземпляром класса Class — тем самым Object указывает обратно на Class. Класс Class является классом сам по себе и тем самым является экземпляром самого себя. Если мы исследуем типичный класс, скажем Set, то объект Set будет являться экземпляром класса Class, но, кроме того, он будет (неявно) и подклассом класса Object. Конкретное множество set является экземпляром класса Set. Эти взаимоотношения проиллюстрированы на рис. 20.3, на котором сплошные линии представляют взаимосвязь экземпляров, а пунктирные линии обозначают связь подклассов.

20.2.3. Метаклассы и класс-методы

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

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

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

converted to PDF by BoJIoc

Если мы хотим, чтобы экземпляры класса имели свое собственное поведение, единственное решение — сделать их экземплярами своих собственных классов.

Метакласс является классом классов. В Smalltalk-80 метакласс неявно и автоматически конструируется для любого класса, определенного пользователем. Каждый метакласс имеет только один экземпляр, который является собственно классом. Метаклассы организованы в иерархию «класс–подкласс», которая отражает аналогичную иерархию для исходного класса. Эта иерархия содержит метаклассы и имеет корень в классе Class, а не в классе Object.

Ниже показана часть иерархии классов в Smalltalk-80:

Object — надкласс всех объектов

Collection — абстрактный надкласс всех совокупностей Bag — класс мультимножеств

Соответствующая иерархия метаклассов выглядит так:

Object — надкласс всех объектов

Class — поведение, общее для всех классов Metaclass-Object — инициализация всех объектов

Metaclass-Collection — инициализация коллекций collections Metaclass-Bag — инициализация мультимножеств bags

Код, специфический для отдельного класса, связывается с метаклассом этого класса. Например, экземпляры класса Bag содержат словарь, который используется для хранения фактических значений. Метакласс для класса Bag переопределяет

Листинг 20.1. Метод newDay:year: класса Date

newDay: dayСount year: referenceYear

"Возвращает дату, отстоящую на dayСount дней "

"от начала года referenceYear "

Ѕday year daysInYear Ѕ

day <- dayCount.

year <- referenceYear.

[ day > (daysInYear <- self daysInYear: year) ] whileTrue:

[ year <- year + 1

day <- day — daysYear ]. [day <= 0]

whileTrue:

[ year <- year — 1

day <- day + (self daysInYear: year) ] self new day: day year: year

метод new, чтобы производить инициализацию словаря при создании новых экземпляров. Это действие осуществляется методом new, определенном в классе Metaclass-Bag и переопределяющем метод класса Class. Сам метод приведен ниже:

new

" создать и инициализировать новый экземпляр " super new setdictionary

Поскольку класс Bag является экземпляром класса Metaclass-Bag,

converted to PDF by BoJIoc

Листинг 20.2. Метод daysInYear: класса Date

daysInYear: yearInteger " возвращает число дней в году, yearInteger "

365 + (self leapYear: yearInteger) leapYear: yearInteger

"1, если год yearInteger — високосный, "

"иначе 0 "

то указанный метод будет вызываться в ответ на сообщение new. Прежде всего, метод пересылает сообщение надклассу, который осуществляет действия, аналогичные обязанностям, показанным на CRC-карте, приведенной ранее. Таким способом надкласс создает новый объект. Как только новый объект возвращен, ему посылается сообщение setDictionary. Соответствующий метод, показанный ниже, устанавливает значения полей экземпляра для вновь созданного словаря:

setDictionary

" установить новый словарь " contents <- Dictionary new

Не вы одни считаете эти рассуждения запутанными. Концепция метаклассов имеет репутацию одного из наиболее труднодоступных аспектов в Smalltalk-80. Несмотря на это, она полезна тем, что позволяет нам придать конкретные свойства функции инициализации для индивидуальных классов, не выходя за рамки чистого объектно- ориентированного подхода. Однако, учитывая запутанную природу метаклассов, большинство программистов очень благодарны системе, которая позволяет их не замечать. Например, в Smalltalk-80 класс-методы определяются при просмотре броузером базового класса, а не метакласса. Щелчок «класса» или «экземпляра» во втором окошке показывает, описывается ли метакласс или собственно класс. Аналогично в языке Objective-C методы, перед которыми в первой колонке стоит знак «плюс» (так называемые методы-«фабрики»), связаны с метаклассами, в то время как методы, которые начинаются с «минуса», являются класс-методами.

Дальнейшая информация о метаклассах и метапрограммировании может быть найдена в работе [Kiczales 1991].

20.2.4. Инициализация объектов

Мы продемонстрировали, как методы классов, определяемые посредством метаклассов, используются для решения одной из проблем, очерченных в начале этого раздела — проблемы специализированной инициализации. Вернемся теперь ко второй проблеме, — инициализации объектов, для которых требуется больше информации, чем просто их размер. Мы покажем (наряду с другими вопросами), как методы класса могут быть использованы для решения этой проблемы.

В качестве примера используем класс Date для языка Smalltalk-80. Экземпляры класса представляют собой дату определенного года. Каждый экземпляр класса Date хранит два значения: номер года и число в диапазоне от 1 до 366, то есть день. Новый экземпляр класса Date может быть создан различными способами. Например, сообщение Date today порождает экземпляр класса Date, представляющий текущую дату. Даты могут быть также в явном виде определены пользователем путем задания года и дня. В этом случае вызывается код, показанный в листинге 20.1. Он осуществляет небольшую проверку, гарантируя, что номер дня положителен и не превосходит числа дней в году. Когда есть

converted to PDF by BoJIoc

уверенность, что значения допустимы, код использует метод new для создания нового объекта и инициализации его заданными значениями.

Сообщение daysInYear:, вызываемое в методе, показанном в листинге 20.1, иллюстрирует другое использование методов класса: здесь обеспечивается поведение, связанное с классом в целом, а не с каким-либо конкретным экземпляром. Объект Date на запрос о

количестве дней в определенном году возвращает требуемое целое число без фактического построения нового экземпляра класса. Он делает это, используя тот же самый механизм определения метода класса за исключением того, что в данном случае метод класса возвращает целое число, а не новое значение. Методы daysInYear и leapYear (високосный-год), которые вызываются при этом, показаны в листинге 20.2.

20.2.5. Подстановки в Objective-C

Интересной иллюстрацией точки зрения «классы суть объекты» является понятие подстановки класса в языке Objective-C. Мы часто видели ситуации, когда программист желает подставить вместо одного класса другой в уже существующем приложении.

Обычно новый класс наследует все из исходного класса и модифицирует только небольшую часть поведения. Примерами являются классы GraphicalReactor из главы 12 и ParallelCard, описанный выше в этой главе. В обоих случаях было бы желательно изменить все сообщения о создании объектов, чтобы использовать новый класс вместо исходного.

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

[ GraphicalReactor poseAs: [ Reactor class ]];

Все последующие ссылки на класс Reactor, включая сообщения о создании экземпляров класса, будут отсылаться к классу GraphicalReactor. Наиболее часто объект, подставляемый вместо другого, — это подкласс замещаемого класса. Тем самым

большинство сообщений будет переадресовано обратно исходному

Листинг 20.3. Описание класса со статическими полями

// // --------- класс Card

//

class Card

{

public:

//конструктор

Card(int s, int c);

//константы

static const int CardWidth; static const int CardHeight;

...

};

const int Card::CardWidth = 68; const int Card::CardHeight = 75;

классу (являющемуся теперь надклассом).

converted to PDF by BoJIoc

Как статические переменные, так и статические методы обычно доступны через имя класса. Однако для удобства к ним можно обратиться и через экземпляр класса.

20.3.4. Переменные класса в Objective-C

В языке Objective-C нет явной поддержки переменных класса. Мы можем получить нечто похожее, объявляя простые статические (static) переменные языка C в части implementation описания класса. Такие переменные доступны только внутри файла, содержащего реализацию, и к ним нет доступа у клиентов-подклассов и у клиентов- пользователей. Например, методы в нижеследующем классе Date могут ссылаться на статический массив dayNames. (Этот трюк работает также в C++ до тех пор, пока все функции,

Рис. 20.4. Схемы делегирования

обращающиеся к данным, находятся в одном файле.)

# import "Date.h"

static char *dayNames[ ] = {"Воскресенье", "Понедельник", "Вторник", "Среда", "Четверг", "Пятница", "Суббота"};

@implementation Date

...

@end

20.4. Нужны ли классы?

Учитывая все нюансы объектов, экземпляров, классов, метаклассов и тому подобного, невольно задумаешься, нельзя ли создать объектно-ориентированный язык без привлечения классов? Оказывается, можно, хотя не вполне ясно, чем программирование

втаких «деклассированных» объектно-ориентированных языках оказывается проще или быстрее, чем в языках с классами. Также не ясно, являются ли получающиеся программы

вчем-то более эффективными.

converted to PDF by BoJIoc

Рис. 20.5. Результат работы калейдоскопического пера

20.4.1. Что такое знание?

Объектно-ориентированный подход связан с тем представлением, что знание есть отнесение конкретной вещи к абстрактному типу. Платон, например, утверждал, что наше понятие лошади не основывается на какой-либо конкретной лошади, но выводится из идеи «лошадности». Все физические объекты — только приближения к более совершенной абстракции; они — всего лишь бледная тень идеи.

Альтернативное представление утверждает, что люди получают информацию путем изучения конкретных объектов, а затем отбрасывают несущественные частности, чтобы построить общую абстракцию. Например, концепция слона основывается на конкретном слоне, которого данный человек в молодости видел в зоопарке. Затем человек создает образ второго слона, соотнося его с более ранним образцом. У этого нового слона уши могут быть меньше, и, таким образом, познающий заключает, что размер уха не является существенной характеристикой «слоновости». Путем многократного повторения такого процесса сравнения человек вырабатывает общее представление. Каждая абстракция приводит обратно к конкретным экземплярам, на которых она и основывается.

20.4.2. Делегирование полномочий

В языках программирования идея общности между конкретными экземплярами известна как делегирование [Lieberman 1986]. При делегировании нет классов — вместо этого программист создает конкретные экземпляры объектов, и вся функциональность связывается с конкретными объектами. Всякий раз, когда объект оказывается похожим на уже существующий объект, программа может делегировать часть поведения нового объекта объекту-оригиналу. Любое сообщение, которое не распознается новым объектом, будет переадресовано объекту, которому осуществлено делегирование. Он в свою очередь может делегировать свое поведение другому объекту и т. д.

Таким образом, мы можем построить язык программирования из объектов (которые содержат переменные и методы) и делегирования (посредством которого объект переадресовывает выполнение любых нераспознаваемых методов другому объекту).

Совместное использование кода происходит в таких языках через применение общих делегатов.

В качестве иллюстрации построим простую графическую систему. Предположим, что у нас есть объект, который рисует линии и реагирует на единственное сообщение

converted to PDF by BoJIoc

drawFromTo(a, b, c, d). В качестве реакции на это сообщение рисуется отрезок сплошной линии из точки с координатами (a,b) к точке с координатами (c,d).

Прежде всего мы построим перо, являющееся инструментом рисования, которое помнит свои координаты. Объект-перо инкапсулирует две переменные, x и y, а также определяет методы установки и сообщения этих переменных: getX(), getY(), setX(a), setY(b). Затем объект-перо определяет два метода рисования — а именно, moveTo(a,b), который только перемещает перо без рисования, и drawTo(a,b), который рисует линию. Эти методы могут быть определены с помощью следующего псевдокода:

method moveTo(a, b) self setX(a) self setY(b)

end

method drawTo(a, b)

self drawFromTo(self getX(), self getY(), a, b) self moveTo(a,b)

end

Объект-перо делегирует ответственность за метод drawFromTo объекту-линии (рис. 20.4).

Предположим, что программист хочет создать второе перо. Используя технику делегирования, он прежде всего обеспечивает описание объекта, соотнося его (по возможности) с уже существующими объектами. Одна из форм описания может выглядеть так: «второе перо должно вести себя в точности как первое, но поддерживать свои собственные координаты». Из этого описания ясно, что второе перо обязано содержать свои собственные переменные и определять методы для setX и т. д. Однако поскольку оно делегирует себя первому перу, это будут единственные методы, которые надо определить; оставшиеся детали поведения будут унаследованы от первого пера. Когда второму перу посылается сообщение, то получатель (второе перо) пересылается как составная часть сообщения дальше по пути делегирования. Когда следующие сообщения посылаются объекту self (клиенту в терминологии Либермана), поиск начинается снова с исходного получателя. Тем самым сообщения setX и getX, — используемые, например, в методе drawTo, будут сопоставляться с методами второго пера, а не первого. Этот процесс сопоставления аналогичен способу, при котором связывание метода всегда начинается с базового класса получателя. Проблемы, возникающие при этом способе, проявляются и в своем «делегированном» эквиваленте.

Делегирующие объекты не всегда должны переопределять переменные. Предположим, мы хотим создать калейдоскопическое перо, которое производит отражение относительно осей x и y, рисуя четыре линии вместо одной линии для исходного пера (рис. 20.5). Мы можем ввести объект, который переопределяет только метод drawTo; все остальное поведение делегируется первоначальному перу. Поскольку координаты x и y являются координатами исходного пера, изменения в пере типа «калейдоскоп» приводят к изменениям в первоначальном пере. Новый метод drawTo выглядит следующим образом:

self moveTo(a,b) end

Теперь предположим, что программист хочет определить перо типа «черепашка», которое сохраняет не только координаты, но и ориентацию [Abelson 1981]. Кроме собственно рисования, «черепашку» можно научить поворачиваться и двигаться вперед или назад относительно текущей ориентации. Если мы используем существующее перо для сохранения координат «черепашки», ей потребуется определить единственную переменную, а также методы turn(amount), forward(amount) и backward(amount).