Từ khóa mới của JavaScript có bị coi là có hại không? [đóng cửa]

Trong một câu hỏi khác , một người dùng đã chỉ ra rằng newtừ khóa này rất nguy hiểm khi sử dụng và đề xuất một giải pháp cho việc tạo đối tượng không sử dụng new. Tôi không tin đó là sự thật, chủ yếu là vì tôi đã sử dụng Prototype, Scriptacificent và các thư viện JavaScript tuyệt vời khác và tất cả mọi người trong số họ đã sử dụng newtừ khóa.

Mặc dù vậy, hôm qua tôi đã xem cuộc nói chuyện của Douglas Crockford tại nhà hát YUI và anh ấy đã nói chính xác điều đó, rằng anh ấy đã không sử dụng newtừ khóa nữa trong mã của mình ( Crockford trên JavaScript - Act III: Function the Ultimate - 50:23 phút ).

Có phải là 'xấu' khi sử dụng newtừ khóa? Những lợi thế và bất lợi của việc sử dụng nó là gì?

Crockford đã làm rất nhiều để phổ biến các kỹ thuật JavaScript tốt. Lập trường đầy quan điểm của ông về các yếu tố chính của ngôn ngữ đã gây ra nhiều cuộc thảo luận hữu ích. Điều đó nói rằng, có quá nhiều người coi mỗi lời tuyên bố "xấu" hoặc "có hại" là phúc âm, từ chối nhìn xa hơn ý kiến ​​của một người. Nó có thể là một chút bực bội đôi khi.

Việc sử dụng chức năng được cung cấp bởi newtừ khóa có một số lợi thế so với việc xây dựng từng đối tượng từ đầu:

1. Di truyền nguyên mẫu . Mặc dù thường được xem xét với sự pha trộn giữa sự nghi ngờ và dè bỉu của những người quen với các ngôn ngữ OO dựa trên lớp, kỹ thuật kế thừa tự nhiên của JavaScript là một phương tiện sử dụng lại mã đơn giản và hiệu quả đáng ngạc nhiên. Và từ khóa mới là phương tiện chính (và chỉ có sẵn trên nhiều nền tảng) có nghĩa là sử dụng nó.
2. Hiệu suất. Đây là tác dụng phụ của # 1: nếu tôi muốn thêm 10 phương thức cho mọi đối tượng tôi tạo, tôi có thể viết một hàm tạo tự gán từng phương thức cho từng đối tượng mới ... Hoặc, tôi có thể gán chúng cho chức năng tạo prototypevà sử dụng newđể dập tắt các đối tượng mới. Điều này không chỉ nhanh hơn (không cần mã cho mỗi và mọi phương thức trên nguyên mẫu), nó còn tránh việc tạo bóng cho từng đối tượng với các thuộc tính riêng cho từng phương thức. Trên các máy chậm hơn (hoặc đặc biệt là trình thông dịch JS chậm hơn) khi nhiều đối tượng đang được tạo, điều này có thể có nghĩa là tiết kiệm đáng kể thời gian và bộ nhớ.

Và vâng, newcó một nhược điểm rất quan trọng, được mô tả bằng các câu trả lời khác: nếu bạn quên sử dụng nó, mã của bạn sẽ bị hỏng mà không có cảnh báo. May mắn thay, nhược điểm đó dễ dàng được giảm thiểu - chỉ cần thêm một chút mã vào chính hàm:

function foo()
{
   // if user accidentally omits the new keyword, this will 
   // silently correct the problem...
   if ( !(this instanceof foo) )
      return new foo();

   // constructor logic follows...
}

Bây giờ bạn có thể có những lợi thế của newmà không phải lo lắng về các vấn đề gây ra do vô tình sử dụng sai. Bạn thậm chí có thể thêm một xác nhận vào kiểm tra nếu suy nghĩ về mã bị hỏng âm thầm làm phiền bạn. Hoặc, như một số nhận xét, sử dụng kiểm tra để giới thiệu ngoại lệ thời gian chạy:

if ( !(this instanceof arguments.callee) ) 
   throw new Error("Constructor called as a function");

(Lưu ý rằng đoạn mã này có thể tránh mã hóa cứng tên hàm xây dựng, vì không giống như ví dụ trước, nó không cần phải thực sự khởi tạo đối tượng - do đó, nó có thể được sao chép vào từng hàm mục tiêu mà không cần sửa đổi.)

