Apa Keuntungan Metode Getter / Setter VS “Individual”?


12

Inilah yang saya sebut metode pengambil / penyetel "gabungan" (dari 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")

Ini adalah logika yang sama dengan metode (teoretis) yang terpisah:

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

Pertanyaan saya:

Saat mendesain perpustakaan seperti jQuery, mengapa Anda memutuskan untuk memilih rute pertama dan bukan yang kedua? Bukankah pendekatan kedua lebih jelas dan lebih mudah dipahami?


6
Martin Fowler bukan penggemar dari apa yang ia sebut "setter pengambil yang kelebihan beban": martinfowler.com/bliki/OverloadedGetterSetter.html
vaughandroid

1
Saya dulu suka metode get / set split (berpikir itu membuat kode lebih "jelas"), tapi saya menemukan pola pengambil / penyetel overload lebih menarik hari ini. Itu bisa membuat kode lebih bersih. Saya tidak pernah menemukan diri saya menyukai kompromi Pak Fowler. Menurut saya itu adalah yang terburuk dari kedua dunia.
Brian Knoblauch

Satu-satunya argumen nyata Martin Fowler yang menentangnya adalah ketika 'pengambil' meneruskan sebuah argumen, dalam hal ini membingungkan pembaca karena tidak terlihat seperti pengambil. Sampai sekarang, saya telah menyimpulkan bahwa jika Anda tetap pada konvensi bahwa pengambil tidak mengambil argumen, dan setter mengambil satu, bahwa, bersama dengan komentar API yang jelas, pendekatan jQuery / Angular harus baik-baik saja. Untuk sekarang.
zumalifeguard

Jawaban:


13

Murni berspekulasi di sini, tapi saya akan cenderung percaya para pengembang jQuery yang menggunakan banyak gaya fungsional dalam penataan jQuery jelas memiliki kecenderungan ke arah paradigma fungsional.

Mengingat bahwa, dalam paradigma fungsional ada budaya yang kuat untuk mengurangi redundansi, dan bisa dikatakan bahwa pendekatan kedua memiliki redundansi yang tidak perlu. Pendekatan pertama mungkin tidak jelas bagi seseorang yang terbiasa dengan semua bahasa imperatif umum, tetapi itu tidak dapat disangkal melakukan lebih banyak dengan lebih sedikit dengan hanya memiliki satu metode, bukan dua. Ini mungkin berbahaya, tetapi ini adalah alat umum dalam paradigma fungsional dan sesuatu yang dengan cepat terbiasa.

Berlatihlah dalam paradigma fungsional dan Anda dengan cepat mengatasi keinginan menuju upacara dan belajar untuk menghargai kemampuan untuk berbuat lebih banyak dengan lebih sedikit. Meskipun ini merupakan pilihan subjektif berdasarkan preferensi dengan cara yang sama banyak orang memiliki preferensi mengenai manajemen spasi putih. Dengan cara ini saya tidak mengatakan satu cara yang lebih baik, melainkan bahwa mereka adalah hal-hal yang biasa dilakukan orang, yang mungkin mengapa jQuery memiliki pendekatan yang dilakukannya.

Ini akan menjadi mengapa saya percaya para pengembang jQuery melakukan ini dan secara umum mengapa seseorang mungkin mengambil pendekatan ini.


2
Setuju, ditambah saya akan menambahkan keinginan untuk mengurangi ukuran JS sebanyak mungkin.
Matt S

-1 untuk poin imperatif / verbose dan fungsional / implisit.

3
@ MattFenwick Saya tidak bermaksud menyinggung, apakah Anda mengatakan itu tidak benar bahwa paradigma fungsional memiliki kecenderungan ke arah saksi di mana paradigma penting memiliki kecenderungan ke arah saksi? Saya tidak mengatakan salah satu lebih baik, hanya saja seseorang dapat terbiasa dengan yang satu atau yang lain yang akan menyebabkan Anda melakukan hal-hal dengan cara yang secara otomatis berlawanan dengan yang lain (ini berlaku untuk kedua cara yang sama)
Jimmy Hoffa

@ Jimmy tidak masalah; maksud saya adalah bahwa dalam pengalaman saya, saya menemukan bahwa implisit / explicitness bersifat ortogonal terhadap FP / imperatif.

@MattFenwick bisa saja, tapi saya akan mengatakan selain dari inferensi tipe yang memungkinkan banyak tersirat dan umum untuk sistem tipe HM, hal-hal lain yang umum untuk bahasa FP condong ke arah implisit juga seperti semua operator-sebagai-fungsi di mana fungsi tidak memiliki nama eksplisit, hanya simbol yang Anda diharapkan untuk pelajari dan ketahui secara implisit, atau penggunaan umum daftar atau tupel yang membutuhkan pengetahuan implisit tentang makna dan lokasi anggota alih-alih DU (pikirkan tentang cara kerja penulis monad). Saya juga cenderung melihat kesamaan nama parameter satu huruf, tetapi Anda mungkin benar
Jimmy Hoffa

2

Formulir

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

dapat menyiratkan sejumlah hal. Paling umum, ini menyarankan fooobjek, dengan metode yang disebut textmenerima string, yang melakukan sesuatu . Tidak ada implikasi bahwa ini adalah properti sama sekali.

Dalam banyak bahasa, ini dapat dianggap sebagai bentuk disingkat dari

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

di mana hasilnya dibuang. Jadi pendekatan ini terlalu ambigu untuk menjadi cara yang efektif untuk mengatur properti (dari sudut pandang keterbacaan kode).


Ini adalah poin yang sangat bagus! Saya memakai kacamata FP saya ketika saya membaca javascript dan segala sesuatunya terlihat berbeda sehingga saya bahkan tidak memikirkan hal ini, tetapi jika saya melihat kode seperti ini di C #, saya akan mendapatkan reaksi persis yang Anda maksudkan dengan "Bagaimana metode ini dilakukan?" ?? "
Jimmy Hoffa

1

Agak spekulatif, tapi ini kesempatan saya.

jQuery merangkul sepenuhnya sifat fungsional javascript. Itulah yang membuatnya sangat mengagumkan, tetapi bisa membuat banyak pengembang menggaruk-garuk kepala ketika mereka berasal dari bahasa OO yang lebih murni seperti java. Tampaknya melanggar semua konvensi dan praktik yang baik.

Bahasa fungsional cenderung menekankan sintaksis deklaratif. Itu cenderung membaca pernyataan seperti fakta daripada perintah seperti. Contoh

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

yang dapat dibaca sebagai "pelanggan yang memenuhi syarat adalah pelanggan yang usianya di atas 30". Secara konstrast, bahasa imperatif dibaca seperti urutan perintah

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

Itu dapat dibaca sebagai "Periksa setiap pelanggan, dan jika usianya lebih dari 30, tambahkan mereka ke koleksi yang memenuhi syarat"

Menambahkan aa setdan getoperasi akan membuat jQuery terasa seperti perpustakaan wajib. Anda dapat menyusun cara untuk membaca pernyataan berikut

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

Dengan menjaga kata kerja tindakan dari api jQuery, mereka membuatnya terasa seperti API deklaratif. Ini memberikan nuansa fungsional yang konsisten ke perpustakaan. Itu sebabnya saya pikir mereka kelebihan kata kunci.


1

Itu membuatnya berperilaku agak lebih seperti properti , yang baru-baru ini diperkenalkan ke JavaScript, dan karena itu belum banyak digunakan, terutama di perpustakaan seperti jQuery yang dimaksudkan untuk membantu abstrak ketidaksesuaian browser.

Jika Anda pernah melihat definisi kelas yang penuh dengan properti seperti itu, awalan "set" dan "get" terlihat berlebihan, karena penambahan parameter nilai sudah memberitahu Anda itu adalah setter. Martin Fowler membuat poin bagus tentang getter yang memerlukan parameter, tetapi meskipun demikian, dalam konteks itu parameter nilai tambahan dengan jelas menunjukkan setter, serta fakta bahwa setter jarang muncul di sisi kanan penugasan. Dan ketika Anda menulis kode, Anda harus tetap melihat dokumentasi untuk perpustakaan.

Karena Anda hanya meminta keuntungan, saya tidak akan menutupi kekurangannya.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.