Categorias
O Objective-C tem uma funcionalidade chamada Categories. Essencialmente isso permite “reabrir” classes já existentes e extendê-las com mais métodos.
Na minha interpretação o Obj-C, assim como Ruby, são linguagens orientadas a objeto mas, mais importante, eu diria que elas são orientadas a protocolo. Em vez de pensar em interfaces estáticas e “chamar um método” o correto é pensar em “enviar mensagens”. Protocolos definem quais mensagens o objeto sabe responder. A diferença é que você não busca uma coerência em tempo de compilação mas sim em tempo de execução. Você pode mandar mensagens que o objeto não entende se quiser sem receber um erro de compilação.
Uma convenção de nomenclatura que podemos usar é criar o arquivo header e a implementação usando o nome da classe a ser extendida, o símbolo “+”, e o nome da Categoria que queremos implementar. Por exemplo, digamos que eu queira a mesma funcionalidade do método each de Array do Ruby no equivalente NSArray do Obj-C, podemos fazer assim:
1 2 3 4 5 6 |
// NSArray+functional.h @interface NSArray (functional) - (void) each:(void (^) (id))block; @end |
E a implementação seria:
1 2 3 4 5 6 7 8 9 10 11 12 |
// NSArray+functional.m #import "NSArray+functional.h" @implementation NSArray (functional) - (void) each:(void (^) (id))block { int i; for (i = 0; i < [self count]; i ++) { block([self objectAtIndex:i]); } } @end |
A sintaxe é exatamente a mesma se estivéssemos definindo uma nova classe, mas neste caso declaramos o mesmo nome da classe que já existe NSArray e entre parênteses colocamos o nome da nossa categoria que, neste caso, chamei arbitrariamente de “functional” para ter diversos métodos funcionais.
Categorias não podem ter variáveis de instância entre chaves na declaração da interface, ela só pode comportar novos métodos, por isso falei que não era não flexível, mas isso já seria o bastante.
Essa funcionalidade pode ser usada principalmente para duas coisas: substituir a necessidade de criar sub-classes e, com isso, evitar usar herança sempre que possível e que fizer sentido; e a outra é quebrar classes com implementações muito grande em múltiplos arquivos de forma a melhor organizar os arquivos do projeto.
Blocos
Como vocês devem ter suspeitado, implementar o método each semelhante ao Ruby significa que deveríamos poder usar blocos. E o Obj-C também permite blocos, na forma de métodos anônimos (sem nome).
O parâmetro que implementamos é (void (^) (id))block. “block” é o nome da variável que vai receber o bloco. Seu tipo é de retorno “void” e parâmetro “id”. O “^” é o “nome” do bloco, no caso, sem nome algum, ou anônimo. Tendo em mãos o bloco podemos executá-la assim: block([self objectAtIndex:i]). O tipo id em Obj-C é um tipo genérico que denota um objeto arbitrário. Ele é usado por todo o framework Cocoa e seria, mais ou menos, o equivalente a dizer que o método recebe qualquer tipo de objeto.
E como podemos usar essa nova categoria com o novo método? Vejamos:
1 2 3 4 5 6 7 8 9 |
#import "NSArray+functional.h" - (IBAction) foo:(id)sender { NSMutableArray *list = [NSMutableArray arrayWithObjects:@"a", @"b", @"c", nil ]; NSString *msg = @"elemento: %@"; [list each:^(id obj) { NSLog(msg, obj); }]; } |
No caso, faça de conta que estamos numa aplicação de iPhone ou Mac, por isso criei um método que retorna IBAction. Para quem não sabe, IBAction é a mesma coisa que void, ou seja, que o método não retorna nada. A diferença é que o Interface Builder reconhece métodos que retornam IBAction como métodos que podem ser ligados diretamente a ações de um elemento visual na tela, por exemplo.
No corpo do método começamos criando um NSMutableArray. Fiz isso de propósito porque essa classe herda de NSArray e, portanto, também herdará o novo método each que implementamos.
Agora a parte importante é como chamamos o método nesse objeto: [list each:^(id obj) { … }]. Ou seja, estamos enviando a mensagem each ao objeto list passando como parâmetro um bloco anônimo “^” que tem parâmetro id obj. Se você não conhece blocos de Ruby ou de outra linguagem como Lisp, pode ser difícil entender o que está acontecendo, por isso recomendo novamente ler meu artigo sobre blocos antes.
Note que dentro do bloco o NSLog está usando a string msg que foi criada fora do bloco, exatamente como eu poderia fazer em Ruby, o bloco tem conhecimento do ambiente ao seu redor e eu posso usar variáveis criadas fora do bloco. Isso é uma das coisas que torna essa funcionalidade de blocos diferente de um simples “delegate” ou simplesmente passar um ponteiro de uma função.
Em Ruby, eu posso capturar um bloco em uma variável, assim:
1 2 3 |
bloco = lambda { |a| puts a }
bloco.call("bla")
# => "bla"
|
No exemplo acima, criamos um bloco e em seguida executamos esse bloco usando o método call. Em Obj-C podemos fazer algo similar assim:
1 2 3 4 |
void (^bloco)(NSString*) = ^(NSString* msg) { NSLog(msg); }; bloco(@"bla"); |
Veja que é muito parecido só que precisamos declarar os tipos. Na primeira linha definimos uma variável do tipo bloco, com o nome de “bloco” (o nome vem logo depois do “^”). Antes do nome temos o tipo de retorno, void, e depois o tipo do parâmetro que ele aceita, ponteiro de NSString. Daí criamos o bloco propriamente dito.
Em seguida basta chamar o bloco como se fosse uma função normal de C, usando a notação de passar parâmetros entre parênteses.
Conclusão
Categorias e Blocos podem ajudar muito a tornar a programação em Obj-C mais flexível e mais próxima dos conceitos de linguagens mais dinâmicas como Ruby. Como exercício que tal completar a minha Categoria NSArray+functional.h e acrescentar métodos como select, map, sort, etc? Coloquem links para Gist nos comentários com sugestões de implementação.
Para aprender mais sobre blocos, recomendo ler: