Quali sono i vantaggi di un Getter / Setter "combinato" VS metodi individuali?

Questo è ciò che chiamo metodo getter / setter "combinato" (da jQuery):

var foo = $("<div>This is my HTML</div>"),
    myText;

myText = foo.text(); // myHTML now equals "This is my HTML" (Getter)
foo.text("This is a new value"); // The text now equals "This is a new value")

Questa è la stessa logica con metodi (teorici) separati:

var foo = $("<div>This is my HTML</div>"),
    myText;

myText = foo.getText(); // myHTML now equals "This is my HTML" (Getter)
foo.setText("This is a new value"); // The text now equals "This is a new value")

La mia domanda:

Quando progetti una libreria come jQuery, perché dovresti decidere di seguire il primo percorso e non il secondo? Il secondo approccio non è più chiaro e più facile da capire a colpo d'occhio?

Qui sto solo speculando, ma sarei propenso a credere che gli sviluppatori di jQuery che hanno usato molto dello stile funzionale nella strutturazione di jQuery abbiano chiaramente una tendenza verso il paradigma funzionale.

Dato che, nel paradigma funzionale, esiste una forte cultura di riduzione della ridondanza, e si potrebbe sostenere che il secondo approccio ha una ridondanza non necessaria. Il primo approccio potrebbe non essere chiaro a qualcuno abituato a tutte le lingue imperative comuni, ma sta indiscutibilmente facendo di più con meno avendo un solo metodo anziché due. Questo può essere pericoloso, ma è uno strumento comune nel paradigma funzionale e qualcosa a cui ci si abitua rapidamente.

Esercitati nel paradigma funzionale e superi rapidamente quel desiderio di cerimonia e impari ad apprezzare la capacità di fare di più con meno. Sebbene questa sia riconoscibilmente una scelta soggettiva basata sulla preferenza nello stesso modo in cui molte persone hanno preferenze riguardo alla gestione degli spazi bianchi. In questo modo non sto dicendo che un modo sia migliore, piuttosto che siano cose a cui le persone si abituano, motivo per cui jQuery ha l'approccio che ha.

Questo sarebbe il motivo per cui credo che gli sviluppatori di jQuery abbiano fatto questo ed è in generale il motivo per cui qualcuno potrebbe adottare questo approccio.

Il modulo

foo.text("This is a new value"); 

può implicare un numero di cose. Più comunemente, suggerisce un foooggetto, con un metodo chiamato textaccettare una stringa, che fa qualcosa . Non c'è alcuna conseguenza che questa sia una proprietà.

In molte lingue, questa può essere considerata una forma abbreviata di

var result = foo.text("This is a new value"); 

dove il risultato viene scartato. Quindi questo approccio è troppo ambiguo per essere un modo efficace per impostare una proprietà (dal punto di vista della leggibilità del codice).

È un po 'speculativo, ma ecco la mia idea.

jQuery abbraccia pienamente la natura funzionale di javascript. Questo è ciò che lo rende così fantastico, ma può lasciare un sacco di sviluppatori che si grattano la testa quando provengono da un linguaggio più puramente OO come Java. Sembra infrangere ogni convenzione e buona pratica.

La lingua funzionale tende a porre l'accento su una sintassi dichiarativa. Tende a leggere la dichiarazione simile di un fatto piuttosto che i comandi simili. Esempio

var eligible = customers.where(c => c.age > 30);

che può essere letto come "il cliente idoneo sono i clienti di età superiore ai 30". Per contrasto, il linguaggio imperativo si legge come una sequenza di comando

for (customer in customers)
    if (customer.age > 30)
        eligible.add(customer)

Che può essere letto come "Controlla ogni cliente e se la sua età è superiore a 30, aggiungili alla raccolta idonea"

L'aggiunta di aa sete di getun'operazione renderebbe jQuery una libreria imperativa. Puoi costruire il modo di leggere le seguenti affermazioni

// The element tag have an html of <p>hello</p>
$("#element").html("<p>hello</p>"); 

// content represent the html of the element tag
var content = $("#element").html();


//Imperative style

// Set the element tag to an inner html of <p>hello</p>
$("#element").setHtml("<p>hello</p>");

//Get the html of #element, and put it in the content variable
var content = $("#element").getHtml();

Mantenendo il verbo delle azioni fuori dall'API jQuery, lo facevano sembrare un'API dichiarativa. Dà un aspetto coerente e funzionale alla biblioteca. Questo è il motivo per cui penso che abbiano sovraccaricato le parole chiave.

Lo fa comportare in qualche modo più come le proprietà , che sono state introdotte solo di recente a JavaScript, e quindi non sono ancora ampiamente utilizzate, specialmente in librerie come jQuery che hanno lo scopo di aiutare a sottrarre incompatibilità del browser.

Se hai mai visto una definizione di classe piena di tali proprietà, i prefissi "set" e "get" sembrano superflui, perché l'aggiunta del parametro value ti dice già che è un setter. Martin Fowler fa un buon punto sui getter che richiedono un parametro, ma anche in quel contesto il parametro del valore aggiuntivo indica chiaramente un setter, così come il fatto che un setter appare raramente sul lato destro di un compito. E quando scrivi il codice, devi comunque consultare la documentazione della libreria.

Dal momento che hai chiesto solo vantaggi, non coprirò gli svantaggi.