Objective-C and iOS on demand

Uma das mais poderosas e recentes adições no Objective-C é a inclusão de um recurso conhecido como blocos. Veremos como isso funciona.

Essencialmente, um bloco permite que você defina uma função de um objeto em linha de código. Essas funções do objeto podem ser referenciadas usando variáveis tradicionais. Isso significa que podemos definir pedaços reutilizáveis de código que funcionam e que podem ser passados apenas como objetos que permitem que o código seja executado dentro de outros objetos, dinamicamente. Isso pode parecer confuso, mas ao vermos isso mais adiante, o conceito ficará mais claro.

Declarando Blocos 

Nesta sessão, veremos o que é um bloco em Objective-C. Abaixo, uma amostra de um bloco simples.

int main (int argc, const char * argv[ ])

{

    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

    void (^myBlock) (NSString) *x);

    myBlock = ^(NSString *x)

    {

     NSLog(@"%@", x);

    };

    [pool drain];

    return 0;

}

Um bloco, em sua essência, é uma variável como qualquer outra. O que faz blocos ser diferente é que os dados armazenados dentro do bloco são o corpo de uma função. Ao utilizar um bloco, podemos chamar a função, tal como uma outra função padrão, passando-lhe argumentos e recebendo um valor de retorno.

No caso deste código, a variável que contém o bloco é chamada de "myBlock". Primeiro, foi declarada a variável com a linha vazia (^myBlock) (NSString *). Variáveis normais, quando declaradas são relativamente simples. Essas, não precisam ter argumentos passados pra elas, nem retornam valores. Um bloco, por outro lado, é armazenado em uma variável, não possui argumentos e tipo de retorno declarados. Portanto, a sua declaração é um pouco mais complexa do que a de uma variável normal.

Uma declaração de bloco consiste em seu tipo de retorno (neste caso, void). O tipo de retorno do bloco é colocado no lugar onde normalmente esperamos ver a definição do tipo de variável que está sendo declarada. Em uma declaração de bloco, no entanto, estamos declarando o tipo de valor que será devolvido a partir do bloco quando ele é executado. 

Após a definição do tipo de retorno, há um operador essencial que é usado pra dizer ao compilador que estamos definindo um bloco, ao invés de outro tipo de variável. Este operador é o caractere ^.

Podemos pensar nisso como sendo mais fácil declarar um ponteiro. Assim como quando se declara uma variável ponteiro o caractere * é usado para indicar que a variável em questão é um ponteiro. No caso do bloco, usamos o caractere ^. Seguindo o caractere ^, o nome da variável que armazena o bloco (myBlock). Este nome vem entre parênteses para separa-los dos seus argumentos depois.

O nome da variável segue as mesmas convenções de nomes de variáveis do resto da linguagem, que deve conter apenas caracteres alfanuméricos e não podem começar com números.

Após o fechamento dos parênteses do bloco com o nome da variável, os argumentos que precisam ser passados para o bloco quando ele é usado, são separados por vírgulas e incluem um conjunto adicional de parênteses (aqui, este é (NSString *)). Ao listar estes argumentos, precisamos fornecer os nomes das variáveis. Se o fizer, é com você, mas não é necessário. Uma boa maneira de pensar sobre isso é que não estamos realmente declarando o corpo da função neste momento. Portanto, fornecer os nomes das variáveis para os argumentos não serve de nada, porque não será utilizado agora. Ao invés disso, temos simplesmente que dizer ao compilador quais os tipos de argumentos esperar. Basta fornecer os tipos de argumentos separados por vírgulas. 

Como sempre, ao terminar uma declaração, utiliza-se o ponto e vírgula. Neste ponto, declaramos uma variável, que pode armazenar um bloco que retorna o tipo de valor que especificamos, e leva os argumentos que também especificamos. Lembrando, o nome dessa variável é myBlock.

Declarar a variável apenas, como sabermos, não é o suficiente. Temos também que armazenar o bloco, a fim de usa-lo. Iniciar uma nova variável com um bloco é tranquilo, usando o operador de atribuição, em seguida, novamente, uma sintaxe especial indicando que estamos criando a variável que irá armazenar o bloco.

Para a definição do bloco, novamente se usa o caractere ^ para dizer ao compilador que o que se segue é a definição do bloco. Podemos omitir o tipo de retorno na definição, já que o compilador pode determinar o tipo de retorno, verificando a variável que está sendo armazenada no bloco. Devemos, no entanto, fornecer a especificação do argumento para o bloco, novamente, dentro de parênteses. Neste caso, devemos também fornecer o nome das variáveis para os argumentos que estão sendo passados. Isso faz sentido, porque estamos declarando o nome das variáveis para os argumentos que serão utilizado dentro do corpo do bloco.

Após o fechamento do parênteses da lista de argumentos, fornecemos em seguida o corpo do bloco. Este corpo de código assume uma forma que é quase idêntico a declaração de uma função. Devemos colocar o código do bloco entre chaves, para executar qualquer outra operação que escolhermos, utilizando os argumentos conforme necessário e retornar o valor apropriado após finalizar. Assim como na definição de uma função padrão, o código dentro de um bloco pode ser distribuído em várias linhas.

Em adição a interface funcional do garbage collector, que é apropriado para usar em código de baixo nível (o qual ainda não me atrevo :P) a Apple também fornece uma abstração de alto nível para se trabalhar com o garbage collector: é a classe NSGarbageCollector.

Essa classe é um singleton que nos permite interagir com o garbage collector através de uma interface Objective-C. Podemos acessar o garbage collector atual chamando o método defaultCollector. Depois de ter a instância do garbage collector, podemos usa-lo para ativar ou desativar a coleta de ponteiros específicos, ou mesmo para uma thread como um todo. Além disso, podemos forçar o uso de uma coleção usando os métodos collectExhaustively ou collectIfNeeded.

Metodos NSGarbageCollector comumente usados

+defaultCollector: Retorna o NSGarbageCollector para a thread atual.

-disable/-enable: Desabilita e habilita o garbage collector temporariamente.

-isEnable: Retorna YES se o garbage collector estiver habilitado, caso contrário, não.

-collectExhaustively: Dispara uma coleção exaustiva de objetos garbage collector.

-collectIfNeeded: Dispara uma coleção, mas o consumo de memória cresce além dos limites desde a última coleção.

-disableCollectionForPointer: Faz com que o ponteiro se torne um objeto raiz e portanto, inelegível para a coleção.

