Was sind die Vorteile eines "kombinierten" Getter / Setter im Vergleich zu einzelnen Methoden?

Das nenne ich eine "kombinierte" Getter / Setter-Methode (von 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")

Dies ist die gleiche Logik mit getrennten (theoretischen) Methoden:

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")

Meine Frage:

Warum sollten Sie sich beim Entwerfen einer Bibliothek wie jQuery für den ersten Weg und nicht für den zweiten entscheiden? Ist der zweite Ansatz nicht auf einen Blick klarer und verständlicher?

Hier wird nur spekuliert, aber ich würde gerne glauben, dass die jQuery-Entwickler, die einen Großteil des funktionalen Stils für die Strukturierung von jQuery verwendet haben, eindeutig ein Hang zum funktionalen Paradigma haben.

In Anbetracht dessen, dass es im funktionalen Paradigma eine starke Kultur der Redundanzreduzierung gibt, und es könnte argumentiert werden, dass der zweite Ansatz unnötige Redundanz aufweist. Der erste Ansatz ist für jemanden, der mit allen gängigen imperativen Sprachen vertraut ist, vielleicht nicht klar, aber er führt unbestreitbar zu mehr mit weniger, indem er nur eine Methode anstelle von zwei Methoden verwendet. Das mag gefährlich sein, ist aber ein gängiges Werkzeug im Funktionsparadigma und etwas, an das man sich schnell gewöhnt.

Wenn Sie das Funktionsparadigma üben, werden Sie schnell über den Wunsch nach Zeremonie hinwegkommen und die Fähigkeit zu schätzen lernen, mit weniger mehr zu erreichen. Obwohl dies erkennbar eine subjektive Entscheidung ist, die auf Präferenzen beruht, haben viele Menschen Präferenzen in Bezug auf die Verwaltung von Leerzeichen. Auf diese Weise sage ich nicht, dass ein Weg besser ist, sondern dass es Dinge sind, an die sich die Leute gewöhnen. Deshalb hat jQuery wahrscheinlich den Ansatz, den es hat.

Aus diesem Grund glaube ich, dass die jQuery-Entwickler dies getan haben, und im Allgemeinen ist dies der Grund, warum jemand diesen Ansatz wählen könnte.

Die Form

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

kann eine Reihe von Dingen implizieren. Am häufigsten wird ein fooObjekt vorgeschlagen, das mit einer Methode namens textAkzeptieren einer Zeichenfolge etwas bewirkt . Es gibt keine Implikation, dass dies überhaupt eine Eigenschaft ist.

In vielen Sprachen kann dies als abgekürzte Form von betrachtet werden

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

wo das Ergebnis verworfen wird. Daher ist dieser Ansatz zu mehrdeutig, um eine Eigenschaft effektiv festzulegen (aus Sicht der Codelesbarkeit).

Es ist ein bisschen spekulativ, aber hier ist mein Schuss drauf.

jQuery unterstützt die Funktionalität von Javascript. Das ist es, was es so großartig macht, aber es kann eine Menge Entwickler am Kopf kratzen lassen, wenn sie aus einer reineren OO-Sprache wie Java stammen. Es scheint gegen alle Konventionen und bewährten Praktiken zu verstoßen.

Funktionale Sprache tendiert dazu, den Schwerpunkt auf eine deklarative Syntax zu legen. Es liest sich eher wie eine Feststellung einer Tatsache als wie ein Befehl. Beispiel

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

was als "der berechtigte Kunde sind die Kunden, die über 30 Jahre alt sind" gelesen werden kann. Demgegenüber liest sich die imperative Sprache wie eine Befehlsfolge

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

Das kann gelesen werden als "Überprüfen Sie jeden Kunden, und wenn ihr Alter über 30 ist, fügen Sie sie der berechtigten Sammlung hinzu"

Durch Hinzufügen von aa setund einer getOperation würde sich jQuery wie eine imperative Bibliothek anfühlen. Sie können das Lesen der folgenden Anweisungen einschränken

// 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();

Indem sie das Verb "actions" aus der jQuery-API heraushalten, fühlen sie sich wie eine deklarative API an. Es gibt der Bibliothek ein einheitliches, funktionales Gefühl. Deshalb haben sie meiner Meinung nach die Keywords überladen.

Dadurch verhält es sich eher wie Eigenschaften , die erst kürzlich in JavaScript eingeführt wurden und daher noch nicht häufig verwendet werden, insbesondere in Bibliotheken wie jQuery, die dazu beitragen sollen, Browser-Inkompatibilitäten zu beseitigen.

Wenn Sie sich jemals eine Klassendefinition mit solchen Eigenschaften angesehen haben, erscheinen die Präfixe "set" und "get" überflüssig, da Sie durch Hinzufügen des value-Parameters bereits wissen, dass es sich um einen Setter handelt. Martin Fowler macht eine gute Aussage zu Gettern, die einen Parameter erfordern, aber selbst dann kennzeichnet der zusätzliche Werteparameter in diesem Kontext eindeutig einen Setter sowie die Tatsache, dass ein Setter selten auf der rechten Seite einer Zuweisung erscheint. Und wenn Sie Code schreiben , müssen Sie sich sowieso die Dokumentation der Bibliothek ansehen.

Da Sie nur nach Vorteilen gefragt haben, werde ich die Nachteile nicht abdecken.