Typescript: 静的メソッドを定義するためのサポートインターフェースを追加する

これで何を達成したいですか？ シナリオについて詳しく説明していただけますか？

abstractクラスがあなたが探しているものだと思います。

@mhegazy
例：

interface JsonSerializable {
      public static fromJson(obj: any);
      public toJson(): string;
}

@rozzzlyこの例では、 abstract classは無効です。

これはかなりクールだと思います！ Javaは、前回のバージョンでこの機能を追加しました。

@Serginho
私はあなたがこれを面白いと思うかもしれないと思います：

interface JsonSerializableStatic<C extends new (...args) => JsonSerializable<C>> {
  fromJson(json: string): JsonSerializable<C>;
}

interface JsonSerializable<C extends new (...args) => any> {
  toJson: () => string;
  constructor: C;
}

interface A extends JsonSerializable<typeof A> { }
class A implements JsonSerializable<typeof A> {

  constructor(readonly id: number, readonly name: string) { }
  toJson() { return JSON.stringify(this); }

  static fromJson(json: string): A {
    const obj = JSON.parse(json);
    return new A(obj.id, obj.name);
  }
}

const a = new A(1, 'Charlize');

const json = a.toJson();

const y = A.fromJson(json);
console.info(a, json, y);
console.info(new a.constructor(1, 'Theron'));
const m = new A.prototype.constructor(1, 'Charlize Theron');
console.info(m);

@aluanhaddadあなたのコードは明らかな何かの回避策だと思います。

interface JsonSerializable {
      public static fromJson(obj: any);
      public toJson(): string;
}

どちらがよりはっきりと見えますか？

@aluanhaddadあなたのコードは明らかな何かの回避策だと思います。

インターフェイスJsonSerializable {
public static fromJson（obj：any）;
public toJson（）：文字列;
}
どちらがよりはっきりと見えますか？

確かに、しかし私のものは回避策ではありません、それはあなたのユースケースの正当化です。 静的な逆シリアル化とインスタンスのシリアル化をクラスごとに実装し、それによってカプセル化してタイプセーフにします。
あなたの宣言：

interface JsonSerializable {
     public static fromJson(obj: any);
     public toJson(): string;
}

基本的にJSONオブジェクトのインターフェースを再宣言するため、は無関係です。 これには、静的インターフェイスメソッドはまったく必要ありません。

あなたはインターフェースの概念を失っています。 class A implements JsonSerializableを使用すると、両方のメソッドを実装できます。 しかし、実際には私に実装させます：

toJson: () => string;
constructor: new (...args) => JsonSerializableStatic<C>;

それは明確な解決策ではありません。

インターフェイスで静的メソッドを定義できないようにする技術的な理由はありません。

@Serginho私は状況が理想的であると主張しているのではありません。 私はそれが表現できることを説明しようとしていました。

@aluanhaddadさあ！ 心を開いてください。 typescriptはインターフェイスで静的メソッドを許可する必要があると思いますか？ これは前回のバージョンのJava8で実装されていたので、ナンセンスな話ではないと思います。

@SerginhoTypeScriptには特に適しているとは思いません。 インターフェイスは、オブジェクトが提供する機能を定義する必要があります。 この機能は、オーバーライド可能で交換可能である必要があります（そのため、インターフェイスメソッドは仮想です）。 静的は、動的な動作/仮想メソッドと並行する概念です。 この2つを織り交ぜることは、デザインの観点からは正しく感じられません。

@aluanhaddadがすでに書いたように、TypeScriptには、実際には、あなたが望むものを表現するメカニズムがすでにあります。 大きな違いは、この場合、クラスをオブジェクトとして扱い、論理的に一貫していることです。 私の見解では、クラスは一種のハック/二級市民であるため、あなたが提案するアプローチはTypeScript（およびJavaScript開発）には特に適していません。 現在普及しているパターンは、厳密なクラスではなく、ダックタイピング/シェイププログラミングに依存しています。

