• Alliberar el nom objecte assignat.
• Retornar l'objecte Compte prèviament inicialitzat amb aquest identificador únic.

Per fer això, l'inicialitzador assegura que els identificadors siguin únics mentre es pugui demanar una instància de Compte a partir d'un identificador.

Alguns cops els mètode init... no pot executar la inicialització requerida. Per exemple, un mètode initDesDunFitxer: expera inicialitzar un objecte a partir del contingut d'un fitxer, la situació del qual es passa en un argument. Però si el fitxer no existeix en aquest lloc l'objecte no pot inicialitzar-se. Un problema semblant podria succeir si un inicialitzador initAmbArray: es passa un objecte NSDictionary en comptes d'un objecte NSArray. Quan un mètode init... no pot inicialitzar un objecte, aquest ha de fer:

• Alliberar el nou objecte assignat.
• Retornar nil.

Retornant nil des d'un inicialitzador indica que l'objecte requerit no s'ha pogut crear. Quan crees un objecte, tu normalment has de comprovar si el valor retornat és nil abans de continuar:

id unObjecte = [[LaMevaClasse alloc] init];
if (unObjecte) {
    [unObjecte ferQuelco];
    // més missatges...
} else {
    // capturar l'error
}

Donat que un mètode init... pot retornar nil o un altre objecte que un ha assignat explícitament, és perillós utilitzar la instància retornada per un alloc o un allocWithZone: en comptes del retornat per l'inicialitzador. Considereu el següent codi:

id elMeuObjecte = [LaMevaClasse alloc];
[elMeuObjecte init];
[elMeuObjecte ferQuelcom];

El mètode init en aquest exemple pot haver retornat un nil o pot haver-se substituït per un objecte diferent. Com que pots enviar un missatges a un nil sense produir una excepció, no passaria res en aquest cas, excepte (potser) un maldecap en la comprovació d'errors. Sempre hauries de confiar amb la instància inicialitzada més que en la "només assignada". És recomanat que jerarquitzis els missatges d'assignació i d'inicialització i comprovar que el valor retornar per l'inicialitzador abans de continuar.

id elMeuObjecte = [[LaMevaClasse alloc] init];
if ( elMeuObjecte ) {
    lMeuObjecte ferQuelcom];
} else {
    // recuperació de l'error 
}

Implementant un Inicialitzador

Hi ha diversos passos crítics a seguir quan implementem un mètode init... que serveix com un únic inicialitzador de classe o, si hi ha múltiples inicialitzadors el seu inicialitzador designat (descrit en "Multiples Inicializadors i l'Inicialitzador Designat"):

• Sempre s'invoca primer a l'inicialitzador de la super-classe (super).
• Comprovar l'objecte retornat per la super-classe. Si és un nil, l'inicialitzador no pot continuar; retornant nil al receptor.
• Quan s'inicialitzen variables d'instància que referencien a objectes, és necessari retenir o copiar l'objecte.
• Després d'activar les variables d'instància a valors inicials vàlids, es retorna self excepte:
  • Era necessari retornar un objecte substituït, en aquest cas primer alliberar l'objecte acabat d'assignar.
  • Es preveu que l'inicialització tindrà un problema i no s'aconseguirà, en aquest cas es retorna nil.

El mètode init... en "Un exemple d'un inicialitzador" il·lustra aquests passos:

Llistat 1: Un exemple d'un inicialitzador

- (id)initAmbCompteID:(NSString *)identificador {
    if ( self = [super init] ) {
        Compte *compte = [diccionariDeComptes objectForKey: identificador];
        if (compte) { // objecte amb que l'ID realment existeix
            [self release];
            return [compte retain];
        } 
        if (identificador) {
            compteID = [identificador copy];
            return self;
        } else {
            [self release];
            return nil;
        }
    } else
        return nil;
}

No és necessari inicialitzar totes les variables d'instància d'un objecte explícitament, només aquells que són necessari per fer funcional l'objecte. La inicialització posada-a-zero per defecte executada en una variables d'instància durant l'assignació sovint és suficient. És necessari assegurar-se que es reté o es copien les variables d'instància.

El requeriment d'invocar l'inicialitzador de la super-classe en primera instància és important. Remarcar que un objecte encapsula no només les variables d'instància definides per la seva superclasse sinó les variables d'instància definides per totes les seves classes antecessores. Per invocar l'inicialitzador de super primer assegura't que les variables d'instància definides per classes superior s'han inicialitzat primer. La super-classe immediata, en el seu inicialitzador, invoca l'inicialitzador de la seva super-classe, la qual invoca la seu mètode init... principal de la seva super-classe, etc. (mireu "L'inicialització per sobre la cadena de l'herència"). L'ordre adequat d'inicialització és crítica perquè les següents inicialitzacions de les subclasses poden dependre de variables d'instància d'una super-classe definida essent inicialitzats per valors raonables.

Figura 1: L'inicialització per sobre la cadena de l'herència

