Setiap pemimpin opini JS mengatakan bahwa memperluas objek asli adalah praktik yang buruk. Tapi kenapa? Apakah kita mendapatkan kinerja yang baik? Apakah mereka takut seseorang melakukan itu dengan "cara yang salah", dan menambahkan tipe yang dapat dihitung Object, secara praktis menghancurkan semua loop pada objek apa pun?

Ambil TJ Holowaychuk 's should.js misalnya. Dia menambahkan getter sederhana untuk Objectdan semuanya bekerja dengan baik ( sumber ).

Object.defineProperty(Object.prototype, 'should', {
  set: function(){},
  get: function(){
    return new Assertion(Object(this).valueOf());
  },
  configurable: true
});

Ini sangat masuk akal. Misalnya seseorang dapat memperpanjang Array.

Array.defineProperty(Array.prototype, "remove", {
  set: function(){},
  get: function(){
    return removeArrayElement.bind(this);
  }
});
var arr = [0, 1, 2, 3, 4];
arr.remove(3);

Apakah ada argumen yang menentang perluasan tipe asli?

Saat Anda memperluas objek, Anda mengubah perilakunya.

Mengubah perilaku objek yang hanya akan digunakan oleh kode Anda sendiri tidak masalah. Tetapi ketika Anda mengubah perilaku sesuatu yang juga digunakan oleh kode lain ada risiko Anda akan merusak kode lain itu.

Ketika datang menambahkan metode ke objek dan kelas array di javascript, risiko melanggar sesuatu sangat tinggi, karena cara kerja javascript. Pengalaman bertahun-tahun telah mengajarkan saya bahwa hal-hal semacam ini menyebabkan semua jenis bug yang mengerikan di javascript.

Jika Anda memerlukan perilaku khusus, jauh lebih baik untuk mendefinisikan kelas Anda sendiri (mungkin subkelas) daripada mengubah yang asli. Dengan begitu Anda tidak akan merusak apa pun.

Kemampuan untuk mengubah cara kerja kelas tanpa mensubclassing itu adalah fitur penting dari setiap bahasa pemrograman yang baik, tetapi itu adalah salah satu yang harus jarang digunakan dan dengan hati-hati.

Tidak ada kelemahan yang terukur, seperti hit kinerja. Setidaknya tidak ada yang menyebutkan. Jadi ini adalah pertanyaan tentang preferensi dan pengalaman pribadi.

Argumen pro utama: Terlihat lebih baik dan lebih intuitif: sintaksis gula. Ini adalah fungsi spesifik tipe / instance, jadi harus secara spesifik terikat pada tipe / instance tersebut.

Argumen kontra utama: Kode dapat mengganggu. Jika lib A menambahkan fungsi, itu bisa menimpa fungsi lib B. Ini dapat memecahkan kode dengan sangat mudah.

Keduanya ada benarnya. Ketika Anda mengandalkan dua pustaka yang secara langsung mengubah jenis Anda, kemungkinan besar Anda akan berakhir dengan kode yang rusak karena fungsi yang diharapkan mungkin tidak sama. Saya setuju sepenuhnya tentang itu. Perpustakaan makro tidak boleh memanipulasi tipe asli. Kalau tidak, Anda sebagai pengembang tidak akan pernah tahu apa yang sebenarnya terjadi di balik layar.

Dan itulah alasan saya tidak suka lib seperti jQuery, garis bawah, dll. Jangan salah paham; mereka benar-benar diprogram dengan baik dan mereka bekerja seperti pesona, tetapi mereka besar . Anda hanya menggunakan 10% dari mereka, dan mengerti tentang 1%.

Itu sebabnya saya lebih suka pendekatan atomistik , di mana Anda hanya membutuhkan apa yang benar-benar Anda butuhkan. Dengan cara ini, Anda selalu tahu apa yang terjadi. Perpustakaan mikro hanya melakukan apa yang Anda inginkan, sehingga tidak akan mengganggu. Dalam konteks memiliki pengguna akhir yang mengetahui fitur mana yang ditambahkan, memperluas tipe asli dapat dianggap aman.

