Propriedades no ARC: sempre ou somente público?

Depois de ler humildemente um artigo chamado "Os mandamentos de código: práticas recomendadas para codificação de Objective-C", de Robert McNally, há pouco menos de dois anos, adotei a prática de usar propriedades para praticamente todos os membros de minhas classes de Objective-C ( o terceiro mandamento em maio de 2012). McNally lista estas razões para fazê-lo (minha ênfase):

1. As propriedades aplicam restrições de acesso (como somente leitura)
2. As propriedades aplicam a política de gerenciamento de memória (forte, fraca)
3. As propriedades oferecem a oportunidade de implementar de forma transparente setters e getters personalizados.
4. As propriedades com setters ou getters personalizados podem ser usadas para impor uma estratégia de segurança de encadeamento.
5. Ter uma maneira única de acessar variáveis ​​de instância aumenta a legibilidade do código.

Eu coloquei a maioria das minhas propriedades em categorias particulares, portanto, os números 1 e 4 geralmente não são problemas nos quais eu corro. Os argumentos 3 e 5 são mais "flexíveis" e, com as ferramentas certas e outras consistências, podem se tornar problemas. Então, finalmente, para mim, o mais influente desses argumentos foi o número 2, gerenciamento de memória. Eu venho fazendo isso desde então.

@property (nonatomic, strong) id object; // Properties became my friends.

Nos meus últimos projetos, mudei para o uso do ARC, o que me fez duvidar que a criação de propriedades para praticamente qualquer coisa ainda seja uma boa ideia ou talvez um pouco supérflua. O ARC cuida da memória gerenciando objetos Objective-C para mim, o que para a maioria dos strongmembros funciona bem se você apenas declarar os ivars. Os tipos C que você precisava gerenciar manualmente de qualquer maneira, antes e depois do ARC, e as weakpropriedades são principalmente públicas.

É claro que ainda uso propriedades para qualquer coisa que precise de acesso de fora da classe, mas essas são apenas algumas propriedades, enquanto a maioria dos membros de dados é listada como ivars sob o cabeçalho de implementação

@implementation GTWeekViewController
{
    UILongPressGestureRecognizer *_pressRecognizer;
    GTPagingGestureRecognizer *_pagingRecognizer;
    UITapGestureRecognizer *_tapRecognizer;
}

Como experimento, tenho feito isso com um pouco mais de rigor, e a mudança de propriedades para tudo tem alguns efeitos colaterais positivos.

1. Os requisitos de código do membro de dados ( @property/ @synthesize) diminuíram apenas para a declaração ivar.
2. A maioria das minhas self.somethingreferências foi limpa _something.
3. É fácil distinguir quais membros de dados são privados (ivars) e quais são públicos (propriedades).
4. Por fim, parece que esse era o objetivo para o qual as propriedades da Apple se destinavam, mas isso é especulação subjetiva.

Sobre a questão : estou lentamente deslizando em direção ao lado sombrio, usando cada vez menos propriedades a favor da implementação-ivars. Você pode me fornecer um pouco de raciocínio sobre por que devo usar propriedades para tudo ou confirmar minha corrente de pensamentos sobre por que devo usar mais ivars e menos propriedades somente quando necessário? A resposta mais persuasiva para ambos os lados receberá minha nota.

EDIT: McNally comenta no Twitter, dizendo : "Acho que meu principal motivo para manter as propriedades é: uma maneira de fazer tudo, que faz tudo (incluindo KVC / KVO.)"

Você pode me fornecer um pouco de raciocínio sobre por que devo usar propriedades para tudo ou confirmar minha corrente de pensamentos sobre por que devo usar mais ivars e menos propriedades somente quando necessário?

No momento, acho justo dizer que é principalmente uma questão de estilo. Como você diz, o benefício de gerenciamento de memória das propriedades é menos importante com o ARC. Por outro lado, os "benefícios" de voltar ao acesso direto ao ivar também não são muito atraentes:

1. Uma declaração @property é bastante semelhante a uma declaração ivar. Evitar a diretiva @synthesize não parece uma grande vitória - não estamos falando de muito código.

2. A foo.somethingsintaxe é sem dúvida muito melhor que _something. Obviamente, a sintaxe de acesso à propriedade foi projetada para parecer e funcionar como a sintaxe de ponto de C para acessar membros de uma estrutura. Ser explícito sobre qual objeto você está acessando (seja isso selfou outra coisa) é útil. (Algumas pessoas - não eu! - defendem o self->somethingacesso a ivar por esse motivo.) A convenção principal de sublinhado para ivars é boa, mas não é usada de forma consistente em todo o código Objective-C.

3. As propriedades parecem uma opção melhor para acessar dados armazenados em outros objetos da mesma classe (o que é permitido em acesso "privado") e para acesso por subclasses (como "protegido" em C ++). Portanto, a idéia 'properties == public' é um pouco embaçada.

4. Meu senso é que as propriedades foram projetadas para simplificar o gerenciamento de memória e fornecer alguns outros benefícios. Como você diz, com o benefício de gerenciamento de memória diminuído, as propriedades parecem menos atraentes.

O caminho que você escolheu - voltando ao acesso direto a dados internos - parece ser uma escolha muito razoável e não há razão óbvia para mudar seu curso. Mas a aderência às propriedades também é bastante razoável - as desvantagens não são significativas e existem alguns benefícios interessantes, como a conformidade com o KVO e um estilo de acesso ao membro mais consistente.

As propriedades não foram o último passo na evolução do Objective-C, e também não espero que o ARC seja. Não tenho nenhuma informação específica, mas parece um bom palpite de que recursos adicionais possam ser adicionados em algum momento que tornem as propriedades mais atraentes ou menos. Teremos que esperar e ver o que acontece.

Eu também estive pensando sobre esta questão. Na minha humilde opinião, apenas o uso de propriedades para acessadores torna o código muito mais legível. Você pode ver imediatamente quais variáveis ​​devem ser acessadas publicamente. E, pessoalmente, sempre digitando @property (...) na frente de uma variável é demorado.