Недели три назад мне пришлось основательно взяться за разработку под iOS и (куда же тут без него) Objective-C. Из всего опыта была только прочитанная летом наполовину книжка по сабжу, пару раз открытый XCode, и попытка собрать ScummVM для iPad из сорцов. Надо сказать что идея овладеть obj-c появилась у меня в голове ещё больше года назад (с появлением iPad), а после переезда на мак этому не оставалось уже никаких препятствий.

Заранее извиняюсь у экспертов в iOS-деве за возможные ляпы: всё-таки, несколько недель это слишком мало чтобы досконально изучить все тонкости разработки под новую для себя платформу (но в самый раз чтобы зафиксировать впечатления, пока они не успели выветриться из головы). Если вы найдёте какую-то неточность или ошибку - пишите и я обязательно постараюсь её исправить.

Тёплые ламповости

Итак, первое что бросается в глаза тому, кто приходит писать под Cocoa (это, если кто не знает, UI-фреймворк в OSX/iOS) - непривычно выглядящий Objective-C. Многие ставят ему в вину необычный синтаксис для вызова методов (которые являются smalltalk-style посылкой сообщений). На самом деле, синтаксис любого языка это, конечно же дело вкуса, и, наверное, самая малая часть из того, к чему приходится привыкать при разработке под новую платформу.

С другой стороны, привычка (выработанная в Scala) выстраивать вызовы методов в длинные цепочки приводит к совершенно нечитаемым кускам кода:

1

    [webView loadRequest:[NSURLRequest requestWithURL:[NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"test" ofType:@"html"] isDirectory:NO]]];

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

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

Нераскрытые возможности

Впрочем, это всё мелочи, с которыми можно смириться. Можно даже их любить, если вас греет ощущение использования тёплого лампового языка. От чего действительно становится немного грустно, так это (как ни странно) от его достоинств и клёвых фич. Здесь Objective-C немного напоминает JavaScript лет 5-10 назад, когда большинство программистов на нём просто до конца не понимали что им делать со всей этой динамичностью, прототипами и замыканиями.

Итак, как я уже говорил, вызов метода в Objective-C является передачей сообщения от одного объекта другому. Это очень похоже на то, как это сделано в Ruby. Предвидя возмущение некоторых поклонников Erlang от того факта что передача сообщений происходит синхронно (а поэтому сообщения там “ненастоящие”), надо заметить что впервые эта концепция и терминология была предложена в Smalltalk (если не раньше), лет эдак за 15 до Erlang.

Как и Ruby, Objective-C умеет обрабатывать неизвестные сообщения (то есть те, для которых не написаны методы). Однако, в отличие от Ruby или Groovy, где возможности метапрограмминга используются на полную катушку, obj-c разработчики, похоже, рассматривают эту возможность скорее как метод расстановки костылей. Хотя лично мне кажется, что аналог dynamic finders в activerecord был бы отличным дополнением к core data.

Ещё одна относительно новая фича языка, блоки (“form of closures”, как говорит википедия), практически не используется в полную силу. Похоже, ни разработчики библиотек, ни прикладные ios-девелоперы просто не понимают, зачем им это нужно. Хотя, в отличие от предыдущего примера с dynamic finders, мне удалось найти несколько библиотек, пытающихся прикрутить ФП к Objective-C. Самая развесистая - это, пожалуй, FunctionalKit.

Остальное

С остальными вещами всё более-менее понятно: это протоколы (читай интерфейсы), категории (иногда их ошибочно считают миксинами, хотя они скорее являются формой манки-патчинга) и полуавтоматический менеджмент указателей. Последнее, наверное, пугает java- и других “высокоуровневых” девелоперов больше всего, однако на практике здесь всё просто. Хотя не к месту всунутый autorelease может доставить немало приятных минут в дебаггере, а устроить себе утечку памяти - вообще как нефиг делать. Всё это хорошо описано и давно используется в повседневной разработке.

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