TL; DR Jika ragu, jangan berikan jenis asli. Hanya perluas jenis asli jika Anda 100% yakin, bahwa pengguna akhir akan mengetahui dan menginginkan perilaku itu. Dalam tidak ada kasus memanipulasi fungsi yang ada jenis pribumi, karena akan mematahkan antarmuka yang ada.

Jika Anda memutuskan untuk memperluas jenisnya, gunakan Object.defineProperty(obj, prop, desc); jika tidak bisa , gunakan jenisnya prototype.

Saya awalnya datang dengan pertanyaan ini karena saya ingin Errordapat dikirim melalui JSON. Jadi, saya perlu cara untuk mengikat mereka. error.stringify()merasa jauh lebih baik daripadaerrorlib.stringify(error) ; seperti saran kedua, saya beroperasi errorlibdan tidak dengan errorsendirinya.

Menurut pendapat saya, ini adalah praktik yang buruk. Alasan utamanya adalah integrasi. Mengutip dokumen should.js:

OMG IT MEMPERPANJANG OBYEK ???!?! @ Ya, ya, dengan satu pengambil harus, dan tidak itu tidak akan merusak kode Anda

Nah, bagaimana penulis bisa tahu? Bagaimana jika kerangka kerja mengejek saya melakukan hal yang sama? Bagaimana jika janji saya melakukan hal yang sama?

Jika Anda melakukannya di proyek Anda sendiri maka tidak apa-apa. Tapi untuk perpustakaan, maka itu desain yang buruk. Underscore.js adalah contoh dari hal yang dilakukan dengan cara yang benar:

var arr = [];
_(arr).flatten()
// or: _.flatten(arr)
// NOT: arr.flatten()

Jika Anda melihatnya berdasarkan kasus per kasus, mungkin beberapa implementasi dapat diterima.

String.prototype.slice = function slice( me ){
  return me;
}; // Definite risk.

Menimpa metode yang sudah dibuat menciptakan lebih banyak masalah daripada yang dipecahkan, itulah sebabnya mengapa hal itu dinyatakan secara umum, dalam banyak bahasa pemrograman, untuk menghindari praktik ini. Bagaimana Devs mengetahui fungsi telah diubah?

String.prototype.capitalize = function capitalize(){
  return this.charAt(0).toUpperCase() + this.slice(1);
}; // A little less risk.

Dalam hal ini kami tidak menimpa metode JS core yang diketahui, tetapi kami memperluas String. Satu argumen dalam posting ini menyebutkan bagaimana pengembang baru mengetahui apakah metode ini adalah bagian dari inti JS, atau di mana menemukan dokumen? Apa yang akan terjadi jika objek JS String inti adalah untuk mendapatkan metode bernama capitalize ?

Bagaimana jika alih-alih menambahkan nama yang mungkin bertabrakan dengan perpustakaan lain, Anda menggunakan pengubah khusus perusahaan / aplikasi yang dapat dipahami semua devs?

String.prototype.weCapitalize = function weCapitalize(){
  return this.charAt(0).toUpperCase() + this.slice(1);
}; // marginal risk.

var myString = "hello to you.";
myString.weCapitalize();
// => Hello to you.

Jika Anda terus memperluas objek lain, semua devs akan menemui mereka di alam liar dengan (dalam hal ini) kami , yang akan memberi tahu mereka bahwa itu adalah ekstensi khusus perusahaan / aplikasi.

Ini tidak menghilangkan tabrakan nama, tetapi mengurangi kemungkinan. Jika Anda menentukan bahwa memperluas objek JS inti adalah untuk Anda dan / atau tim Anda, mungkin ini untuk Anda.

Memperluas prototipe built-in memang ide yang buruk. Namun, ES2015 memperkenalkan teknik baru yang dapat digunakan untuk mendapatkan perilaku yang diinginkan:

Memanfaatkan WeakMaps untuk mengaitkan tipe dengan prototipe bawaan

Implementasi berikut memperluas Numberdan membuat Arrayprototipe tanpa menyentuhnya sama sekali:

// new types

const AddMonoid = {
  empty: () => 0,
  concat: (x, y) => x + y,
};

const ArrayMonoid = {
  empty: () => [],
  concat: (acc, x) => acc.concat(x),
};

