Mỗi nhà lãnh đạo ý kiến ​​của JS đều nói rằng việc mở rộng các đối tượng bản địa là một thực tiễn tồi. Nhưng tại sao? Chúng ta có nhận được một hit perfomance? Họ có sợ rằng ai đó làm điều đó "sai cách" và thêm vô số loại vào Object, thực tế phá hủy tất cả các vòng trên bất kỳ đối tượng nào không?

Hãy TJ Holowaychuk 's should.js ví dụ. Ông cho biết thêm một getter đơn giản để Objectvà tất cả mọi thứ hoạt động tốt ( nguồn ).

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

Điều này thực sự có ý nghĩa. Ví dụ, người ta có thể mở rộng Array.

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

Có bất kỳ đối số chống lại việc mở rộng các loại bản địa?

Khi bạn mở rộng một đối tượng, bạn thay đổi hành vi của nó.

Thay đổi hành vi của một đối tượng sẽ chỉ được sử dụng bởi mã của riêng bạn là ổn. Nhưng khi bạn thay đổi hành vi của một thứ cũng được sử dụng bởi mã khác, có nguy cơ bạn sẽ phá vỡ mã khác đó.

Khi nói đến việc thêm các phương thức vào các lớp đối tượng và mảng trong javascript, nguy cơ phá vỡ một cái gì đó là rất cao, do cách javascript hoạt động. Kinh nghiệm lâu năm đã dạy tôi rằng loại công cụ này gây ra tất cả các loại lỗi khủng khiếp trong javascript.

Nếu bạn cần hành vi tùy chỉnh, tốt hơn hết là xác định lớp của riêng bạn (có thể là lớp con) thay vì thay đổi lớp gốc. Bằng cách đó bạn sẽ không phá vỡ bất cứ điều gì cả.

Khả năng thay đổi cách một lớp hoạt động mà không cần phân lớp nó là một tính năng quan trọng của bất kỳ ngôn ngữ lập trình tốt nào, nhưng nó là một thứ phải được sử dụng hiếm khi và thận trọng.

Không có nhược điểm có thể đo lường được, như một cú đánh hiệu suất. Ít nhất không ai đề cập đến bất kỳ. Vì vậy, đây là một câu hỏi về sở thích và kinh nghiệm cá nhân.

Đối số pro chính: Nó trông tốt hơn và trực quan hơn: cú pháp đường. Đây là một hàm cụ thể kiểu / thể hiện, vì vậy nó nên được liên kết cụ thể với kiểu / thể hiện đó.

Đối số contra chính: Mã có thể can thiệp. Nếu lib A thêm chức năng, nó có thể ghi đè chức năng của lib B. Điều này có thể phá vỡ mã rất dễ dàng.

Cả hai đều có một điểm. Khi bạn dựa vào hai thư viện thay đổi trực tiếp các loại của mình, rất có thể bạn sẽ kết thúc với mã bị hỏng vì chức năng dự kiến ​​có thể không giống nhau. Tôi hoàn toàn đồng ý về điều đó. Thư viện macro không được thao tác các kiểu gốc. Nếu không, bạn là một nhà phát triển sẽ không bao giờ biết những gì đang thực sự xảy ra đằng sau hậu trường.

Và đó là lý do tôi không thích các lib như jQuery, gạch dưới, v.v. Đừng hiểu sai ý tôi; chúng hoàn toàn được lập trình tốt và chúng hoạt động như một lá bùa, nhưng chúng rất lớn . Bạn chỉ sử dụng 10% trong số họ, và hiểu khoảng 1%.

Đó là lý do tại sao tôi thích cách tiếp cận nguyên tử , nơi bạn chỉ yêu cầu những gì bạn thực sự cần. Bằng cách này, bạn luôn biết những gì xảy ra. Các thư viện vi mô chỉ làm những gì bạn muốn họ làm, vì vậy họ sẽ không can thiệp. Trong bối cảnh có người dùng cuối biết các tính năng nào được thêm vào, việc mở rộng các kiểu gốc có thể được coi là an toàn.