Outro padrão comum do Objective-C que pode causar dificuldade no garbage collection em aplicações que usam um um tipo de dado void * para transmitir dados específicos do aplicativo entre callbacks. A vantagem dessa abordagem é que os dados passados entre os métodos podem ser de qualquer tipo. Pode ser um objeto, ou apenas uma "bolha de bytes". O método de recebimento do parâmetro void * typecast para qualquer tipo de dado que ele espera receber.

O problema em um ambiente de garbage collection surge porque o ponteiro void é "opaco", e assim pode ser confundido com um objeto sem referência, e, portanto, um garbage collected (lixo coletado). Isso pode ocorrer entre o método de início e o método de retorno, de tal modo que o ponteiro recebido pelo método callback estará apontado para um objeto desalocado.

A solução para este problema é usar os métodos Core Foundation CFRetain e CFRelease para forçar uma referência forte para ser mantida na estrutura global Core Fundation. 

Retenção de ponteiros "opacos"para uso com uma chamada de retorno (callback)

@implementation Baz

-(void) callbackMethodForObject: (id)object withUserInfo:(void *) inData

{

    Bar *bar = (Bar *) inData;

    // faça algo com bar...

    CFRelease(bar);

}

-(void) startLongOperation

{

    Bar *bar = [[Bar alloc] init];

    CFRetain(bar);

    foo = [Foo alloc] init];

    [foo startLongOperationWithDelegate: self callBackMethod:      @selector(callbackMethodForObject:withUserInfo:)

                                             userinfor:bar];

}

@end

Essencialmente, antes de passar os dados do seu ponteiro para o objeto que vai chamar o seu método de retorno, chamamos manualmente um CFRetain, passando os dados do ponteiro como parâmetro. Nesse ponto, uma referência forte é estabelecida para o objeto em questão.

Em alguns casos, podemos forçar o garbage collector a coletar o que estiver disponível para isso em um determinado ponto de execução de uma aplicação. Por exemplo, se tivermos apenas alocado e em seguida desalocado uma grande coleção de objetos, pode ser que seja apropriado dizer para o garbage collector que comece a recolher, para que esses objetos possam ser desalocados o mais rápido possível. 

Comentamos anteriormente sobre aplicações Foundation do tipo command line tool. Sabemos que para criar uma aplicação foundation que usa garbage collection, devemos inicia-lo manualmente na função main, antes de alocar todos os objetos. No entanto, é importante entendermos outro detalhe.

O garbage collection do Objective-C funciona buscando ponteiros que se referem a objetos tanto no âmbito global e local. Quando isso ocorre, ele visualiza todas as variáveis ativas atualmente na pilha local. Assim, ele não leva em consideração se a variável local foi inicializada ou não. Lembre-se que uma variável antes de ser inicializada, está apontando para uma posição de memória, em que anteriormente, pode ter contido dados inicializados ou variáveis que foram excluídas. Em outras palavras, uma variável não inicializada no seu escopo atual, pode estar apontando para um objeto que você alocou em uma função anterior, mas que posteriormente não possui mais referência. Portanto, o garbage collector pode pensar equivocadamente que a variável local pode ser uma referência a um objeto que deve ser coletado como "lixo".

Para evitar que ocorra esse tipo de problema, precisamos limpar a pilha local em uma base regular. O método Objective-C de baixo nível que utilizamos pra fazer isso é objc_clear_stack_(CLEAR_RESIDENT_STACK OBJC_).

Levando isso em consideração, uma típica função command line tool deve se parecer com isso:

Aplicação Foundation da função main

int main (int argc, const char * argv[ ])

{

    objc_startCollectorThread ( );

    //...

    while (running)

    {

        objc_clear_stack(CLEAR_RESIDENT_STACK);

        for (RunnableItem *item in runnableItems)

        {

            [item run]; //...

        }

    }

 return 0;

}

Para podermos entender de fato como usar o Garbage Collector (visto anteriormente) nas nossas aplicações, precisamos ainda entender dois conceitos fundamentais que diz respeito em como o garbage collector irá funcionar. Estes conceitos são referências fortes e fracas. Todos os ponteiros de objeto em Objective-C são referências, isso significa que eles se referem a memória alocada para um objeto. Uma referência pode ser forte ou fraca. Por padrão, todas as referências em Objective-C são referências fortes. Esta, é um tipo de referência que o garbage collector seguirá para determinar que um objeto está "vivo" e não poderá ser recolhido. Referências fracas, por outro lado, são referências de objetos a serem recolhidos, se estes não possuírem referências fortes.

Este conceito é útil quando tivermos uma referência a um objeto, e esse objeto está marcado para ser desalocado, e não podemos rete-lo. Por exemplo, o NSNotification Center usa referências fracas para quem está registrado nele. Vale a pena ressaltar que em um ambiente de referência, os objetos que estão registrados com o NSNotification Center devem remover-se como observadores em seus métodos dealloc. Em um ambiente de garbage collector, este requisito não é necessário porque quando o objeto é desalocado, a referência fraca para esse objeto no NSNotification Center se torna inválida, definida pra zero. Portanto, o NSNotification Center não faz mais envios de notificações para esse objeto.

Lembre-se que em um ambiente de reference counted, quando um objeto tem um delegate, ele usa o atributo de propriedade assign para criar uma referência fraca para o delegate. A razão para este feito é reter ciclos. Vejamos um exemplo de como definir uma referência.

Definindo uma referência fraca

@interface Foo : NSObject

{

    __weak NSString *memberVariable;

}

@end

Além de especificar manualmente uma referência como sendo fraca, há também a possibilidade de usar classes especializadas para armazenar listas de referências fracas. Podemos usar essas classes, tais como NSArray ou NSDictionary em casos onde queremos armazenar referências fracas, ao invés de fortes.

As classes especiais são: NSMapTable, NSHashTable e NSPointerArray. Quando usamos essas classes e temos um elemento desse array desalocado, a referência a esse elemento é simplesmente removida do array. Normalmente, se utilizamos um NSArray ou similar, a referência forte do array mantém os objetos ativos.

Configurando o seu projeto para o Garbage Collector

Configurar o projeto para o Garbage Collector é relativamente simples. Tudo o que precisamos fazer é configurar o build settings, e alterar a configuração para Objective-C Garbage Collector. Se você procurar por essa configuração, irá encontrar uma lista de possíveis valores. Esta incluem o seguinte:

