Proprietà sotto ARC: sempre o solo pubblico?

Dopo aver letto un articolo umilmente intitolato "I comandamenti del codice: migliori pratiche per la codifica dell'obiettivo-C" di Robert McNally poco meno di due anni fa, ho adottato la pratica di utilizzare le proprietà per quasi tutti i membri dei dati delle mie classi di Objective-C ( il 3 ° comandamento a maggio 2012). McNally elenca questi motivi per farlo (la mia enfasi):

1. Le proprietà applicano restrizioni di accesso (ad esempio di sola lettura)
2. Le proprietà applicano i criteri di gestione della memoria (forte, debole)
3. Le proprietà offrono l'opportunità di implementare in modo trasparente setter e getter personalizzati.
4. Le proprietà con setter o getter personalizzati possono essere utilizzate per applicare una strategia di sicurezza del thread.
5. Avere un solo modo per accedere alle variabili di istanza aumenta la leggibilità del codice.

Metto la maggior parte delle mie proprietà in categorie private, quindi i numeri 1 e 4 di solito non sono problemi in cui mi imbatto. Gli argomenti 3 e 5 sono più "morbidi" e con gli strumenti giusti e altre coerenze potrebbero diventare problemi. Quindi, infine, per me il più influente di questi argomenti è stato il numero 2, la gestione della memoria. Lo sto facendo da allora.

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

Per i miei ultimi progetti sono passato all'utilizzo di ARC, il che mi ha fatto dubitare che la creazione di proprietà praticamente per qualsiasi cosa sia ancora una buona idea o forse un po 'superflua. ARC si occupa della memoria gestendo oggetti Objective-C per me, che per la maggior parte dei strongmembri funziona bene se si dichiarano semplicemente gli ivar. I tipi C che dovevi gestire manualmente comunque, prima e dopo ARC, e le weakproprietà sono principalmente pubbliche.

Ovviamente uso ancora le proprietà per tutto ciò che richiede l'accesso dall'esterno della classe, ma queste sono per lo più solo una manciata di proprietà, mentre la maggior parte dei membri dei dati sono elencati come ivar sotto l'intestazione dell'implementazione

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

Come esperimento, l'ho fatto in modo un po 'più rigoroso e l'allontanamento dalle proprietà di tutto ha alcuni effetti collaterali positivi.

1. Requisiti del codice membro dei dati ( @property/ @synthesize) ridotti solo alla dichiarazione ivar.
2. La maggior parte dei miei self.somethingriferimenti è stata ripulita solo da _something.
3. È facilmente distinguibile quali membri di dati sono privati ​​(ivars) e quali sono pubblici (proprietà).
4. Infine, sembra che questo sia lo scopo per cui Apple intendeva le proprietà, ma questa è una speculazione soggettiva.

Alla domanda : sto lentamente scivolando verso il lato oscuro, usando sempre meno proprietà a favore degli ivar di implementazione. Potete fornirmi un po 'di ragionamento sul perché dovrei attenermi all'uso delle proprietà per tutto, o confermare il mio attuale flusso di pensieri sul perché dovrei usare più ivar e meno proprietà solo dove necessario? La risposta più persuasiva per entrambe le parti riceverà il mio voto.

EDIT: McNally pesa su Twitter, dicendo : "Penso che il mio motivo principale per attenermi alle proprietà sia: un modo per fare tutto, che fa tutto (incluso KVC / KVO.)"

Potete fornirmi un po 'di ragionamento sul perché dovrei attenermi all'uso delle proprietà per tutto, o confermare il mio attuale flusso di pensieri sul perché dovrei usare più ivar e meno proprietà solo dove necessario?

In questo momento, penso che sia giusto dire che è principalmente una questione di stile. Come dici tu, il vantaggio della gestione della memoria delle proprietà è meno importante con ARC. D'altra parte, i "vantaggi" di tornare all'accesso diretto all'ivar non sono neanche molto convincenti:

1. Una dichiarazione @property è abbastanza simile a una dichiarazione ivar. Evitare la direttiva @synthesize non sembra una grande vittoria - non stiamo parlando di molto codice.

2. La foo.somethingsintassi è probabilmente molto meglio di _something. La sintassi dell'accesso alle proprietà è ovviamente progettata per apparire e funzionare come la sintassi del punto C per accedere ai membri di una struttura. Essere espliciti su quale oggetto stai accedendo (sia esso selfo qualcos'altro) è utile. (Alcune persone - non io!) Sono a favore self->somethingdell'accesso agli ivar per questo motivo. La convenzione di sottolineatura principale per gli ivar va bene, ma non è usata coerentemente da tutto il codice Objective-C.

3. Le proprietà sembrano una scelta migliore per accedere ai dati memorizzati in altri oggetti della stessa classe (che è consentito sotto l'accesso "privato") e per l'accesso da sottoclassi (come il "protetto" di C ++). Quindi l'idea "proprietà == pubblico" è piuttosto sfocata.

4. La mia sensazione è che le proprietà intendessero semplificare la gestione della memoria e fornire altri vantaggi. Come dici tu, con il vantaggio della gestione della memoria diminuito, le proprietà sembrano meno convincenti.

Il percorso che hai scelto - tornando all'accesso diretto all'ivar per i dati interni - sembra una scelta molto ragionevole e non c'è motivo ovvio per cambiare rotta. Ma attenersi alle proprietà è anche abbastanza ragionevole: gli svantaggi non sono significativi e ci sono alcuni bei vantaggi come la conformità KVO e uno stile di accesso dei membri più coerente.

Le proprietà non sono state l'ultimo passo nell'evoluzione di Objective-C, e non mi aspetto che ARC lo sia. Non ho informazioni specifiche, ma sembra una buona ipotesi che ad un certo punto potrebbero essere aggiunte funzionalità aggiuntive che rendono le proprietà più avvincenti o meno. Dovremo aspettare e vedere cosa succede.

Ho anche riflettuto su questa domanda. A mio modesto parere, l'utilizzo delle proprietà per gli accessori rende il codice molto più leggibile. Puoi immediatamente vedere a quali variabili si intende accedere pubblicamente. E personalmente, digitare sempre @property (...) davanti a una variabile richiede tempo.