TL; DR Khi nghi ngờ, không mở rộng các loại bản địa. Chỉ mở rộng loại bản địa nếu bạn chắc chắn 100%, rằng người dùng cuối sẽ biết và muốn hành vi đó. Trong mọi trường hợp, thao tác các chức năng hiện có của một kiểu bản địa, vì nó sẽ phá vỡ giao diện hiện có.

Nếu bạn quyết định mở rộng loại, sử dụng Object.defineProperty(obj, prop, desc); nếu bạn không thể , hãy sử dụng loại prototype.

Ban đầu tôi đã đưa ra câu hỏi này vì tôi muốn Errors có thể gửi được qua JSON. Vì vậy, tôi cần một cách để xâu chuỗi chúng. error.stringify()cảm thấy cách tốt hơn errorlib.stringify(error); như cấu trúc thứ hai cho thấy, tôi đang hoạt động errorlibchứ không phải trên errorchính nó.

Theo tôi, đó là một thực tế tồi. Lý do chính là hội nhập. Trích dẫn tài liệu nên.js:

OMG IT EXTENDS MỤC TIÊU ???!?! @ Vâng, đúng vậy, với một getter duy nhất, và không nó sẽ không phá vỡ mã của bạn

Vâng, làm thế nào tác giả có thể biết? Điều gì xảy ra nếu khung mô phỏng của tôi không giống nhau? Điều gì sẽ xảy ra nếu lời hứa của tôi không giống nhau?

Nếu bạn đang làm điều đó trong dự án của riêng bạn thì tốt thôi. Nhưng đối với một thư viện, thì đó là một thiết kế tồi. Underscore.js là một ví dụ về điều được thực hiện đúng cách:

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

Nếu bạn xem xét nó trên cơ sở từng trường hợp, có lẽ một số triển khai được chấp nhận.

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

Ghi đè các phương thức đã tạo tạo ra nhiều vấn đề hơn giải quyết, đó là lý do tại sao nó thường được nêu, trong nhiều ngôn ngữ lập trình, để tránh thực hành này. Làm thế nào là Dev để biết chức năng đã được thay đổi?

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

Trong trường hợp này, chúng tôi không ghi đè bất kỳ phương thức JS cốt lõi nào đã biết, nhưng chúng tôi đang mở rộng Chuỗi. Một đối số trong bài viết này đã đề cập đến việc nhà phát triển mới biết liệu phương thức này là một phần của JS cốt lõi hay tìm tài liệu ở đâu? Điều gì sẽ xảy ra nếu đối tượng Chuỗi JS cốt lõi có được một phương thức có tên là hoa ?

Điều gì sẽ xảy ra nếu thay vì thêm tên có thể xung đột với các thư viện khác, bạn đã sử dụng công cụ sửa đổi cụ thể cho công ty / ứng dụng mà tất cả các nhà phát triển có thể hiểu được?

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.

Nếu bạn tiếp tục mở rộng các đối tượng khác, tất cả các nhà phát triển sẽ gặp họ trong tự nhiên với (trong trường hợp này) , chúng tôi sẽ thông báo cho họ rằng đó là tiện ích mở rộng dành riêng cho công ty / ứng dụng.

Điều này không loại bỏ va chạm tên, nhưng làm giảm khả năng. Nếu bạn xác định rằng việc mở rộng các đối tượng JS cốt lõi là dành cho bạn và / hoặc nhóm của bạn, có lẽ đây là dành cho bạn.

Mở rộng các nguyên mẫu của tích hợp thực sự là một ý tưởng tồi. Tuy nhiên, ES2015 đã giới thiệu một kỹ thuật mới có thể được sử dụng để có được hành vi mong muốn:

Sử dụng WeakMaps để liên kết các loại với các nguyên mẫu tích hợp

Việc thực hiện sau đây mở rộng Numbervà các Arraynguyên mẫu mà không chạm vào chúng:

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

