web-dev-qa-db-ja.com

TypeScriptがキーワード「export」を使用してクラスとインターフェイスを公開するのはなぜですか？

TypeScriptに手を出している間、モジュール内のクラス（名前空間として使用）は、次のようにexportキーワードを記述しない限り、他のクラスでは使用できないことに気付きました。

module some.namespace.here
{
   export class SomeClass{..}
}

そのため、次のように上記のコードを使用できます。

var someVar = new some.namespace.here.SomeClass();

ただし、メソッドまたはプロパティに外部からアクセスできることを示すためにメソッドレベルで使用されるpublicキーワードを単に使用するのではなく、なぜこのキーワードが使用されるのか疑問に思っていました。では、この同じメカニズムを使用して、クラスやインターフェースなどを外部から見えるようにしないのはなぜですか？

これにより、次のようなコードが生成されます。

module some.namespace.here
{
   public class SomeClass{..}
}
typescriptmodulepublicaccess-modifiers
121
Grofit

主な理由は、exportがECMAScriptの計画と一致することです。 「彼らは「パブリック」の代わりに「エクスポート」を使用すべきだったが、「エクスポート/プライベート/保護」が不十分に一致するアクセス修飾子のセットであることを主張すると、これを説明する2つの間に微妙な違いがあると思う。

TypeScriptでは、クラスメンバーをpublicまたはprivateとしてマークしても、生成されたJavaScriptには影響しません。これは、設計/コンパイル時のツールであり、TypeScriptコードがアクセスしてはならないものにアクセスできないようにするために使用できます。

exportキーワードを使用すると、JavaScriptはエクスポートされたアイテムをモジュールに追加する行を追加します。あなたの例では：here.SomeClass = SomeClass;。

したがって、概念的には、publicおよびprivateで制御される可視性は単なるツールであり、exportキーワードは出力を変更します。

159
Fenton

スティーブフェントンの答えに追加するいくつかのこと：

  • exportalreadyは、2つの異なることを意味します（トップレベルかどうかによって異なります）。つまり、3分の1はpublic/privateを追加するよりもおそらく悪いということです。
  • 実装を簡単にすることは絶対にありません。 public対exportの追加された複雑さは簡単です。既に多くのキーワードを変更しました。難しくありません。
  • クラスメンバーのデフォルトの可視性mustは、ES6クラスの提案に合わせて公開する必要があるため、「非公開」を示すキーワードが必要です。 export（unexport ??）に適した反意語がないため、privateが論理的な選択です。 privateを取得したら、publicを対応しないものとして選択しないことはやや狂気になります。
  • 内部モジュールの可視性を変更するためにexportを使用することは、ES6モジュールとの最良の一致です
45
Ryan Cavanaugh