おそらく、あなたも心を開いて、さまざまなスタイルのプログラミングを試すことができます。 世界はOOPで始まりも終わりもありません。 関数、プレーンオブジェクト、および（ある程度）プロトタイプを使用したプログラミングは、楽しく、さらに優れている場合があります。 このようなスタイルは、JavaScriptが最初に設計された目的とはるかに一致しています。 ちなみに、JSは（少なくとも委員会レベルでは）OOP風のパターンにゆっくりと移行していることに同意しますが、それは、さまざまなプログラミングパラダイムや開発手法に慣れていない人々の大きなプッシュによるものです。 私にとって、それは深く悲しくてがっかりすることです。

@gcnewが言ったように、インターフェースはクラスではなく、個々のオブジェクトの形状を記述します。 ただし、クラスもオブジェクトであるため、インターフェイスを使用してクラス自体の形状を記述できない理由はありません。

import assert = require("assert");

interface JsonSerializableStatic<JsonType, InstanceType extends JsonSerializable<JsonType>> {
    fromJson(obj: JsonType): InstanceType;
}
interface JsonSerializable<JsonType> {
    toJson(): JsonType;
}

interface PointJson { x: number; y: number; }
class Point /*static implements JsonSerializableStatic<PointJson, Point>*/ {
    static fromJson(obj: PointJson): Point {
        return new Point(obj.x, obj.y)
    }

    constructor(readonly x: number, readonly y: number) {}

    toJson(): PointJson {
        return { x: this.x, y: this.y };
    }
}
// Hack for 'static implements'
const _: JsonSerializableStatic<PointJson, Point> = Point;

function testSerialization<JsonType, InstanceType extends JsonSerializable<JsonType>>(cls: JsonSerializableStatic<JsonType, InstanceType>, json: JsonType) {
    const instance: InstanceType = cls.fromJson(json);
    const outJson: JsonType = instance.toJson();
    assert.deepEqual(json, outJson);
}
testSerialization(Point, { x: 1, y: 2 });

toJsonまたはfromJsonのいずれかの署名を満たさない場合、コンパイルエラーが発生します。 （残念ながら、エラーはメソッドではなくconst _ます。）

おそらく関連している（静的メソッドの入力を扱っているため）：＃5863。

@aluanhaddad ：あなたの例には間違いがあります： JsonSerializableのconstructorメンバーは、実際にはconstructorというインスタンスプロパティを参照します。これは、 new呼び出されるとJsonSerializableStatic返します。 つまり、 (new ((new X()).constructor)).fromJson({})が機能する必要があるということです。 正常にコンパイルされる理由は、 interface A extends JsonSerializable<typeof A> 、実際にチェックせずに実装が有効であると宣言しているためです。 たとえば、これはエラーなしでコンパイルされます。

interface I { m(): void; }
interface A extends I { }
// No compile error
class A implements I { em() {} }

@Serginho Javaユーザーではありませんが、言語でクラスの静的側のインターフェイスを定義できるようには見えません（つまり、インターフェイスを実装するクラスは、準拠するために静的メソッドを実装する必要があります）。 Javaを使用すると、インターフェイスに本体を使用して静的メソッドを定義できます。TypeScriptに相当するものは次のとおりです。

interface I { ... }
namespace I {
   export function interfaceStaticMethod() {}
}

ジェネリックファクトリーを作成しようとした場合はどうなりますか？

interface Factorizable {
  static factory<U>(str: string): U
}

class Foo {
  private data: string[] = []
  bar<T extends Factorizable>(): T[] {
    return this.data.map(T.factory);
  }
}

class Bar implements Factorizable {
  static factory(str: string): Bar {
    // ...
  }
}

// Usage
var x = new Foo();
var y: Bar[] = x.bar();

ここで提案しているinterface構文についてはよくわかりませんが、「使用法」構文が私が達成しようとしているものであることはわかっています。 これは私がSwiftで頻繁に使用するパターン（ protocols ）であり、TypeScriptでは本当に素晴らしいと思います。 言語設計者やコンパイラの実装者ではありませんが、TypeScriptの意図した方向に適合しているか、実装するのが現実的かはわかりません。

クラスはインターフェースをimplementする必要はありません。 インターフェイスを定義するだけで、構造タイプのチェックにより、使用サイトでの問題がキャッシュされます。例：

interface Factorizable<U> {
    factory(str: string): U
}

class Foo {
  private data: string[] = []
  bar<T>(factory: Factorizable<T>): T[] {
    return this.data.map(factory.factory);
  }
}

