Это хороший (какао, одобренный Apple) класс моделей?

Пожалуйста, не упоминайте self = [super init]…

Итак, почему этого не?

То же самое и с initWithCoder:: вы должны использовать объект, возвращаемый [self init], не предполагая, что он инициализировал начальный объект.

- (void)dealloc
{
    [super dealloc];
    [tileTemplates release];
}

Как сказал Абизерн в своем комментарии, [super dealloc] должен идти последним. В противном случае вы обращаетесь к переменной экземпляра освобожденного объекта.

- (IRTileTemplate*)copyWithZone:(NSZone*)zone

Тип возврата здесь должен быть id, что соответствует типу возврата, объявленному протоколом NSCopying.

{
    IRTileset* copy = [IRTileset new];
    [copy insertTileTemplates:tileTemplates atIndexes:[NSIndexSet indexSetWithIndex:0]];
    [copy setUniqueID:uniqueID];

Вы вставляете ноль или более объектов в один индекс. Создайте свой набор индексов с диапазоном: location = 0, length = count массива tileTemplates. А еще лучше просто присвоить всему свойству значение:

copy.tileTemplates = self.tileTemplates;

Или получить доступ к переменным экземпляра напрямую:

copy->tileTemplates = [tileTemplates copy];

(Обратите внимание, что вы должны делать copy самостоятельно, обходя методы доступа к свойствам, и что вы copy обрабатываете массив от имени копии.)

    return [copy autorelease];
}

copyWithZone: не должен возвращать автоматически выпущенный объект. Согласно правилам управления памятью , вызывающий copy или copyWithZone: владеет копией, что означает, что задача вызывающего - освободить ее, а не copyWithZone:.

@synthesize tileTemplates;
[et al]

Вы также можете реализовать методы доступа к однообъектным массивам:

- (void) insertObjectInTileTemplates:(IRTileTemplate *)template atIndex:(NSUInteger)idx;
- (void) removeObjectFromTileTemplatesAtIndex:(NSUInteger)idx;

Это, конечно, необязательно.

// Однако следует ли мне перечислять здесь протоколы, даже если они уже перечислены в IRTileset.h?

Нет, не надо. Расширение класса, объявленное в файле реализации, является расширением, поэтому вам не нужно заботиться о том, каким протоколам должен следовать класс.

Я бы рекомендовал отмечать имена переменных вашего экземпляра знаком подчеркивания: _tileTemplates. (Пуристы посоветуют вам ставить подчеркивание вместо префикса; сделайте это, если вы их боитесь.)

Не используйте new для создания экземпляров классов. Насколько я понимаю, никогда не рекомендуется.

[NSMutableArray new];                     //  :(
[NSMutableArray arrayWithCapacity:20];    //  :)

Не звоните [super dealloc], пока не освободите свои ресурсы! При определенных обстоятельствах это может вызвать сбой.

- (void)dealloc
{
    [tileTemplates release];
    [super dealloc];          // Do this last
}

Я не уверен, какой у типа uniqueID, но разве он не должен быть выпущен в dealloc?

Я бы никогда не поместил свои директивы @synthesize в середину файла (поместите их сразу под «@ implementation»).

Кроме того, поскольку я не имею четкого представления о роли этого класса, countOfTileTemplates мне не нравится. Может быть, подойдет просто «count», если однозначно, что этот класс делает для хранения шаблонов тайлов?

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

Например, что, если какой-то внешний код вызывает это:

myIRTileset.tileTemplates=someArray;

Бум, вы потеряли все свои данные.

Вы должны определить оба свойства данных как только для чтения. Затем напишите средства доступа внутри класса, которые будут управлять их сохранением в реализации класса. Таким образом, единственный способ для внешнего объекта изменить tileTemplates - это вызвать методы - insertTileTemplates:atIndexes: и removeTileTemplatesAtIndexes:.

Edit01:

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

Интерфейс

@interface PrivateTest : NSObject {
@private 
    //iVar is invisible outside the class, even its subclasses
    NSString *privateString; 
@public
    //iVar is visible and settable to every object. 
    NSString *publicString; 
}
@property(nonatomic, retain)  NSString *publicString; //property accessors are visible, settable and getable. 
//These methods control logical operations on the private iVar.
- (void) setPrivateToPublic;  
- (NSString *) returnPrivateString;
@end

Таким образом, при использовании это будет выглядеть так:

Выполнение

#import "PrivateTest.h"

//private class extension category defines 
// the propert setters and getters 
// internal to the class
@interface PrivateTest ()
@property(nonatomic, retain)  NSString *privateString;
@end

@implementation PrivateTest
//normal synthesize directives
@synthesize privateString; 
@synthesize publicString;

// Methods that control access to private
- (void) setPrivateToPublic{
    //Here we do a contrived validation test 
    if (self.privateString != nil) {
        self.privateString=self.publicString;
    }
}

- (NSString *) returnPrivateString{
    return self.privateString;
}

@end

Вы бы использовали это так:

PrivateTest *pt=[[PrivateTest alloc] init];
    // If you try to set private directly as in the next line
    // the complier throws and error
//pt.privateString=@"Bob"; ==> "object cannot be set - either readonly property or no setter found"
pt.publicString=@"Steve";
[pt setPrivateToPublic];
NSLog(@"private=%@",[pt returnPrivateString]); //==> "Steve"

Теперь у класса есть пуленепробиваемая целостность данных. Любой объект в вашем приложении может установить и получить строковое свойство publicString, но ни один внешний объект не может установить или получить private.

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

две незначительные нюансы: один - это метод init (где стилистически я против двух разных точек возврата, но это только я), однако ничто не мешает super init возвращать объект, отличный от себя или nil, например, другой объект его класс или даже просто другой объект в целом. По этой причине self = [super init], как правило, является хорошей идеей, даже если на практике это вряд ли принесет много пользы. Во-вторых, в методе copyWithZone вы не копируете tileTemplates, что может быть преднамеренным, но, как правило, является плохой идеей (если только они не являются неизменяемыми). Предполагается, что копирование объекта имеет тот же эффект, что и выделение нового, например. сохранить счетчик 1, поэтому не отпускайте его автоматически. Кроме того, не похоже, что вы что-то делаете с зоной, поэтому вам, вероятно, следует заменить ее чем-то вроде

- (IRTileTemplate*)copyWithZone:(NSZone*)zone {
    IRTileset* copy = [[IRTileset allocWithZone:zone] init];
    [copy insertTileTemplates:[tileTemplates copyWithZone:zone]
                    atIndexes:[NSIndexSet indexSetWithIndex:0]];
    [copy setUniqueID:uniqueID];
    return copy;
}

вот и все, что я нашел; за исключением сохраняемого счетчика копий (что БУДЕТ приводить к ошибкам в дальнейшем), в основном это просто вещи, которые я предпочитаю, вы можете сделать это по-своему, если вам это больше нравится. Хорошая работа