Стиль интерфейса какао

Это то, что в Objective-C называется «категориями». Категории позволяют иметь несколько блоков @interface и @implementation для одного и того же класса. Это работает даже в той степени, в которой вы можете добавлять методы в классы в стандартных фреймворках Apple, например. добавление категории в NSString для добавления в нее новых методов. Категории могут добавлять методы, но не переменные экземпляра, поэтому в вашем примере первый @interface - это объявление основного класса, а все остальные - категории в классе AViewController.

Это ни в коем случае не «старая шляпа», но ваш пример доводит использование категорий до довольно причудливой крайности. Категории имеют смысл везде, где есть логический смысл разбить реализацию класса на несколько блоков, например, если у класса есть набор методов, которые логически распадаются на две или более группы. Они также иногда используются для объявления псевдоприватных методов, помещая категорию @interface с именем "private" в тот же файл, что и @implementation. Динамическая отправка ObjC означает, что не существует такой вещи, как частный метод, но этот подход позволяет избежать публикации имен методов, которые вы бы предпочли, чтобы люди не использовали.

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

Я не знаю; Для меня это очень похоже на неформальные протоколы, в основном для делегатов. См. Страницы 297 - 298 в Программирование какао в Mac OS X, 3-е издание. Протоколы реализованы с помощью категорий ... И, честно говоря, в вашем образце они явно чрезмерно используются.

Этот пример очень странный и определенно поднимет красный флаг для любого опытного программиста Cocoa.

Обычной практикой является использование категорий таким же образом, чтобы отделить частные методы от общедоступной реализации, и я делал то же самое в прошлом, чтобы отделить частные многопоточные методы от кода, который выполняется в основном потоке. Я не вижу ничего хорошего в том, чтобы отделять все ваши общедоступные методы таким образом.

В этой ситуации можно использовать ключевое слово #pragma mark <label>. что позволяет группировать похожие методы в реализации. Я думаю, это то, к чему вы стремитесь, хотя вам не нужно переусердствовать в создании групп. Например, в классе оконного контроллера у меня будет #pragma mark API, #pragma mark NSWindowController Overrides, #pragma mark NSObject Overrides, #pragma mark NSWindow Delegate Methods и так далее. Это помогает мне очень быстро найти метод, который я ищу, в Xcode и перейти к нему, хотя это всего лишь вопрос стиля, так что вы действительно можете использовать его, как сочтете нужным.

Что касается ответа Джона Руди. Это правда, что неформальные протоколы реализованы как категории, но обычно они категории в NSObject. Поскольку неформальный протокол может использоваться практически любым объектом, это должна быть категория класса, от которого наследуется принимающий объект, и почти все будет унаследовано от NSObject. Вы могли бы привести доводы в пользу неформального протокола как категории для какого-то другого класса в определенных ситуациях, но это необычный подход и определенно не «путь какао».

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

@interface NSButton : NSControl <NSUserInterfaceValidations>

- (NSString *)title;
- (void)setTitle:(NSString *)aString;
...
...
@end

@interface NSButton(NSKeyboardUI)
- (void)setTitleWithMnemonic:(NSString *)stringWithAmpersand;
@end

@interface NSButton(NSButtonAttributedStringMethods)
- (NSAttributedString *)attributedTitle;
- (void)setAttributedTitle:(NSAttributedString *)aString;
- (NSAttributedString *)attributedAlternateTitle;
- (void)setAttributedAlternateTitle:(NSAttributedString *)obj;
@end

@interface NSButton(NSButtonBezelStyles)
- (void) setBezelStyle:(NSBezelStyle)bezelStyle;
- (NSBezelStyle)bezelStyle;
@end

@interface NSButton(NSButtonMixedState)
- (void)setAllowsMixedState:(BOOL)flag;
- (BOOL)allowsMixedState;
- (void)setNextState;
@end

@interface NSButton(NSButtonBorder)
- (void) setShowsBorderOnlyWhileMouseInside:(BOOL)show;
- (BOOL) showsBorderOnlyWhileMouseInside;
@end

@interface NSButton (NSButtonSoundExtensions)
- (void)setSound:(NSSound *)aSound;
- (NSSound *)sound;
@end

Итак, если они используют категории для организации NSButton в разделы: (NSButtonMixedState) (NSButtonBorder) выше, у которых действительно есть только пара операций, почему это используется для организации средств доступа / мутаторов в плохом стиле? Конечно, моим первым примером был глупый педантичный интерфейс, но цель разделения операций на группы остается прежней.

Во-первых, то, что что-то появляется в одном из файлов заголовков Apple, не обязательно означает, что вы должны воспринимать это как пример хорошего способа что-то делать. Разработчики Apple тоже люди и подвержены тем же ограничениям навыков и нехватки времени, что и все остальные.

Использование нескольких категорий таким образом предполагает, что реализация NSButton разделена на несколько исходных файлов. Это может быть связано с тем, что разные аспекты NSButton были закодированы разными людьми, или в разное время, или, возможно, по какой-то другой причине. Независимо от этого, разделение, вероятно, частично основано на том, как организована команда разработчиков и ее процессы, а система категорий обеспечивает способ разделения работы. В идеальной установке вы бы разбили вещи по логическим функциональным границам, но на практике в игру могут вступить и другие факторы.

Одна действительно веская причина для наличия общедоступной категории, которую Apple часто использует, - это расширение класса функциональностью, которая существует в структуре категории, но не существует в структуре, которая определяет класс. Например, NSString определен в Foundation.framework, но категории в NSString, определяющие методы рисования NSString на экране, определены в AppKit.framework.

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

Как отмечает Том, действительно большая реализация с несколькими исходными файлами (но с одним заголовком) также является хорошим кандидатом :)

Я просто хотел бы добавить к исходному ответу Тома: как правило, при объявлении частных методов лучше использовать расширение класса, чем категорию класса. Таким образом, вы можете реализовать расширение в том же блоке @implementation, что и общедоступные методы, без предупреждения об «отсутствующей реализации категории». Пример:

// .h file

@interface Foo : NSObject
-(void)publicMethod;
@end

// .m file

@interface Foo () 
// Notice the empty paren; this is how you define
// a class extension, which is not the same as a category
-(void)somePrivateMethod;
@end

@implementation Foo
#pragma mark Public methods
-(void)publicMethod;
{ ... }

#pragma mark Private methods
-(void)privateMethod;
{ ... }
@end