class Bar {
  static factory(str: string): Bar {
    // ...
  }
}

// Usage
var x = new Foo();
var y = x.bar(Bar); // Bar[]

@mhegazyは比較的良い解決策です。 それを提供してくれてありがとう！ 🙏

私に不快感を与える2つのことがまだあります（確かにどちらもショーストッパーではありません）：

1. 我々はまだそれを宣言することができませんBar明示的に実装またはに準拠Factorizable 。

   • 実際には、これは実際には問題ではないと思います。 Factorizableインターフェースが互換性のない方法で変更された場合、使用法x.bar(Bar)がエラーになり始め、ドリフトの変更を修正するのは事実です。

2. 私にとっては、割り当ての右側でyのタイプを宣言することは依然として認知的負担です。

   • それでも奇妙なことに、この構文はこの動作を有効にします： var y: Baz[] = x.bar(Bar) 。 明らかにエラーですが、構文により、開発者は2つの場所で戻り値の型を定義することにより、問題を過度に制約することができます。

BarがFactorizableを明示的に実装または準拠していることを宣言することはまだできません。

関係するタイプは2つあります。1。コンストラクター関数（クラスの静的側など）と2.インスタンス側（ new呼び出したときに出力されるもの）です。 これら2つを1つのタイプに混合することは正しくありません。 理論的にはimplementsとstatic implements使用できますが、実際には、これはめったに使用されず、implements句は実際にはあまり追加されません。 チェックは、 implements句があるかどうかに関係なく、使用サイトで行われます。

私にとって、割り当ての右側でyのタイプを宣言することは依然として認知的負担です。

2つの意味は異なります。 var y = x.bar(Bar) 、 x.bar(Bar)と同じタイプの新しい変数yを宣言します。 こことしてvar y: Bar[] = x.bar(Bar)新しい変数宣言yタイプBar[]の種類ことと検証x.bar(Bar)に割り当て可能であり、 Bar[] 。

それを言って、これはむしろスタイルの問題です。 個人的には、必要がない限り、型注釈を明示的に使用しないことをお勧めします。 タイプをシステムに流します。 ただし、スタイルガイドが反対で、すべてに明示的な型注釈があるコードベースを見てきました。

@mhegazyディスカッション/パースペクティブをありがとう。

@ andy-hanson時間を割いて修正していただきありがとうございます。 私の例ではエラーを修正しました。

これも機能し、追加の関数呼び出しなしでコンパイル時にエラーを表示します。

interface Type<T> {
    new (...args: any[]): T;
}

/* static interface declaration */
interface ComparableStatic<T> extends Type<Comparable<T>> {
    compare(a: T, b: T): number;
}

/* interface declaration */
interface Comparable<T> {
    compare(a: T): number;
}

/* class decorator */
function staticImplements<T>() {
    return (constructor: T) => {}
}

@staticImplements<ComparableStatic<TableCell>>()   /* this statement implements both normal interface & static interface */
class TableCell { /* implements Comparable<TableCell> { */  /* not required. become optional */
    value: number;

    compare(a: TableCell): number {
        return this.value - a.value;
    }

    static compare(a: TableCell, b: TableCell): number {
        return a.value - b.value;
    }
}

議論の結果は何ですか？

私はこれに遭遇しました、そして私もstatic interfaceを使いたいです：

interface IDb {
  public static instance: () => Db,
}

ほとんどの人は、コンストラクター関数/クラスにコンストラクターインターフェイスとインスタンスインターフェイスの2つのインターフェイスがすでにあるという意味で、すでに_static_インターフェイスがあることを忘れています。

interface MyFoo {
  method(): void;
}

interface MyFooConstructor {
  new (): MyFoo;
  prototype: MyFoo;
  staticMethod(): any;
}

const MyFoo = function MyFoo() {
  this.prop = '';
} as any as MyFooConstructor;

MyFoo.prototype = {
  method() { console.log(this); }
}

MyFoo.staticMethod = function () { /* do something static */ }

_abstract_クラスを使用していない場合は、すでにパワーがあります。

返信してくれてありがとう@kitsonk 。

あなたの宣言はうまくいくはずですが、その場合には冗長すぎます。

