「複合」ゲッター/セッターVS個別メソッドの利点は何ですか?


12

これは、「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")

これは、個別の(理論的な)メソッドを使用した同じロジックです。

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

私の質問:

jQueryのようなライブラリを設計するとき、なぜ2番目のルートではなく最初のルートに行くことにしたのですか?2番目のアプローチは一目でわかりやすく、理解しやすいものではありませんか?


6
Martin Fowler氏は、彼が「オーバーロードゲッターセッター」と呼ぶもののファンではありません。martinfowler.com/bliki/OverloadedGetterSetter.html
vaughandroid

1
以前はget / set splitメソッドが好きでした(コードをより「自明」にしたと思います)が、最近ではオーバーロードされたgetter / setterパターンがより魅力的になっています。コードをきれいにすることができます。ファウラー氏の妥協が好きだとは思いませんでした。それは両方の世界の最悪だと私には思えます。
ブライアン・ノブラウフ

それに対するマーティン・ファウラーの唯一の本当の議論は、「ゲッター」が引数を渡すときです。その場合、それはゲッターのように見えないという点で読者にとって混乱します。今のところ、ゲッターが引数を取らず、セッターが引数を取るという慣習に固執する場合、明確なAPIコメントとともに、jQuery / Angularアプローチはうまくいくはずだと結論づけました。今のところ。
zumalifeguard 14

回答:


13

ここでは純粋に推測しますが、jQueryの構造化に多くの機能的なスタイリングを使用したjQuery開発者は、明らかに機能的なパラダイムに傾倒していると信じています。

それを考えると、機能的パラダイムには冗長性を減らす強い文化があり、2番目のアプローチには不必要な冗長性があると主張できます。最初のアプローチは、すべての一般的な命令型言語に慣れている人には明らかではないかもしれませんが、2つではなく1つのメソッドのみを使用することで、より少ないリソースでより多くのことを実行できます。これは危険かもしれませんが、機能的なパラダイムでは一般的なツールであり、すぐに慣れるものです。

機能的なパラダイムで練習すれば、式典に対するその欲求をすぐに乗り越え、少ない労力でより多くのことを行う能力に感謝することを学びます。これは、多くの人がホワイトスペース管理に関する選好を持っているのと同じように、選好に基づく主観的な選択であることが認識できますが。このように、私は1つの方法がより良いと言っているのではなく、それらは人々が慣れる物であるということではありません。

これが、jQuery開発者がこれを行ったと私が信じる理由であり、一般的に誰かがこのアプローチを取る理由です。


2
同意した上で、JSサイズをできるだけ小さくしたいという要望を追加します。
マットS

-1命令/詳細および機能/暗黙のポイント。

3
@MattFenwick気分を害するつもりはありませんが、機能的パラダイムが暗黙的に傾いているのに、命令的パラダイムが明示的に傾いているのは間違っていると言っていますか?私はどちらかが優れていると言っているのではなく、どちらか一方に慣れることができるので、他方とは対照的にあなたは自動的にそのように物事を行うことができます(これはどちらの方法でも同じです)
ジミー・ホファ

@ジミー問題ありません。私のポイントは、私の経験では、暗黙性/明示性がFP /命令型に直交していることを発見したということです。

@MattFenwickは可能ですが、多くの暗黙性を可能にし、HM型システムに共通の型推論は別として、FP言語に共通する他のことは、すべての演算子としての関数と同様に暗黙性に傾いていますfunctionには明示的な名前はなく、暗黙的に学習して知ることが期待されるシンボル、またはDUの代わりにメンバーの意味と場所の暗黙的な知識を必要とするリストまたはタプルの一般的な使用法があります(ライターモナドの仕組みを考えてください)。私はまた、単一の文字のパラメータ名の共通性を確認する傾向があるが、あなたは正しいかもしれない
ジミー・ホッファ

2

フォーム

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

多くのことを暗示しています。最も一般的には、文字列を受け入れるfooと呼ばれるメソッドtextを使用して、何かを行うオブジェクトを提案します。これがプロパティであるという意味はまったくありません。

多くの言語では、これは次の短縮形と考えることができます。

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

結果は破棄されます。したがって、このアプローチはあまりにも曖昧すぎて、プロパティを設定する効果的な方法にはなりません(コードの可読性の観点から)。


これは素晴らしい点です!JavaScriptを読むときにFPゴーグルを着用すると、物事が違って見えるので、これについても考えませんでしたが、C#でこのようなコードを見た場合、「このメソッドは??」。
ジミー・ホッファ

1

それは少し推測ですが、ここに私のショットがあります。

jQueryはjavascriptの機能的な性質を完全に取り入れています。それがとても素晴らしいことですが、Javaのようなより純粋なオブジェクト指向言語から来た開発者の多くが頭を悩ませる可能性があります。それはすべての慣習と良い慣行を破るようです。

機能的言語は、宣言構文に重点を置く傾向があります。コマンドのようではなく、事実の声明のように読む傾向があります。例

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

「対象となる顧客は30歳以上の顧客です」と読むことができます。対照的に、命令型言語は一連のコマンドのように読みます

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

「各顧客を確認し、年齢が30歳を超えている場合は、対象のコレクションに追加してください」と読むことができます。

aa setget操作を追加すると、jQueryは命令型ライブラリのように感じられます。次の文を読む方法を理解できます

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

アクションの動詞をjQueryのAPIから除外することで、宣言的なAPIのように感じさせました。ライブラリに一貫した機能的な感触を与えます。だから私は彼らがキーワードをオーバーロードしていると思う。


1

JavaScriptに最近導入されたばかりのプロパティのように動作するため、特にブラウザの非互換性を抽象化するためのjQueryのようなライブラリではまだ広く使用されていません。

そのようなプロパティで満たされたクラス定義を見たことがある場合、「set」および「get」プレフィックスは不要に見えます。これは、valueパラメーターを追加すると既にセッターであることを示しているためです。 Martin Fowlerは、パラメーターを必要とするゲッターについて良い点を述べていますが、それでも、そのコンテキスト内では、追加の値パラメーターはセッターを明確に示し、セッターが割り当ての右側にめったに表示されないという事実も示しています。そして、コードを書いているときは、とにかくライブラリのドキュメントを見る必要があります。

あなたは長所だけを求めたので、短所はカバーしません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.