John Resig đi sâu vào chi tiết về kỹ thuật này trong bài đăng Khởi tạo "Lớp" đơn giản của mình , cũng như bao gồm một phương tiện xây dựng hành vi này vào "các lớp" của bạn theo mặc định. Chắc chắn đáng đọc ... như là cuốn sách sắp ra mắt, Bí mật của Ninja JavaScript , mà thấy ẩn vàng trong việc này và nhiều người khác "có hại" đặc trưng của ngôn ngữ JavaScript (các chương trên withlà đặc biệt soi sáng cho chúng ta những người ban đầu bị sa thải tính năng không phù hợp này như một mánh lới quảng cáo).

Tôi vừa đọc một số phần của cuốn sách Crockfords "Javascript: The Good Parts". Tôi có cảm giác rằng anh ta coi mọi thứ đã từng cắn mình là có hại:

Giới thiệu về chuyển đổi rơi qua:

Tôi không bao giờ cho phép các trường hợp chuyển đổi rơi vào trường hợp tiếp theo. Tôi đã từng tìm thấy một lỗi trong mã của tôi gây ra bởi một sự cố ngoài ý muốn ngay lập tức sau khi đã có một bài phát biểu mạnh mẽ về lý do tại sao rơi qua đôi khi lại hữu ích. (trang 97, ISBN 976-0-596-51774-8)

Giới thiệu về ++ và -

Các toán tử ++ (tăng) và - (giảm) đã được biết là đóng góp cho mã xấu bằng cách khuyến khích sự khéo léo xuất thần. Chúng chỉ đứng thứ hai sau kiến ​​trúc bị lỗi trong việc kích hoạt virus và các mối đe dọa bảo mật khác. (trang 122)

Về mới:

Nếu bạn quên bao gồm tiền tố mới khi gọi hàm xây dựng, thì điều này sẽ không bị ràng buộc với đối tượng mới. Đáng buồn thay, điều này sẽ bị ràng buộc với đối tượng toàn cầu, vì vậy thay vì tăng đối tượng mới của bạn, bạn sẽ ghi đè các biến toàn cục. Điều đó thực sự tồi tệ. Không có cảnh báo biên dịch, và không có cảnh báo thời gian chạy. (trang 49)

Có nhiều hơn, nhưng tôi hy vọng bạn có được hình ảnh.

Câu trả lời của tôi cho câu hỏi của bạn: Không, nó không có hại. nhưng nếu bạn quên sử dụng nó khi bạn cần, bạn có thể gặp một số vấn đề. Nếu bạn đang phát triển trong một môi trường tốt, bạn nhận thấy điều đó.

Cập nhật

Khoảng một năm sau khi câu trả lời này được viết, phiên bản thứ 5 của ECMAScript đã được phát hành, với sự hỗ trợ cho chế độ nghiêm ngặt . Trong chế độ nghiêm ngặt, thiskhông còn bị ràng buộc với đối tượng toàn cầu mà là undefined.

Javascript là ngôn ngữ động có hàng trăm cách để gây rối trong đó ngôn ngữ khác sẽ ngăn bạn.

Tránh một tính năng ngôn ngữ cơ bản như newtrên cơ sở rằng bạn có thể gây rối cũng giống như tháo giày mới sáng bóng của bạn trước khi đi qua một bãi mìn chỉ trong trường hợp bạn có thể khiến đôi giày của mình bị bùn.

Tôi sử dụng một quy ước trong đó các tên hàm bắt đầu bằng một chữ cái viết thường và 'các hàm' thực sự là các định nghĩa lớp bắt đầu bằng một chữ cái viết hoa. Kết quả là một đầu mối trực quan thực sự khá hấp dẫn rằng 'cú pháp' sai: -

var o = MyClass();  // this is clearly wrong.

Trên đầu thói quen đặt tên tốt này giúp. Sau khi tất cả các hàm làm mọi việc và do đó nên có một động từ trong tên của nó trong khi các lớp đại diện cho các đối tượng và là danh từ và tính từ không có động từ.

var o = chair() // Executing chair is daft.
var o = createChair() // makes sense.

Thật thú vị khi cách tô màu cú pháp của SO đã diễn giải đoạn mã trên.

Tôi là người mới sử dụng Javascript nên có lẽ tôi không quá kinh nghiệm trong việc cung cấp một quan điểm tốt cho vấn đề này. Tuy nhiên, tôi muốn chia sẻ quan điểm của tôi về điều "mới" này.

Tôi đến từ thế giới C #, nơi sử dụng từ khóa "mới" rất tự nhiên đến nỗi nó là mẫu thiết kế nhà máy trông rất kỳ lạ đối với tôi.

Khi tôi lần đầu tiên viết mã bằng Javascript, tôi không nhận ra rằng có từ khóa và mã "mới" giống như từ khóa trong mẫu YUI và tôi không mất nhiều thời gian để gặp thảm họa. Tôi mất dấu vết về những gì một dòng cụ thể được cho là sẽ làm khi nhìn lại mã tôi đã viết. Hỗn loạn hơn là tâm trí tôi không thể thực sự chuyển giữa các ranh giới đối tượng khi tôi "chạy khô" mã.

