打字稿相当于包范围？

Question

TypeScript 有没有办法允许一个文件访问另一个文件中的方法，但不允许它们全局访问？

用例是有一个包含一些私有方法的大类，这些方法是危险的，不应公开暴露以可能在代码库中的任何地方使用。 我希望能够在另一个文件中编写访问它们的方法，以允许对它们进行逻辑分组，而无需将它们全部放在一个巨大的类中。

理想情况下，像 Java 的包范围之类的东西可以让我声明这两个文件可以访问彼此的危险方法，但不能访问其他任何人。 是否有任何 TypeScript 语言功能允许这样做？

例子：

A 类的方法d1到d100都是危险的，不应全局访问。

B 类具有方法s1到s100 ，这些方法对于项目内的公共使用是安全的。 每个s方法在进行一些安全检查后都会调用d方法。 B 类需要访问所有d方法。

C 类想要调用s方法中的任何一个，并且应该能够，但不应该能够调用任何d方法。

但是，据我了解 Typescript，如果我导出任何d方法以便 B 可以调用它们，那么 C 也可以访问它们。 如果这是 Java，我会将 A 和 B 放在同一个包中并使d方法包作用域。

在 TypeScript 中似乎没有任何相似之处，但是是否有任何东西可以模拟 1) 能够将功能分解为单独的文件但 2) 限制谁可以调用这些方法的目标？

（是的，我知道一旦它被编译成 Javascript，所有的赌注都没有了。目标是只使用 TypeScript 作为静态检查器来在编译时验证合同。）

Answer 1

在 Typescript 中没有直接的方法来强制执行此操作。 根据我的经验，解决此类问题的最佳方法是通过清晰的文档和清晰的命名模式。

如果有不熟练或恶意的开发人员，他们将有多种方法来制造破坏，编译器限制也无济于事。 但是，所有具有合理技能和道德的开发人员都应该能够避免调用内部的、危险的方法。

我的建议是生成某种命名约定。 由于语言限制而公开的所有非 API 方法/属性/字段都应具有相同的前缀或后缀。

例如，我们团队的工作方式如下：

1. 所有非 API 公共方法/属性/字段都以_为前缀。
2. 所有非 API 公共类都以Internal为后缀。
3. 所有非 API 模块都在一个internal文件夹中。 例如- src/models具有 API 的模型模块。 src/models/internal包含非 API 的模型模块。
4. 所有非 API 类都有一个注释，将它们记录为非 API。

此外，我们还没有这样做，但正在考虑创建 tslint 规则来帮助执行这些规则。 我们还没有走得太远，因为我们没有任何开发人员意外使用非 API，但这仍然是一种可能性。

在我看来，适当的命名约定、适当的文档和适当的指导足以解决这个问题，我同意这是 Typescript 语言的局限性。

Answer 2

使用跨文件拆分的命名空间似乎可以很好地实现这一点：
https://www.typescriptlang.org/docs/handbook/namespaces.html#splitting-across-files

与MyNamespace.ts文件中的一样：

namespace MyNamespace {
    export interface Foo {}
}

并且相同的命名空间加上另一个文件中的引用标记：

/// <reference path="MyNamespace.ts" />
namespace MyNamespace {
    export class Bar implements Foo {}
}

Answer 3

我会使用 Rob 提出的方法隐藏危险的方法：将类 A 放在与类 B 相同的文件中。导出类 B，但不导出类 A。这样，类 A 仅对类 B 可见。当然，作为替代方案，您可以创建一个巨大的类，但您对这条路犹豫不决是正确的......

不过你应该小心：TypeScript 会编译为 JavaScript，因此从 JavaScript 的角度来看，每一点不安全的代码都可以用于不需要的用途。

Answer 4

TypeScript 中没有等效的 Java 包范围，但有时确实需要它。 这是我的解决方案：

export class Foo {

    private doSomething(): void {
    //do something
    }
}

interface FooUnlocker {

   doSomething(): void;
}

const foo: Foo = new Foo();
(<FooUnlocker><any>foo).doSomething();

优点 - 需要额外的约定，比如 _doSomething() 等，代码干净，我们有编译检查。

缺点 - 我们需要同步 Foo 和 FooUnlocker。

Node，FooUnlocker 没有被导出，所以它只在模块中可见（如果使用 ES6 模块）。