Владислав Ресли (как мне кажется - Если вы до этого изучали С#, то это знание может сыграть с вами злую шутку в понимании делегатов в иос разработке. Почему? Потому что в отличии от С# в иос разработке они декларативны. За ними не стоят специяальные конструкции и объявления.)
Если вы создали классы "Зритель" и "Проигрыватель" и вам надо чтобы "зритель" знал о событии окончания проигрывания, то вы в классе "Проигрыватель" создаете пропертю c типом"Пользователь", чтобы, когда надо, вызвать по этой проперти нужный метод (пусть будет
didEndPlaying()).
Получается, что, по логике, проигрыватель делегирует пользователю совершить действия по конкретному событию. Получается (в моем примере), зритель - делегат проигрывателя. И, чтобы, при просмотре кода зразу понимать эту логическую цепочку, принято подобные проперти именовать
delegate (в моем случае такая проперти будет в классе Проигрыватель).
А так как по конкретному классу обращаться не прааааавильно, но создают протокол "ДелегатПроигрывателя" (на инглише бы было
PlayerDelegate, уже знакомей звучит, не правдали [AppDelegate итп]) которому и должен будет удовлетворять любой кто захочет быть делегатьм Проигрывателя.
код:
weak var delegate: PlayerDelegate?,
...
private func onReachingEnd() {
delegate?.didEndPlaying()
}
А вот почему делегат должен быть weak и опшионал, это я оставляю узнать самому.
Средний
