Примеры реального мира @optional методов протокола
Большой вопрос. Я отошлю Вас к Josh Bloch в Эффективном Java, который пишет (объект 16), почему предпочесть использование интерфейсов по абстрактным классам. Между прочим, если у Вас нет этой книги, я настоятельно рекомендую его! Вот сводка того, что он говорит:
- Существующие классы могут быть легко модифицированы для реализации нового интерфейса. Все, что необходимо сделать, реализовать интерфейс и добавить требуемые методы. Существующие классы не могут быть модифицированы легко для расширения нового абстрактного класса.
- Интерфейсы идеальны для определения соединения-ins. соединение А - в интерфейсе позволяет классам объявлять дополнительное, дополнительное поведение (например, Сопоставимый). Это позволяет дополнительной функциональности быть смешанной в с основной функциональностью. Абстрактные классы не могут определить соединение-ins - класс не может расширить больше чем одного родителя.
- Интерфейсы допускают неиерархические платформы. , Если у Вас есть класс, который имеет функциональность многих интерфейсов, она может реализовать их всех. Без интерфейсов необходимо было бы создать чрезмерно увеличенную в размерах иерархию классов с классом для каждой комбинации атрибутов, приводящих к комбинаторному взрыву.
- Интерфейсы включают безопасные улучшения функциональности. можно создать классы обертки с помощью Шаблона "декоратор", устойчивого и гибкого дизайна. Класс обертки реализует и содержит тот же интерфейс, передавая некоторую функциональность существующим методам, при добавлении специализированного поведения к другим методам. Вы не можете сделать этого с абстрактными методами - необходимо использовать наследование вместо этого, которое более хрупко.
Что относительно преимущества абстрактных классов, обеспечивающих базовое внедрение? Можно предоставить абстрактному скелетному классу реализации каждый интерфейс. Это комбинирует достоинства и интерфейсов и абстрактных классов. Скелетные реализации оказывают помощь реализации, не налагая серьезные ограничения, которые вызывают абстрактные классы, когда они служат определениями типа. Например, эти Платформа Наборов определяет интерфейсы использования типа и предоставляет скелетную реализацию каждому.
1 ответ
Приведу вам пример. У меня есть несколько классов ObjC, которые взаимодействуют с Flickr API. Один, называемый FKAccount , может выполнять множество действий, связанных с учетной записью пользователя Flickr, включая загрузку фотографий пользователя, получение их списка контактов и т. Д.
Класс FKAccount определяет делегата протокол FKAccountDelegate . Этот протокол определяет ряд методов обратного вызова, которые FKAccount будет вызывать для своего делегата в зависимости от успеха или неудачи различных сетевых операций с Flickr. Не каждое приложение, использующее FKAccount , будет интересоваться каждой операцией Flickr, которую может выполнить FKAccount .
Если бы требовалось, чтобы каждый класс, претендующий на реализацию протокола FKAccountDelegate , реализовывал каждый метод, вы бы получили множество методов-заглушек (FWIW, существует 41 метод, определенный в FKAccountDelegate ). Когда эти методы объявлены в протоколе @optional , делегату нужно реализовать только те обратные вызовы, которые он хочет получить.
Класс FKAccount проверяет, отвечает ли его делегат на ] @optional методы в протоколе:
if([self.delegate respondsToSelector: @selector(accountDidDownloadContacts:)]) {
[self.delegate accountDidDownloadContacts: self];
}