Использование протоколов Objective C

У меня есть вопрос о домашнем задании, который меня смутил, действительно плохо. Ниже приводится краткое объяснение вопроса.

Представьте, что вы разрабатываете приложение, в котором хранятся контакты Информация. Адресная книга может содержать множество типов объектов, например. Человек будь то компания или что-либо еще, имеющее контактную информацию.

Теперь вместо явной проверки каждого типа объекта напишите протокол, который объявляет, как объект должен вести себя и успешно появятся в вашей адресной книге.

Мое понимание и усилия для ответа на этот вопрос:

Создайте протокол, который имеет общие методы для каждого типа контактной информации в теге @required. И все другие методы, которые не похожи друг на друга (например, номер факса имеет связь с компанией, но не человек...) под @optional. Во время выполнения вы можете проверить, реагирует ли объект на какой-либо данный метод, используя selector. Сомнение: Однако это снова явно указывает тип объекта косвенно, я прав?
Моя вторая мысль - использовать что-то вроде abstract class в java. Что означает, что унаследованный класс из абстрактного класса реализует свои собственные абстрактные методы. Как никогда, как наивный разработчик iOS, я не знаю, как это реализовать? и я не уверен, что это решит мою проблему. Я хотел бы получить просветление, если кто-то это знает.

Внешнее чтение сделано до сих пор. Пожалуйста, дайте мне знать, если ответ, который я ищу, находится в одной из этих ссылок. Я буду читать это снова, чтобы понять и решить эту проблему:). спасибо.

Ответ 1

Протокол - это то же самое, что и интерфейс Java. Он просто определяет, какие методы должен поддерживать класс. Вот страница, которая объясняет это четко: http://www.otierney.net/objective-c.html#protocols

По сути, если вы хотите убедиться, что класс будет иметь метод phoneNumber (accessor к свойству phoneNumber), вы сделаете что-то вроде этого:

@protocol ContactProtocol
-(void) phoneNumber;
@end

@interface Person: NSObject <ContactProtocol> {
    ...
}

@interface Company: NSObject <ContactProtocol> {
    ...
}

И затем во время компиляции (или для xcode 4) он скажет вам, если вы забыли добавить метод phoneNumber в классы Person или Company.

Ответ 2

Однако это снова явно указывает тип объекта косвенно, я прав?

Нет, проверка поведения отличается от типа проверки. Вы можете отправить -respondsToSelector: на любой объект, и если результатом будет ДА, вы можете отправить сообщение независимо от типа объекта. Вы также можете потребовать, чтобы объект реализовал данный протокол, снова не заботясь о его фактическом типе:

id<SomeProtocol> foo;  // foo points to any type that implements SomeProtocol

Моя вторая мысль - использовать что-то вроде абстрактного класса в java.

Это может сработать, но, по-видимому, это не то, о чем просили ваше задание, верно? В нем говорится: "... написать протокол..."

Objective-C не предоставляет способ явно сделать абстрактную абстракцию, как это делает Java. Вы просто создаете класс, и если вы не хотите, чтобы он был создан напрямую, вы документируете это где-то.

Ответ 3

У вас есть... варианты.

Необязательные методы удобны для человека, который записывает класс в соответствие с протоколом, раздражая человека, использующего протокол. Так что это зависит от того, кого вы пытаетесь угодить.

Необязательные методы не так плохи, как тип проверки. Представьте, как будет выглядеть код при доступе к контаблируемому объекту объекта. Когда вы используете необязательный метод, у вас должен быть случай if и else. Это не так удобно, как просто идти вперед и предполагать, что вы можете вызвать метод. Но это более удобно, чем проверка типа. Это будет один случай для каждого типа объекта (и случай else, который может быть утверждением). Кроме того, если вы используете необязательные методы, информация об объекте инкапсулируется в свой класс. Если вы проверяете тип перед вызовом метода, то информация о том, какой тип контактной информации предоставляется сущностью, находится вне класса в вызывающем коде. Если вы обновите объект для предоставления дополнительного типа контакта, это улучшение не будет доступно, пока вы не обновите код вызова.

Вариант B состоит в том, чтобы сделать все необходимые методы, но дать им возможность вернуть значение, указывающее, что никакой информации нет, например, nil. Конечно, это все равно означает случай, когда нужно проверить нулевой результат, он будет менее подробным. Еще лучшее решение этой проблемы - вернуть методы коллекциям нескольких контактов. В конце концов, у людей может быть более одного номера телефона. Затем, чтобы указать, что тип контакта неприменим, вы просто вернете пустую коллекцию.

Недостатком является то, что тот, кто пишет класс, который соответствует протоколу, должен добавить простой метод заглушки, который говорит return nil или что-то еще.