Чому я можу отримати доступ до приватних членів TypeScript, коли я не маю можливості?

Я дивлюся на реалізацію приватних членів у TypeScript, і вважаю це трохи заплутаним. Intellisense не дозволяє отримувати доступ до приватного члена, але в чистому JavaScript це все є. Це змушує мене думати, що TS не реалізує приватних членів правильно. Будь-які думки?

class Test{
  private member: any = "private member";
}
alert(new Test().member);

Так само, як і при перевірці типів, конфіденційність членів забезпечується лише в межах компілятора.

Приватна власність реалізується як звичайна властивість, і код за межами класу не має доступу до неї.

Щоб зробити щось дійсно приватне всередині класу, він не може бути членом класу, це буде локальна змінна, створена всередині функції функції всередині коду, який створює об'єкт. Це означає, що ви не можете отримати доступ до нього, як член класу, тобто використовуючи thisключове слово.

JavaScript підтримує приватні змінні.

function MyClass() {
    var myPrivateVar = 3;

    this.doSomething = function() {
        return myPrivateVar++;        
    }
}

У TypeScript це виражатиметься так:

class MyClass {

    doSomething: () => number;

    constructor() {
        var myPrivateVar = 3;

        this.doSomething = function () {
            return myPrivateVar++;
        }
    }
}

EDIT

Цей підхід слід застосовувати БЕЗПЕЧНО тільки там, де він абсолютно необхідний. Наприклад, якщо вам потрібно тимчасово кешувати пароль.

Існує вартість продуктивності використання цього шаблону (не має значення для Javascript або Typescript), і його слід використовувати лише там, де це абсолютно необхідно.

Після того, як підтримка WeakMap більш широко доступні є цікавий метод докладно в прикладі № 3 тут .

Це дозволяє використовувати приватні дані І уникає витрат на ефективність прикладу Джейсона Еванса, дозволяючи доступ до даних з методів прототипу замість методів лише екземплярів.

Пов'язана сторінка MDN WeakMap перераховує підтримку браузера в Chrome 36, Firefox 6.0, IE 11, Opera 23 та Safari 7.1.

let _counter = new WeakMap();
let _action = new WeakMap();
class Countdown {
  constructor(counter, action) {
    _counter.set(this, counter);
    _action.set(this, action);
  }
  decrement() {
    let counter = _counter.get(this);
    if (counter < 1) return;
    counter--;
    _counter.set(this, counter);
    if (counter === 0) {
      _action.get(this)();
    }
  }
}

Оскільки TypeScript 3.8 буде випущений, ви зможете оголосити приватне поле, яке не можна отримати або навіть виявити за межами класу, що містить .

class Person {
    #name: string

    constructor(name: string) {
        this.#name = name;
    }

    greet() {
        console.log(`Hello, my name is ${this.#name}!`);
    }
}

let jeremy = new Person("Jeremy Bearimy");

jeremy.#name
//     ~~~~~
// Property '#name' is not accessible outside class 'Person'
// because it has a private identifier.

Приватні поля починаються з #символу

Зауважте, що ці приватні поля будуть чимось іншими, ніж поля, позначені privateключовим словом

Реф. https://devblogs.microsoft.com/typescript/announcing-typescript-3-8-beta/

Дякую Шону Фельдману за посилання на офіційну дискусію з цього питання - дивіться його відповідь за посиланням.

Я прочитав дискусію, з якою він пов’язаний, і ось короткий виклад основних моментів:

• Пропозиція: приватні властивості в конструкторі
  • проблеми: не вдається отримати доступ із функцій прототипу
• Пропозиція: приватні методи в конструкторі
  • проблеми: так само, як і з властивостями, плюс ви втрачаєте перевагу продуктивності створення функції одного разу в класі прототипу; натомість ви створюєте копію функції для кожного примірника
• Рекомендація: додайте панель котлів до абстрактного доступу до властивостей та забезпечте видимість
  • проблеми: основні результативні результати; TypeScript розроблений для великих програм
• Пропозиція: TypeScript вже закриває визначення конструктора та прототипу в закриття; розмістити там приватні методи та властивості
  • проблеми з розміщенням приватних властивостей у цьому закритті: вони стають статичними змінними; не існує жодного примірника
  • проблеми із тим, як закрити приватні методи у цьому закритті: вони не мають доступу thisбез якогось вирішення
