Това добър (подобен на какао, одобрен от 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];

Вмъквате нула или повече обекти в един индекс. Създайте своя набор от индекси с диапазон: местоположение = 0, дължина = броят на масива 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 (където стилистично съм против наличието на 2 различни точки за връщане, но това е само аз), но нищо не пречи на init на super да връща обект, различен от себе си или нула, напр. различен обект от неговия клас или дори съвсем друг обект. Поради тази причина 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;
}

това е всичко, което намерих; с изключение на запазването на броя копия (което ЩЕ доведе до грешки по-късно) предимно само неща, които предпочитам, можете да го направите по вашия начин, ако ви харесва повече. Добра работа