2009-06-19 6 views
8

Una delle cose che mi piace di più del cacao è il fattore di leggibilità.Perché non avviare i costruttori di convenienza con "with"?

Una delle cose che mi infastidisce di più è la convenzione dei costruttori di convenienza per forzare la ripetizione.

Ecco un esempio:

[NSString stringWithString:s] 

[NSNumber numberWithDouble:d] 

[NSValue valueWithInt:i] 

[NSDictionary dictionaryWithObjectsAndKeys:<blah>] 

ecc

Perché non la convenzione semplicemente iniziare a costruttori di convenienza con la parola "con"? così allora avremmo:

[NSString withString:s] 

[NSNumber withDouble:d] 

[NSValue withInt:i] 

[NSDictionary withObjectsAndKeys:<blah>] 

ecc

E 'un punto di discussione minore, ma ho pensato solo buttare là fuori e vedere se qualcuno con più peso di quanto mi può spiegare tutti gli echi di la mia testa.

Ovviamente, non ho intenzione di presentare una petizione AAPL per riscrivere l'appKit in favore del mio suggerimento, ma ci sono argomenti contro nominare i miei costruttori di convenienza in quanto tali?

Ovviamente posso usare le convenzioni che voglio nel mio codice ma odio nuotare controcorrente alla cieca.

risposta

13

Esiste in realtà un motivo tecnico per essere così. Se ogni metodo shoelaceWithString: -type venisse modificato in solo withString:, si finirebbe con un numero spaventosamente enorme di classi con metodi con nomi identici e diverse firme. Questo gioca con trucchi sul controllo statico del tipo del compilatore e può far sì che generi tutti gli avvisi fastidiosi e non necessari.

C'è anche un aspetto della cultura Cocoa in cui agli sviluppatori piace il proprio codice per essere auto-documentanti. Ciò significa che i nomi dei metodi indicano sia i loro argomenti che cosa restituiscono. Le linee guida di codifica di Apple effettivamente mettono in guardia sui metodi con nomi vaghi, suggerendo che aggiungere parole al nome per chiarire che cosa sia un metodo preferibile.

+0

grazie mille, Chuck. questa è un'informazione molto utile, apprezzo la tua risposta. – kent

-2

Se non ti piace, perché non scrivere una serie di dichiarazioni #define che includi in tutti i tuoi progetti?

+0

è sicuramente qualcosa che posso vivere con , ma molte volte mi sono chiesto. ma sì, ho una manciata di macro che rendono conv-control molto usato più spesso e più facile da scrivere ... tecnicamente parlando, queste definizioni non rappresentano un anti-pattern? – kent

+5

Penso che questa sia una pessima idea. Anche se ha senso per te, il tuo codice diventa molto meno leggibile quando qualcun altro deve mantenerlo. –

+1

quindi anti-pattern. – kent

3

Penso che sia solo una parte del generale "dici esattamente cosa intendi" filosofia del wordiness della struttura del cacao. Alcune selezioni di scelta:

[UIView setAnimationBeginsFromCurrentState] 
[UITableView scrollToNearestSelectedRowAtScrollPosition] 
[UIApplication didRegisterForRemoteNotificationsWithDeviceToken] 

ecc

ETA:

Per rispondere alle domande specificamente circa i costruttori, una cosa che mi piace il modo in cui sono fatto è che è facile all'interno di X-Code per identificare quali metodi sono metodi del tipo di costruttore. Ad esempio, si inizia a digitare:

[NSString string 

E il "intellisense" whittles verso il basso l'elenco dei metodi per quelli che iniziano con "stringa" che ovviamente sono tutti i metodi costruttori (e il tutto comodamente raggruppati pure) . La stessa cosa vale per la convenzione "init".

+1

la strega è un gioco da ragazzi quando sei venuto da C# e ricevi un sacco di codice da leggere come int a, b, c; ...: -/ – balexandre

+0

@eric: sono d'accordo, lol. ma nei tuoi esempi è piacevole leggere nei file di implementazione. ma in questo caso "roger roger" le implementazioni balbettano e le dichiarazioni sembrano sensate: ironia perché finisci di scrivere la dichiarazione una volta, ma le implementazioni per il resto della tua vita ... – kent

10

Perché è coerente.

ci sono metodi come:

[NSDictionary dictionary] 
[NSArray array] 

Come liberarsi di tutto ciò che fino a with non è ovviamente un'opzione qui. Mantenerli, ma accorciare gli altri introdurrebbe un'incoerenza nella denominazione dei metodi di convenienza.

E i metodi di convenienza sono compatibili con i metodi init e initWith….

+0

...... roger, roger. – kent

3

In definitiva, credo che la filosofia Objective-C, come incorporata nei framework Cocoa (e nei framework NextStep prima di esso), sia esplicita, e di facile manutenzione abbia la precedenza sulla concisione del codice.L'evidenza principale di questa filosofia è che i selettori Objective-C hanno argomenti denominati (ad esempio -[NSObject performSelector:withObject:]).

Nel caso di metodi di fabbrica come +[NSString stringWithString:], è necessario ricordare che le sottoclassi possono sovrascrivere questi metodi di classe per restituire sottoclassi (ad esempio cluster di classi come NSNumber).

Quindi, si può finire con una chiamata come [MyPoorlyNamedSubclass stringWithString:] nel qual caso -[MyPoorlyNamedSubclass withString:] non sarebbe ovviamente informativo per quanto riguarda il tipo di oggetto restituito (ricordate che molti metodi di fabbrica tipo id ritorno). stringWithString:, d'altra parte chiarisce che il metodo restituirà una stringa (o una sua sottoclasse).

2

Usano anche questa parola in più per dire se l'oggetto è autorizzato o meno. initWithFormat è per non autoreleased e quando stringWithFormat è autoreleased ... Credo che siano andati con quel modo di dire al lettore che tipo di gestione della memoria l'oggetto usa ...

Problemi correlati