Typescript: コンストラクターの可視性を許可する

すべての「クラス」は実際には単なる関数であり、呼び出し不可能な関数などはないため、クラスが表示されている場所であればどこでもnew演算子を使用できます。

ただし、クラスを非公開（モジュールなど）にして、クラスのインターフェイスをエクスポートすることはできます。 これは、インターフェースがクラスを拡張できるという事実を悪用しますが、それらは直接インスタンス化も拡張もできません。

同じことがクラスのプライベート関数にも当てはまりますよね？ プライベートコンストラクターにアクセスするためにコンパイルエラーが発生しなかった理由がわかりません。

@billccn 「JSが許可すると非表示にできなくなります」でリクエストを
TSと生成されたJSで完全に保護することと、JSを生成するまで保護することです。 あなたが説明したように、完全な保護は不可能ですが、コンパイラによって異なる可視性がチェックされることは可能であるはずです。
可視性修飾子が気に入らない場合は、どこでもデフォルトのパブリックを使用してください。その概念が役立つと思われるものは他にもあります。

ええ、プライベートフィールドがコンパイラチェックとしてのみ実装されている場合は、おそらくコンストラクタに拡張できると思います。 ただし、インターフェイスベースの回避策はすでに機能しています。

：+1：コードを読みやすくするためにプログラマーにファクトリメソッドを使用させたい場合があります。 インターフェイスベースの回避策は、コードに多くのノイズを発生させます。

コンパイラチェックだけが道だと思います。

承認済み、PRの承認

明確にするために、プライベートコンストラクターを持つクラスは拡張可能でしょうか？

つまり、これはエラーをスローしますか？

class A {
    private constructor() {
    }
}

class B extends A { // Should there be an error at A saying: "Cannot extend private class 'A'"?
}

もしそうなら、私たちはこれを許可しますか？

class A {
    protected constructor(a?: any)
    private constructor() {

    }
}

class B extends A { // No error since 'A' has a non-private constructor
}

JS以外の開発者の経験から、予想される動作です。

最初の例でB 、暗黙のスーパーコールが不正であるため、 private constructorクラスは、実質的にsealed / finalます。

2番目の例では、コンストラクターのすべてのオーバーロードとその実装が同じ可視性（メソッドと同じルール）を持っている必要があるため、 Aの宣言はエラーになります。

＃471も参照してください。 コンストラクターをプライベートにすることが本当に必要ですか、それとも保護されますか？

@benliddicottは、シングルトンを強制したり、プログラマーに静的メソッドの1つを使用してオブジェクトを作成するように強制したりすると便利な場合があります。

こちらをご覧ください。

@dsherret protectedは、これらすべてのニーズを満たします。

ただし、ダウンストリームユーザーがクラスから継承する正当な必要性がないことを確認することはできません。 privateの唯一の効果は、ダウンストリームユーザーが予期していなかったニーズに対応できないようにすることです。

@benliddicott時々、あなたが望む唯一のことは、クラスが拡張

"2.クラスを拡張できないようにします。これにより、不注意または悪意のあるサブクラスが、オブジェクトの状態が変化したかのように動作することで、クラスの不変の動作を損なうのを防ぎます。サブクラス化の防止は、通常、クラスをfinalにすることで実現されますが、これは、後で説明する代替手段です。

現在、TypeScriptにはfinal / sealedサポートがないため、型システムの観点から不変のクラスを実現する唯一の方法はプライベートコンストラクターです。 （ただし、コンストラクターでオブジェクトをフリーズすることもお勧めします。）

@billccn 、その作者の意見は興味深いです。 図書館の執筆者の意見が図書館の利用者の意見よりも優先されるべきであるという考えもそうです。 私自身の経験では、ライブラリの作成者はプライベートをいつ使用するかわからず、使いすぎると、実際にはライブラリがどのように使用されるかを知っていると信じているだけで、ユーザーに頭痛の種を引き起こします。

しかし、Javaのような静的言語ではなく、より適切な比較はPerlであり、別の動的言語です： http ：

perlにpublic、private、protectedなどのアクセス修飾子がない理由の1つは、perlが仕事の遂行を妨げることがよくあると認識されているためです。元の設計者が想定したことは、何の関係もありません。あなたがそれで何をしたいのか。 同様に、柔軟性を考慮した設計-今は必要ないと思われるかもしれませんが、次に来る人は、その新しい問題を解決するのに非常に便利であると感じるかもしれません。そして、その柔軟性を開発するための天才を祝福します;-)

そして：

Perlには、強制されたプライバシーに夢中になることはありません。 散弾銃を持っているからではなく、招待されなかったので、居間から離れたほうがいいでしょう。

http://www.perlmonks.org/?node_id=1096925

