TS TypeScript · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Лёгкий ·

Классы и модификаторы доступа

Вопросы требуют читать код, сопоставлять статические гарантии с поведением JavaScript и выбирать решение, которое не рассыплется при развитии проекта.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 20 вопросов отведено 55 минут. Код читайте построчно: часть заданий проверяет не результат JavaScript, а то, что TypeScript способен доказать до запуска.

Вопрос 1 из 20

Какая строка вызывает ошибку доступа?

class Account {
  public owner = "Ada";
  private balance = 100;
}
const account = new Account();
console.log(account.owner);
console.log(account.balance);

Ни одна строка Создание Account console.log(account.balance) console.log(account.owner) Оба чтения

Вопрос 2 из 20

Что важно знать о private в TypeScript после компиляции?

class Vault {
  private secret = "key";
}

Поле полностью удаляется из JavaScript private шифрует значение private работает только при strict: false Обычный private — проверка TypeScript private всегда превращается в WeakMap

Вопрос 3 из 20

Почему два класса несовместимы, хотя публичная структура одинакова?

class A { private tag = 0; value = "x" }
class B { private tag = 0; value = "x" }
let a: A = new B();

Имена классов разной длины Поле value должно быть private Классы TypeScript вообще не структурны Private-члены имеют разное происхождение new B() возвращает интерфейс

Вопрос 4 из 20

Когда публичное поле класса лучше заменить методом или accessor?

Всегда: public запрещён в библиотечном коде Когда поле хранит строку Только если поле readonly Когда нужно удержать инвариант или менять реализацию Когда класс экспортируется

Вопрос 5 из 20

Нужно скрыть секрет даже от нетипизированного JavaScript. Что выбрать?

protected secret ECMAScript-поле #secret либо закрытие secret as never readonly secret public secret с комментарием

Вопрос 6 из 20

В показанном фрагменте где доступно поле id?

class Base {
  protected id = "base";
}
class Child extends Base {
  read() { return this.id; }
}
const child = new Child();
child.id;

Только в конструкторе Child Внутри Base и его наследников Только внутри Base Нигде: protected равен private Везде как public

Вопрос 7 из 20

Почему доступ может быть запрещён в наследнике?

class Base { protected x = 1 }
class Derived extends Base {
  compare(other: Base) {
    return other.x;
  }
}

protected доступен только в static-методах protected нельзя читать через произвольный экземпляр Base Наследование отключено без abstract Методы не могут принимать Base Поле x имеет тип never

Вопрос 8 из 20

Какую проблему показывает слишком частое использование protected?

class Report {
  protected rows: string[] = [];
}
class CsvReport extends Report {
  export() { return this.rows.join(","); }
}

protected автоматически делает rows immutable Наследники привязаны к внутреннему массиву rows Поле rows становится глобальным Базовый класс нельзя экспортировать join не работает в наследниках

Вопрос 9 из 20

Когда protected оправдан?

Чтобы скрыть любое поле от unit-тестов Чтобы заменить интерфейсы Для небольшой стабильной точки расширения наследников Чтобы разрешить доступ всем модулям Чтобы сделать класс быстрее

Вопрос 10 из 20

Как уменьшить связанность наследника с базовым классом?

Дать узкий protected-метод вместо доступа к хранилищу Передать base as any Скопировать приватные поля по имени Отключить noImplicitOverride Сделать все поля public

Вопрос 11 из 20

Почему класс должен быть abstract?

abstract class Shape {
  abstract area(): number;
}
new Shape();

Абстрактные классы существуют только как интерфейсы abstract нужен только для private-полей Класс можно создать после as Shape Его нельзя создать до реализации abstract-членов Метод area автоматически возвращает 0

Вопрос 12 из 20

Что обязан сделать Circle?

abstract class Shape {
  abstract area(): number;
  label() { return "shape"; }
}
class Circle extends Shape {
  constructor(readonly radius: number) { super(); }
}

Объявить Circle как interface Реализовать area() Удалить вызов super Переопределить label обязательно Сделать radius protected

Вопрос 13 из 20

Зачем включать noImplicitOverride?

class Base { save() {} }
class Child extends Base { override save() {} }

Чтобы разрешить перегрузки Чтобы компилятор заметил исчезновение базового метода Чтобы запретить наследование Чтобы все методы стали virtual в JavaScript Чтобы override вызывал super автоматически

Вопрос 14 из 20

Когда абстрактный класс лучше интерфейса?

Когда требуется только структурное описание объекта Когда нужно объединение примитивов Когда нужны общий runtime-код, состояние и контракт Когда класс нельзя импортировать Когда экземпляры не должны иметь методов

Вопрос 15 из 20

Почему глубокая иерархия абстрактных классов часто хрупка?

Интерфейсы нельзя реализовать вместе с классом Каждый уровень создаёт новый процесс Абстрактные методы выполняются медленнее Изменение базы затрагивает поведение многих наследников TypeScript поддерживает максимум два уровня

Вопрос 16 из 20

Что проверяет implements?

interface Clock {
  now(): Date;
}
class SystemClock implements Clock {
  now() { return new Date(); }
  reset() {}
}

Класс копирует реализацию из интерфейса implements запрещает дополнительные члены Интерфейс добавляет метод reset Конструктор класса обязан называться Clock Экземпляр класса содержит совместимый метод now

Вопрос 17 из 20

Почему implements не меняет тип параметра метода?

interface Service { handle(value: string | number): void }
class TextService implements Service {
  handle(value: string) {}
}

Методы класса всегда получают any value должен быть private Интерфейс действует только на public-поля Класс обязан сам объявить сигнатуру, совместимую со всем контрактом implements автоматически расширит string до union

Вопрос 18 из 20

Как проверить и static-сторону класса?

interface SerializableInstance { serialize(): string }
interface SerializableConstructor { new (): SerializableInstance; version: number }

Использовать keyof SerializableInstance Сделать интерфейс abstract Проверить только typeof instance Добавить static-поле в обычный implements-интерфейс экземпляра Принимать конструктор отдельным параметром типа SerializableConstructor

Вопрос 19 из 20

Класс реализует огромный интерфейс, но использует только два метода. Что это может означать?

Следует заменить интерфейс на enum TypeScript не поддерживает большие интерфейсы Интерфейс стоит разделить на небольшие роли Достаточно добавить as Нужно сделать все методы private

Вопрос 20 из 20

Почему implements не является runtime-проверкой переданного объекта?

Потому что методы нельзя проверять Потому что классы не существуют в JavaScript Потому что strict отключает runtime implements исчезает после компиляции Потому что объект всегда корректен после JSON.parse

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу