NSProxy, как способ срезать на поворотах

[UncleAli]

- (void)forwardInvocation:(NSInvocation *)invocation
{
    [invocation invokeWithTarget:self.instance];
}

В таком случае лучше использовать -forwardingTargetForSelector::

- (id)forwardingTargetForSelector:(SEL)aSelector
{
    return self.instance;
}

[i_user]

Да, согласен полностью.

[Fanruten]

UIAppearance — насколько мне известно — единственное использование NSProxy в базовых iOS фреймворках

Какая связь между UIAppearance и NSProxy?

[i_user]

Если я не ошибаюсь, именно об этом пишут в документации, да и поведение весьма напоминает отложенный форвардинг.

[Fanruten]

Proxy и NSProxy это не одно и тоже)

(lldb) po [[[UIView appearance] class] superclass]
NSObject

Да и зачем ему NSProxy?

[i_user]

Хм… Проверил [UIButton appearance].isProxy — False. Так что вы правы, моя ошибка) Забавно, очень гармонично ложится на такую функциональность как раз NSProxy.
Спасибо за исправление!

[Fanruten]

Просто у вас получилось все в куче. Проксирование не всегда подразумевает использование NSProxy.

Прокисирование в Cocoa реализуется при помощи Message Forwarding, для этого у NSObject есть methodSignatureForSelector, forwardInvocation и другие.

Но если объект имплементирует какой-то селектор, то до форврадинга не дойдет. И если в качестве базового класса для прокси брать NSObject, то часть методов не проксируется (init, performSelector, ...). (конечно можно извратиться и переопределить эти методы в классе прокси, например руками или в runtime, но это слишком утомительно)

А если не NSObject, то что?! Свой root-класс просто не сделать, так как нужно имплементировать alloc и протокол NSObject.

Поэтому инженеры Apple добавили еще один root-класс (NSProxy), который имплементирует минимальное количество селекторов, и следовательно может проксировать почти всё.