Typescript: 생성자에 대한 가시성 허용

모든 "클래스"는 실제로 함수일 뿐이며 호출 할 수없는 함수가 없기 때문에 클래스가 보이는 모든 곳에서 new 연산자를 사용할 수도 있습니다.

그러나 클래스를 공개하지 않고 (예 : 모듈에서) 클래스에 대한 인터페이스를 내보낼 수 있습니다. 이것은 인터페이스가 클래스를 확장 할 수 있다는 사실을 남용하지만 직접 인스턴스화하거나 확장 할 수는 없습니다.

클래스의 개인 함수에도 똑같이 적용됩니다. 개인 생성자에 액세스 할 때 컴파일 오류가 발생하지 않는 이유를 알 수 없습니다.

@billccn "JS가 허용하면 숨길 수 없게됩니다"라는 요청을 죽이고 싶지 않습니다.
사물은 TS 및 생성 JS에서 완전히 보호하고 다른 것은 JS 생성 지점까지 보호하는 것입니다. 설명했듯이 완전한 보호는 불가능하지만 컴파일러에서 다른 가시성을 확인하는 것은 가능해야합니다.
가시성 수정자가 마음에 들지 않으면 모든 곳에서 기본 공개를 사용하면 해당 개념이 유용하다고 생각하는 다른 도구가 있습니다.

예, 개인 필드가 컴파일러 검사로만 구현되면 생성자로 확장 될 수 있습니다. 그러나 인터페이스 기반 해결 방법은 이미 작동합니다.

: +1 : 프로그래머가 코드 가독성을 위해 팩토리 메서드를 사용하도록 강제하고 싶을 때가 있습니다. 인터페이스 기반 해결 방법은 코드에 많은 노이즈를 생성합니다.

나는 컴파일러 검사가 갈 길이라고 생각합니다.

수락 됨, PR 수락

명확히하기 위해 private 생성자가있는 클래스를 확장 할 수 있습니까?

즉 이것은 오류가 발생합니까?

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 입니다.

두 번째 예제에서 A 의 선언은 생성자의 모든 오버로드와 그 구현이 동일한 가시성을 가져야하기 때문에 오류 여야합니다 (메서드에 대한 동일한 규칙).

# 471도 참조하십시오. 생성자를 비공개로 허용하는 것이 정말로 필요합니까, 아니면 보호 될까요?

@benliddicott 때로는 더 있기 때문에 단일 항목을 강제로 사용하거나 프로그래머가 정적 메서드 중 하나를 사용하여 개체를 만들도록 강제하는 것이 유용합니다.

여기를보십시오 .

@dsherret protected 는 이러한 모든 요구 사항을 충족합니다.

그러나 다운 스트림 사용자가 클래스에서 상속해야하는 합법적 인 필요성이 전혀 없다는 것을 확신 할 수 없습니다. private 의 유일한 효과는 다운 스트림 사용자가 예상치 못한 요구를 충족하지 못하도록하는 것입니다.

@benliddicott 때때로 당신이 원하는 유일한 것은 클래스가 확장

"2. 클래스를 확장 할 수 없는지 확인합니다. 이렇게하면 부주의하거나 악의적 인 하위 클래스가 객체의 상태가 변경된 것처럼 동작하여 클래스의 불변의 동작을 손상시키는 것을 방지 할 수 있습니다. 일반적으로 클래스를 최종 클래스로 설정하여 하위 클래스 지정을 방지합니다. 나중에 논의 할 대안입니다.

현재 TypeScript에는 final / sealed 지원이 없으므로 private 생성자는 유형 시스템의 관점에서 변경할 수없는 클래스를 만드는 유일한 방법입니다. (하지만 생성자에서 객체를 고정하는 것도 권장합니다.)

@billccn , 그 저자의 의견은 흥미 롭습니다. 도서관 작성자의 의견이 도서관 이용자의 의견보다 우선해야한다는 생각도 그렇습니다. 내 경험에 따르면 도서관 작성자는 비공개로 사용할 때를 모르고 과도하게 사용하여 사용자에게 골칫거리를 유발합니다. 실제로 사용하지 않을 때 라이브러리가 어떻게 사용 될지 알고 있다고 믿기 때문입니다.

그러나 Java와 같은 정적 언어보다 더 적절한 비교는 다른 동적 언어 인 Perl입니다. http://www.perlmonks.org/?node_id=437623

perl에 public, private, protected와 같은 액세스 수정자가없는 이유 중 하나는 종종 작업을 수행하는 데 방해가되는 것으로 인식되기 때문입니다. 원래 디자이너가 구상 한 것은 아무 관련이 없습니다. 그것으로 무엇을하고 싶은지. 같은 방식으로 유연성을 고려한 설계-지금은 필요하지 않을 수도 있지만 다음 사람은 새로운 문제를 해결하는 데 매우 편리하다는 것을 알 수 있으며 유연성을 개발 한 천재성을 축복 할 것입니다 ;-)

과:

Perl은 개인 정보 보호에 열광하지 않습니다. 산탄 총이있어서가 아니라 초대받지 않았기 때문에 거실에서 나가는 것이 좋습니다.

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

