2010-04-15 4 views
6

Generalmente parlando, la creazione di un'API fluida è qualcosa che rende felici tutti i programmatori; Sia per i creatori che scrivono l'interfaccia, sia per i consumatori che programmano contro di essa. Guardando oltre le convenzioni, perché è che prefiggiamo tutti i nostri getters con la parola "get". Omettendola di solito si ottiene un insieme di istruzioni più fluido e facile da leggere, che alla fine porta alla felicità (per quanto piccola o passiva). Considera questo esempio molto semplice. (pseudo codice)Perché i getter sono preceduti dalla parola "get"?

convenzionale:

person = new Person("Joey") 
person.getName().toLower().print() 

Alternativa:

person = new Person("Joey") 
person.name().toLower().print() 

Naturalmente questo vale solo per lingue in cui getter/setter sono la norma, ma non è diretto ad alcuna specifica linguaggio. Queste convenzioni si sviluppavano attorno a limitazioni tecniche (disambiguazione) o semplicemente attraverso il perseguimento di un'interfaccia di tipo più esplicito e intenzionale, o forse questo è solo un caso di una norma downle down. Quali sono i tuoi pensieri? E come semplici cambiamenti a queste convenzioni influenzano la tua felicità/atteggiamenti quotidiani nei confronti del tuo mestiere (comunque minimo).

Grazie.

+4

Alcuni di noi non scrivono getter o setter o credono in "API fluide". –

+1

Non sono d'accordo che ' person.name() 'è un set di istruzioni più fluido e più semplice da leggere, poiché penserei che il metodo assegni effettivamente un nome o un soprannome a questa persona e, onestamente, se hai intenzione di usarlo in quel contesto, 'person.name.whatever' sembra e legge molto più facilmente di adesso,' name' diventa una proprietà (leggibile/assegnabile) invece di un metodo. –

+2

così quando hai e IDE con il completamento del codice, puoi digitare "get" e vedere tutti i getter – colinjwebb

risposta

10

Perché, nelle lingue senza Proprietà, name() è una funzione. Senza ulteriori informazioni, tuttavia, non è necessariamente specifico su ciò che sta facendo (o su cosa restituirà).

Anche le funzioni/i metodi sono verbi perché eseguono un'azione. name() ovviamente non si adatta al conto perché non ti dice nulla su quale azione sta eseguendo.

getName() consente di sapere senza ombra di dubbio che il metodo restituirà un nome.

Nelle lingue con proprietà, il fatto che qualcosa sia una proprietà esprime lo stesso significato di aver ottenuto o impostato ad esso. Semplicemente rende le cose un po 'più ordinate.

+0

concordato. Ciò ricade sul caso che ho menzionato esplicitamente sulle cose intenzionalmente da non creare alcun tipo di ambiguità. Tuttavia, sono convinto che un'API ben progettata utilizzi i nomi corretti per oscurare qualsiasi ambiguità in questo modo. Come sfida, puoi darmi un esempio in cui la mancanza del prefisso potrebbe farti pensare che non sai cosa sta succedendo? – Joey

+0

@Joey: il problema con la disposizione dei nomi non è il nome ma il paren. I parents suggeriscono di eseguire un'azione, piuttosto che restituire il valore di una proprietà. Ecco perché è necessario il prefisso 'get'. –

+0

@robert punto molto valido. In situazioni in cui tale linguaggio non ha alcun meccanismo per implementare gli accessor di proprietà, o dopo che il fatto cambia ad un'implementazione di proprietà, l'uso di parer attorno al nome nudo è davvero l'unica situazione. – Joey

1

A scuola ci è stato insegnato a utilizzare per distinguere i metodi dalle strutture dati. Non ho mai capito perché i paren non sarebbero un ribaltamento. Sono dell'opinione personale che l'uso eccessivo dei metodi get/set può essere un orrendo spreco di tempo, ed è una fase in cui vedo che molti programmatori orientati agli oggetti passano subito dopo l'avvio.

+2

La tua scuola non ha capito bene, IMO. –

+1

D'altra parte, approvo la tua opinione personale. –

+0

Vedi qui per l'uso appropriato di getter e setter: http://stackoverflow.com/questions/565095/java-are-getters-and-setters-evil –

4

La risposta migliore che io abbia mai sentito per l'utilizzo dei prefissi get/set è come tale:

Se non li utilizzano, sia la funzione di accesso e mutator (getter e setter) avrebbe lo stesso nome; quindi, sarebbero sovraccaricati. Generalmente, si dovrebbe sovraccaricare un metodo solo quando ciascuna implementazione del metodo esegue una funzione simile (ma con input diversi).

In questo caso, si avrebbero due metodi con lo stesso nome che hanno funzioni molto diverse e che potrebbero confondere gli utenti dell'API.

+1

Bella osservazione. I setter, credo, meritano giustamente il prefisso, poiché cambiano una sorta di stato. Non è un gioco a somma zero, la rimozione del "get" non porta necessariamente alla liberazione del "set". E se venisse usato solo il set, evitando così il sovraccarico? – Joey

+0

@Joey: Sembra più rumore rispetto all'utilizzo di 'get' e' set', poiché l'uno non assomiglia all'altro. E hai ancora il problema con Parens che suggerisce un'azione da eseguire, piuttosto che una proprietà da recuperare. –

+0

Sarebbe ok se la convenzione fosse che ogni metodo che non aveva un verbo nel suo nome era un accessorio. – danben

0

Personalizzato.

Inoltre, in C++, se si restituisce un riferimento, questo fornisce una potenziale perdita di informazioni nella classe stessa.

+0

Davvero? Pensi che l'operatore [] di std :: string (ad esempio) causi una tale perdita? –

+0

Neil: Io di per sé non significa perdita di memoria. –

+0

Non intendevo né menzionavo perdite di memoria, intendevo il tuo concetto di "perdita". –

3

E il caso in cui una proprietà prende il nome da un verbo?

object.action() 

Questo ottenere il tipo di azione da eseguire, o eseguire l'azione ... L'aggiunta di get/set/fare rimuove l'ambiguità, che è sempre una buona cosa ...

object.getAction() 
object.setAction(action) 
object.doAction() 
+0

Grazie per la risposta curiosa. Puoi darmi un esempio in cui una proprietà che prende il nome da un verbo potrebbe anche essere logicamente usata come getter? – Joey

+0

"action" non è un verbo, quindi questo è un cattivo esempio. In generale, le proprietà prendono sempre il nome da nomi, non da verbi. –

4

Apprezzo sempre il prefisso get/set coerente quando si lavora con una nuova API e la relativa documentazione. Il raggruppamento automatico di getter e setter quando tutte le funzioni sono elencate in ordine alfabetico aiuta a distinguere tra accesso ai dati semplice e funzionalità avanzata.

Lo stesso vale quando si utilizza il completamento intellisense/automatico nell'IDE.

+0

Questo è un punto molto buono, forse il più forte a mio avviso. – Joey

0

Non posso scrivere molto Objective-C, ma da quando l'ho imparato ho imparato ad amare le sue convenzioni. La stessa cosa che stai chiedendo è addressed dalla lingua.

+1

@jsumners molti cerchi attorno a Apple davvero non usano questa convenzione. (* via webkit style gudie *). "Precedere i setter con la parola" set ". Usa parole nude per i getter.I nomi di setter e getter devono corrispondere ai nomi delle variabili impostate/ottenute". http://webkit.org/coding/coding-style.html. Certamente alcune lingue hanno abbandonato tali convenzioni perché hanno convenzioni o costrutti linguistici per aggirarle. Il chilometraggio può variare. – Joey

+0

Bene, devo usare C# al lavoro. C# ha proprietà, ma sono fastidiose (come alluso alla domanda originale). Ad esempio, questo non funzionerà:

 public class MyClass { private int foo; public int foo { get { return this.foo; } set { this.foo = value; } } } 
Invece, quello che dovete fare:
 public class MyClass { private int _foo; public int foo { get { return this._foo; } set { this._foo = value; } } } 
Penso solo Objective-C è un po 'meno fastidioso in questo senso. –

+1

Impressionante. I commenti non supportano il markup. –

1

Ecco una risposta Smalltalk che mi piace di più. Uno deve sapere alcune regole su Smalltalk BTW. I campi sono accessibili solo nel modo in cui sono definiti. Se non si scrivono "accessors" non si sarà in grado di fare nulla con loro.

La convenzione non è avere una variabile (diciamo ANME si instVar1 allora si scrive una funzione instVar1 che restituisce solo instVar1 e instVar:.. Che stabilisce il valore

Mi piace questa convenzione molto di più di qualsiasi altra cosa Se vedi un: da qualche parte puoi scommettere che è un "setter" nell'uno o nell'altro modo

Problemi correlati