C# C# · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Средний ·

Свойства, индексаторы и операторы

Проверяет, как свойства и индексаторы защищают состояние объекта, чем init отличается от обычного setter и когда перегрузка оператора остаётся понятной. Кодовые задания затрагивают инварианты, равенство, хеширование и неожиданные побочные эффекты.

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

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 20 вопросов отведено 55 минут. В заданиях с кодом учитывайте указанную конструкцию и не додумывайте отсутствующие условия. После завершения откроются общий результат, тематические шкалы и разбор каждого ответа.

Вопрос 1 из 20

Почему это свойство плохо защищает инвариант «возраст не может быть отрицательным»?

public int Age { get; set; }

Любой клиент может присвоить отрицательное число Getter должен быть закрытым, иначе значение нельзя читать Автосвойство с int не компилируется без начального значения Автосвойства не поддерживаются сериализаторами Проблема только в том, что свойству не задано начальное значение

Вопрос 2 из 20

Что означает private set?

public sealed class Order
{
    public Order(Guid id) => Id = id;
    public Guid Id { get; private set; }
}

Свойство читается и меняется отовсюду Свойство становится readonly-полем Извне доступен get, а присваивать может только сам тип Свойство доступно лишь наследникам setter вызывается только через reflection

Вопрос 3 из 20

Какой результат выведет код?

class Rect
{
    public int Width { get; set; }
    public int Height { get; set; }
    public int Area => Width * Height;
}
var r = new Rect { Width = 2, Height = 4 };
Console.WriteLine(r.Area);

5 0 3 Ошибка компиляции 8

Вопрос 4 из 20

Для чего нужен required у свойства?

Чтобы компилятор запретил null для свойства во время выполнения Чтобы компилятор потребовал инициализацию при создании объекта, если это не сделал конструктор Чтобы setter можно было вызвать только из метода владельца Чтобы свойство автоматически стало static Чтобы значение стало константой после первого чтения

Вопрос 5 из 20

Когда вычисляемое свойство хуже метода?

Когда операция дорогая, долгая или имеет заметный побочный эффект Когда результат имеет тип string или другую ссылку Когда класс sealed и не допускает наследования Когда значение вычисляется из двух уже загруженных полей Когда свойство доступно только для чтения и не имеет setter

Вопрос 6 из 20

Какое присваивание допустимо?

class User { public string Name { get; init; } = ""; }
var user = new User { Name = "A" };
// user.Name = "B";

Любое присваивание через reflection запрещено CLR user.Name = "B" после создания Ни одно: init равен get-only Только присваивание null Name = "A" внутри object initializer

Вопрос 7 из 20

Почему объект всё ещё изменяем?

class Note
{
    public List<string> Tags { get; init; } = new();
}
var n = new Note();
n.Tags.Add("new");

init делает неизменяемым весь граф объекта init не работает для List<T> Свойство фактически имеет public set Коллекция копируется при каждом чтении Ссылка Tags фиксирована, но сам список допускает Add

Вопрос 8 из 20

Как усилить неизменяемость коллекционного свойства?

public sealed class Report
{
    public IReadOnlyList<string> Lines { get; init; } = Array.Empty<string>();
}
var report = new Report { Lines = source.ToArray() };

Объявить список dynamic Добавить второй init Использовать public field Вернуть readonly-представление коллекции Вызывать ToArray при каждом Add внутри клиента

Вопрос 9 из 20

Можно ли присвоить init-свойство из конструктора самого типа?

Да, но только первичный конструктор record входит в разрешённый период инициализации Нет: присваивание разрешено в object initializer, но не внутри конструктора самого типа Да, если обратиться к init-свойству через reflection вместо обычного присваивания Нет: конструктор может назначать поля, но init-свойство доступно лишь вызывающему коду Да: конструктор самого типа входит в разрешённый период инициализации объекта

Вопрос 10 из 20

Какой API лучше для объекта, который должен меняться после создания по проверенным правилам?

Публичные init-свойства для всех будущих изменений Только публичные поля object initializer при каждом изменении Новый экземпляр Type для каждого свойства Закрытые setter и именованные методы изменения с проверками

Вопрос 11 из 20

Какой элемент вернёт индексатор Letters для индекса 1?

class Letters
{
    private readonly string[] data = { "a", "b", "c" };
    public string this[int i] => data[i];
}
Console.WriteLine(new Letters()[1]);

2 Ошибка компиляции a b c

Вопрос 12 из 20

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

Компилятор на месте вызова Реализация индексатора и объявленный ею контракт Внутренний контейнер, даже если он принимает более широкий набор ключей Среда выполнения независимо от контракта пользовательского типа Вызывающий код, даже если индексатор публично обещает проверку

Вопрос 13 из 20

Когда метод TryGetValue яснее индексатора?

Когда коллекция маленькая Когда значение строковое Когда отсутствие ключа — обычный ожидаемый исход Когда класс sealed Когда ключ имеет тип int

Вопрос 14 из 20

Что допускает C#-индексатор?

Только getter: наличие setter сделало бы индексатор неоднозначным с массивом Статический индексатор без экземпляра, если его параметры образуют уникальную сигнатуру Несколько параметров разных типов при однозначной сигнатуре Ровно один параметр int, поскольку синтаксис квадратных скобок повторяет массив Один строковый ключ: другие типы параметров поддерживаются только обычными методами

Вопрос 15 из 20

Почему сеттер индексатора может быть опасен в многопоточном контейнере?

counter[key] = counter[key] + 1; // две отдельные операции

Если setter использует lock, вся последовательность чтение-изменение-запись становится атомарной Чтение-изменение-запись может быть неатомарным Индексаторы запрещены в потоках При конкурентной записи CLR отбрасывает один аргумент set Сеттер получает отдельную копию и записывает её атомарно

Вопрос 16 из 20

Какой результат ожидается от корректного operator + для неизменяемого Vector?

Записать результат в статическое поле Изменить левый объект и вернуть null Сравнить ссылки Вызвать Dispose у обоих Вернуть новый Vector-сумму, не меняя операнды

Вопрос 17 из 20

Что следует сделать при перегрузке == для класса-значения?

Согласовать !=, Equals и GetHashCode Ничего больше Запретить null Обязательно сделать тип mutable Удалить object.Equals

Вопрос 18 из 20

Какое число выведет программа?

readonly record struct Point(int X, int Y)
{
    public static Point operator +(Point a, Point b) => new(a.X + b.X, a.Y + b.Y);
}
var p = new Point(1, 2) + new Point(4, 5);
Console.WriteLine(p.X + p.Y);

12 7 15 9 10

Вопрос 19 из 20

Что даст checked-перегрузка сложения Counter на границе int.MaxValue?

readonly record struct Counter(int Value)
{
    public static Counter operator +(Counter a, Counter b) =>
        new(unchecked(a.Value + b.Value));
    public static Counter operator checked +(Counter a, Counter b) =>
        new(checked(a.Value + b.Value));
}
var x = checked(new Counter(int.MaxValue) + new Counter(1));

Получится int.MinValue Оператор вернёт null Компилятор запретит вызов Будет OverflowException Результат станет long

Вопрос 20 из 20

Какой оператор лучше не перегружать необычным образом?

Сравнение значений с естественным порядком Оператор с неожиданным смыслом, например умножение для отправки письма Сложение денежных значений одной валюты Явное преобразование, которое подчёркивает риск потери данных Унарный минус, меняющий направление математического вектора

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

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

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

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