2
クラスのTypescriptでデコレータや注釈を使用する理由がわかりません。コンパイラは新しいタイプのクラスを推論することはできません。私がデコレータを使用せずにES5でこれを行うために古い方法（つまり、デコレータを手動で呼び出す）を使用すると、明らかに機能します。例えばTypescript：デコレータ使用時の型推論
は、ここでの問題を示すサンプル：
function decorate(Target: typeof Base): IExtendedBaseConstructor {
return class extends Target implements IExtendedBase {
public extendedtMethod(): number {
return 3;
}
};
}
interface IBase {
baseMethod(): number;
}
interface IExtendedBase extends Base {
extendedtMethod(): number;
}
interface IExtendedBaseConstructor {
new(): IExtendedBase;
}
@decorate
class Base implements IBase {
public baseMethod(): number {
return 5;
}
}
const test = new Base();
test.baseMethod(); // OK
test.extendedtMethod(); // NOT OK, typescript think, Base is still Base but we decorated it.
古い方法では、それが動作します：事前に
class Base implements IBase {
public baseMethod(): number {
return 5;
}
}
const ExtendedBase = decorate(Base);
const test = new ExtendedBase();
test.baseMethod(); // OK
test.extendedtMethod(); // OK
感謝を。
このパターンの利点は何ですか？ [this code]（https://jsfiddle.net/pcyybdt7/1/）は理解しにくいですか？ –
あなたは正しいです。この場合、このパターンは役に立たない。しかし、新しいフロントエンドフレームワーク（angular2のような）は、継承の代わりにデコレータを使用して新しいコンポーネントを宣言しました。 – Cnode
私は、クラスAPIを作成するためのヘルパーをユーザに提案するライブラリを作成しました（いくつかのパラメータと便利なメソッドが組み込まれています）。だから私は機能を提供する抽象Apiクラスと、メタデータを介してAPIを自分のフレームワークに登録するデコレータを作成しました。 私のユーザーがしなければならない。この場合： 'インポート{AbstractAPI、アピ} 'MYLIB' @Api（...）から クラスUserApiはAbstractAPI {}' 私のSOの質問はまた、これに関連しているが拡張されています。私が拡張子を削除してすべてをデコレータ '@ Api 'にマージすると、最終的なユーザの入力ミスを減らすことができます。 – Cnode