const ArrayFold = {
  reduce: xs => xs.reduce(
   type(xs[0]).monoid.concat,
   type(xs[0]).monoid.empty()
)};


// the WeakMap that associates types to prototpyes

types = new WeakMap();

types.set(Number.prototype, {
  monoid: AddMonoid
});

types.set(Array.prototype, {
  monoid: ArrayMonoid,
  fold: ArrayFold
});


// auxiliary helpers to apply functions of the extended prototypes

const genericType = map => o => map.get(o.constructor.prototype);
const type = genericType(types);


// mock data

xs = [1,2,3,4,5];
ys = [[1],[2],[3],[4],[5]];


// and run

console.log("reducing an Array of Numbers:", ArrayFold.reduce(xs) );
console.log("reducing an Array of Arrays:", ArrayFold.reduce(ys) );
console.log("built-ins are unmodified:", Array.prototype.empty);

Seperti yang Anda lihat, prototipe primitif pun dapat diperluas dengan teknik ini. Ini menggunakan struktur peta danObject identitas untuk mengaitkan tipe dengan prototipe bawaan.

Contoh saya mengaktifkan reducefungsi yang hanya mengharapkan Arrayargumen tunggal, karena dapat mengekstrak informasi cara membuat akumulator kosong dan cara menggabungkan elemen dengan akumulator ini dari elemen Array itu sendiri.

Harap dicatat bahwa saya bisa menggunakan Maptipe normal , karena referensi yang lemah tidak masuk akal ketika mereka hanya mewakili prototipe built-in, yang tidak pernah mengumpulkan sampah. Namun, a WeakMaptidak dapat diubah dan tidak dapat diperiksa kecuali Anda memiliki kunci yang tepat. Ini adalah fitur yang diinginkan, karena saya ingin menghindari segala bentuk refleksi.

Satu lagi alasan mengapa Anda tidak perlu memperluas Objek asli:

Kami menggunakan Magento yang menggunakan prototype.js dan memperluas banyak hal pada Object asli. Ini berfungsi dengan baik sampai Anda memutuskan untuk mendapatkan fitur baru dan di situlah masalah besar dimulai.

Kami telah memperkenalkan komponen Web di salah satu halaman kami, jadi webcomponents-lite.js memutuskan untuk mengganti seluruh Objek Acara (asli) di IE (mengapa?). Ini tentu saja memecah prototype.js yang pada gilirannya memecah Magento. (sampai Anda menemukan masalah, Anda dapat menginvestasikan banyak jam untuk melacaknya kembali)

Jika Anda suka masalah, terus lakukan!

Saya dapat melihat tiga alasan untuk tidak melakukan ini (dari dalam aplikasi , setidaknya), hanya dua di antaranya yang dibahas dalam jawaban yang ada di sini:

1. Jika Anda salah melakukannya, Anda akan secara tidak sengaja menambahkan properti enumerable ke semua objek dari tipe yang diperluas. Mudah dikerjakan menggunakanObject.defineProperty , yang menciptakan properti non-enumerable secara default.
2. Anda mungkin menyebabkan konflik dengan perpustakaan yang Anda gunakan. Dapat dihindari dengan tekun; cukup periksa metode apa yang didefinisikan oleh perpustakaan yang Anda gunakan sebelum menambahkan sesuatu ke prototipe, periksa catatan rilis saat meningkatkan, dan uji aplikasi Anda.
3. Anda mungkin menyebabkan konflik dengan versi masa depan dari lingkungan JavaScript asli.

Poin 3 bisa dibilang yang paling penting. Anda dapat memastikan, melalui pengujian, bahwa ekstensi prototipe Anda tidak menyebabkan konflik dengan perpustakaan yang Anda gunakan, karena Anda memutuskan perpustakaan apa yang Anda gunakan. Hal yang sama tidak berlaku untuk objek asli, dengan asumsi kode Anda berjalan di browser. Jika Anda menentukan Array.prototype.swizzle(foo, bar)hari ini, dan besok Google menambahkan Array.prototype.swizzle(bar, foo)ke Chrome, Anda mungkin berakhir dengan beberapa rekan bingung yang bertanya-tanya mengapa.swizzle perilaku tampaknya tidak cocok dengan apa yang didokumentasikan di MDN.

