Что показалось странным в Objective-C?

Странности Objective-C с точки зрения современного iOS разработчика

Objective-C, являясь уникальным гибридом C и Smalltalk, всегда воспринимался как язык с яркой индивидуальностью. После многолетнего перехода на Swift многие его особенности видятся особенно странными. Главная странность — это его синтаксис сообщений (message syntax), который фундаментально отличается от привычного вызова методов в большинстве языков.

Синтаксис отправки сообщений

Вместо классического object.method(param) мы видим [object method:param]. Это не просто другая запись — это философская разница. Вызов [receiver selector:argument] является динамической отправкой сообщения, а не статическим вызовом функции. Это позволяет делать такие вещи, как отправка сообщений к nil (которая просто возвращает nil без краха), что одновременно и мощно, и потенциально опасно.

// Странный, но мощный синтаксис
NSString *result = [someObject performComplicatedOperation:withArgument:andAnother:];

// Сравниваем с более "нормальным" синтаксисом (как в Swift)
// let result = someObject.performComplicatedOperation(withArgument, andAnother)

Динамичность достигается через runtime — уникальную среду, которая позволяет менять поведение программы на лету. Например, можно добавлять методы классу во время исполнения программы или менять реализацию существующих методов (method swizzling).

Обилие символов @ и разделение интерфейса/реализации

Другой странной особенностью является "засилье" символа @. Он используется для обозначения практически всех конструкций языка, добавленных сверху C:

// Странный "синтаксический сахар"
@interface MyClass : NSObject // Объявление класса
@property (nonatomic, strong) NSString *name; // Свойство
@end

@implementation MyClass
@synthesize name; // Автосинтезирование свойства (в ранних версиях)
- (void)sayHello {
    NSLog(@"Hello, %@!", self.name); // Строка и форматирование с %
}
@end

• @interface / @implementation — разделение объявления и реализации класса в разных файлах (.h и .m). Это кажется странным после Swift, где всё объединяется.
• @property — объявление свойства, которое автоматически генерирует методы доступа, но синтаксис их описания (nonatomic, strong, copy) выглядит как отдельный мини-язык.
• @selector() — получение селектора метода (его идентификатора) для динамических вызовов.
• Литералы строк, массивы,字典 — всегда с @: @"строка", @[], @{}.

Динамическая типизация и ручное управление памятью

Отсутствие строгой типизации в ранних Objective-C тоже воспринимается как странность. Идентификатор id может указывать на любой объект, и компилятор не будет жаловаться. Это даёт гибкость, но приводит к ошибкам времени выполнения.

id mysteriousObject = ...; // Что здесь? Неизвестно!
[mysteriousObject someMethod]; // Компилятор это пропустит, но может случиться крах.

Ручное управление памятью с подсчётом ссылок (Manual Reference Counting, MRC) до появления ARC было источником многих странных и болезненных практик. Необходимость явно вызывать retain, release и autorelease, соблюдать правила владения и балансировать счетчик ссылок — всё это создавало барьер для новичков и источник ошибок.

Прочие "странности"

• Длинные и часто повторяющиеся названия методов, которые читаются как предложения (stringByAppendingString:). Это было частью философии ясности, но выглядит чрезмерно.
• Протоколы (protocols), которые объявляются с @protocol, и необходимость проверять соответствие объекту протокола с conformsToProtocol: динамически.
• Использование префиксов (часто двух- или трехбуквенных) для имен классов из-за отсутствия пространств имен, что приводило к длинным именам вроде NSMutableArray, UIViewController.

В итоге, "странности" Objective-C — это не просто синтаксические quirks, а отражение его философии: максимальная динамичность, гибкость и близость к runtime. Для разработчика, привыкшего к строгой типизации и статическим языкам, он кажется архаичным и сложным. Но именно эти особенности позволяли создавать мощные, гибкие системы и фреймворки (как Cocoa и Cocoa Touch), которые до сих пор являются основой iOS и macOS разработки, даже в эпоху Swift.