実際、JavaScriptは同じであり、-はい-TypeScriptはほとんどすべての点で同じです。 typescriptでは、適切な名前のエスケープハッチを使用してプライベートメンバーに問題なくアクセスできます： obj["propertyName"] 。

ライブラリライターとして、メソッドを呼び出したり、オブジェクトから継承したりするのは賢明ではないと思われる場合は、賢明ではないことをユーザーに伝えてください。 しかし、彼らを妨げないでください-結局、彼らはあなたよりよく知っているかもしれません。

「保護されていれば十分」という議論がわかりません。 TSに可視性の概念があり、この概念をコンストラクターに適用できる場合、答えは「十分ではありません」です。

コンストラクターでアクセス修飾子が許可されている場合は、他の修飾子と一貫した動作をし、プライベートを許可する必要があると思います。

一般的にプライベートメンバーは確かに便利です。 これらを使用すると、クラス外で副作用を引き起こすことを心配せずに、クラスの実装の詳細を整理してリファクタリングできます。

プライベートコンストラクターを使用すると、チームの開発者に特定の方法でプログラミングを強制したい場合があります。 たとえば、ここで静的メソッドを使用するように強制したい場合があります。これは、より読みやすく、このクラスを拡張しないように強制するためです。

class Currency {
    private constructor(private value: number, private type: CurrencyType) {
    }

    static fromNumberAndType(value: number, type: CurrencyType) {
        return new Currency(value, type);
    }

    static fromString(str: string) {
        const value = ...,
              type  = ...;

        return new Currency(value, type);
    }

    // ... omitted ...
}

// error:
const badCurrency = new Currency(5.66, CurrencyType.USD);
// ok:
const goodCurrency1 = Currency.fromNumberAndType(5.66, CurrencyType.USD);
const goodCurrency2 = Currency.fromString("5.66 USD");

プライベートコンストラクターを使用すると、チームの開発者に特定の方法でプログラミングを強制したい場合があります。

これは管理上の問題であり、言語設計の問題ではありません。

@benliddicott変数の型記述子についても同じことが言えます:)この機能が気に入らない場合は、プレーンJSを使用してください。 または
TSを使用して、コンストラクターでのprivateの使用を禁止する糸くずのようなルールを作成します。最後のコメントを言い換えると、「これは言語設計の問題ではなく、ツールの問題です」。

@benliddicott何かが不可能な場合は、コードレビューを行った後、間違っているときにそれを送り返す必要はありません。 それは時間を節約します。

コードを正しく使用する方法をコンパイラーに正確に伝えることは、プログラミング中にコードを使用する開発者に適切なフィードバックを提供する資産です。

@dsherretいいえ、 Architecture astronauts権限を与えるのは任意の制約です：-1：

@jbondcこの「建築宇宙飛行士」は合理的な議論ですか？ この機能を必要としている人々を怒らせたり賞賛したりしようとしていますか？

@jbondcここでは「建築宇宙飛行士」という言葉は関係ないと思います。 それは、コードを書くよりもアーキテクチャについて考えることに

さらに、コードの誤用を防ぐのに役立つため、「任意」ではないと思います。 コンストラクターを使用せず、代わりに静的メソッドの1つを使用するか、静的メソッドの使用を強制してシングルトンを強制することを自分自身またはチームに思い出させたいと思うかもしれません。 すばやく簡単で、コンパイラから適切なフィードバックを受け取ります。 それが恣意的であるなら、あなたは言語の多くの側面が恣意的であると主張することができます。 コメントで表現しなかったのは恣意的だと​​いうことについてもっと言いたいことがあるでしょうか。

これは言語機能であり、人々が気に入らない場合は簡単に使用しないことができます。

@dsherretさらに別の制​​約を適用する代わりに、文書化するのに十分ではありませんか？

多重継承は非常に複雑になります。＃4805を参照してください（これは今のところ後付けのようです）。 私はすでに＃3578で私の考えのいくつかを表現しているので、二度とそれをする気にはなりません。 astronautで少し強くなりました、誰かを怒らせるつもりはありません。

プライベートコンストラクターを持つ@jbondcクラスは継承できません。 それらは本質的に封印されているので、継承はもちろん、多重継承はこれで機能しないはずです。

自己文書化コードを作成する方が、外部やコメントに書き込むよりもはるかに優れています。 これが、TypeScriptのすべての制限が好きな理由のひとつであり、基本的にこの機能で求めているものです。言語自体を使用してコードを文書化するもう1つの方法です。

さてここにあなたの例を書く別の方法があります：

module Currency {
    export enum Type {
        CAD = 1.3,
        USD = 1,
    }

    class PrivateCurrency {
        constructor(private value: number, private type: Type) { }
    }