Sau đó, tôi tìm thấy từ khóa "mới" mà theo tôi, nó "tách biệt" mọi thứ. Với từ khóa mới, nó tạo ra mọi thứ. Nếu không có từ khóa mới, tôi biết tôi sẽ không nhầm lẫn nó với việc tạo ra mọi thứ trừ khi chức năng tôi đang gọi cho tôi manh mối mạnh mẽ về điều đó.

Chẳng hạn, với var bar=foo();tôi không có manh mối nào là thanh có thể là gì .... Nó có phải là giá trị trả về hay nó là một đối tượng mới được tạo? Nhưng với var bar = new foo();tôi biết chắc chắn thanh là một đối tượng.

Một trường hợp khác cho cái mới là cái mà tôi gọi là Pooh Coding . Winnie the Pooh theo bụng của mình. Tôi nói đi với ngôn ngữ bạn đang sử dụng, không chống lại nó.

Rất có thể là những người duy trì ngôn ngữ sẽ tối ưu hóa ngôn ngữ cho các thành ngữ mà họ cố gắng khuyến khích. Nếu họ đặt một từ khóa mới vào ngôn ngữ, có lẽ họ nghĩ nó có ý nghĩa rõ ràng khi tạo một thể hiện mới.

Mã được viết theo ý định của ngôn ngữ sẽ tăng hiệu quả với mỗi lần phát hành. Và mã tránh các cấu trúc chính của ngôn ngữ sẽ bị ảnh hưởng theo thời gian.

EDIT: Và điều này vượt xa hiệu suất. Tôi không thể đếm số lần tôi đã nghe (hoặc nói) "tại sao họ lại làm thế ?" khi tìm mã tìm lạ. Nó thường chỉ ra rằng tại thời điểm mã được viết, có một số lý do "tốt" cho nó. Theo Tao của ngôn ngữ là bảo hiểm tốt nhất của bạn vì không có mã của bạn bị chế giễu vài năm kể từ bây giờ.

Tôi đã viết một bài về cách giảm thiểu vấn đề gọi hàm tạo mà không có từ khóa mới.
Nó chủ yếu là mô phạm, nhưng nó cho thấy cách bạn có thể tạo các hàm tạo hoạt động cùng hoặc không newvà không yêu cầu bạn thêm mã soạn sẵn để kiểm tra thistrong mọi hàm tạo.

http://js-bits.blogspot.com/2010/08/constructor-without-USE-new.html

Đây là ý chính của kỹ thuật:

/**
 * Wraps the passed in constructor so it works with
 * or without the new keyword
 * @param {Function} realCtor The constructor function.
 *    Note that this is going to be wrapped
 *    and should not be used directly 
 */
function ctor(realCtor){
  // This is going to be the actual constructor
  return function wrapperCtor(){
    var obj; // object that will be created
    if (this instanceof wrapperCtor) {
      // Called with new
      obj = this;
    } else {
      // Called without new. Create an empty object of the
      // correct type without running that constructor
      surrogateCtor.prototype = wrapperCtor.prototype;
      obj = new surrogateCtor();
    }
    // Call the real constructor function
    realCtor.apply(obj, arguments);
    return obj;
  }

  function surrogateCtor() {}
}

Đây là cách sử dụng nó:

// Create our point constructor
Point = ctor(function(x,y){
  this.x = x;
  this.y = y;
});

// This is good
var pt = new Point(20,30);
// This is OK also
var pt2 = Point(20,30);

Lý do đằng sau không sử dụng từ khóa mới, rất đơn giản:

Bằng cách không sử dụng nó, bạn tránh được cạm bẫy khi vô tình bỏ qua nó. Mẫu xây dựng mà YUI sử dụng, là một ví dụ về cách bạn có thể tránh hoàn toàn từ khóa mới "

var foo = function () {
    var pub= { };
    return pub;
}
var bar = foo();

Ngoài ra, bạn có thể như vậy:

function foo() { }
var bar = new foo();

Nhưng bằng cách đó, bạn sẽ gặp rủi ro khi ai đó quên sử dụng từ khóa mới và điều này toán tử toàn là fubar. AFAIK không có lợi thế để làm điều này (ngoài việc bạn đã quen với nó).

Vào cuối ngày: Đó là về phòng thủ. Bạn có thể sử dụng tuyên bố mới? Đúng. Nó làm cho mã của bạn nguy hiểm hơn? Đúng.