Els inicialitzadors heretats són una preocupació quan crees una sub-classe. Alguns cops un mètode init... de super-classe inicialitza correctament les instàncies de la teva classe. Però és més probable que no ho faci. Si no saps, la implementació que s'invocarà de la super-classe, i com que la super-classe no coneix res de la teva classe, les teves instàncies poden no estar correctament inicialitzades.

Múltiples Inicialitzadors i l'Inicialitzador Designat

Una classe pot definir més d'un inicialitzador. De vegades multiples inicialitzadors permeten als clients de la classe proporcionar una entrada de la mateixa informació de diferents formes. La classe NSSet, per exemple, oferir als clients varis inicialitzadors que accepten les mateixes dades en diferents formes, un agafa un objecte NSArray, un altre una llista contada d'elements i un altre una llista d'elements acabats amb nil:

- (id)initWithArray:(NSArray *)array;
- (id)initWithObjects:(id *)objects count:(unsigned)count;
- (id)initWithObjects:(id)firstObj, ...;

Algunes sub-classes proporcionen inicialitzadors a conveniència que proporcionen valors per defecte a un inicialitzador que agafa un complement complet dels paràmetres d'inicialització. Aquest inicialitzador normalment l'inicialitzador designat, l'inicialitzador més important d'una classe. Per exemple, assumeix que hi ha una classe Tasca i que declara un inicialitzador designat amb aquesta signatura:

- (id)initAmbTitol:(NSString *) unTitol data:(NSDate *) unaData;

La classe Tasca pot incloure un inicialitzador secundari, o de conveniència, que simplement invoca l'inicialitzador designat, passant-li els valors per defecte d'aquests paràmetres.

Llistat 2: Inicialitzadors Secundaris

- (id)initAmbTitol:(NSString *) unTitol {
    return [self initAmbTitol: titol data:[NSDate data]];
}

- (id)init {
    return [self initAmbTitol:@�Tasca�];
}

L'inicialitzador designat juga un rol important per una classe. Assegura que les variables d'instància heretades són inicialitzades invocant els inicialitzadors designats de super. És normalment el mètode init... que té el major nombre d'arguments i que realitza la major part del treball d'inicialització, i és l'inicialitzador que l'inicialitzador secundari de la classe invoca amb missatges a self.

Quan defineixes una sub-classe has de poder identificar l'inicialitzador designat de la super-classe i invocar-lo en l'identificador designat de la teva sub-classe a través d'un missatge a super. També has d'assegurar que les inicialitzadors heredats es comportaran de la mateixa forma. Quan es dissenyen els inicialitzadors de la teva classe, recordeu que els inicialitzadors designats estan encadenats entre ells a través dels missatges a super mentre els altres inicialitzadors estan encadenats per l'inicialitzador designa de la seva classe a través dels missatges a selg.

Un exemple ho aclarirà. Diguem que hi ha tres classes, A, B i C; la classe B hereta de A, i la classe C hereta de B. Cada sub-classe afegeix un atribut com una variable d'instància i implementa un mètode init... -- l'inicialitzador designat -- per inicialitzar aquesta variable d'instància. També defineixen inicialitzadors secundaris i s'assegura que els inicialitzadors heretats estaran sobre-escrits, si cal. A "Interaccions d'inicialitzadors secundaris i designats" s'il·lustren els inicialitzadors de totes tres classes i les seves relacions.

Figura 2: Interaccions d'inicialitzadors secundaris i designats

L'inicialitzador designat per cada classe és l'inicialitzador amb la màxima cobertura; és el mètode que inicialitza l'atribut afegit per la sub-classe. L'inicialitzador designat també és el mètode init... que invoca l'inicialitzador designat de la super-classe en un missatge a super. En l'exemple, l'inicialitzador designat de la classe C, initAmbTitol:data:, invoca l'inicialitzador designat de la seva super-classe, initAmbTitol:, el qual a l'hora invoca el mètode init de la classe A. Quan es crea una sub-classe, sempre és important conèixer l'inicialitzador designat de la super-classe.

Mentre els inicialitzadors designats són aquells que connecten cap amunt en la cadena d'herència a través de missatges a super, els inicialitzadors secundaris estan connectats als inicialitzadors designats de les seves classes a través de missatges a selg. Els inicialitzadors secundaris (com en aquest exemple) són freqüentment sobre-escrits en versions d'inicialitzadors heretats. La classe C sobre-escriu initAmbTitol: per invocar al seu inicialitzador designat de la classe B, el qual és el mètode sobre-escrit initAmbTitol:. Si envies un missatge initAmbTitol: a objectes de la classe B i C, estaràs invocant diferents implementacions de mètodes. Per una altra banda, si la calsse C no ha sobre-escrit l'initAmbTitol: i envies el missatge a una instància de la classe C, serà invocada la implementació de la classe B. Conseqüentment, la instància C no serà completament inicialitzada. Quan es crea una sub-classe, és important per assegurar-se que tots els inicialitzadors heretats estan correctament cobert.