    export function fromNumberAndType(value: number, type: Type) {
        return new PrivateCurrency(value, type);
    }

    export function fromString(str: string) {
        let value = 10;
        let type = Type.CAD;
        return new PrivateCurrency (value, type);
    }
}

OOっぽくないですが、実際には「本物の」本当のプライベートクラスがあります。

@jbondcプライベートクラスへの道を見つけたのは素晴らしいことです！ 他の人に別のアプローチ（プライベートコンストラクターを持つエクスポート可能なクラス）を使用させます。 これで、グループAのニーズを満たし、グループBの作業を中断しない機能が存在する可能性があることがわかります。 :)

+1

+1

これはまだレーダーに乗っていますか？ PRは古くなっています！

+1

+1

+1

：+1：ファクトリデザインパターンに役立ちます

これが繰り返しであるか、パーティーに遅れている場合はお詫びしますが、プライベートコンストラクターを実現するために次のパターンを使用しています。

interface ExampleBuilder {
    Instance(): Example;
}

export interface Example {
    Val(): number;
}

export let Example: ExampleBuilder = class ExampleImpl {
    constructor(v: number) {
    }

    Val(): number {
        return 42;
    }

    static Instance(): Example {
        return new ExampleImpl(2);
    }
};

let x = Example.Instance(); // OK: x has type Example
let y = new Example(5);     // ERROR: Cannot use 'new' with an expression whose type lacks a call or construct signature.

最近マージされたreadonly修飾子を使用すると、これをさらに整理できることに注意してください。

@myitcv今のところそれを強制するのはかなりクールです...おそらく私の意見で言及されている最良の方法です。 ただし、それでも冗長すぎて、何が起こっているのかを理解するのに数秒かかります。そのため、アクセス修飾子はコンストラクターで非常に便利です。

個人的には、将来のすべてのプライベートコンストラクターに// todo: make private once supportedコメントを付けて、コンストラクターを呼び出さないようにしています。 この機能が導入されたら、アクセス修飾子を使用していくつかの施行とより良いドキュメントを取得できると便利です。

@dsherret

それでもまだ冗長すぎて、何が起こっているのかを理解するのに数秒かかります

同意しました。 これらのクラスはコードで生成されるため、認知的負荷にそれほど悩まされることはありません。 したがって、プログラマーへのインターフェースは実際には素晴らしくシンプルです。

https://github.com/Microsoft/TypeScript/pull/6885で修正済み

ありがとう@AbubakerB！

こんにちは、この機能はtypescriptの将来のバージョンでリリースされる予定ですか？
今のところ、プライベートまたは保護されたコンストラクターを宣言しようとすると、typescript1.8.10で次のエラーが発生します。
エラーTS1089： 'private'修飾子をコンストラクター宣言に表示できません。

ああ、気にしないで。 この機能がtypescript2.0に含まれることを示すロードマップを見つけました。

ああ、気にしないで。 この機能がtypescript2.0に含まれることを示すロードマップを見つけました。

また、マイルストーンがTypeScript 2.0に設定され、ラベルFixedは、それが含まれていることを示します。 ラベルがFixed通常、マスターに含まれ、 npm install typescript@nextから入手できます。

TypeScript 2.0.2 RCを使用していますが、 privateコンストラクターを作成しようとするとTS1089が表示されます。 私はそれを間違っていますか、それともこれは単に修正されていませんか？

TypeScript 2.0.2 RCを使用していますが、プライベートコンストラクターを作成しようとするとTS1089が表示されます。 私はそれを間違っていますか、それともこれは単に修正されていませんか？

それは私のために働いています。 コマンドエイリアスが正しいバージョンを指していること、およびエディターが最新のTSバージョンを使用するように更新されていることを確認してください。

私は問題を見つけました。 package.json私の仕様と、 PATH解決されたものにもかかわらず、間違ったバージョンのtscを使用していたのはgulp-typescriptのせいPATH 。

この問題を抱えている他の人にとって、私の解決策は私のgulpfile.jsを編集すること

1. 次のように、gulp-typescriptの前のrequire TypeScript：

// Tool-Chain: Scripts
var tsc = require("typescript");
var typescript = require('gulp-typescript');

1. ビルドタスクを定義するときに、コンパイラをオーバーライドとして提供します。

// Task(s): Build TypeScript Outputs
var tsconfig = typescript.createProject("path to tsconfig", { typescript: tsc });
gulp.task('build:scripts', function () {
    let ts = tsconfig.src()
                     .pipe(sourcemaps.init())
                     .pipe(typescript(tsconfig));

    return ts.js.pipe(sourcemaps.write(".")).pipe(gulp.dest(path.join(outputs.root, outputs.scripts)))
});