Như bạn có thể thấy các nguyên mẫu nguyên thủy có thể được mở rộng bằng kỹ thuật này. Nó sử dụng cấu trúc bản đồ và Objectdanh tính để liên kết các loại với các nguyên mẫu tích hợp.

Ví dụ của tôi cho phép một reducehàm chỉ mong đợi một Arrayđối số duy nhất của nó, bởi vì nó có thể trích xuất thông tin làm thế nào để tạo một bộ tích lũy trống và cách nối các phần tử với bộ tích lũy này từ chính các phần tử của mảng.

Xin lưu ý rằng tôi có thể đã sử dụng Maploại bình thường , vì các tham chiếu yếu không có ý nghĩa khi chúng chỉ đại diện cho các nguyên mẫu tích hợp, không bao giờ được thu gom rác. Tuy nhiên, WeakMapkhông thể lặp lại và không thể kiểm tra trừ khi bạn có khóa đúng. Đây là một tính năng mong muốn, vì tôi muốn tránh mọi hình thức phản chiếu kiểu.

Thêm một lý do tại sao bạn không nên mở rộng Đối tượng gốc:

Chúng tôi sử dụng Magento sử dụng nguyên mẫu và mở rộng rất nhiều thứ trên các Đối tượng gốc. Điều này hoạt động tốt cho đến khi bạn quyết định nhận các tính năng mới và đó là nơi những rắc rối lớn bắt đầu.

Chúng tôi đã giới thiệu Webcomponents trên một trong các trang của mình, vì vậy, các thành phần web-lite.js quyết định thay thế toàn bộ Đối tượng sự kiện (nguyên gốc) trong IE (tại sao?). Điều này tất nhiên phá vỡ nguyên mẫu.js mà lần lượt phá vỡ Magento. (cho đến khi bạn tìm thấy vấn đề, bạn có thể đầu tư rất nhiều giờ để truy tìm lại)

Nếu bạn thích rắc rối, hãy tiếp tục làm điều đó!

Tôi có thể thấy ba lý do để không làm điều này ( ít nhất là trong một ứng dụng ), chỉ có hai lý do trong các câu trả lời hiện có ở đây:

1. Nếu bạn làm sai, bạn sẽ vô tình thêm một thuộc tính vô số vào tất cả các đối tượng thuộc loại mở rộng. Dễ dàng làm việc xung quanh bằng cách sử dụng Object.defineProperty, tạo ra các thuộc tính không thể đếm được theo mặc định.
2. Bạn có thể gây ra xung đột với thư viện mà bạn đang sử dụng. Có thể tránh được với sự siêng năng; chỉ cần kiểm tra những phương thức mà thư viện bạn sử dụng xác định trước khi thêm một cái gì đó vào nguyên mẫu, kiểm tra ghi chú phát hành khi nâng cấp và kiểm tra ứng dụng của bạn.
3. Bạn có thể gây ra xung đột với phiên bản tương lai của môi trường JavaScript gốc.

Điểm 3 được cho là quan trọng nhất. Bạn có thể đảm bảo, thông qua thử nghiệm, các tiện ích mở rộng nguyên mẫu của bạn không gây ra bất kỳ xung đột nào với các thư viện bạn sử dụng, vì bạn quyết định thư viện nào bạn sử dụng. Điều tương tự cũng không đúng với các đối tượng gốc, giả sử rằng mã của bạn chạy trong trình duyệt. Nếu bạn xác định Array.prototype.swizzle(foo, bar)ngày hôm nay và ngày mai Google sẽ thêm Array.prototype.swizzle(bar, foo)vào Chrome, bạn sẽ có khả năng kết thúc với một số đồng nghiệp bối rối, người tự hỏi tại sao .swizzlehành vi của họ dường như không khớp với những gì được ghi lại trên MDN.

(Xem thêm câu chuyện về cách các mootools nghịch ngợm với các nguyên mẫu mà họ không sở hữu đã buộc phải đổi tên phương thức ES6 để tránh phá vỡ web .)

