Часть четвёртая, ещё более объектно-ориентированная

Мы с вами уже обсудили некоторые аспекты программирования на Objective-C - основном языке создания приложения для платформы Apple iOS, используемой в коммуникаторе iPhone, плеере iPod и планшете iPad. Сегодня продолжим знакомство с этим языком.

Должно быть, из прошлой части статьи вы помните, что язык Objective-C, будучи объектно-ориентированным, реализует несколько иную объектную модель, чем другой популярный язык, основанный на классическом C - C++. Используемый в Objective-C стиль перекочевал из языка Smalltalk, в то время как в C++ используется стиль, изначально предложенный создателями языка Simula. И дело здесь не столько в записи конструкций, сколько в тех возможностях, которые эти конструкции предоставляют. Мы уже достаточно подробно говорили о механизме посылки сообщений объектами друг другу, и сейчас я хочу напомнить обо всех этих вещах исключительно для того, чтобы вам было легче включиться в дальнейший разговор об особенностях Objective-C, по сравнению с привычными большинству наших читателей языками программирования, такими, как, например, тот же самый C++, с которым сравнение рассматриваемого языка напрашивается само собой.

Протоколы

Это страшное для мыслящего категориями административного кодекса гражданина слово для программиста на Objective-C не несет в себе совершенно никакого негатива. Протоколы в этом языке программирования - очень удобное и интересное средство для решения ряда достаточно распространенных задач.

В некотором роде протоколы можно уподобить интерфейсам, хотя это сходство не сказать чтобы было совсем уж полным. Фактически, протокол в Objective-C - просто список методов, которые должен реализовывать класс в том случае, если он поддерживает данный протокол (естественно, для того, чтобы говорить о том, что данный протокол поддерживается, класс обязан содержать реализацию каждого из описанных в нем методов). При этом протоколы, как и классы, поддерживают наследование - причем здесь оно может быть множественным, то есть один протокол может быть наследником сразу нескольких других.

Протоколы в Objective-C, как и интерфейсы в других языках программирования, удобно использовать в тех ситуациях, когда точно неизвестно, с каким именно классом будет вестись работа, но при этом нужно, чтобы класс поддерживал определенные, заранее известные, методы. Само собой, класс может поддерживать сразу несколько протоколов.

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

Рождение и смерть объектов

Казалось бы, чем может один объектно-ориентированный язык программирования отличаться от другого языка, основанного также на объектной парадигме, в области создания и уничтожения объектов? Но после того, как привычные вызовы методов заменились отсылкой сообщений объектам, логично было бы предположить, что и во многих других отношениях Objective-C отличается от правящих сегодня бал Java, C++, C# и т.д. Что ж, такое предположение действительно оправдывается...

В Objective-C для создания объекта необходимо выделить под него память, а затем инициализировать этот самый объект. Первая часть этой процедуры выполняется с помощью метода alloc, который есть в базовом классе Apple'овской runtime-библиотеки для Objective-C. Сама инициализация значения полей осуществляется методами, которые нужно писать, что называется, "ручками". Традиционно таким методам дают имена, начинающиеся с "init", но, в общем-то, сами понимаете, что это, скорее, для удобства, чем из каких-то других соображений. Выглядит же это всё в итоге следующим образом:

id anObject = [[Rectangle alloc] init];

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

В общем-то, конечно, в таком разнесении одного конструктора на два разных метода наверняка можно найти свои плюсы, хотя и не очень очевидные и явно не слишком часто нужные большинству программистов. В случае, если вы хотите использовать привычные конструкторы, а не alloc'и и init'ы, вы вполне можете быстро написать метод, объединяющий их, и пользоваться им практически как привычным конструктором. Но, с другой стороны, конечно, для стандартных классов, которые вы обязательно будете использовать в программировании под iPhone, таких методов не будет...

Еще несколько слов, касающихся непосредственно рождения и смерти объектов (то есть, экземпляров классов) в Objective-C, нужно сказать и о ссылках на объекты. В любом объекте "зашит" счетчик ссылок на него, который показывает, скажем так, "нужность" того или иного объекта для программы в целом. При создании объекта этот самый счетчик получает значение, равное единице, и затем оно может либо увеличиваться, когда он получает сообщение retain, либо уменьшаться, если он получает сообщение release. Сообщение retain должно приходить объекту, когда вы создаете ссылку на него (если, конечно, вы создаете её не просто из спортивного интереса и планируете как-либо в дальнейшем использовать). Сообщение release присылается объекту, соответственно, когда он перестает вас интересовать.

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

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

Что ж, пожалуй, не буду перегружать вас рассказами об Objective-C и его возможностях и на сегодня закончу. Думаю, в следующий раз мы с вами еще немного поговорим о некоторых особенностях основного "яблочного" языка программирования, но сильно этот разговор постараемся не затягивать, потому что всё-таки нас интересует не столько сам язык, сколько создание приложений для платформы iOS.

Вадим СТАНКЕВИЧ