Typescript: 정적 메서드를 정의하기위한 지원 인터페이스 추가

이것으로 무엇을 성취하고 싶습니까? 시나리오에 대해 자세히 설명해 주시겠습니까?

abstract 수업이 당신이 찾고있는 것이라고 생각합니다.

헉헉
예:

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

@rozzzly 이 예에서 abstract class 는 유효하지 않습니다.

나는 이것이 꽤 멋질 것이라고 생각한다! Java는 마지막 버전에서이 기능을 추가했습니다.

세르지 뉴
나는 당신이 이것이 흥미로울 것이라고 생각한다.

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 나는 당신의 코드가 명백한 문제의 해결 방법을 찾았습니다.

interface 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 나는 상황이 이상적이라고 주장하지 않습니다. 나는 그것이 표현 될 수 있다는 것을 설명하려고 노력했습니다.

트윗 담아 가기 마음을 열어 라. typescript가 인터페이스에서 정적 메서드를 허용해야한다고 생각하십니까? 이것은 마지막 버전의 Java 8에서 구현되었으므로 말도 안되는 소리가 아닙니다.

@Serginho 저는

@aluanhaddad가 이미 작성했듯이

마음을 열고 다른 스타일의 프로그래밍을 시도 할 수도 있습니다. 세상은 OOP로 시작하거나 끝나지 않습니다. 함수, 일반 객체 및 (그리고 어느 정도는) 프로토 타입을 사용한 프로그래밍이 즐겁고 훨씬 더 좋습니다. 이러한 스타일은 JavaScript가 처음에 설계된 것과 훨씬 더 일치합니다. 참고로, JS가 (적어도위원회 수준에서는) OOP-esque 패턴으로 천천히 이동하고 있다는 데 동의하지만, 다른 프로그래밍 패러다임과 개발 기술에 익숙하지 않은 사람들의 엄청난 압박 때문입니다. 저에게 그것은 매우 슬프고 실망스러운 일입니다.

@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 는 비교적 좋은 솔루션입니다. 제공해 주셔서 감사합니다! 🙏

여전히 나에게 불편 함을주는 두 가지가 있습니다 (분명히 쇼 스토퍼가 아닙니다).

1. Bar 이 Factorizable 를 명시 적으로 구현하거나 준수한다고 여전히 선언 할 수 없습니다.

   • 실제로는 이것이 실제로 문제가되지 않는다고 생각합니다. Factorizable 인터페이스가 호환되지 않는 방식으로 변경되면 x.bar(Bar) 에 오류가 발생하기 시작하고 드리프트 변경 사항을 수정하는 것이 사실이기 때문입니다.

2. 저에게는 과제 오른쪽에 y 유형을 선언하는 것이 여전히인지 적 부담입니다.

   • 더 이상하게이 구문은 var y: Baz[] = x.bar(Bar) 동작을 가능하게합니다. 분명히 오류이지만 구문은 개발자가 두 위치에서 반환 유형을 정의하여 문제를 과도하게 제한 할 수 있도록합니다.

우리는 여전히 Bar가 Factorizable을 명시 적으로 구현하거나 준수한다고 선언 할 수 없습니다.

관련된 두 가지 유형이 있습니다. 1. 생성자 함수 (예 : 클래스의 정적 측) 및 2. 인스턴스 측 ( new 호출 할 때 나오는 것). 이 두 가지를 하나의 유형으로 혼합하는 것은 올바르지 않습니다. 이론적으로는 implements 및 static implements 있지만 실제로는 언급했듯이 거의 사용되지 않으며 구현 절은 실제로 많이 추가되지 않습니다. implements 조항이 있는지 여부와 관계없이 사용 사이트에서 확인이 이루어집니다.

나에게는 과제의 오른쪽에 y 유형을 선언하는 것이 여전히인지 적 부담입니다.

두 가지 상이한 평균, var y = x.bar(Bar) 새로운 변수를 선언 y 같은 타입 x.bar(Bar) ; 여기서 같이 var y: Bar[] = x.bar(Bar) 새로운 변수 선언 y 유형 Bar[] 유형 있고를 검증 x.bar(Bar) 귀속 인 Bar[] .

siad가 있으면 이것은 오히려 스타일 문제입니다. 개인적으로 필자는 꼭 필요한 경우가 아니면 명시 적으로 유형 주석을 사용하지 않는 것이 좋습니다. 유형이 시스템을 통해 흐르게하십시오. 그러나 스타일 가이드가 반대 인 코드베이스를 보았습니다. 모든 것이 명시적인 타입 어노테이션을 가지고 있습니다.

@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,
}

대부분의 사람들은 생성자 함수 / 클래스에 이미 생성자 인터페이스와 인스턴스 인터페이스라는 두 개의 인터페이스가 있다는 의미에서 이미 _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_ 클래스를 시도했지만 static 와 함께 abstract static 를 지원하지 않는 것 같습니다.

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