そして、私は_abstract_クラスを試しましたが、 abstract staticをサポートしていないようです。

[ts] 'static' modifier cannot be used with 'abstract' modifier.

問題＃14600である@zixia

ええ、投票しましょう。

ここに私の質問の解決策を返信してくれる人はいますか： http ：

インターフェイスで静的メンバーを指定できるようにすることで問題全体が解決されると思います。この問題が不要であるために閉じられた

@grantila私はあなたの質問に答えました。 この号で前述したように、ここに記載されていない要件がない限り、クラスをオブジェクトとして扱うことで簡単に解決できます。

@ Enet4質問を更新しましたが、過度に単純化されていました。 残念ながら、実際の問題はObject.defineProperty()ハックでは修正できません。 これはところで、ハックです。 makeつづりを間違えないようにしたい-基本的に適切な静的チェック。

これは私が抱えている本当の問題です。TypeScriptへの移植を開始しましたが、現在はJavaScriptとして保持しています。これは、他の方法で必要となるような大量のコードを現在書き直すことができないためです。

makeのスペルを間違えないようにしたい-基本的に適切な静的チェック。

静的チェックはここまでしか行えません。 しかし、現在の唯一の懸念が適切なプロパティを設定していることである場合は、メーカータイプにキャストし、そこからプロパティを設定することで対処できるようです。

@ Enet4は実用的なソリューションです、ありがとう。 型キャストを使用したあなたのような解決策は実際には型安全ではないため、この問題（13462）をもう一度検討する必要があると思います。これが、クラス型を値として使用する状況を解決する唯一の方法である場合は、動的言語の柔軟性の多くを失っています。

型キャストを使用するあなたのようなソリューションは、実際には型セーフではありません。これがクラス型を値として使用する状況を解決する唯一の方法である場合、動的言語の柔軟性が大幅に失われます。

@grantila私の弁護では、それは議論の余地があります。 ：wink：ユースケースは、実行時の条件に応じてクラスタイプがメソッドを提供する（または提供しない）という点で、この問題で提示されているものとは異なります。 そして、オブジェクトへのフィールドの挿入を許可するためにのみ実行された、私の回答で提示された型キャストよりも安全でないIMO。 その意味で、結果のクラスタイプC & Maker<T>は、 C依存する他のすべてとの互換性を維持する必要があります。

また、インターフェイスの静的メソッドがここで役立つ場所を想像してみましたが、何かが足りない可能性があります。 インターフェイスにstatic make?(... args: any[]): selfようなものがある場合でも、呼び出しの前に実行時に存在するかどうかを確認する必要があります。 この議論を続けたい場合は、ノイズを減らすために他の場所でそうすることを検討しましょう。 ：slightly_smiling_face：

したがって、同じインターフェイスを実装するクラスで静的ファクトリメソッドを型チェックすることはできませんか？

私のユースケースは次のとおりです。

interface IObject {
    static make(s: string): IObject;
}

class A implements IObject{
    static make(s: string): IObject {
        // Implementation A...
    }
}

class B implements IObject{
    static make(s: string): IObject {
        // Implementation B...
    }
}

A.make("string"); // returns A
B.make("string"); // returns B

このためだけに新しいファクトリクラスを作成したくありません。

@ tyteen4a03その例からIObjectを削除すると、コンパイルされます。 https://github.com/Microsoft/TypeScript/issues/17545#issuecomment-319422545も参照して

@ andy-msはい、明らかに機能しますが、型チェックの全体的なポイントは、型をチェックすることです。 すべてのユースケースをコンパイルするのに十分な程度まで型安全性をいつでも低下させることができますが、これは機能要求であり、それほどクレイジーではないという事実を無視しています。

はい、明らかに機能しますが、型チェックの全体的なポイントは、型をチェックすることです。

これは、クラスの静的側がインスタンス側とは別のインターフェースであり、 implementsがインスタンス側を指す方法に関するlong longlongスレッドです。 @ andy-msは、 @ tyteen4a03に、コードのスニペットを機能させる方法を示していました。これは、型チェックを忘れないために、_間違った_ためです。