Alguns cops l'inicialitzador designat d'una super-classe pot ser suficient per la sub-classe, i així no hi ha necessitat per la sub-classe per implementar els seus propis inicialitzadors designats. Altres cops, un inicialitzador designat de classe pot ser una versió sobre-escrita de l'inicialitzador designat de la super-classe. Això és freqüentment els cas quan la sub-classe necessita suplementar la feina realitzada per l'inicialitzador designat de la super-classe, encara que la sub-classe no afegeix cap variable d'instància pròpia (o les variables d'instància afegides no necessiten inicialització explícita).

El Mètode dealloc

En molts aspectes, el mètode dealloc és la part contrària del mètode init... de la classe, especialment del seu inicialitzador designat. En comptes d'invocar-se just després de l'assignació de l'objecte, el dealloc s'invoca just abans de la destrucció de l'objecte. En compte d'assegurar-se que les variables d'instància d'un objecte són correctament inicialitzades, el mètode dealloc s'assegura que les variables d'instància d'objecte estan alliberades i que qualsevol memòria dinàmicament assignada s'ha alliberat.

L'últim punt de paral·lelisme té a veure amb la invocació de la implementació de la super-classe del mateix mètode. En un inicialitzador, invoques l'inicialitzador designat de la super-classe en primera instància. En el dealloc, invoques la implementació del dealloc de la super-classe en última instància. La raó d'això, és l'oposició amb els inicialitzadors; les sub-classes han d'alliberar les pròpies variables d'instància abans que les variables d'instància de les classes antecessores siguin alliberades.

A "Un exemple del mètode dealloc" mostra com s'ha d'implementar aquest mètode.

Llistat 3: Un exemple del mètode dealloc

- (void)dealloc {
    [diccionariCompte release];
    if ( mallocdChunk != NULL )
        free(mallocdChunk);
    [super dealloc];
}

Fixeu-vos que, com es mostra en aquest exemple, és prudent comprovar si les variables d'instancia d'un malloc és no-NULL abans d'intentar alliberar-lo. Ja que pots enviar un missatge a un objecte nil, aquesta precaució no es necessària amb les variables d'instància d'objecte.

Mètodes de Factoria de Classes

Els mètodes de la factoria de classes són implementats per una classe per conveniència dels clients. Ells combinen assignament i inicialització en un pas i retornen l'objecte creat autoalliberat. Aquests mètodes són de la forma +(tipus) nomClasse... (on nomClasse exclou qualsevol prefix).

Cocoa proporciona un munt d'exemple, especialment sobre classe de valor. L'NSDate inclou els següents mètodes de factoria de classes:

+ (id)dateWithTimeIntervalSinceNow:(NSTimeInterval)secs;
+ (id)dateWithTimeIntervalSinceReferenceDate:(NSTimeInterval)secs;
+ (id)dateWithTimeIntervalSince1970:(NSTimeInterval)secs;

I l'NSData ofereix els següents:

+ (id)dataWithBytes:(const void *)bytes length:(unsigned)length;
+ (id)dataWithBytesNoCopy:(void *)bytes length:(unsigned)length;
+ (id)dataWithBytesNoCopy:(void *)bytes length:(unsigned)length
        freeWhenDone:(BOOL)b;
+ (id)dataWithContentsOfFile:(NSString *)path;
+ (id)dataWithContentsOfURL:(NSURL *)url;
+ (id)dataWithContentsOfMappedFile:(NSString *)path;

Els mètodes de factoria poden ser quelcom més que una simple conveniència. No només poden combinar assignament i inicialització, sinó que l'assignament pot informar l'inicialització. Com a exemple, diguem que hem d'inicialitzar una col·lecció d'objectes des d'un fitxer de llista de propietats que codifica qualsevol nombre d'elements de la col·lecció (objectes NSString, NSData, NSNumber, etc). Abans que el mètode de factoria pugui saber quanta memòria s'ha d'assignar per la col·lecció, aquest ha de llegir l'arxiu i analitzi la llista de propietats per determinar quants elements hi ha de cada tipus.

Un altre propòsit per un mètode de factoria de classe és assegurar que una certa classe (NSWorkspace, per exemple) ofereix una instància única. Encara que el mètode init... ha de verificar que només existeixi una única instància a l'hora en un programa, aquest requereix l'assignació prèvia d'una instància "crua" i llavors s'hauria d'alliberar aquesta instància. Un mètode de factoria, per altra banda, et dona una via per evitar assignament de memòria oculta per un objecte que no podries utiltizar (mireu "Un mètode de factoria per una instància única").

Llistat 4: Un mètode de factoria per una instància única

static GestorComptes *GestorPerDefecte = nil;

+ gestorPerDefecte {
    if (! GestorPerDefecte) GestorPerDefecte = [[self allocWithZone:NULL] init];
    return GestorPerDefecte;
}