(Lihat juga kisah bagaimana mengutak-atik mootool dengan prototipe yang tidak mereka miliki memaksa metode ES6 diganti namanya untuk menghindari melanggar web .)

Ini dapat dihindari dengan menggunakan awalan khusus aplikasi untuk metode yang ditambahkan ke objek asli (misalnya mendefinisikan Array.prototype.myappSwizzlebukan Array.prototype.swizzle), tapi itu agak jelek; itu hanya dapat dipecahkan dengan menggunakan fungsi utilitas mandiri alih-alih menambah prototipe.

Perf juga merupakan alasan. Terkadang Anda mungkin perlu mengulang tombol. Ada beberapa cara untuk melakukan ini

for (let key in object) { ... }
for (let key in object) { if (object.hasOwnProperty(key) { ... } }
for (let key of Object.keys(object)) { ... }

Saya biasanya menggunakan for of Object.keys()karena melakukan hal yang benar dan relatif singkat, tidak perlu menambahkan cek.

Tapi, ini jauh lebih lambat .

Hanya menebak alasannya Object.keyslambat sudah jelas, Object.keys()harus membuat alokasi. Bahkan AFAIK harus mengalokasikan salinan semua kunci sejak itu.

  const before = Object.keys(object);
  object.newProp = true;
  const after = Object.keys(object);

  before.join('') !== after.join('')

Mungkin saja mesin JS dapat menggunakan beberapa jenis struktur kunci yang tidak dapat diubah sehingga Object.keys(object)mengembalikan sesuatu referensi yang beralih pada kunci yang tidak dapat diubah dan yang object.newPropmenciptakan objek kunci yang sama sekali tidak dapat diubah baru tapi apa pun, itu jelas lebih lambat hingga 15x

Bahkan memeriksa hasOwnPropertyhingga 2x lebih lambat.

Inti dari semua itu adalah bahwa jika Anda memiliki kode sensitif perf dan perlu untuk mengulang kunci maka Anda ingin dapat menggunakan for intanpa harus menelepon hasOwnProperty. Anda hanya dapat melakukan ini jika Anda belum mengubahObject.prototype

Perhatikan bahwa jika Anda menggunakan Object.definePropertyuntuk memodifikasi prototipe jika hal-hal yang Anda tambahkan tidak dapat dihitung maka mereka tidak akan mempengaruhi perilaku JavaScript dalam kasus-kasus di atas. Sayangnya, setidaknya di Chrome 83, mereka mempengaruhi kinerja.

Saya menambahkan 3000 properti non-enumerable hanya untuk mencoba memaksa masalah perf muncul. Dengan hanya 30 properti tes terlalu dekat untuk mengetahui apakah ada dampak perf.

https://jsperf.com/does-adding-non-enumerable-properties-affect-perf

Firefox 77 dan Safari 13.1 tidak menunjukkan perbedaan dalam perf antara kelas Augmented dan Unaugmented mungkin v8 akan diperbaiki di area ini dan Anda dapat mengabaikan masalah perf.

Tapi, izinkan saya juga menambahkan ada kisahnyaArray.prototype.smoosh . Versi singkatnya adalah Mootools, perpustakaan populer, dibuat sendiri Array.prototype.flatten. Ketika komite standar mencoba untuk menambahkan yang asli Array.prototype.flattenmereka menemukan tidak bisa tanpa melanggar banyak situs. Para devs yang mengetahui tentang istirahat menyarankan menamai metode es5 smooshsebagai lelucon tetapi orang-orang panik tidak mengerti itu adalah lelucon. Mereka memilih flatbukannyaflatten

Moral dari cerita ini adalah Anda tidak harus memperluas objek asli. Jika Anda melakukannya, Anda bisa mengalami masalah yang sama tentang kerusakan barang-barang Anda dan kecuali perpustakaan khusus Anda menjadi sepopuler MooTools, vendor peramban tidak mungkin mengatasi masalah yang Anda sebabkan. Jika pustaka Anda menjadi sepopuler itu, itu akan menjadi semacam cara untuk memaksa orang lain mengatasi masalah yang Anda sebabkan. Jadi, tolong jangan Perluas Objek Asli