静的メソッドがクラスジェネリックパラメーターを使用できるようにするための私のユースケースは、ミックスインクラスの場合です。 アノテーションを使用して列やデータベースなどを定義するエンティティフレームワークを構築しています。エンティティクラスに静的関数を混在させて、正しく入力されたリポジトリに簡単にアクセスできるようにしたいです。

class RepositoryMixin<T> {
    public static repository(): EntityRepository<T> {
        return new EntityRepository<T>(Object.getPrototypeOf(this));
    }
}

@mixin(RepositoryMixin)
class Entity implements RepositoryMixin<Entity> {
    public id: number;
}

Entity.repository().save(new Entity());

@rmblstrp例で提案された機能をどのように使用するかを示していただけますか？ できれば検証可能なものとして？

この機能を必要としない@rmblstrp 。 実際、デコレータを使用しているので、注釈付きクラスが必要な静的メソッドを提供していることを確認するために、実際にそのタイプを指定できます。 両方は必要ありませんが、実際にはかなり冗長になります。

こんにちは、私はこの会話のトピックや範囲から外れたくありません。
ただし、さまざまなプログラミングパラダイム（OOPまたは関数型を使用する必要がありますか？）について話し合ったので、データベースへの接続を作成したり、何らかのサービスを提供したりするために通常使用される静的ファクトリについて具体的に説明します。
PHPやJavaのような多くの言語では、静的ファクトリは依存性注入を支持して非推奨になっています。 依存性注入とIOCコンテナーは、SymfonyやSpringなどのフレームワークのおかげで人気があります。
Typescriptには、InversifyJSという名前のすばらしいIOCコンテナがあります。

これらは、すべてがどのように処理されるかを確認できるファイルです。
https://github.com/Deviad/virtual-life/blob/master/models/generic.ts
https://github.com/Deviad/virtual-life/blob/master/service/user.ts
https://github.com/Deviad/virtual-life/blob/master/models/user.ts
https://github.com/Deviad/virtual-life/blob/master/utils/sqldb/client.ts
https://github.com/Deviad/virtual-life/blob/master/bootstrap.ts

私はそれが完璧な解決策だと言っているわけではありません（そしておそらくそれはいくつかのシナリオをカバーしていないままにします）が、Reactでも機能します、すでにあなたが見ることができるいくつかの例があります。

また、どちらが優れているかについて、この側面をカバーする関数型プログラミングに関するこのビデオをご覧になることをお勧めします：https：//www.youtube.com/watch？v = e-5obm1G_FY＆t = 1487s
ネタバレ：誰よりも優れているわけではありません。解決したい問題によって異なります。 ユーザー、教室、教師を扱う場合は、オブジェクトを使用して問題をモデル化する方がOOPの方が適しています。
Webサイトをスキャンするパーサーが必要な場合は、部分的な結果などを返す関数発生器を使用する方が機能的である可能性があります。:)

@Deviad @aluanhaddad私の投稿以来、私はInversifyJSを使用してきましたが、それは絶対に素晴らしく、間違いなくはるかに優れた方法です。 私の投稿の時点では、以前にPHP / C＃を使用した後、Typescript / Nodeを使い始めたばかりでした。 環境と利用可能なパッケージに慣れるのに少し時間がかかりました。

これの状況はどうですか？ なぜリポジトリ内の未解決の問題を閉じ続けるのですか？

インターフェイスに静的メソッドを持たないという選択は仕様によるものであるため、これは問題に「wontfix」という明示的なラベルを付ける必要があるケースの1つだと思います。

@ enet4 、私は新参者ですが、それはまったく明確ではありませんでした。 これと他の関連する問題を読むと、それは主に次の問題のように聞こえます：

A.難しいです
B.これまでに見た（それぞれの）特定の構文は好きではありません。
C.少数の少数派は、それが実行可能であるべきだとはまったく信じておらず、むしろそれを実行するための現在の奇妙な方法を削除したいと考えています。

それが実際に設計によるものであり、担当者がそれを望まない場合は、公開ドキュメントを作成し、このスレッドや他のスレッドにクロスリンクする必要があります。 これにより、私たちを不自由な状態に保つよりも多くの時間を節約できます。

このスレッドではすでに＃14600にリンクしています。これは、機能リクエストで従うべき問題です。