2012-05-16 40 views
7

Tôi đã nghiên cứu để đưa ra một phong cách mã hóa Javascript chuẩn hóa cho nhóm của mình. Hầu hết các tài nguyên hiện đều đề xuất mẫu "Mô-đun" có liên quan đến việc đóng cửa, chẳng hạn như:Lợi ích của Mô-đun Mô-đun Javascript là gì?

var Module = function() { 

    someMethod = function() { /* ... */ }; 

    return { 
     someMethod: someMethod 
    }; 

}(); 

và gọi nó như Module.someMethod();. Cách tiếp cận này dường như chỉ hoạt động với các phương thức tĩnh trong ngữ cảnh OOP truyền thống, ví dụ các lớp lưu trữ để tìm nạp/lưu dữ liệu, các lớp dịch vụ để thực hiện các yêu cầu bên ngoài và tương tự. Trừ khi tôi bỏ lỡ một cái gì đó, mô hình mô-đun không có ý định được sử dụng với các lớp dữ liệu (nghĩ DTO) mà thường sẽ cần phải được chuyển đến/từ các phương thức dịch vụ đến mã keo UI.

Một lợi ích chung tôi thấy trích dẫn là bạn có thể có phương pháp tin đúng và các lĩnh vực trong Javascript với kiểu mô-đun, nhưng điều này cũng có thể đạt được cùng với việc có thể có tĩnh hay phương pháp dụ với " kiểu "kiểu Javascript cổ điển" tương tự như thế này:

myClass = function(param) { 
    // this is completely public 
    this.publicProperty = 'Foo'; 

    // this is completely private 
    var privateProp = param; 

    // this function can access the private fields 
    // AND can be called publicly; best of both? 
    this.someMethod = function() { 
     return privateProp; 
    }; 

    // this function is private. FOR INTERNAL USE ONLY 
    function privateMethod() { 
     /* ... */ 
    }; 
} 

// this method is static and doesn't require an instance 
myClass.staticMethod = function() { /* ... */ }; 

// this method requires an instance and is the "public API" 
myClass.prototype.instanceMethod = function() { /* ... */ }; 

Vì vậy, tôi đoán câu hỏi của tôi là điều làm cho Mô hình mô-đun tốt hơn kiểu truyền thống? Đó là một chút sạch hơn, nhưng đó dường như là lợi ích duy nhất mà là rõ ràng ngay lập tức; trên thực tế, phong cách truyền thống dường như cung cấp khả năng cung cấp đóng gói thực sự (tương tự như các ngôn ngữ OOP thực như Java hoặc C#) thay vì chỉ đơn giản trả về một tập hợp các phương thức tĩnh.

Có điều gì tôi thiếu không?

+0

Mô-đun mô-đun có thể được sử dụng để tạo mẫu thử cũng như: 'var Module = function() { function Module() {}; Module.prototype.whatever = function() {}; return Module }(); ' –

+1

Nếu bạn định nghĩa một singleton, nó không quan trọng cho dù bạn sử dụng phương pháp tĩnh hay dụ. Trong thực tế, tôi sẽ thích phiên bản tĩnh kể từ đó tôi không phải lo lắng về việc rối tung lên "điều này" khi sử dụng các chức năng của các chức năng trong một cuộc gọi lại. – hugomg

Trả lời

1

Một lợi ích khác mà bạn quên đề cập đến mẫu mô-đun, là nó khuyến khích ít lộn xộn hơn trong không gian tên chung, tức là, những gì mọi người đề cập khi họ nói "không gây ô nhiễm không gian tên chung". Chắc chắn bạn có thể làm điều đó theo cách tiếp cận cổ điển của bạn, nhưng có vẻ như việc tạo ra các đối tượng bên ngoài các hàm ẩn danh sẽ cho vay dễ dàng hơn để tạo ra các đối tượng đó trong không gian tên chung.

Nói cách khác, mẫu mô-đun quảng bá mã tự chứa. Một mô-đun thường sẽ đẩy một đối tượng vào không gian tên chung và tất cả tương tác với mô-đun sẽ đi qua đối tượng này. Nó giống như một phương pháp "chính".

Ít lộn xộn trong không gian tên chung là tốt, bởi vì nó làm giảm cơ hội va chạm với các khung công tác khác và mã javascript.

1

Pattern Mô-đun có thể được sử dụng để tạo ra nguyên mẫu cũng xem:

var Module = function() { 
    function Module() {}; 
    Module.prototype.whatever = function() {}; 
    return Module 
}(); 
var m = new Module(); 
m.whatever(); 

Như các poster khác nói không gian tên toàn cầu sạch là lý do cho nó. Tuy nhiên, một cách khác để đạt được điều này là sử dụng mẫu AMD, nó cũng giải quyết các vấn đề khác như quản lý sự phụ thuộc. Nó cũng kết thúc tốt đẹp mọi thứ trong việc đóng cửa các loại. Đây là một số tuyệt đối Introduction to AMD viết tắt của Định nghĩa Mô-đun Không đồng bộ.

Tôi cũng khuyên bạn nên đọc JavaScript Patterns vì nó bao gồm kỹ lưỡng các lý do cho các mẫu mô-đun khác nhau.

2

Mẫu mô-đun ở trên là vô nghĩa. Tất cả những gì bạn đang làm là sử dụng một đóng để trả về một hàm tạo với nguyên mẫu. Bạn có thể đạt được điều tương tự với:

function Module() {}; 
Module.prototype.whatever = function() {}; 

var m = new Module(); 
m.whatever(); 

Thực tế bạn đã lưu một đối tượng (đóng) từ cùng một đầu ra.

Thịt bò khác của tôi với mô-đun mô-đun là nếu bạn đang sử dụng nó để đóng gói riêng, bạn chỉ có thể sử dụng nó dễ dàng với các lớp đơn và không phải lớp bê tông. Để tạo ra các lớp cụ thể với dữ liệu riêng tư, bạn kết thúc gói hai closers, mà sẽ xấu xí. Tôi cũng đồng ý rằng việc có thể gỡ lỗi các thuộc tính giả dưới dạng riêng tư sẽ dễ dàng hơn nhiều khi chúng hiển thị. Toàn bộ khái niệm "nếu ai đó sử dụng lớp của bạn không chính xác" thì không bao giờ được biện minh. Tạo một API công khai rõ ràng, ghi lại nó và nếu mọi người không tuân theo đúng, thì bạn có một lập trình viên kém trong nhóm của bạn. Lượng nỗ lực cần thiết trong Javascript để ẩn các biến (có thể được phát hiện bằng eval trong Firefox) không đáng để sử dụng JS điển hình, ngay cả đối với các dự án trung bình đến lớn. Mọi người không rình mò xung quanh các đối tượng của bạn để tìm hiểu chúng, họ đọc tài liệu của bạn. Nếu tài liệu của bạn tốt (ví dụ bằng cách sử dụng JSDoc) thì chúng sẽ dính vào nó, giống như chúng ta sử dụng mọi thư viện của bên thứ ba mà chúng ta cần. Chúng tôi không "làm xáo trộn" với jQuery hoặc YUI, chúng tôi chỉ tin tưởng và sử dụng API công khai mà không cần quan tâm quá nhiều đến mức độ hoặc cách sử dụng của nó bên dưới.

Các vấn đề liên quan