糖果杯类比
版本 1：每个糖果一个杯子
假设你写了一些这样的代码：
Mod1.ts
export namespace A {
export class Twix { ... }
}
Mod2.ts
export namespace A {
export class PeanutButterCup { ... }
}
Mod3.ts
export namespace A {
export class KitKat { ... }
}
您已创建此设置：
每个模块（一张纸）都有自己的杯子，命名为A。这是没用的 - 你实际上并没有组织你的糖果，你只是在你和零食之间增加了一个额外的步骤（把它从杯子里拿出来）。
版本 2：全局范围内的一个杯子
如果您不使用模块，您可能会编写这样的代码（注意缺少export 声明）：
global1.ts
namespace A {
export class Twix { ... }
}
global2.ts
namespace A {
export class PeanutButterCup { ... }
}
global3.ts
namespace A {
export class KitKat { ... }
}
这段代码在全局范围内创建了一个合并的命名空间A：
此设置很有用，但不适用于模块（因为模块不会污染全局范围）。
版本 3：无罩杯
回到最初的例子，杯子A、A 和A 对你没有任何好处。相反，您可以将代码编写为：
Mod1.ts
export class Twix { ... }
Mod2.ts
export class PeanutButterCup { ... }
Mod3.ts
export class KitKat { ... }
创建如下所示的图片：
好多了！
现在，如果您仍然在考虑是否真的想在模块中使用命名空间，请继续阅读...
这些不是您要寻找的概念
我们需要回到命名空间最初存在的根源，并检查这些原因是否对外部模块有意义。
组织：命名空间便于将逻辑相关的对象和类型组合在一起。例如，在 C# 中，您将在 System.Collections 中找到所有集合类型。通过将我们的类型组织到分层命名空间中，我们为这些类型的用户提供了良好的“发现”体验。
名称冲突：命名空间对于避免命名冲突很重要。例如，您可能有My.Application.Customer.AddForm 和My.Application.Order.AddForm——这两种类型名称相同，但命名空间不同。在所有标识符都存在于同一根范围内并且所有程序集都加载所有类型的语言中，将所有内容都放在命名空间中至关重要。
这些原因在外部模块中有意义吗？
组织：外部模块必然已经存在于文件系统中。我们必须通过路径和文件名来解决它们，所以有一个逻辑组织方案供我们使用。我们可以有一个/collections/generic/ 文件夹，里面有一个list 模块。
名称冲突：这根本不适用于外部模块。 在一个模块内，没有合理的理由让两个对象具有相同的名称。从消费端来看，任何给定模块的consumer 都可以选择他们将用来引用该模块的名称，因此不可能发生意外的命名冲突。
即使您不相信这些原因可以通过模块的工作方式充分解决，尝试在外部模块中使用命名空间的“解决方案”甚至不起作用。
盒中盒盒中盒
一个故事：
你的朋友鲍勃给你打电话。 “我家里有一个很棒的新组织计划”，他说，“来看看吧！”。没关系，我们去看看 Bob 想出了什么。
你从厨房开始，打开储藏室。有 60 个不同的盒子，每个盒子都标有“Pantry”。你随机选择一个盒子并打开它。里面是一个标有“谷物”的盒子。您打开“谷物”框，找到一个标有“意大利面”的框。打开“Pasta”框，找到一个标有“Penne”的框。你打开这个盒子，正如你所料，发现了一袋通心粉。
有点困惑，你拿起一个相邻的盒子，也标有“Pantry”。里面是一个盒子，同样标有“谷物”。打开“Grains”框，再次找到一个标有“Pasta”的框。你打开“Pasta”盒子，找到一个盒子，这个盒子标有“Rigatoni”。打开这个盒子，你会发现……一袋通心粉。
“太棒了！”鲍勃说。 “一切都在一个命名空间中！”。
“但是鲍勃……”你回答。 “你的组织计划没用。你必须打开一堆盒子才能找到任何东西，实际上找到任何东西并不比你把所有东西都放在一个盒子里而不是三个。事实上，既然你的储藏室已经按架子分类了，你根本不需要盒子。为什么不把意大利面放在架子上，当你需要的时候拿起它吗？”
“你不明白——我需要确保没有其他人放置不属于‘Pantry’命名空间的东西。而且我已经将我所有的意大利面安全地组织到 Pantry.Grains.Pasta 命名空间中，所以我很容易找到它”
鲍勃是个很困惑的人。
模块是他们自己的盒子
您可能在现实生活中发生过类似的事情：您在亚马逊上订购了一些东西，每件商品都出现在自己的盒子里，里面有一个较小的盒子，您的商品用自己的包装包裹着。即使内箱相似，货物也不能有效地“组合”。
与盒子类比，关键观察是外部模块是它们自己的盒子。它可能是一个具有很多功能的非常复杂的项目，但任何给定的外部模块都是它自己的盒子。
外部模块指南
既然我们已经弄清楚我们不需要使用“命名空间”，那么我们应该如何组织我们的模块？以下是一些指导原则和示例。
尽可能接近顶层导出
- 如果您只导出单个类或函数，请使用
export default：
MyClass.ts
export default class SomeType {
constructor() { ... }
}
MyFunc.ts
function getThing() { return 'thing'; }
export default getThing;
消费
import t from './MyClass';
import f from './MyFunc';
var x = new t();
console.log(f());
这对消费者来说是最佳选择。他们可以随意命名您的类型（在这种情况下为t），并且不必做任何无关的点来查找您的对象。
MyThings.ts
export class SomeType { ... }
export function someFunc() { ... }
消费
import * as m from './MyThings';
var x = new m.SomeType();
var y = m.someFunc();
- 如果你要导出大量的东西，那么你才应该使用
module/namespace 关键字：
MyLargeModule.ts
export namespace Animals {
export class Dog { ... }
export class Cat { ... }
}
export namespace Plants {
export class Tree { ... }
}
消费
import { Animals, Plants} from './MyLargeModule';
var x = new Animals.Dog();
危险信号
以下所有内容都是模块结构的危险信号。如果其中任何一个适用于您的文件，请仔细检查您是否没有尝试命名您的外部模块：
- 唯一顶级声明为
export module Foo { ... } 的文件（删除 Foo 并将所有内容“向上”移动一个级别）
- 具有单个
export class 或export function 而不是export default 的文件
- 在顶层具有相同
export module Foo { 的多个文件（不要认为这些文件会合并为一个Foo！）