Unsupported: Usa o retain count para gerenciamento de memória.

Supported: Especifica que o projeto suporta o Garbage Collector, mas não o exige.

Required: O Garbage Collector é necessário para esta aplicação e todos os frameworks que ele usa.

A primeira opção é sem suporte. A segunda opção é a de suporte. Esta, adiciona o sinalizador -fobjc-gc, que especifica que o projeto suporta o garbage collector, mas não exige isso.

Ao usar essa configuração, podemos lincar o nosso projeto com aplicações que não tenham sido compiladas com garbage collector. Esta configuração é normalmente usada apenas para as bibliotecas. Nesta configuração, se espera que o código implemente ambos os métodos, dealloc e finalize, independente do fato da aplicação ser compilada com garbage collector ou não.

Na configuração final, é necessário que o compilador acrescente -fobjc-gc somente para as configurações de compilação, e especifica não usa retain/release. Portanto, não pode ser carregado em uma aplicação que não faz uso do garbage collector.

Se você estiver convertendo uma aplicação existente a partir de um ambiente que não faz uso de garbage collector para um ambiente que o utilize, você deve saber que todos os métodos específicos para o modelo que não faz uso de garbage collector deixarão de ser funcionais. O inicializador ainda vai ser chamado, mas o seu método dealloc, não. Você deve então refatorar o método dealloc, ou remover os recursos de desalocação que você pode ter tido antes, em um método finalize.

Se a idéia de gerenciar manualmente a memória em uma aplicação soa como uma tarefa, então você ficará feliz em saber que há não muito tempo, a Apple adicionou o Garbarge Collection no Objective-C. Se você não está familiarizado com o conceito de Garbage Collection, este, é um meio pelo qual o tempo de execução de um aplicativo determina dinamicamente os objetos que não estão mais sendo utilizados ou referenciados, dentro da sua aplicação, e desaloca automaticamente esses objetos. Aplicações que utilizam Garbage Collection não precisam se preocupar em liberar os objetos, manter ciclos, ou, na maior parte, vazamentos de memória. Quando usado adequadamente, o Garbage Collection pode ajudar a evitar algumas armadilhas, algumas das mais comuns, das quais os programadores sempre encontram.

Infelizmente, o Garbarge Collection tem um lado negativo. Ele está disponível apenas no Mac OS X 10.5 ou superior, e não disponível, atualmente, no iPhone, iPad, ou qualquer uma das plataformas menos comum, como Linux ou Windows. Devido a esta limitação, é importante aprender a escrever código Objective-C para ambientes com gerenciamento manual de memória.

Embora o Garbage Collection resolva muito dos problemas no que diz respeito ao gerenciamento de memória, ele também apresenta desafios adicionais que devemos entender, para podermos usa-lo de forma eficaz.

Entendendo o Garbage Collection

É essencial compreender os conceitos básicos do funcionamento do Objective-C Garbage Collection. Para qualquer aplicação que possui um loop de execução incorporada, aplicações Cocoa ou Cocoa Touch por exemplo, quando o loop principal é executado, o Garbage Collector entra em ação com busca por objetos que não possuem referências ativas a eles. Quando ele encontra algum, então desaloca-o.

O Garbage Collector visualiza um conjunto de objetos raiz dentro da aplicação, e pesquisa todas as referências que possuem esses objetos raiz. Qualquer objeto que não possa ser utilizado a partir de um desses objetos raiz é considerado "garbage" (lixo) e então, será recolhido. Objetos raiz são definidos como variáveis globais, variáveis de pilha, e referências externas.

Quando um objeto é coletado, a memória é liberada, mas o método dealloc não é chamado. Em alguns ambientes que utilizam Garbage Collector, métodos dealloc são considerados obsoletos e não são mais usados. Em vez disso, um novo método de objeto foi adicionado, chamado finalize.

Como o Garbage Collector é relativamente não determinístico em relação a quando ele vai realmente chamar o seu método finalize, este, não pode determinar quando ele será chamado. Portanto, é importante que os recursos que estamos utilizando sejam livres, e provavelmente iremos querer colocar o código para liberar esses recursos em outro método que pode ser chamado de forma determinística pelo código, podendo desalocar o nosso objeto. Em função disso verifiquei que alguns desenvolvedores evitam o uso do método finalize.

O exemplo abaixo mostra como podemos iniciar o Garbarge Collector em uma aplicação Foundation. Para fazer isso, nós chamamos a função objc_startCollectorThread(), como mostrado abaixo.

Usando Garbage Collector em uma aplicação Foundation

int main (int argc, const char * argv[])

{

    objc_startCollectorThread();

    //...

    return 0;

}

Em um determinado momento, nós nos vemos na situação de nos perguntar o que acontece com os objetos quando estamos alocando ou liberando-os. "Quando alguém instancia um desses objetos, eles chamam o seu método init. Quando eles liberam um desses objetos, o seu método dealloc é chamado automaticamente pelo tempo de execução. Ao alocar e inicializar um novo objeto, o nosso inicializador deve alocar e inicializar todos as variáveis dos objetos.

Do mesmo modo, quando um objeto é liberado, o método dealloc deve liberar toda memória atribuída a partir do inicializador de objetos, bem como qualquer memória que pode ter sido atribuída dinamicamente durante a execução de qualquer método em um objeto. Essencialmente, quando se inicializa um novo objeto, você aloca os recursos que esse objeto irá exigir, e quando liberar esses objetos, devemos também liberar esses recursos. Já vimos que quando criamos um novo objeto, e atribuímos a uma variável, chamamos a alocação dessa classe que, por sua vez, retorna um objeto alocado, sem dados. Então, usamos esse objeto para chamar init, ou outro inicializador apropriado para a sua classe.

O inicializador é onde nós iremos alocar memória para variáveis em nossos objetos. Escrevendo inicializadores Para chamar o inicializador designado da nossa classe atual, devemos chama-lo usando a variável especial self, assim: [self init]. Para chamar o inicializador designado da super classe, devemos a variável especial super, e chamar o inicializador designado da super classe chamando [super init]. Ambos os métodos irão retornar um objeto auto inicializado, o que representa o objeto que estamos inicializando, e que deve ser devolvido a partir do seu inicializador.