Nếu bạn đã từng viết C ++, thì giống như đặt con trỏ thành NULL sau khi bạn xóa chúng.

Tôi nghĩ "mới" thêm sự rõ ràng vào mã. Và sự rõ ràng là giá trị mọi thứ. Thật tốt khi biết có những cạm bẫy, nhưng tránh chúng bằng cách tránh sự rõ ràng dường như không phải là cách dành cho tôi.

Trường hợp 1: newkhông bắt buộc và nên tránh

var str = new String('asd');  // type: object
var str = String('asd');      // type: string

var num = new Number(12);     // type: object
var num = Number(12);         // type: number

Trường hợp 2: newlà bắt buộc, nếu không bạn sẽ gặp lỗi

new Date().getFullYear();     // correct, returns the current year, i.e. 2010
Date().getFullYear();         // invalid, returns an error

Dưới đây là tóm tắt ngắn gọn nhất mà tôi có thể đưa ra về hai lý lẽ mạnh nhất cho và không sử dụng new toán tử:

Lập luận phải đối new

1. Các hàm được thiết kế để được khởi tạo như các đối tượng sử dụng newtoán tử có thể có các hiệu ứng tai hại nếu chúng được gọi không chính xác như các hàm bình thường. Mã của một hàm trong trường hợp như vậy sẽ được thực thi trong phạm vi mà hàm được gọi, thay vì trong phạm vi của một đối tượng cục bộ như dự định. Điều này có thể khiến các biến và thuộc tính toàn cầu bị ghi đè lên với hậu quả tai hại.
2. Cuối cùng, viết function Func(), sau đó gọi Func.prototype và thêm nội dung vào nó để bạn có thể gọi new Func()để xây dựng đối tượng của mình có vẻ xấu đối với một số lập trình viên, những người muốn sử dụng một kiểu kế thừa đối tượng khác vì lý do kiến ​​trúc và phong cách.

Để biết thêm về lập luận này, hãy xem cuốn sách tuyệt vời và ngắn gọn của Douglas Crockford Javascript: The Good Parts. Trong thực tế, kiểm tra xem nó ra.

Lập luận ủng hộ new

1. Sử dụng newtoán tử cùng với gán nguyên mẫu là nhanh chóng.
2. Những thứ về việc vô tình chạy mã của hàm xây dựng trong không gian tên toàn cục có thể dễ dàng bị ngăn chặn nếu bạn luôn bao gồm một chút mã trong các hàm tạo của bạn để kiểm tra xem chúng có được gọi chính xác không, và trong trường hợp chúng không được gọi , xử lý cuộc gọi phù hợp như mong muốn.

Xem bài đăng của John Resig để biết giải thích đơn giản về kỹ thuật này và để được giải thích sâu hơn về mô hình thừa kế mà ông ủng hộ.

Tôi đồng ý với pez và một số ở đây.

Đối với tôi có vẻ rõ ràng rằng "mới" là việc tạo đối tượng tự mô tả, trong đó mẫu YUI mà Greg Dean mô tả là hoàn toàn bị che khuất .

Khả năng ai đó có thể viết var bar = foo;hoặc var bar = baz();nơi baz không phải là một đối tượng tạo ra phương pháp dường như xa nguy hiểm hơn.

Tôi nghĩ rằng mới là xấu xa, không phải vì nếu bạn quên sử dụng nó do nhầm lẫn, nó có thể gây ra vấn đề mà vì nó làm hỏng chuỗi thừa kế, khiến ngôn ngữ khó hiểu hơn.

JavaScript là hướng đối tượng dựa trên nguyên mẫu. Do đó mọi đối tượng PHẢI được tạo từ một đối tượng khác như vậy var newObj=Object.create(oldObj). Ở đây oldObj được gọi là nguyên mẫu của newObj (do đó "dựa trên nguyên mẫu"). Điều này ngụ ý rằng nếu một tài sản không được tìm thấy trong newObj thì nó sẽ được tìm kiếm trong oldObj . Do đó, newObj theo mặc định sẽ là một đối tượng trống nhưng do chuỗi nguyên mẫu của nó, nó dường như có tất cả các giá trị của oldObj .

Mặt khác, nếu bạn làm thế var newObj=new oldObj(), nguyên mẫu của newObj là oldObj.prototype , rất khó hiểu một cách không cần thiết.

Bí quyết là sử dụng

Object.create=function(proto){
  var F = function(){};
  F.prototype = proto;
  var instance = new F();
  return instance;
};

Chính bên trong chức năng này và chỉ ở đây mới được sử dụng. Sau này chỉ cần sử dụng phương thức Object.create () . Phương pháp giải quyết vấn đề nguyên mẫu.