• Пропозиція: автоматично маніпулювати іменами приватних змінних
  • зустрічні аргументи: це конвенція про іменування, а не мовна конструкція. Погладьте це самі
• Рекомендація:@private анотувати приватні методи з настільки мініфієрами, що визнають, що анотація може ефективно мінімізувати назви методів
  • Немає суттєвих протилежних аргументів до цього

Загальні контр-аргументи для додавання підтримки видимості в емітований код:

• проблема полягає в тому, що сам JavaScript не має модифікаторів видимості - це не проблема TypeScript
• у спільноті JavaScript вже встановлена ​​закономірність: префікс приватних властивостей та методів із підкресленням, який говорить: "продовжуйте на свій страх і ризик".
• коли дизайнери TypeScript сказали, що по-справжньому приватні властивості та методи "неможливі", вони означають "неможливі в умовах наших дизайнерських обмежень", зокрема:
  • Випромінюваний JS є ідіоматичним
  • Котельня плита мінімальна
  • Ніяких додаткових накладних витрат у порівнянні зі звичайними JS OOP

У TypeScript приватні функції доступні лише всередині класу. Подібно до

І при спробі отримати доступ до приватного члена він з’явиться помилка. Ось приклад:

Примітка. Це буде добре з JavaScript, і обидві функції доступні зовні.

Я усвідомлюю, що це давнє обговорення, але все ж може бути корисним поділитися моїм рішенням проблеми нібито приватних змінних та методів у TypeScript, що "просочується", у публічний інтерфейс зібраного класу JavaScript.

Для мене ця проблема є чисто косметичною, тобто вся справа у візуальному захаращенні, коли змінну примірника переглядають у DevTools. Моє виправлення полягає в тому, щоб групувати приватні декларації разом в іншому класі, який потім інстанціюється в основному класі і присвоюється privateзмінній (але все ще публічно видно в JS) з назвою типу __(подвійне підкреслення).

Приклад:

class Privates {
    readonly DEFAULT_MULTIPLIER = 2;
    foo: number;
    bar: number;

    someMethod = (multiplier: number = this.DEFAULT_MULTIPLIER) => {
        return multiplier * (this.foo + this.bar);
    }

    private _class: MyClass;

    constructor(_class: MyClass) {
        this._class = _class;
    }
}

export class MyClass {
    private __: Privates = new Privates(this);

    constructor(foo: number, bar: number, baz: number) {
        // assign private property values...
        this.__.foo = foo;
        this.__.bar = bar;

        // assign public property values...
        this.baz = baz;
    }

    baz: number;

    print = () => {
        console.log(`foo=${this.__.foo}, bar=${this.__.bar}`);
        console.log(`someMethod returns ${this.__.someMethod()}`);
    }
}

let myClass = new MyClass(1, 2, 3);

Коли myClassекземпляр переглядається в DevTools, замість того, щоб бачити всіх його "приватних" членів, змішаних із справді загальнодоступними (які можуть бути дуже візуально брудними в правильно відреставрованому коді реального життя), ви бачите їх, як вони чітко згруповані всередині згорнутого __ресурсу:

Ось підхід для багаторазового використання для додавання належних приватних властивостей:

/**
 * Implements proper private properties.
 */
export class Private<K extends object, V> {

    private propMap = new WeakMap<K, V>();

    get(obj: K): V {
        return this.propMap.get(obj)!;
    }

    set(obj: K, val: V) {
        this.propMap.set(obj, val);
    }
}

Скажімо, у вас Clientдесь клас, для якого потрібні дві приватні властивості:

• prop1: string
• prop2: number

Нижче описано, як ви це реалізуєте:

// our private properties:
interface ClientPrivate {
    prop1: string;
    prop2: number;
}

// private properties for all Client instances:
const pp = new Private<Client, ClientPrivate>();

class Client {
    constructor() {
        pp.set(this, {
            prop1: 'hello',
            prop2: 123
        });
    }

    someMethod() {
        const privateProps = pp.get(this);

        const prop1 = privateProps.prop1;
        const prop2 = privateProps.prop2;
    }
}

І якщо все, що вам потрібно, - це одна приватна власність, то вона стає ще простішою, оскільки вам не потрібно було б визначати жодну ClientPrivateв цьому випадку.

Варто зауважити, що здебільшого клас Privateпросто пропонує добре прочитаний підпис, тоді як безпосереднє використання цього WeakMapне робить.