Se ocorrer um erro na inicialização da super classe, ou na inicialização do inicializador designado, eles irão retornar nil. O inicializador da super classe pode criar um objeto, e devolve-lo, em vez de reutilizar o objeto que alocamos no nosso inicializador. Isso é feito constantemente em casos que existem classes clusters. Clusters de classes são a implementação de uma classe por uma das várias subclasses. O inicializador determina a subclasse correta para instanciar, e retorna-lo.

Um inicializador típico:

-(id)init

{

    if (self = [super init])

      {

         someMemberVariable = [[Foo alloc] init];

      }

return self;

}

Quando a inicialização da super classe é concluída com êxito, podemos alocar e inicializar as nossas variáveis. Fazer isso consiste em simplesmente chamar o inicializador padrão do Objective-C para cada uma das variáveis que iremos precisar. Em alguns casos, podemos querer atrasar a atribuição de certas variáveis, até que estas sejam realmente necessárias. Se isso ocorres, é só ajustar o código para essa conformidade. Depois de alocar e inicializar as nossas variáveis e outros recursos, então iremos retornar self do nosso inicializador. Fazer isso, cumprimos a função do inicializador, retornando o objeto agora inicializado pelo "chamador".

Em alguns casos, inicializadores especiais são utilizados em Cocoa ou Cocoa Touch, em condições específicas. Por exemplo, ao desserializar um objeto de um arquivo nib, o inicializador especial initWithCoder é chamado para decodificar as informações da classe serializada do arquivo. Esses casos são raros, mas é importante saber. Percebi que membros de comunidades de fóruns de discussão sobre Objective-C debatem constantemente sobre se é ou não apropriado usar os acessadores de propriedade do Objetive-C 2.0 para inicializar variáveis em inicializadores e destrutores, porque o uso desses acessadores disparam Key Value observando eventos (veremos isso mais a frente), mas por hora, sugiro inicializar as nossas variáveis diretamente, e não usar acessadores no inicializador e no destrutor. Dito isso, mesmo que você ignore essa dica, provavelmente não irá rodar em um problema.

Alguns usam essa técnica tranquilamente, mas ainda existe a possibilidade de se introduzir um bug obscuro. Este problema se torna um pouco mais complicado, porque quando se usa o runtime em 64 bits, podemos declarar propriedades que não possuem variáveis associadas. Neste caso, só é possível inicializar ou liberar suas variáveis usando seus acessadores. Portanto, a Apple sugere que, ao usar o runtime 64 bits, e usando propriedades que não possuem variáveis associadas, você deve de fato usar os acessadores nos inicializadores e nos destrutores de seus objetos, e quando usar o runtime 32 bits, que você não os use.

- Escrevendo métodos dealloc

Com o intuito de liberar memória que alocamos no nosso inicializador, podemos também escrever um método destrutor. O nome desse método em Objetctive-C é chamado de dealloc. Como dito antes, dealloc é chamado indiretamente quando você chama o método release em um objeto. Este também é chamado automaticamente quando um objeto é autoreleased.

- Um típico método dealloc

-(void)dealloc

{

    [someMemberVariable release];

    someVariable = nil;

    [super dealloc];

}

Dentro do método dealloc, devemos liberar os recursos que foram alocados pelo nosso objeto, inclusive a memória associada a qualquer das variáveis que o compõem. Podemos fazer isso chamando release em qualquer variável. Após liberar uma variável, devemos fazer um ponto para atribuir o ponteiro que anteriormente continha os dados dessa variável pra zero.

Já vimos o autorelease no código do modelo que nos é fornecido (template) automaticamente todas as vezes em que criamos um novo projeto no Xcode. No caso de não se lembrar, vamos olhar um exemplo:

Uma função main típica

#import <Foundation/Foundation.h>

int main (int, argc, const char * argv[])

{

     NSAutoreleasePool *pool = [[NSAutoreleasepool alloc] init];

     //insira o código aqui...

     NSLog(@"Hello, World!");

     [pool drain];

     return 0;

}

Como podemos ver, a primeira coisa que esse código faz é criar um NSAutoreleasepool para pegar todos os objetos que a aplicação cria, recebendo a mensagem auto release. No final desta função, o autorelease pool é drenado, antes de ser desalocado. Esse ato de drenagem do autorelease pool é o que realmente faz com que a mensagem atual de liberação seja enviada para todos os objetos que tenham sido auto liberados.

Toda aplicação possui pelo menos um NSAautorelease pool.  Se um aplicativo possui vários segmentos, cada um deste deve ter também o seu próprio autorelease pool. Normalmente, a maioria das aplicações GUI possui um autorelease pool que é drenado cada vez que o loop de execução é executado. Isso faz com que nossos objetos autoreleases (auto liberados) sejam liberados, constantemente enquanto a aplicação está sendo executada.

Para criar o nosso próprio autorelease pool, precisamos alocar um objeto NSAutoreleasepool de novo, e depois realizar as operações necessárias para que se auto liberem, incluindo os objetos necessários para o autorelease. Quando estamos realmente prontos para liberar os nossos objetos autoreleased, nós simplesmente drenamos ou liberamos com uma mensagem:

Criando o nosso próprio objeto autorelease pool

-(void)inflateMemoryUsage

{

     for (NSInterger n = 0; n < 1000; n++)

       {

           NSAutoreleasepool *pool = [[NSAutoreleasepool alloc] init];

           //este objeto é autoreleased

           NSData *data = [self getBigBlobOfData];

           //faça algo com data...

           [self doStuff:data];

           [pool release]; //os objetos autorelease serão liberados aqui

       }

      //nada mais...

}

Autorelease pools trabalham como pilhas aninhadas, em que os objetos que são autoreleased são "empurrados" para o autorelease pool de nível mais alto que está disponível para eles. Portanto, se você criar vários autorelease pools um dentro do outro, os objetos autoreleased dentro de autorelease pool serão desalocados quando este autorelease pool for drenado.

Mais uma vez, autorelease pools são uma forma útil para auxiliar no gerenciamento manual de memória. Estes, portanto, não devem ser confundidos com gerenciamento automático de memória. 

No próximo post, iremos ver como o gerenciamento de memória vê de dentro de seus objetos e o que precisamos fazer para se certificar de que o nosso objeto irá gerir os seus recursos corretamente.

Manter o retain count pode parecer complicado, mas memoriza-las pode deixar o trabalho em Objective-C bem mais fácil.

Qualquer objeto que você cria usando uma chamada de método que contém a palavra alloc, copy, ou create, é um objeto. Você é responsável por liberar esse objeto em algum momento futuro. Algo que se parece como [[Foo alloc] init…] é o que você irá precisar liberar, e qualquer coisa que se pareça com CreateFoo() retorna algo que você irá precisar liberar também.