사실 JavaScript는 동일하며-예-TypeScript는 거의 모든면에서 동일합니다. typescript에서는 적절한 이름의 escape-hatch : 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 "건축 우주 비행사"라는 용어가 여기에 관련이 있다고 생각하지 않습니다. 코드를 작성하는 것보다 아키텍처에 대해 생각 하는 데

또한 코드의 오용을 방지 할 수 있기 때문에 "임의"라고 생각하지 않습니다. 아마도 나는 나 자신이나 우리 팀이 생성자를 사용하지 않고 대신 정적 메서드 중 하나를 사용하거나 정적 메서드를 사용하여 싱글 톤을 강제로 사용하도록 상기시키고 싶을 것입니다. 빠르고 간단하며 컴파일러로부터 적절한 피드백을받습니다. 그것이 임의적이라면 언어의 많은 측면이 임의적이라고 주장 할 수 있습니다. 의견에 표현하지 않은 것이 임의적이라는 점에 대해 더 많이 말할 필요가 있습니까?

이것은 사람들이 싫어하는 경우 사용하지 않는 것이 간단한 언어 기능입니다.

@dsherret 다른 제약을 적용하는 대신 문서화하기에 충분하지 않습니까?

다중 상속을 상당히 복잡하게 만듭니다. # 4805를 참조하십시오 (지금 당장은 나중에 생각할 것 같습니다). 나는 이미 # 3578에서 내 생각의 일부를 표현 했으므로 다시는 그것을 귀찮게하지 않을 것입니다. astronaut 로 약간 강하게 나왔으니, 누구에게도 기분을 상하게하지 마십시오.

개인 생성자가있는 @jbondc 클래스는 상속 될 수 없습니다. 그것들은 본질적으로 봉인되어 있으므로 다중 상속은 말할 것도없고 상속도 이것과 함께 작동해서는 안됩니다.

코드를 외부 적으로 작성하거나 주석으로 작성하는 것보다 자체 문서화 코드를 사용하는 것이 훨씬 좋습니다. 이것이 제가 TypeScript의 모든 제한 사항을 좋아하는 이유 중 하나이며 기본적으로이 기능에서 우리가 요구하는 것은 언어 자체를 사용하여 코드를 문서화하는 또 다른 방법입니다.

여기에 예제를 작성하는 또 다른 방법이 있습니다.

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-ish이지만 실제로 '진짜'실제 개인 수업이 있습니다.

@jbondc 개인 수업을위한 방법을 찾았습니다. 다른 접근 방식 (개인 생성자가있는 내보내기 가능한 클래스)을 사용하도록합니다. 이제 그룹 A의 요구 사항을 충족하고 그룹 B 작업을 방해하지 않는 기능이 있음을 확인할 수 있습니다. :)

+1

+1

여전히 레이더에 있습니까? 홍보는 정말 오래되었습니다!

+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 주석으로 미래의 모든 개인 생성자를 표시하고 있습니다. 이 기능이 제공되면 액세스 수정자를 사용하여 일부 시행 및 더 나은 문서화를 얻을 수 있습니다.

뿡뿡

그래도 여전히 너무 장황하고 무슨 일이 일어나고 있는지 이해하는 데 몇 초가 걸립니다.

동의합니다. 이러한 클래스는 코드가 생성되기 때문에인지 부하로 인해 큰 고통을받지 않습니다. 따라서 프로그래머에 대한 인터페이스는 실제로 훌륭하고 간단합니다.

https://github.com/Microsoft/TypeScript/pull/6885에 의해 수정되었습니다.

감사합니다 @AbubakerB!

안녕하세요,이 기능은 향후 버전의 typescript에서 출시 될 예정입니까?
현재 개인 또는 보호 생성자를 선언하려고하면 typescript 1.8.10에서이 오류가 발생합니다.
오류 TS1089 : 'private'수정자는 생성자 선언에 나타날 수 없습니다.

아, 신경 쓰지 마. 이 기능이 typescript 2.0에 포함될 것이라는 로드맵을 방금 발견했습니다.

아, 신경 쓰지 마. 이 기능이 typescript 2.0에 포함될 것이라는 로드맵을 방금 발견했습니다.

또한 마일스톤이 TypeScript 2.0 로 설정되고 레이블 Fixed 는 포함되었음을 나타냅니다. 레이블이 Fixed 일반적으로 마스터에 포함되며 npm install typescript@next 를 통해 사용할 수 있습니다.

TypeScript 2.0.2 RC를 사용하고 있으며 private 생성자를 만들려고 할 때 여전히 TS1089를 얻습니다. 내가 잘못하고 있습니까? 아니면 단순히 수정되지 않았습니까?

TypeScript 2.0.2 RC를 사용하고 있으며 개인 생성자를 만들려고 할 때 여전히 TS1089를 얻습니다. 내가 잘못하고 있습니까? 아니면 단순히 수정되지 않았습니까?

그것은 나를 위해 일하고 있습니다. 명령 별칭이 올바른 버전을 가리키고 있는지, 편집기가 최신 TS 버전을 사용하도록 업데이트되었는지 확인하십시오.

나는 문제를 발견했다. 그것은의 잘못 gulp-typescript 의 잘못된 버전 사용 된 tsc 내 사양에도 불구하고 package.json 와 무엇에 해결 된 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)))
});