Combinando getter e setter

Martin Fowler l'ha recentemente chiamato Overloaded getter e setter in questo articolo :

I've been poking around in Javascript recently and one thing that's struck me is the habit of using the same function name for a getter and a setter. So if you want to find out the height of your banner in jQuery you would use $("#banner").height() and if you want to change the height you would use $("#banner").height(100).

This convention is familiar to me, as it was used by Smalltalk. You might get a value with banner height and change it with banner height: 100. Knowing it was a smalltalk convention is enough to expect me to like it, since I have an distant but abiding love for that language. But even the best things have flaws, and I can't hide my dislike for this coding style...

Despite this preference, you do have to follow the conventions of the language you're dealing with. If I were writing Smalltalk again I'd still use height:100 in order retain consistency with the conventions of the language. Javascript, however, isn't noted for having strong conventions, so here I'd prefer to avoid this convention, even if it is used by jQuery...

Si chiama "overloading dei metodi" nei linguaggi OO o "overloading delle funzioni" in lingue non OO.

Che sia una buona pratica o meno è un argomento di discussione quasi quanto i getter / setter contro i membri pubblici. Quelli dei professionisti e dei membri probabilmente si sono tagliati i denti in lingue che avevano questa caratteristica o no e sono impostate nei loro modi. Lo uso e mi piace la pratica per una serie di motivi:

• Il contesto in cui è usato discretamente si separa l'uno dall'altro.
• La prepending get o set al nome del metodo aggiunge verbosità.
• Se sono presenti più getter (ad esempio, uno per int e uno per double ), la modifica del tipo nell'LHS di un compito ( int x = foo.bar() rispetto a double x = foo.bar() ) non richiede un cambio di codice ( barAsInteger() vs. barAsDouble() ) sul lato destro se la classe fornisce entrambi. Il lato negativo di questo è che a volte può essere difficile sapere esattamente quale metodo viene chiamato solo guardando il codice.

Poiché JavaScript non ha proprietà effettive (dove l'impostazione di un valore può effettivamente eseguire codice), il patter è uno che implementa l'idioma della proprietà. (Anche se lo chiami qualcos'altro.)

Quindi, nelle lingue che implementano le proprietà reali, dovresti farlo invece:

element.css = ...
x = element.css

Se dovessi utilizzare lo schema JavaScript in un linguaggio che gestisce le proprietà, dovresti fare qualcosa di anormale. Probabilmente non sarebbe una buona idea. Gestisci le proprietà nel modo in cui la lingua intende gestirle, in modo da non confondere le altre persone che lavorano con te.

Penso che tu stia cercando properties

Sono completamente contrario a questo per una semplice ragione: una classe, un metodo o una funzione dovrebbero fare solo una cosa - a mio avviso, e combinando il metodo getter e setter violerà quella regola. Come risultato:

1. Il valore di return della funzione varia in base all'esecuzione del blocco getter o setter . Questo può semplicemente portarti in un incubo di manutenibilità. Il tuo metodo dovrebbe restituire solo un tipo di dati / oggetto in ogni caso - o restituire null , false o lanciare un exception in caso di errore.
2. Scrivere Test di unità sarà più difficile in quanto la funzione è responsabile di due funzionalità completamente diverse.
3. Scrivere documentazione per tale metodo o funzione è più difficile per ovvi motivi.
4. Non sarà coerente quando sono necessari più metodi getter - come già menzionato in Blrfl answer.