Um método que você tem acesso e que não for chamado por nenhum dos métodos mencionados acima , significa dizer que você não possui a sua posse. Esses objetos podem ser usados na pilha atual de execução, mas depois que você deixar a pilha, não se pode esperar que os objetos estejam disponíveis para uso.

Quando você recebe um objeto de outras chamadas de métodos, você irá receber de volta um objeto "autoreleased". Não espere que o objeto irá "viver" para além do método atual, por exemplo, se você está atribuindo uma variável, então você precisa conserva-la.

Ao se incrementar um retain count em um objeto, seja alocando-o, copiando-o ou mantendo-o, você está tomando posse desse objeto, e tem direito sobre ele. Assim, estamos dizendo que precisamos de acesso a esse objeto por tempo indefinido, e quando terminarmos com ele, iremos desistir desse objeto e revogar a propriedade dele, permitindo que o mesmo seja destruído.

Atenção

Embora você esteja se tornando o proprietário de um objeto por retê-lo, a propriedade não implica exclusividade. Outros podem possuir o objeto, também. Você não é a única pessoa que poderá estar acessando o objeto e alterar seus valores.

Usando o autorelease

Falamos em autorelease antes. O conceito de autorelease é central para o gerenciamento de memória em Objective-C. Esse conceito permite resolver um problema crítico que vem sendo enfrentado por outras linguagens, como o C e C++. A definição é de um padrão de mecanismo "handoff" para objetos retornados de outros métodos e como a memória associada a eles é gerenciada.

O autorelease é um método que você chama em um objeto, como o release. No entanto, ao invés de imediatamente diminuir o retain count de um objeto, podemos pensar em autorelease como uma promessa de diminuir o retain count em runtime. Quando a contagem de retain count é diminuída desta forma, o objeto será liberado normalmente.

Todas as vezes que estamos retornando um objeto que criamos a partir de um método cujo nome não possui copy, alloc ou create, devemos retornar um objeto autoreleased. O método autoreleased retorna o objeto que ele está auto liberando. Portanto, é especialmente conveniente, e um pouco padrão, usar um modelo semelhante a este:

Retornando um objeto autoreleased

-(Foo *)getFoo

{

    Foo *foo = [[Foo alloc] init];

    // faça algo com foo aqui...

    return [foo autoreleased];

}

Outro padrão comum, onde autorelease é usando de forma eficaz, objetos auto liberados que você cria em vez de libera-los manualmente. Ao fazer isso, estamos nos preocupando com o gerenciamento de memória, ao invés de permitir que o "autorelease pool" limpe automaticamente qualquer coisa que você deixe "pendurado" quando sai do seu método.

O padrão alloc/autorelease

-(void)someMethod

{

    Foo *foo = [[[Foo alloc] init] autorelease];

    // foo ainda é válido aqui, 

    // ele não será liberado até que o método exista

    [foo doSmething];

}

Assim, é menos provável que esqueçamos o gerencimento de memória, quando utilizamos esse padrão.

Um dos maiores desafios que você pode enfrentar como um desenvolvedor Objective-C novo quando vem de outras linguagens como Java, Ruby e Python, é que o Objetive-C exige que você pense no gerenciamento de memória. Outras linguagens modernas tem incorporado sistema de gerenciamento de memória (garbage collection, por exemplo) que permitem programaticamente ignorar as preocupações com o gerenciamento de memória. Objetive-C possui uma versão de garbarge collection em tempo de execução, que é relativamente nova na linguagem.

Seria bom dizer que um desenvolvedor novo em Objective-C não precise se preocupar com o gerenciamento de memória, mas talvez isso não fosse legal pra nós que estamos aprendendo a linguagem. É inteiramente provável que mesmo que você não esteja escrevendo código Objective-C para outras plataformas, diferentes da Mac OS X, você ainda vai correr para o código Mac OS X, que não possui garbage collection e requer que você gerencie o uso de memória manualmente.

No entanto, se nós nos familiarizarmos com as regras de gerenciamento de memória em Objetive-C, gerenciar a memória "na mão" pode ser um assunto razoavelmente simples. Com o tempo, quando fecharmos essa parte, teremos todo o conhecimento de todas as ferramentas que iremos precisar para com código de memória gerenciada, bem como código com memória não gerenciada. 

Usando o Reference Counting

Antes de vermos as ferramentas reais que iremos precisar para gerenciar memória em Objective-C, vamos falar de um mecanismo que a linguagem usa sob o capô pra fazer gerenciamento de memórial manual quase tão fácil quanto usar o garbage collection.

Cada objeto que herda de NSObject herda comportamentos de gestão de memória. Internamente nesses objetos existe um contador de chamadas chamado retain count. Usando certas chamadas, esse contador pode ser incrementado ou decrementado. Em tempo de execução, a lingagem Objective-C sabe quando o retain count chega a zero, e o objeto em questão pode ser liberado da memória.

O retain count pode ser incrementado por vários meios. A qualquer momento que você criar um novo objeto usando um método cujo nome contém as palavras alloc ou create, o objeto retornado terá um retain count um. Além disso, a qualquer momento que você adquirir um objeto usando um método com um nome do método que contém a cópia, esse objeto também terá um retain count um. É possível incrementar manualmente o retain count, chamando o método retain. Você pode também diminuir o retain count chamando o método release. Então, quando o retain count chega a zero, o objeto é liberado da memória. Vejamos agora como isso funciona na prática.

Alocação padrão de um objeto

Bar *foo = [[Bar alloc] init];

Neste caso, no final, o objeto foo tem o retain count um.

Retendo um objeto

Bar *foo = [[Bar alloc] init];

[foo retain];

Neste caso, além de afetar o objeto usando a chamada alloc, também estamos incrementando o retain count utilizando o método retain. No final, o objeto terá um retain count de dois.

Alocando e liberando um objeto

Bar *foo = [[Bar alloc] init];

[foo release];

[foo doSomething];

Neste caso, depois de chamar o método release, o objeto tem um retain count zero, e, portanto, pode ser liberado. Na linha em seguida, estamos tentando acessar um objeto já desalocado, e isso resultaria um crash.

Propositalmente, isso foi um erro. Vejamos agora um caso de vazamento de memória. (memory leak)

Bar *foo = [[Bar alloc] init];

