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

Обобщения и ограничения

Проверяет, умеете ли вы выражать типовые связи через обобщения, ограничения и вариантность. Задания затрагивают вывод параметров типа, comparer, фабрики, ковариантность и признаки ложной универсальности API.

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

⏱ --:--

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

Вопрос 1 из 20

Какой плюс у List<int> перед ArrayList?

var typed = new List<int> { 1, 2, 3 };
int first = typed[0];

var legacy = new ArrayList { 1, "two" };
int value = (int)legacy[0];

ArrayList нельзя перечислять Статическая типизация без boxing при чтении int List<int> поддерживает элементы отсортированными при добавлении List<int> хранит только один элемент List<int> работает только на стеке

Вопрос 2 из 20

Какой тип выведет компилятор для T?

static T Identity<T>(T value) => value;
var x = Identity("hello");

dynamic Вывод невозможен object char[] string

Вопрос 3 из 20

Можно ли иметь одновременно Pair<int,string> и Pair<string,int>?

Да, только когда Pair объявлен структурой и не имеет общей таблицы методов Да, но закрытые варианты должны находиться в разных сборках, чтобы не конфликтовать Да, но лишь если один из аргументов указан как dynamic во время вызова Да, это разные закрытые типы Нет: рантайм создаёт один закрытый тип Pair для всех сочетаний аргументов

Вопрос 4 из 20

Почему generic-метод Max<T> не может использовать оператор > без дополнительных средств?

static T Max<T>(T a, T b)
{
    // return a > b ? a : b; // контракт T этого не обещает
}

Операторы запрещены в generic Оператор > работает только в интерфейсах Неограниченный T рассматривается как object с оператором, выбираемым во время выполнения > Нужен async Для произвольного T оператор > не гарантирован

Вопрос 5 из 20

Когда non-generic API с object всё ещё оправдан?

Когда значимые типы должны обязательно упаковываться Когда generic-версия требует явного указания T при каждом вызове Когда коллекция содержит только числовые типы Когда контракт действительно принимает несвязанные типы, например в низкоуровневой инфраструктуре Когда нужно скрыть все преобразования типов от компилятора

Вопрос 6 из 20

Что позволяет where T : IComparable<T>?

static T Max<T>(T left, T right) where T : IComparable<T> =>
    left.CompareTo(right) >= 0 ? left : right;

Создать T через new T() Использовать любой арифметический оператор Вызывать CompareTo(T) внутри generic-кода Возвращать null без предупреждений Считать T ссылочным

Вопрос 7 из 20

Что требует new() constraint?

static T Create<T>() where T : new() => new T();
var item = Create<List<int>>();

Непубличный конструктор без параметров, доступный через reflection Открытый конструктор с одним параметром типа int Статический фабричный метод Create без параметров Публичный конструктор без параметров; тип не abstract Любой struct, но не ссылочный тип с конструктором

Вопрос 8 из 20

Почему where T : struct исключает int??

Nullable<T> является классом struct constraint требует non-nullable value type Из-за boxing Ограничение работает только с enum int? не существует

Вопрос 9 из 20

Как объявить контракт ключа, для которого не ожидается nullable-значение?

class Cache<TKey, TValue> where TKey : notnull
{
    private readonly Dictionary<TKey, TValue> data = new();
}

where TKey : notnull where TKey : IEquatable<TKey> where TKey : struct where TKey : class where TKey : new()

Вопрос 10 из 20

Когда лучше передать Func<T> factory вместо new()?

Когда фабрика нужна только для значимых типов с default-конструктором Чтобы запретить тестирование Любой значимый тип, даже если параметр T объявлен как абстрактный ссылочный тип Чтобы сделать метод static Закрытый конструктор без параметров: ограничение new() учитывает непубличные члены

Вопрос 11 из 20

Почему IEnumerable<string> можно использовать как IEnumerable<object>?

IEnumerable<string> names = new[] { "A", "B" };
IEnumerable<object> objects = names;

Ковариантность действует у любого generic-типа с совместимыми аргументами IEnumerable<out T> ковариантен Потому что string struct Из-за dynamic Строки копируются в object[]

Вопрос 12 из 20

Почему List<string> нельзя присвоить List<object>?

Такое преобразование запрещает только включённый nullable-контекст List<T> принимает и возвращает T; иначе в список строк через List<object> можно добавить int Тип string не связан наследованием с object Вариантность доступна лишь массивам, но не интерфейсам Во время выполнения List<T> теряет параметр типа и становится обычным List

Вопрос 13 из 20

В каком направлении работает Action<in T>?

Action<object> printObject = o => Console.WriteLine(o);
Action<string> printString = printObject;
printString("ok");

Action<object> можно использовать как Action<string> Ни одно направление: делегаты с generic-параметрами всегда инвариантны Оба направления: параметр in разрешает любое взаимное преобразование Action Action<string> можно использовать как Action<object> Контравариантность действует лишь для значимых типов, но не для ссылочных

Вопрос 14 из 20

Где разрешены in/out в объявлении generic-параметра?

В объявлении generic-класса независимо от использования параметра У enum У struct-полей Только у методов У интерфейсов и делегатов

Вопрос 15 из 20

Почему out T нельзя использовать как тип входного параметра метода интерфейса?

out в объявлении типа равен out-параметру метода Входная позиция позволила бы записать несовместимое значение через ковариантный контракт Интерфейсы с вариантными параметрами не могут иметь методов Входная позиция требует ref struct независимо от объявления in или out Ковариантный T разрешён только для числовых типов

Вопрос 16 из 20

Как переиспользовать сортировку для разных правил?

static void SortBy<T>(List<T> items, IComparer<T> comparer) =>
    items.Sort(comparer);

SortBy(users, UserByNameComparer.Instance);

Копировать алгоритм для каждого типа Преобразовать каждый элемент в строку и сортировать строковые представления Принимать IComparer<T> или Comparison<T> Использовать global static flag Приводить всё к int

Вопрос 17 из 20

Когда extension generic-метод оправдан?

Когда операция естественно относится к широкому контракту и не требует скрытого состояния Для доступа к private-полям чужого класса Extension-метод становится виртуальной точкой расширения Когда метод расширения предназначен для одного конкретного типа string Чтобы заменить наследование состояния

Вопрос 18 из 20

Что не так с Repository<T> без ограничений и предметного контракта?

Он может обещать одинаковую работу для типов с совершенно разными правилами хранения Generic запрещён для репозиториев JIT не специализирует методы для T без constraints Неограниченный T компилятор рассматривает как nullable Он не компилируется без new()

Вопрос 19 из 20

Как сделать generic-алгоритм создания тестируемым?

static IReadOnlyList<T> Build<T>(int count, Func<int, T> factory) =>
    Enumerable.Range(0, count).Select(factory).ToArray();

Ловить все исключения Создавать зависимости через new внутри цикла Использовать DateTime.Now во всех ветвях Хранить результат в static Передать factory/dependency извне

Вопрос 20 из 20

Какой признак говорит, что generic-абстракция неудачна?

Метод возвращает IReadOnlyList<T>, а не изменяемый список Почти каждый вызов требует cast, проверки typeof(T) и специальных исключений Для обобщённого типа написаны отдельные модульные тесты У типа есть только один параметр T и нет второго параметра В реализации используется интерфейс вместо базового класса

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

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

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

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