Tương tự Cup kẹo
Phiên bản 1: Một cốc cho mỗi viên kẹo
Giả sử bạn đã viết một số mã như thế này:
Mod1.ts
export namespace A {
export class Twix { ... }
}
Mod2.ts
export namespace A {
export class PeanutButterCup { ... }
}
Mod3.ts
export namespace A {
export class KitKat { ... }
}
Bạn đã tạo thiết lập này:
Mỗi mô-đun (tờ giấy) được đặt tên riêng của nóA
. Điều này là vô ích - bạn không thực sự tổ chức kẹo của mình ở đây, bạn chỉ cần thêm một bước bổ sung (lấy nó ra khỏi cốc) giữa bạn và các món ăn.
Phiên bản 2: Một cốc trong phạm vi toàn cầu
Nếu bạn không sử dụng các mô-đun, bạn có thể viết mã như thế này (lưu ý thiếu export
khai báo):
toàn cầu1.ts
namespace A {
export class Twix { ... }
}
toàn cầu2.ts
namespace A {
export class PeanutButterCup { ... }
}
toàn cầu3.ts
namespace A {
export class KitKat { ... }
}
Mã này tạo ra một không gian tên được hợp nhất A
trong phạm vi toàn cầu:
Thiết lập này hữu ích, nhưng không áp dụng trong trường hợp mô-đun (vì mô-đun không gây ô nhiễm phạm vi toàn cầu).
Phiên bản 3: Không ly
Trở lại với ví dụ ban đầu, những chiếc tách A
, A
và A
không làm bạn bất kỳ ưu đãi. Thay vào đó, bạn có thể viết mã dưới dạng:
Mod1.ts
export class Twix { ... }
Mod2.ts
export class PeanutButterCup { ... }
Mod3.ts
export class KitKat { ... }
để tạo ra một hình ảnh như thế này:
Tốt hơn nhiều!
Bây giờ, nếu bạn vẫn đang suy nghĩ về mức độ bạn thực sự muốn sử dụng không gian tên với các mô-đun của mình, hãy đọc tiếp ...
Đây không phải là những khái niệm bạn đang tìm kiếm
Chúng ta cần quay trở lại nguồn gốc tại sao không gian tên tồn tại ở nơi đầu tiên và kiểm tra xem những lý do đó có hợp lý với các mô-đun bên ngoài hay không.
Tổ chức : Không gian tên thuận tiện cho việc nhóm các đối tượng và loại liên quan đến logic. Ví dụ: trong C #, bạn sẽ tìm thấy tất cả các loại bộ sưu tập trong System.Collections
. Bằng cách tổ chức các loại của chúng tôi thành các không gian tên phân cấp, chúng tôi cung cấp trải nghiệm "khám phá" tốt cho người dùng của các loại đó.
Xung đột tên: Không gian tên là quan trọng để tránh xung đột đặt tên. Ví dụ: bạn có thể có My.Application.Customer.AddForm
và My.Application.Order.AddForm
- hai loại có cùng tên, nhưng không gian tên khác nhau. Trong một ngôn ngữ mà tất cả các mã định danh tồn tại trong cùng một phạm vi gốc và tất cả các hội đồng tải tất cả các loại, điều quan trọng là phải có mọi thứ trong một không gian tên.
Những lý do đó có ý nghĩa trong các mô-đun bên ngoài?
Tổ chức : Các mô-đun bên ngoài đã có mặt trong một hệ thống tệp, nhất thiết phải có. Chúng tôi phải giải quyết chúng bằng đường dẫn và tên tệp, vì vậy có một sơ đồ tổ chức hợp lý để chúng tôi sử dụng. Chúng ta có thể có một /collections/generic/
thư mục với một list
mô-đun trong đó.
Xung đột tên : Điều này hoàn toàn không áp dụng trong các mô-đun bên ngoài. Trong một mô-đun, không có lý do chính đáng để có hai đối tượng có cùng tên. Từ phía tiêu thụ, người tiêu dùng của bất kỳ mô-đun cụ thể nào sẽ chọn tên mà họ sẽ sử dụng để đề cập đến mô-đun, vì vậy xung đột đặt tên ngẫu nhiên là không thể.
Ngay cả khi bạn không tin rằng những lý do đó được giải quyết thỏa đáng bằng cách các mô-đun hoạt động, "giải pháp" cố gắng sử dụng không gian tên trong các mô-đun bên ngoài thậm chí không hoạt động.
Hộp trong hộp trong hộp
Một câu chuyện:
Bob bạn của bạn gọi bạn lên. "Tôi có một kế hoạch tổ chức mới tuyệt vời trong nhà của mình", anh nói, "hãy kiểm tra xem!". Không, chúng ta hãy xem những gì Bob đã đưa ra.
Bạn bắt đầu vào bếp và mở tủ đựng thức ăn. Có 60 hộp khác nhau, mỗi hộp được dán nhãn "Phòng đựng thức ăn". Bạn chọn một hộp ngẫu nhiên và mở nó. Bên trong là một hộp duy nhất có nhãn "Ngũ cốc". Bạn mở hộp "Ngũ cốc" và tìm một hộp có nhãn "Pasta". Bạn mở hộp "Pasta" và tìm thấy một hộp có nhãn "Penne". Bạn mở hộp này và tìm thấy, như bạn mong đợi, một túi mì ống penne.
Hơi bối rối, bạn nhặt một hộp liền kề, cũng được dán nhãn "Phòng đựng thức ăn". Bên trong là một hộp duy nhất, một lần nữa được dán nhãn "Ngũ cốc". Bạn mở hộp "Ngũ cốc" và, một lần nữa, tìm một hộp duy nhất có nhãn "Pasta". Bạn mở hộp "Pasta" và tìm thấy một hộp duy nhất, hộp này được dán nhãn "Rigatoni". Bạn mở cái hộp này và tìm ... một túi mì ống cứng.
"Thật tuyệt vời!" Bob nói. "Mọi thứ đều trong một không gian tên!".
"Nhưng Bob ..." bạn trả lời. "Sơ đồ tổ chức của bạn là vô ích. Bạn phải mở ra một loạt các hộp để lấy bất cứ thứ gì, và thực sự không có gì thuận tiện hơn để tìm thấy bất cứ thứ gì hơn là nếu bạn chỉ đặt mọi thứ vào một hộp thay vì ba . Thực tế, vì bạn phòng đựng thức ăn đã được sắp xếp theo từng kệ, bạn hoàn toàn không cần các hộp. Tại sao không đặt mì ống lên kệ và lấy nó khi bạn cần? "
"Bạn không hiểu - Tôi cần đảm bảo rằng không ai khác đặt thứ gì đó không thuộc về không gian tên 'Pantry'. Và tôi đã sắp xếp an toàn tất cả mì ống của mình vào Pantry.Grains.Pasta
không gian tên để tôi có thể dễ dàng tìm thấy nó"
Bob là một người đàn ông rất bối rối.
Các mô-đun là hộp riêng của họ
Bạn có thể đã có một điều tương tự xảy ra trong cuộc sống thực: Bạn đặt mua một vài thứ trên Amazon và mỗi mặt hàng xuất hiện trong hộp riêng của nó, với một hộp nhỏ hơn bên trong, với mặt hàng của bạn được bọc trong bao bì riêng. Ngay cả khi các hộp bên trong tương tự nhau, các lô hàng không được "kết hợp" một cách hữu ích.
Đi cùng với sự tương tự hộp, quan sát chính là các mô-đun bên ngoài là hộp riêng của chúng . Nó có thể là một mục rất phức tạp với nhiều chức năng, nhưng bất kỳ mô-đun bên ngoài nào cũng là hộp riêng của nó.
Hướng dẫn cho các mô-đun bên ngoài
Bây giờ chúng tôi đã nhận ra rằng chúng tôi không cần phải sử dụng 'không gian tên', chúng tôi nên tổ chức các mô-đun như thế nào? Một số nguyên tắc hướng dẫn và ví dụ sau đây.
Xuất càng gần cấp cao nhất càng tốt
- Nếu bạn chỉ xuất một lớp hoặc hàm duy nhất, hãy sử dụng
export default
:
MyClass.ts
export default class SomeType {
constructor() { ... }
}
MyFunc.ts
function getThing() { return 'thing'; }
export default getThing;
Tiêu dùng
import t from './MyClass';
import f from './MyFunc';
var x = new t();
console.log(f());
Điều này là tối ưu cho người tiêu dùng. Họ có thể đặt tên cho loại của bạn bất cứ điều gì họ muốn ( t
trong trường hợp này) và không phải thực hiện bất kỳ việc rải rác ngoại lai nào để tìm đối tượng của bạn.
- Nếu bạn đang xuất nhiều đối tượng, hãy đặt tất cả chúng ở cấp cao nhất:
MyThings.ts
export class SomeType { ... }
export function someFunc() { ... }
Tiêu dùng
import * as m from './MyThings';
var x = new m.SomeType();
var y = m.someFunc();
- Nếu bạn đang xuất một số lượng lớn các thứ, chỉ sau đó bạn nên sử dụng
module
/ namespace
từ khóa:
MyLargeModule.ts
export namespace Animals {
export class Dog { ... }
export class Cat { ... }
}
export namespace Plants {
export class Tree { ... }
}
Tiêu dùng
import { Animals, Plants} from './MyLargeModule';
var x = new Animals.Dog();
Cờ đỏ
Tất cả những điều sau đây là cờ đỏ cho cấu trúc mô-đun. Kiểm tra kỹ xem bạn không cố gắng đặt tên cho các mô-đun bên ngoài nếu bất kỳ điều nào trong số này áp dụng cho các tệp của bạn:
- Một tệp chỉ có khai báo cấp cao nhất là
export module Foo { ... }
(xóa Foo
và di chuyển mọi thứ 'lên' một cấp)
- Một tập tin có một
export class
hoặc export function
khôngexport default
- Nhiều tệp có cùng
export module Foo {
mức ở cấp cao nhất (đừng nghĩ rằng những tệp này sẽ kết hợp thành một Foo
!)