[foo retain];

[foo release];

Agora, estamos alocando um objeto e em seguindo, mantendo-o e mais adiante, liberando-o, mas somente uma vez. Neste caso, estamos lidando apenas com o código nesta pilha particular, e isso seria de fato um vazamento de memória.

Vamos agora criar uma aplicação simples que demonstra o uso das técnicas de Programação Orientada a Objetos.

Iremos criar uma aplicação simples para gestão de Recursos Humanos, onde o resultado final não será uma aplicação procedural usual, mas o processo de criação irá demonstrar a programação orientada a objetos.

Criando a classe funcionário

O objetivo dessa aplicação é simplesmente armazenar uma lista de funcionários e seus gerentes. Além disso, a classe funcionário irá permitir bônus e aumentos aos funcionários.

Haverá também, um tipo especial de funcionário, um gestor. O gerente terá funcionários que irão se reportar diretamente a ele. O funcionário terá uma referência ao seu respectivo gerente. 

Interface da classe funcionário (Employee)

#import <Cocoa/Cocoa.h>

@interface Employee : NSObject 

{

    NSString *firstName;

    NSString *lastName;

    NSDate *birthDate;

    NSDate *dateOfEmployment;

    Employee *manager;

    NSString *ssn;

    double *salary;

}

@property (nonatomic, retain) NSString *firstName;

@property (nonatomic, retain) NSString *lastName

@property (nonatomic, retain) NSDate *birthDate;

@property (nonatomic, retain) NSDate *dateOfEmployment;

@property (nonatomic, assign) Employee *manager;

@property (nonatomic, retain) NSString *ssn;

@property (nonatomic, readonly) NSTimeInterval  age;

@property (nonatomic) double salary;

-(id)initWithFirstName:)NSString *)inFirstName

                   lasName:(NSString *)inLastName

                   birthDate:(NSDate *)inBirthDate

                             ssn:(NSString *)inSsn;

-(void)giveRise:(double)percentage;

-(double)bonus;

@end

Observe que a interface define uma variedade de dados para todos os atributos que uma classe funcionário possa precisar. Além disso, definimos as propriedades para acessar esses dados.

A maioria das propriedades utilizam o atributo retain. As exceções incluem os atributos de valor escalar, a propriedade calculada ( que é readonly) e a propriedade gerente. A propriedade gerente, vai ser um caso especial. Essa propriedade terá uma lista de funcionários que se reportam a ele. 

Implementação da classe funcionário (Employee)

#import "Employee.h"

@implementation Employee

@synthetize firstName;

@synthetize lasName;

@synthetize birthDate;

@synthetize dateOfEmployment;

@synthetize manager;

@synthetize ssn;

@synthetize salary;

@dynamic age;

-(void)dealloc

{

    [self setFirstName: nil];

    [self setLastName: nil];

    [self setBirthDate: nil];

    [self setDateOfEmployment: nil];

    [self setSsn: nil];

    [self setManager: nil];

    [super dealloc];

}

-(id)init;

{

    if(self = [super init])

     {

             }

    return self;

}

-(id)initWithFirstName:)NSString *)inFirstName

                   lasName:(NSString *)inLastName

                   birthDate:(NSDate *)inBirthDate

                             ssn:(NSString *)inSsn

{

      if(self = [super init])

     {

            [self setFirstName: nil];

            [self setLastName: nil];

            [self setBirthDate: nil];

            [self setDateOfEmployment: nil];

            [self setSsn: nil];

            [self setManager: nil];

     }

    return self;

}

-(NSTimeInterval)age

{

    return [bithDate = timeIntervalSinceNow];

}

-(void)giveRaise:(double)percentage;

{

    salary = salary + (salary * percentage);

}

-(double)bonus

{

    return salary * .05;

}

@end

Coisas importantes a serem observadas: há um inicializador que tem uma variedade de parâmetros que são usados para inicializar as variáveis da classe Employee (funcionário). Ao utilizar esse inicializador, o objeto que você criar terá todos os atributos básicos inicializados e prontos para serem utilizados.

É importante notar também neste código o fato de que estamos criando uma propriedade dynamic para efeitos de cálculo da idade do funcionário. Para fazer isso, nós utilizamos a diretiva @dynamic para a propriedade idade (age). Nós, então, criamos, um método de acesso que calcula a idade usando a data de nascimento do funcionário. Há também dois métodos definidos, um para dar ao trabalhador um aumento e outro para lhe dar um bônus. Ambos os métodos serão substituídos na classe manager, para dar uma porcentagem diferente de aumento e bônus.

Criando a classe manager

Agora que já criamos a classe Employee, precisamos criar uma sub classe da classe Employee, chamada Manager. Essa classe terá uma lista de funcionários que se reportam a outros funcionários, e possuem diferentes aumentos e gratificações.

Interface da classe Manager

#import <Cocoa/Cocoa.h>

#import "Employee.h"

@interface Manager : Employee

{

    NSMutableArray *reports;

}

@property (nonatomic, retain) NSMutableArray *reports;

-(void)addReport:(Employee *)inEmployee;

@end

Lembre-se que, a fim de se criar uma classe que herda de outra classe, temos que especificar a classe parente após o nome da classe, no arquivo de interface. Como visto neste código, fizemos exatamente isso. Com essa ação, estamos dizendo que a classe Manager herdará todos os atributos da classe Employee.

Quando se trata de coisas que são da classe Manager, é preciso especificar os ítens aqui. Especificamente, precisamos adicionar o array reports para armazenar os funcionários que  se reportam a um gerente no caso.

Implementação da classe Manager

#import "Manager.h"

@implementation Manager

@synthetize reports

-(void)dealloc

{

    for (Employee *employee in reports)

        { 

            [employee setManager:nil];

        }

            [self setReports:nil];

            [self dealloc];

}

-(id)init

{

      if (self = [super init])

         {

             [self setReports:[NSMutable Array]];

         }

         return self;

}

-(void)addReport:(Employee *)inEmployee;

{

    [reports addObject:inEmployee];

    [inEmployee setManager:self];

}

-(double)bonus

{

    return salary * .10;

}

@end

O que se pode observar no código acima é que temos um inicializador designado, que cria o array de relatórios e o inicializa. Esse inicializador designado será chamado a partir da classe Employee.

