Proprietà sotto ARC: sempre o solo pubblico?

9

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):

  1. Proprietà impone restrizioni di accesso (come readonly)
  2. Le proprietà applicano criteri di gestione della memoria (forti, deboli)
  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 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.

  1. Requisiti del codice membro dati ( @property / @synthesize ) ridotti alla sola dichiarazione di ivar.
  2. La maggior parte dei miei riferimenti a self.something è stata pulita a solo _something .
  3. È facilmente distinguibile quali membri dei dati sono privati (ivars) e pubblici (proprietà).
  4. 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.) "

    
posta epologee 22.05.2012 - 11:10
fonte

2 risposte

5

Can you provide me with a bit of reasoning for why I should stick to using properties for everything, or confirm my current train of thoughts as to why I should use more ivars and less properties only where needed?

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

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

  2. La sintassi foo.something è decisamente migliore di _something . La sintassi di accesso alle proprietà è ovviamente progettata per assomigliare e funziona come la sintassi dei punti di C per l'accesso ai membri di una struttura. Essere espliciti su quale oggetto si sta accedendo (sia che sia self o qualcos'altro) è utile. (Alcune persone - non io! - sostengono self->something per l'accesso a ivar per questo motivo.) La convenzione di sottolineatura principale per ivars è soddisfacente, ma non viene utilizzata in modo coerente da tutto il codice Objective-C.

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

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

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

Le proprietà non erano l'ultimo passo nell'evoluzione di Objective-C, e non mi aspetto che sia ARC. Non ho alcuna informazione specifica, ma sembra una buona ipotesi che a un certo punto possano essere aggiunte funzionalità aggiuntive che rendono le proprietà più convincenti o meno. Dovremo aspettare e vedere cosa succede.

    
risposta data 22.05.2012 - 13:20
fonte
-1

Ho anche riflettuto su questa domanda. Nella mia umile opinione, solo l'uso delle proprietà per gli accessor rende il codice molto più leggibile. È possibile vedere immediatamente quali variabili devono essere consultate pubblicamente. E personalmente, scrivere sempre @property (...) davanti a una variabile richiede molto tempo.

    
risposta data 31.05.2013 - 08:40
fonte

Leggi altre domande sui tag