Điều này có thể tránh được bằng cách sử dụng tiền tố dành riêng cho ứng dụng cho các phương thức được thêm vào đối tượng gốc (ví dụ: xác định Array.prototype.myappSwizzlethay vì Array.prototype.swizzle), nhưng đó là loại xấu xí; nó cũng có thể giải quyết được bằng cách sử dụng các chức năng tiện ích độc lập thay vì tăng các nguyên mẫu.

Perf cũng là một lý do. Đôi khi bạn có thể cần phải lặp qua các phím. có nhiều hướng khác nhau để làm điều đó

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

Tôi thường sử dụng for of Object.keys()vì nó làm đúng và tương đối ngắn gọn, không cần thêm kiểm tra.

Nhưng, nó chậm hơn nhiều .

Chỉ cần đoán lý do Object.keyslà chậm là rõ ràng, Object.keys()phải phân bổ. Trong thực tế AFAIK, nó phải phân bổ một bản sao của tất cả các khóa kể từ đó.

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

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

Có thể công cụ JS có thể sử dụng một số loại cấu trúc khóa bất biến để Object.keys(object)trả về một tham chiếu thứ gì đó lặp lại trên các khóa bất biến và object.newProptạo ra một đối tượng khóa bất biến hoàn toàn mới nhưng dù sao, nó rõ ràng chậm hơn tới 15 lần

Ngay cả việc kiểm tra hasOwnPropertycũng chậm hơn tới 2 lần.

Điểm quan trọng của tất cả đó là nếu bạn có mã nhạy cảm hoàn hảo và cần lặp lại các khóa thì bạn muốn có thể sử dụng for inmà không phải gọi hasOwnProperty. Bạn chỉ có thể làm điều này nếu bạn chưa sửa đổiObject.prototype

lưu ý rằng nếu bạn sử dụng Object.definePropertyđể sửa đổi nguyên mẫu nếu những thứ bạn thêm vào không thể đếm được thì chúng sẽ không ảnh hưởng đến hành vi của JavaScript trong các trường hợp trên. Thật không may, ít nhất là trong Chrome 83, chúng ảnh hưởng đến hiệu suất.

Tôi đã thêm 3000 thuộc tính không thể đếm được chỉ để cố gắng buộc bất kỳ vấn đề hoàn hảo nào xuất hiện. Chỉ với 30 thuộc tính, các thử nghiệm đã quá gần để biết liệu có bất kỳ tác động hoàn hảo nào hay không.

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

Firefox 77 và Safari 13.1 cho thấy không có sự khác biệt về sự hoàn hảo giữa các lớp Augmented và Unaugished có thể v8 sẽ được sửa trong lĩnh vực này và bạn có thể bỏ qua các vấn đề hoàn hảo.

Nhưng, hãy để tôi cũng thêm đó là câu chuyện củaArray.prototype.smoosh . Phiên bản ngắn là Mootools, một thư viện phổ biến, được tạo riêng Array.prototype.flatten. Khi ủy ban tiêu chuẩn cố gắng thêm một người bản địa, Array.prototype.flattenhọ đã tìm thấy không thể phá vỡ nhiều trang web. Các nhà phát triển đã phát hiện ra việc phá vỡ đề nghị đặt tên phương thức es5 smooshlà một trò đùa nhưng mọi người hoảng hốt không hiểu đó là một trò đùa. Họ giải quyết flatthay vìflatten

Đạo đức của câu chuyện là bạn không nên mở rộng các đối tượng bản địa. Nếu bạn làm như vậy, bạn có thể gặp phải vấn đề tương tự về việc phá vỡ nội dung của mình và trừ khi thư viện cụ thể của bạn trở nên phổ biến như MooTools, các nhà cung cấp trình duyệt không có khả năng giải quyết vấn đề bạn gây ra. Nếu thư viện của bạn trở nên phổ biến, đó sẽ là một ý nghĩa để buộc mọi người khác giải quyết vấn đề bạn gây ra. Vì vậy, xin vui lòng không mở rộng đối tượng bản địa