Se você verificar o arquivo de implementação da classe Employee, você verá que há uma chamada [super init] que chama esse método. Note que o método bonus é substituído nesta classe também. Esta é então a quantidade de bônus concedida ao trabalhador que recebe um percentual diferente da quantidade de bônus de um empregado padrão.

No final, no método dealloc, o objeto manager trabalha sobre seus relatórios e remove-se. Lembre-se que o atributo gerente (sobre os funcionários) é atribuído como assign, ao invés de retain.

O resultado disso é, se o objeto alocado é o manager, mas o funcionários não reportam a esse gerente, o ponteiro que referencia o gerente do funcionário se tornará inválido. Portanto, é importante que o gerente tenha sua propriedade definida sobre os seus relatórios para nil quando forem dealloc. Este é um padrão importante para se manter em mente para uso futuro, quando falarmos sobre os delegates.

Ao especificar uma propriedade e permitir que o compilador gere acessadores sintetizados usando a diretiva @synthetized, os atributos da propriedade irão afetar o comportamento do acessador. O próprio compilador irá gerar um código diferente, dependendo desses atributos.

Utilizando o atributo nonatomic

Um dos atributos mais importantes que podemos especificar como parte da nossa declaração de propriedade é a de atomicidade do acessador. A atomicidade de uma propriedade tem a ver com a forma como ele se comporta em um ambiente multithread. Um acessador atômico garante que seu valor está completamente definido ou recuparado, no seguimento que está acessando. Pode-se dizer que um acessador atômico é um thread safe. (funcionará corretamente durante a execução simultânea de várias threads)

Um acessador atômico

-(NSString *)firstName

{

    [threadLock lock];

    NSString *result = [[firstName retain] autorelease];

    [threadLock unlock];

    return result;

}

Acessadores não atômicos não são considerados uma thread safe. Um acessador nonatomic gerado pela diretiva @synthetize pode ser como este:

Um acessador nonatomic (não atômico)

-(NSString *)firstName

{

    return [[firstName retain] autorelease];

}

Podemos optar por utilizar os acessadores nonatomic em aplicações que onde teremos apenas uma thread acessando o nosso objeto.

Usando os atributos assign, retain e copy

Entre os atributos de propriedades, há um conjunto importante de atributos utilizados para especificar a semântica do setter gerado. Estes, são os assign, retain e copy. Estes três atributos são mutuamente exclusivos e definem o comportamento do setter que é usado em conjunção com esta propriedade.

Um estilo simples de setter assign

-(void)setFirstName:(NSString *)inValue

