Когда я определяю объективные-c методы?

Для методов Objective-C общей практикой является размещение методов, которые вы хотите предоставить, в разделе @interface файла заголовка, чтобы другой код мог включать только расширение. h и знаете, как взаимодействовать с вашим кодом. «Ленивое объявление» на основе порядка работает так же, как функции в C - вам не нужно объявлять прототип метода, если только у вас нет зависимости, которую нельзя разрешить путем упорядочивания, но вы можете добавить прототипы методов внутри @implementation , если необходимо.

Так что да, вы на правильном пути. Не повторяйте прототип метода для унаследованных методов - компилятор находит его в родительском заголовочном файле. Методы делегата могут быть определены как прототипы в категории (прикреплены к классу) и реализованы по желанию, но делегату не нужно предоставлять прототип метода, поскольку он уже определен. (Он все еще может, если хочет для ясности и т. Д.)

Поскольку вы только изучаете Objective-C, остальная часть этого ответа содержит гораздо больше деталей, чем вы просили. Вы были предупреждены. ; -)

Когда вы статически вводите переменную (например, MyClass * вместо id ), компилятор предупредит вас, когда вы попытаетесь вызвать метод, что класс не рекламировать, что он реализует, независимо от того, делает это или нет. Если вы вводите переменную динамически, компилятор не помешает вам вызывать все, что угодно, и вы получите ошибки времени выполнения, только если вызовете то, чего не существует. Что касается языка, вы можете вызвать любой метод, который реализует класс, без ошибок во время выполнения - нет способа ограничить круг лиц, которые могут вызывать метод.

Лично я думаю, что это действительно хорошо. Мы настолько привыкли к инкапсуляции и защите нашего кода от другого кода, что иногда относимся к вызывающему как к коварному злоумышленнику, а не как к надежному коллеге или заказчику. Я считаю, что довольно приятно писать код с мышлением «ты делаешь свою работу, а я - мою», когда каждый уважает границы и заботится о своем. Вы можете сказать, что «установка» Objective-C основана на доверии сообщества, а не на строгом принуждении. Например, я рад помочь любому, кто подходит к моему столу, но я бы сильно разозлился, если бы кто-то испортил мои вещи или передвинул их, не спросив. Хорошо продуманный код не не обязательно быть параноиком или социопатом, они просто должны хорошо работать вместе. : -)

Тем не менее, существует множество подходов к структурированию ваших интерфейсов, в зависимости от уровня детализации, который вам нужен / необходим при предоставлении интерфейсов пользователям. Любые методы, которые вы объявляете в общедоступном заголовке, по сути, являются честной игрой для всех. Скрытие деклараций методов немного похоже на запирание вашей машины или дома - это, вероятно, не отпугнет всех, но (1) оно «сохраняет честность честных людей», не соблазняя их чем-то, с чем им не следует связываться, и (2 ) любой, кто делает , наверняка знает, что он не должен этого делать, и не может жаловаться на негативные последствия.

Ниже приведены некоторые соглашения, которые я использую для именования файлов, и то, что входит в каждое из них. файл - начиная с файла .m внизу, каждый файл включает файл над ним. (Использование строгой цепочки включений предотвратит такие вещи, как предупреждения о повторяющихся символах.) Некоторые из этих уровней применимы только к более крупным повторно используемым компонентам, таким как инфраструктуры Какао. Адаптируйте их в соответствии с вашими потребностями и используйте те имена, которые вам подходят.

• MyClass.h - Открытый API (интерфейс прикладного программирования)
• MyClass_Private.h - Внутренний SPI компании (интерфейс системного программирования)
• MyClass_Internal.h - Внутренний IPI проекта (внутренний интерфейс программирования)
• MyClass.m - Реализация, как правило, всех объявлений API / SPI / IPI
• MyClass_Foo.m - Дополнительная реализация, например, для категорий

API, предназначена для использования всеми и поддерживается публично (обычно в Foo.framework / Headers ). SPI предоставляет дополнительные функции для внутренних клиентов вашего кода, но с пониманием того, что поддержка может быть ограничена, а интерфейс может быть изменен (обычно в Foo.framework / PrivateHeaders ). IPI состоит из деталей, специфичных для реализации, которые никогда не должны использоваться вне самого проекта, и эти заголовки вообще не включаются в структуру. Любой, кто решает использовать вызовы SPI и IPI, делает это на свой страх и риск и обычно в ущерб себе, когда изменения нарушают их код. : -)