Comments 6
Возможно строчку
лучше убрать из класса контроллера, потому что это конфьюзит в свете того, что делегат у mapView перебивается в классе прокси.
self.mapView.delegate = self;
лучше убрать из класса контроллера, потому что это конфьюзит в свете того, что делегат у mapView перебивается в классе прокси.
А зачем тут прокси? NewLogicController всё-равно переопределяет делегат MapView и решает, куда дальше прокидывать вызов. Он и может сразу вызывать originalDelegate, вместо прокси. В чем его смысл, кроме как «было интересно попробовать»?
Всё верно говорите. Тут скорее образовательный пример. В проекте есть более сложный и уместный прокси класс, но его реализация достаточно сложна и специфична (частичное использование API из runtime/objc.h), где прокси как раз сам пробрасывает сообщения всем кому может. Всё таки статья расчитана на начинающих, поэтому не хотелось лишних усложнений. Опять же, к сожалению, прокидывать приходится обратно, так как метод требует возвращаемое значение, то есть не void типа.
Я тоже такой вопрос хотел задать, но затем пришло осознание, что ведь в данном случае прокси позволяет вызвать методы у тех, у кого они определены (с приоритетом, конечно же), и без него NewLogicController обязан определить ВСЕ методы делегата и пробросить их дальше, чтобы ничего не потерять. Прокси же автоматически вызовет методы, которых нет в NewLogicController, у старого вью контроллера.
Не то чтобы это было хорошо, все-таки, неявность очень сильно увеличивает время понимания кода, но зато показывает, как, действительно, красиво можно решать проблему.
Не то чтобы это было хорошо, все-таки, неявность очень сильно увеличивает время понимания кода, но зато показывает, как, действительно, красиво можно решать проблему.
Sign up to leave a comment.
Использование NSProxy класса на простом примере