{

    firstName = inValue;

{

Este atributo é normalmente usado para propriedades escalares, delegates e outros tipos de variáveis em que seria inadequado usar o retain.

O atributo retain é usado apenas quando se trabalha com dados que são do próprio objeto. Ele especifica que o valor passado será atribuído a variável e uma mensagem retain será enviada para ele.

Um estilo de setter retain

-(void)setFirstName:(NSString *)inValue

{

    [firstName autorelease];

    firstName = [inValue retain];

}

Finalmente, o atributo copy. Este especifica que o setter gerado deve copiar o objeto para a variável. 

-(void)setFirstName:(NSString *)inValue

{

    [firstName autorelease];

    firstName = [inValue copy];

}

Usando propriedades com diferentes nomes de dados

Normalmente, os nomes das nossas propriedades irá coincidir com os nomes de suas variáveis. 

Especificando o nome do acessador para a propriedade @property (nonatomic, retain, getter=getFirstName) NSString *firstName;

Usando a notação de ponto (Dot Notation)

Internamente, uma propriedade compila uma chamada de método, no caso de fixar um valor num setter, e, no caso de obter um valor de um getter. Ao usar propriedades em Objective-C, podemos usar esses getters e setters diretamente usando chamadas de métodos tradicionais, como por exemplo: [object setFoo:bar], ou podemos usar uma sintaxe especial, chamada de notação de ponto.

Acessando propriedades usando acessadores tradicionais e notação de ponto

{

    // chamada de método tradiconal

    [employee setFirstName:@"Rafael"];

   // com notação de ponto

    employee.firstName = @"Rafael";

}

Para este exemplo, vamos imaginar que estamos escrevendo um aplicativo de RH. Este aplicativo será usado para controlar os benefícios dos empregados, incluindo salário, seguro, e assim por diante. Portanto, iremos criar uma classe Employee, que será usada para encapsular os dados.

A partir daqui, podemos imaginar os tipos de atributos e propriedades que uma classe de empregado (Employee) terá que encapsular. Normalmente, se inclui o primeiro nome do empregado, seu último nome, seu número do Seguro Social, o seu número de funcionário, seu salário, e talvez o uma referência a outro funcionário que seja o seu gerente, por exemplo. 

A classe empregado (Employee)

#import <Cocoa/Cocoa.h>

@interface Employee : NSObject

{

    NSString *firstName;

    NSString *lastName;

    NSDate *birthDate;

    NSDate *dateOfEmployment;

    Employee *manager;

    NSString *ssn;

    double salary;

}

@property (nonatomic, retain) NSString *firstName;

@property (nonatomic, retain) NSString *lastName;

@property (nonatomic, retain) NSDate *birthDate;

@property (nonatomic, retain) NSDate *dateOfEmployment;

@property (nonatomic, assign) Employee *manager;

@property (nonatomic, retain) NSString *ssn;

@property (nonatomic, readonly) NSTimeInterval *age;

@property (nonatomic) double salary;

- (id)initWithFirstName:(NSString *)inFirstName

                    lastName: (NSString *)inLastName

                    birthDate:(NSDate *)inBirthDate ssn:(NSString *)inSsn;

- (id)init;

- (void)giveRaise:(double)percentage;

- (double)bonus;

@end

A primeira coisa a se notar é que todas as propriedades especificadas aqui possuem dados que podem ser mapeados. A declaração de propriedade consiste na diretiva @property seguido dos atributos que afetam o tipo de acesso que é criado como parte da propriedade. Esses atributos são especificados dentro dos parênteses, após a diretiva @property.

getter=<name>,setter=<name> Especifica o nome dos métodos acessadores que irão ser usados para essa propriedade.

readwrite ou readonly Especifica se esta propriedade será capaz de ser escrita. O padrão é readwrite.

assign, retain, e copy Determina o tipo de setter gerado para essa propriedade. Assign gera um setter com uma simples atribuição à variável. Retain gera um setter que mantém o argumento passado a ele enquanto é  atribuído a variável. Copy gera um acessador que copia o valor passado para a variável. O padrão é assign.

Após os atributos da propriedade, devemos especificar os tipos de dados para as propriedades. Finalmente, temos que especificar o nome da propriedade. É possível especificar uma propriedade com um nome que é diferente do nome real que a propriedade representa. Na maioria das vezes, no entanto, não precisaremos fazer isso.

Como de costume, tudo o que foi declarado no arquivo de interface, terá uma implementação no arquivo .m e com as propriedades não é diferente. Para usar os métodos acessadores gerados pelo compilador, as propriedades devem ter uma declaração dentro do nosso bloco de implementação. Os possíveis tipos de declarações de propriedades no nosso arquivo de implementação podem ser tanto @synthetize ou @dynamic. A diretiva @synthetize faz com que o compilador gere completamente todo o código necessário para criar os acessadores para a nossa propriedade. Essencialmente, esta diretiva é uma ajuda e tanto. Se você usar a diretiva @synthetize, nenhum código adicional precisa ser escrito no seu arquivo de implementação. Por outro lado, se você quiser criar mais métodos acessadores por carregamento dinâmico em tempo de execução, você poderá fazer isso usando a diretiva @dynamic. Quando você usa essa diretiva, o compilador espera que você tenha criado um par apropriado acessadores para a sua propriedade.

CUIDADO

Quando você cria os seus próprios acessadores usando a diretiva @dynamic, garanta que eles irão estar de acordo com o que você especificou nos atributos da propriedade. Em outras palavras, se você especificou um atributo como copy, então deve-se garantir que o seu acessador copia o valor que é passado quando a propriedade é definida.

Implementação da classe Employee

#import "Employee.h"

@implementation Employee

@synthetize firstName;

@synthetize lastName;

@synthetize birthDate;

@synthetize dateOfEmployment;

@synthetize manager;

@synthetize ssn;

@synthetize salary;

@dynamic age;

// partes removidas, para mantermos o foco em propriedades

-(NSTimeInterval)age

{

    return [birthDate timeIntervalSinceNow];

}

@end

A maioria das propriedades são definidas através da diretiva @synthetize. Isso significa que o compilador é o encarregado por criar acessadores para essas propriedades. Havia um par de propriedades na classe Employee, no entanto, eram propriedades puramente de cálculo. Por exemplo, a idade do empregador pode ser calculada usando a sua data de nascimento.

Como podemos ver nesse código, nos casos particulares, as propriedades foram especificadas como readonly e dynamic. Isto significa que nós escolheremos ir em frente e criar métodos que calculem dinamicamente esses atributos ao invés de armazena-los. Pra isso, implementamos métodos que façam isso.

Uma recente adição à linguagem Objective-C é o conceito de propriedades. Elas permitem você definir métodos de acesso para os dados da sua classe, assim como também eliminam a maior parte do código clichê que já tenha sido necessário para acessar esses dados.

Entendendo as diferenças entre estado e comportamento  

Comentamos anteriormente que objetos são como um mecanismo para encapsular atributos e comportamentos.  O objetivo das propriedades em Objective-C é nos ajudar a expor os atributos do seu objeto e representar o seu estado. Internamente, as propriedades possuem métodos reais que podem ser usados para obter e definir os estados em seu objeto. Estes métodos são chamados de acessadores. Podemos optar por usar os acessadores gerados pelo compilador, ou substituir por um próprio.

Objetos são compostos por estados e comportamentos. Estado consistem nos dados que compõem o seu objeto. 

Comportamento, por outro lado, pode ser imaginado como um objeto tendo uma ação. Comportamentos podem ser utilizados para atualizar outros objetos, e, assim, causar efeitos secundários, ou pode ser usado para alterar os dados de seus objetos.

Propriedades permitem que você exponha o estado de seu objeto. Elas podem, da mesma forma, ser usadas apenas para manipular o estado do seu objeto. 

Considere uma classe que represente um motor. Esta classe motor pode expor uma propriedade para especificar o seu acelerador. A propriedade para especificar a posição do acelerador só deve definir o valor do acelerador. Se quisermos ainda expor o comportamento que faz com que o motor mude o seu comportamento com base no valor do acelerador, então devemos ter um método (um comportamento) como updateEngineSpeedFromThrottle. Este método não tem nenhum parâmetro, e irá retornar um valor booleano que indica se foi ou não capaz de atualizar a velocidade do motor.

Ao separar o estado e o comportamento de sua classe, você está impedindo efeitos colaterais e dependências entre seus comportamentos e atributos de seu objeto.

Já vimos como declarar classes anteriormente, incluindo seus dados, métodos, e assim por diante. Mas tudo isso seria inútil se você não puder declarar as instâncias de suas classes e usa-las. Então, agora, vamos dar uma olhada em como podemos declarar uma variável de instância no nosso código.

{

    Foo *object;

    object = [[Foo alloc] init];

    [object doSomethingWithParameter:arg];

  // tudo em uma linha

    Foo *object = [[Foo alloc] initWithArray:[NSMutable array]];

    [object soSomethingWithParameter:arg];

 // usando um construtor de método de classe

 Foo *object = [[Foo fooWithArray:[NSMutableArray array]];

 [object doSomethingWithParameter:arg];

} 

Como visto, declarar uma instância de classe é bem simples. Primeiro, usamos o nome da classe, com o operador de ponteiro (*). Então em seguida, colocamos o nome da variável que irá conter a instância da nossa classe, nesse caso, object. Podemos, se assim quisermos, inicializar a variável imediatamente, na mesma linha, com a sua declaração.

Para fazer isso, basta usar o operador de igual para atribuir o valor inicializado na sua variável. No exemplo acima, foram mostradas as duas coisas, primeiro uma forma de não inicializar a variável, e em seguida, inicializar a variável em uma única linha. Há uma sintaxe nova e importante neste código. Essa sintaxe se refere a utilização dos operadores ([]) colchetes.

Em Objective-C, os métodos são chamados nas classes. Abrimos o colchete no início do objeto ou classe que o método se relaciona e, em seguida, colocamos o colchete de fechamento no final da invocação do método. Assim, olhando para o código acima, podemos ver que na inicialização da nossa variável, temos duas chamadas de métodos na verdade, em ambos os trechos.

A primeira delas é uma chamada para alocação. Este método é chamado na classe. O segundo é a chamada para o método init. Essa chamada é feita no objeto retornado da alocação. É importante reconhecer isso quando se olha para um código.