È "cattivo" utilizzare @properties per le variabili private solo per i vantaggi della gestione della memoria?

È errato creare @properties per le variabili private solo per i vantaggi della gestione della memoria?È "cattivo" utilizzare @properties per le variabili private solo per i vantaggi della gestione della memoria?

Sembra strano e sbagliato avere visibilità pubblica @ proprietà per molte variabili private.

(Principalmente, mi sto liberando ivars private durante le condizioni di memoria insufficiente con i rispettivi metodi di "evento".)

Esempio: solito faccio questo per rilasciare un Ivar privato:

[name release]; name = nil;

Ma con @properties, posso fare questo:

self.name = nil;

Più tardi nel mio codice, farà questo, da qui la necessità di impostare a zero:

if(!name) 
    name = [[NSString alloc] initWithFormat:@"Hi %@",inputName];

fonte

2009-09-10 bentford

Un'alternativa è mantenere la proprietà privata. È possibile utilizzare il seguente codice (nel file .m) per rendere la proprietà accessibile solo all'interno della classe:

#import "MyClass.h" 

@interface MyClass() 
    @property (retain) NSString* privateString; 
@end 

@implementation MyClass 

    @synthesize privateString; 
    // Your code here 

@end

ora hai la facilità di un immobile, ma altre classi ancora non è possibile accedervi , anche se importano il tuo file .h!

fonte

2009-09-11 00:21:07 andyvn22

Questo è fantastico, ma sembra un trucco. Non sono sicuro che lo farò nel mio codice, ma almeno so che c'è un'alternativa a quello che sto facendo ora. Grazie!! – bentford

+13

Non è un hack, è una forma esplicita di categoria chiamata estensione. . "È normale che una classe abbia un'API dichiarata pubblicamente e quindi abbia un'API aggiuntiva dichiarata privatamente per l'utilizzo esclusivo della classe o del framework all'interno del quale risiede la classe" –

Non è assolutamente un hack ed è al 100% in linea con perché le estensioni di classe sono state aggiunte alla lingua in primo luogo. Abbraccia questo schema con gusto. – bbum

Per le proprietà pubbliche non credo di Apple raccomanda, perché a volte la fissazione di un immobile a zero può avere effetti collaterali diversi dal semplice rilascio della variabile (notifiche KVO, o un costume metodo setter che fa qualcos'altro).

Per quanto riguarda le proprietà private, non ne sono troppo sicuro. L'utilizzo di una proprietà ti farà risparmiare un paio di tratti chiave durante la codifica, ma lo renderai anche leggermente più complesso e fragile. Io preferisco la leggibilità e la manutenibilità piuttosto che scrivere, perché a lungo termine risparmierai tempo.

fonte

2009-09-11 00:15:26

Citazione dalla documentazione Apple in UIViewController Riferimento di classe per metodo - (void) viewDidUnload: "Il metodo preferito per rinunciare alla proprietà di qualsiasi oggetto (inclusi quelli in punti vendita) consiste nell'utilizzare il corrispondente metodo accessor per impostare il valore del oggetto a zero " – bentford

Mi sono guardato intorno per trovare il motivo originale per cui pensavo che fosse sbagliato (perché l'ho dimenticato), e ho trovato questo: http://stackoverflow.com/questions/192721/why-shouldnt-i-use- obective-c-2-0-accessors-in-init-dealloc. Sembra che sia solo una preoccupazione in init o dealloc. –

Le proprietà esistono per la vostra convenienza. Se non vuoi che altre persone usino proprietà che esistono nelle tue classi, semplicemente non documentarle.

fonte

2009-09-11 00:16:08 NSResponder

Ma sono visibili nel tuo file .h. andyvn22 ha una soluzione alternativa a questo. – bentford

È "cattivo" utilizzare @properties per le variabili private solo per i vantaggi della gestione della memoria?

risposta

Problemi correlati