Какая разница между @interface или @implementation, находясь в .h или .c

Question

Я играл с некоторый код в примере проекта Kobold2D (мультиплексирование с ортогональным плитки на основе игры), и я заметил:

@interface TileMapLayer : CCLayer //Map 
{ 
    float tileMapHeightInPixels; //depricated@interface TileMapLayer() 
} 
@end 

в файле TileMapLayer.h, а также:

@interface TileMapLayer() 
@property (strong) HUDLayer *hud; 
@property (strong) CCTMXTiledMap *tileMap; 
@property (strong) CCTMXLayer *background; 
@property (strong) CCTMXLayer *foreground; 
@property (strong) CCTMXLayer *meta; 
@property (strong) CCTMXLayer *base; 
@property (strong) CCSprite *player; 
@property (strong) CCSprite *playerTurret; 
@property (assign) int money; 
@end 

в файле TileMapLay.m.

Я всегда думал, что .h файлов содержат интерфейсы и .m файлов реализации магазина

Может кто-то пожалуйста, объясните их назначение (начали с основ, я все еще учусь Objective C) и то, что разница в цели между 2 примера выше?

Answer 1

Первое, что .m - это файлы Objective-C (которые могут иметь как Objective-C и C), так и .c - это простые файлы C, которые могут содержать только код C. Оба используют расширение .h для заголовка.

Что касается Objective-C, файл .m делает @interface TileMapLayer() объявить расширение класса . Расширение класса может добавлять ivars и свойства к классу, который уже был объявлен в файле .h. Расширение доступно только в пределах собственного файла .m. Не имеет смысла объявлять расширение внутри файла .h, но я думаю, вы могли бы, если бы захотели.

Что касается цели, рекомендуемая практика объявляет минимальное количество свойств, необходимых в .h, чтобы поддерживать чистоту и чистоту интерфейса. Для свойств, которые необходимы только внутри класса, вы можете объявить их в расширении в файле .m. Мое личное предпочтение заключается в том, чтобы избежать явного объявления и использования ivars вообще (если только я не переопределяю свойство setter или getter), потому что таким образом в реализации я могу с первого взгляда сказать, какие переменные являются локальными для свойств функции или объекта. Накладные расходы, как правило, незначительны, и я предпочитаю кодировать для удобочитаемости, чем преждевременно оптимизировать. Благодаря недавно введенным автосинтезируемым свойствам это также сохраняет много шаблонов.

Стратегия, которую я также рекомендую, тщательно думает, какие свойства должны быть модифицируемы извне объекта или нет. Объявите немодифицируемые свойства как readonly в файлах .h. Затем вы можете повторно объявить их как readwrite в .mрасширение для операций с самого объекта. Это гарантирует, что вы или ваши коллеги не совершите ошибку и не измените свойство readonly, которое не должно меняться извне объекта. В некотором смысле это помогает вам поддерживать логику объекта внутри него.Я попытался бы избежать ловушки объявления всего readwrite (по умолчанию), потому что тогда обычно приходит, чтобы укусить вас позже.

Answer 2

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

Answer 3

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