Dopo aver letto un articolo umilmente chiamato "I comandamenti del codice: best practice per la codifica Objective-C" di Robert McNally poco meno di due anni fa, ho adottato la pratica di utilizzare le proprietà per quasi tutti i membri di dati delle mie classi Objective-C (il 3 ° comandamento a maggio 2012). McNally elenca queste ragioni per farlo (la mia enfasi):
- Proprietà impone restrizioni di accesso (come readonly)
- Le proprietà applicano criteri di gestione della memoria (forti, deboli)
- Le proprietà offrono l'opportunità di implementare in modo trasparente setter e getter personalizzati.
- Le proprietà con setter o getter personalizzati possono essere utilizzate per applicare una strategia di sicurezza del thread.
- Avere un unico modo per accedere alle variabili di istanza aumenta la leggibilità del codice.
Ho inserito la maggior parte delle mie proprietà in categorie private, quindi i numeri 1 e 4 in genere non sono problemi a cui sono interessato. Gli argomenti 3 e 5 sono più "soft" e con gli strumenti giusti e altre consistenze potrebbero diventare non-problematici. Quindi, alla fine, per me il più influente di questi argomenti era il numero 2, gestione della memoria. Lo sto facendo da allora.
@property (nonatomic, strong) id object; // Properties became my friends.
Per i miei ultimi progetti sono passato a usare ARC, il che mi ha fatto dubitare che la creazione di proprietà per praticamente qualsiasi cosa sia ancora una buona idea o forse un po 'superflua. ARC si prende cura della memoria gestendo oggetti Objective-C per me, che per la maggior parte dei membri strong
funziona bene se si dichiarano solo gli ivars. I tipi C che dovevi gestire manualmente comunque, prima e dopo ARC, e le proprietà weak
sono per lo più di pubblico.
Naturalmente uso ancora le proprietà per tutto ciò che ha bisogno di accesso dall'esterno della classe, ma quelle sono per lo più solo una manciata di proprietà, mentre la maggior parte dei membri di dati sono elencate come ivars sotto l'intestazione di implementazione
@implementation GTWeekViewController
{
UILongPressGestureRecognizer *_pressRecognizer;
GTPagingGestureRecognizer *_pagingRecognizer;
UITapGestureRecognizer *_tapRecognizer;
}
Come esperimento lo sto facendo un po 'più rigorosamente, e il passaggio dalle proprietà per tutto ha alcuni effetti collaterali positivi.
- Requisiti del codice membro dati (
@property
/@synthesize
) ridotti alla sola dichiarazione di ivar. - La maggior parte dei miei riferimenti a
self.something
è stata pulita a solo_something
. - È facilmente distinguibile quali membri dei dati sono privati (ivars) e pubblici (proprietà).
- Infine, sembra che più lo stesso fosse lo scopo per cui Apple intendeva le sue proprietà, ma questa è una speculazione soggettiva.
Nella domanda : Sto lentamente scivolando verso the dark side, usando sempre meno proprietà a favore di ivars di implementazione. Potete fornirmi un po 'di ragionamento sul motivo per cui dovrei attenermi all'utilizzo delle proprietà per qualsiasi cosa, o confermare il mio attuale ragionamento sul motivo per cui dovrei usare più ivar e meno proprietà solo dove necessario? La risposta più persuasiva per entrambe le parti riceverà il mio marchio.
EDIT: McNally pesa su Twitter, dicendo : "Penso che il motivo principale per cui mi sono attenuto alle proprietà è: un modo per fare tutto, questo fa tutto (incluso KVC / KVO.) "