Việc đóng gói mã Javascript trong các đối tượng có ảnh hưởng đến hiệu suất không?

Question

Tôi tự hỏi nếu nó có hiệu quả hơn hay ít hơn để đóng gói phần chính của mã JavaScript của bạn trong một đối tượng? Bằng cách này, toàn bộ phạm vi của chương trình của bạn sẽ được tách ra khỏi các phạm vi khác như cửa sổ.

Ví dụ, nếu tôi có đoạn mã sau vào một tập tin JavaScript:

/* My main code body. */ 
var somevar1=undefined; 
var somevar2=undefined; 
var somevarN=undefined; 

function somefunction(){}; 

function initialize(){/* Initializes the program. */}; 
/* End main code body. */ 

tôi thay vì có thể gói gọn cơ thể mã chính trong một đối tượng:

/* Encapsulating object. */ 
var application={}; 
application.somevar1=undefined; 
application.somevar2=undefined; 
application.somevarN=undefined; 

application.somefunction=function(){}; 

application.initialize=function(){/* Initializes the program. */}; 

Logic của tôi là vì JavaScript tìm kiếm thông qua tất cả các biến trong một phạm vi cho đến khi tìm thấy đúng, giữ cho các hàm và biến cụ thể của ứng dụng trong phạm vi riêng của chúng sẽ tăng hiệu quả, đặc biệt nếu có nhiều hàm và biến.

Mối quan tâm duy nhất của tôi là thực hành không tốt hoặc có thể điều này sẽ làm tăng thời gian tra cứu các biến và chức năng bên trong phạm vi "ứng dụng" mới. Nếu đây là hành vi xấu hoặc hoàn toàn vô dụng, xin vui lòng cho tôi biết! Cảm ơn bạn!

Answer 1

Tôi không biết ý nghĩa của hiệu suất là gì (tôi nghi ngờ chúng không đáng kể theo cách, nhưng nếu bạn thực sự quan tâm, hãy thử nghiệm nó), nhưng thực tế rất phổ biến trong JavaScript để giữ các đoạn mã trong phạm vi riêng, thay vì có mọi thứ trong phạm vi toàn cầu.

Lợi ích chính là giảm nguy cơ biến ghi đè vô tình trong phạm vi toàn cầu và đặt tên dễ dàng hơn (nghĩa là bạn có window.application.initialize thay vì ví dụ: window.initialize_application).

Thay vì triển khai ở trên, bạn có thể sử dụng các chức năng tự gọi để tạo phạm vi phạm vi chỉ với một bit mã. Điều này được gọi là the module pattern.

này có những lợi thế nhất của việc cho phép bạn tạo ra các biến “private” mà chỉ có thể tiếp cận bên trong mô-đun, và như vậy là không thể truy cập từ mã khác đang chạy trong đối tượng toàn cầu như nhau:

/* Encapsulating object. */ 
var application=(function() { 
    var someprivatevar = null// This can't be accessed by code running outside of this function 
     , someprivatefunction = function() { someprivatevar = someprivatevar || new Date(); }; 

    return { 
     somevar1: undefined 
     , somevar2: undefined 
     , somevarN: undefined 
     , somefunction: function(){} 
     , getInitialized: function() { return someprivatevar; } 
     , initialize: function(){/* Initializes the program. */ someprivatefunction(); } 
    }; 

})(); 

application.initialize(); 
application.getInitialized();// Will always tell you when application was initialized 

Answer 2

tôi nhận ra bạn đã hỏi một câu hỏi có hoặc không. Tuy nhiên, câu trả lời của tôi là không lo lắng về nó, và để trở lại đó, tôi muốn gửi một báo giá từ Eloquent Javascript, bởi Marijn Haverbeke.

Sự tiến thoái lưỡng nan của tốc độ so với sự thanh lịch là một điều thú vị. Bạn có thể xem đây là loại liên tục giữa tính thân thiện với con người và thân thiện với máy. Hầu như bất kỳ chương trình nào cũng có thể được thực hiện nhanh hơn bằng cách làm cho nó lớn hơn và phức tạp hơn. Lập trình viên phải quyết định số dư thích hợp .... Quy tắc cơ bản, được nhiều lập trình viên lặp lại và với mà tôi hết lòng đồng ý, không phải lo lắng về hiệu quả cho đến bạn biết chắc chắn rằng chương trình cũng vậy chậm. Nếu có, hãy tìm hiểu những phần nào đang chiếm nhiều thời gian nhất và bắt đầu trao đổi sự thanh lịch để có hiệu quả trong các bộ phận đó.

Answer 3

Dễ đọc mã là chìa khóa cho vấn đề của tôi ở đây, vì vậy tôi sẽ gắn bó với phương pháp mô-đun ngay cả khi có chuỗi tìm kiếm hơi dài hơn cho các biến và chức năng. Hoặc là phương pháp dường như có ưu và khuyết điểm như nó được.

Một mặt, bạn có phạm vi toàn cầu chứa nhiều biến số ngay từ đầu. Nếu bạn đặt tất cả mã của mình ngay trong phạm vi toàn cục, danh sách các biến của bạn trong phạm vi đó sẽ bao gồm các biến của riêng bạn cũng như các biến như innerWidth và innerHeight. Danh sách để tìm kiếm thông qua khi tham chiếu biến sẽ dài hơn, nhưng tôi tin rằng đây là một lượng nhỏ phí trên không đáng lo ngại.

Mặt khác, bạn chỉ có thể thêm một đối tượng vào phạm vi toàn cục chứa tất cả các biến mà bạn muốn làm việc. Từ bên trong phạm vi này, bạn có thể tham khảo các biến này một cách dễ dàng và tránh tìm kiếm thông qua các biến toàn cục như innerWidth và innerHeight. Con là khi truy cập các biến đóng gói của bạn từ phạm vi toàn cầu, bạn sẽ có một chuỗi tìm kiếm dài hơn như: globalscope.customscope.myvar thay vì globalscope.myvar hoặc chỉ myvar.

Khi tôi nhìn nó theo cách này, nó có vẻ giống như một câu hỏi rất tầm thường. Có lẽ cách tốt nhất để đi về nó là để chỉ đóng gói những thứ đi cùng nhau chỉ vì lợi ích của mã rút gọn và tập trung vào khả năng đọc thay vì có một mớ hỗn độn mã không đọc được mà chỉ hiệu quả hơn một chút.