@zixia 문제 # 14600

네, 투표합시다.

아무도 내 질문에 대한 해결책으로 답장을 보내시겠습니까? http://stackoverflow.com/questions/44047874/dynamically-modify-typescript-classes-through-a-generic-function

인터페이스에 정적 멤버를 지정할 수 있으면 전체 문제가 해결 될 것이라고 생각하며,이 문제가 필요 하지 않아 종결되면 대신 해결 방법을보고 싶습니다.

@grantila 귀하의 질문에 답변했습니다. 이 문제에서 이전에 언급했듯이 여기에 언급되지 않은 추가 요구 사항이 없으면 클래스를 객체로 처리하여 쉽게 해결할 수 있습니다.

@ Enet4 질문을 업데이트 Object.defineProperty() 해킹으로는 실제 문제를 해결할 수 없습니다. 어느 btw 는 해킹입니다. 기본적으로 적절한 정적 검사 인 make 철자가 틀리지 않도록하고 싶습니다.

이것은 내가 가진 진짜 문제입니다. TypeScript로 포팅하기 시작했지만 지금은 자바 스크립트로 유지하고 있습니다. 다른 방법으로 필요했던 엄청난 양의 코드를 재 작성할 수 없기 때문입니다.

기본적으로 적절한 정적 검사-철자가 틀리지 않도록 보장하고 싶습니다.

정적 검사는 여기까지만 가능합니다. 그러나 지금 유일한 관심사가 올바른 속성을 설정하는 것이라면 제작자 유형으로 캐스팅하고 거기에서 속성을 설정하는 것이 문제를 해결하는 것 같습니다.

@ 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 가 인스턴스 측을 가리키는 방법에 대한 길고 긴 스레드입니다. @ andy-ms는 @ tyteen4a03 에게 코드 스 니펫을 작동시키는 방법을 알려주었습니다. 유형 검사를 포기하는 것이 아니라 _wrong_ 이었기 때문입니다.

정적 메서드가 클래스 제네릭 매개 변수를 사용하도록 허용하는 사용 사례는 mixin 클래스입니다. 주석을 사용하여 열, 데이터베이스 등을 정의하는 엔티티 프레임 워크를 구축 중이며 올바른 유형의 저장소에 대한 편리한 액세스를 허용하는 정적 함수를 엔티티 클래스에 혼합하고 싶습니다.

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 . 사실, 데코레이터를 사용하고 있기 때문에 주석이 달린 클래스가 필요한 정적 메서드를 제공하는지 확인하기 위해 실제로 _its type_ 일 수 있습니다. 둘 다 필요하지 않으며 실제로 중복됩니다.

안녕하세요, 저는 주제를 벗어나거나이 대화의 범위를 벗어나고 싶지 않습니다.
그러나 다른 프로그래밍 패러다임을 논의했기 때문에 (OOP 또는 기능을 사용해야합니까?), 일반적으로 db에 대한 연결을 생성하거나 일종의 서비스를 제공하는 데 사용되는 정적 팩토리에 대해 구체적으로 이야기하고 싶습니다.
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는 개체를 사용하여 문제를 모델링하는 것이 더 좋습니다.
웹 사이트를 스캔하는 파서가 필요한 경우 부분 결과를 반환하는 함수 생성기를 사용하는 것이 기능적 일 수 있습니다. :)

@Deviad @aluanhaddad 내 게시물 이후 InversifyJS를 사용해 왔으며 절대적으로 훌륭하고 확실히 훨씬 더 나은 방법이었습니다. 내 게시물 당시에는 이전에 PHP / C #을 사용한 후 Typescript / Node를 사용하기 시작했습니다. 환경과 사용 가능한 패키지에 익숙해지는 데 약간의 시간이 걸렸습니다.

이것의 상태는 무엇입니까? 리포지토리에서 해결되지 않은 문제를 계속 닫는 이유는 무엇입니까?

인터페이스에 정적 메서드를 사용하지 않는 선택은 디자인에 따라 문제가 명시 적으로 "wontfix"로 표시되어야하는 경우 중 하나라고 생각합니다.

@ enet4 , 나는 새로 온 사람이지만 전혀 명확하지 않았습니다. 이 문제 및 기타 관련 문제를 읽으면 대부분 다음 문제처럼 들립니다.

A. 어렵다
B. 우리는 지금까지 본 (각각) 특정 구문을 좋아하지 않습니다.
C. 소수는 그것이 전혀 가능해야한다고 생각하지 않고 오히려 현재의 이상한 방법을 삭제합니다.

실제로 의도적으로 설계된 것이고 담당자가 원하지 않는 경우 공개 문서를 작성하고이 스레드와 다른 스레드에 교차 링크해야합니다. 이것은 우리를 림보에 두는 것보다 많은 시간을 절약 할 수 있습니다.

이 스레드에서 이미 # 14600에 연결되어 있으며 이것이 기능 요청에 따라 따라야 할 문제입니다.