C++ C++ · 30 вопросов · ~85 мин · ⏱ Таймер 25:00 · Сложный ·

Шаблоны проектирования на современном C++

Профессиональный тест проверяет, умеет ли разработчик выбирать форму вариативности: виртуальный интерфейс, шаблон, callable, variant или обычную функцию. Задания разбирают Strategy, Observer, Factory и случаи, где классический шаблон превращается в лишнюю иерархию.

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

⏱ --:--

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

Вопрос 1 из 30

Когда виртуальный Strategy уместен?

struct CompressionStrategy {
    virtual Bytes compress(std::span<const std::byte>) = 0;
    virtual ~CompressionStrategy() = default;
};
class Archiver {
    std::unique_ptr<CompressionStrategy> strategy_;
};

Для открытого набора runtime-реализаций за стабильным интерфейсом Когда нужна только одна фиксированная реализация Всегда для любой функции из двух строк Когда тип результата неизвестен компилятору Чтобы избежать всех аллокаций

Вопрос 2 из 30

Что даёт передача стратегии как шаблонного параметра?

template<class Strategy>
class Archiver {
    [[no_unique_address]] Strategy strategy_;
public:
    Bytes run(Data data) { return strategy_(data); }
};

Статический выбор и inline без виртуального вызова Запрет stateful стратегий Один ABI для любых компиляторов Позволяет загружать новую стратегию из динамической библиотеки без пересборки вызывающего кода Обязательную heap-аллокацию

Вопрос 3 из 30

Когда `std::function<Result(Input)>` удобнее базового класса Strategy?

using Strategy = std::function<Result(const Input&)>;

Result execute(const Input& input, const Strategy& strategy) {
    return strategy(input);
}

execute(data, [](const Input& x) { return fast_path(x); });

Когда нельзя использовать лямбды Когда callable move-only в любой версии Всегда быстрее шаблона Для единого хранимого callable без расширенного интерфейса Когда нужен доступ к нескольким несвязанным методам

Вопрос 4 из 30

Какой риск у хранения Strategy* сырым указателем без контракта?

class Processor {
    Strategy* strategy_; // кто владеет и сколько живёт?
public:
    explicit Processor(Strategy* strategy) : strategy_(strategy) {}
};

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

Вопрос 5 из 30

Что напечатает код?

#include <iostream>
struct AddOne { int operator()(int x) const { return x+1; } };
template<class Strategy> struct Processor {
    Strategy s; int run(int x){ return s(x); }
};
int main(){ std::cout << Processor<AddOne>{}.run(5); }

10 Код не компилируется Поведение не определено 5 6

Вопрос 6 из 30

Главная lifetime-проблема классического списка `Observer*`?

class Subject {
public:
    void subscribe(Observer& observer) { observers_.push_back(&observer); }
    void notify() {
        for (Observer* observer : observers_) observer->update();
    }
private:
    std::vector<Observer*> observers_;
};

Контейнер не может хранить указатели на полиморфные наблюдатели Observer по умолчанию владеет Subject и не позволяет разрушить его первым Subject может сохранить адрес уже уничтоженного Observer и вызвать его позднее Перед вызовом сырой указатель умеет проверить завершилось ли время жизни объекта Виртуальный деструктор Subject автоматически удаляет все зарегистрированные Observer

Вопрос 7 из 30

Почему нельзя бездумно удалять наблюдателя из vector во время range-for уведомления?

for (Observer* observer : observers_) {
    observer->on_event(event); // callback может вызвать unsubscribe(observer)
}

Удаление из середины vector имеет постоянную стоимость и потому нарушает порядок уведомлений Vector запрещает вызывать пользовательские функции во время обхода Range-for сначала копирует весь vector, поэтому изменение оригинала безопасно и всегда незаметно текущему обходу Erase может инвалидировать текущий и последующие итераторы range-for После первого callback элементы vector становятся const до завершения цикла

Вопрос 8 из 30

Что такое reentrancy в Observer?

void Subject::notify(Event e) {
    for (auto& observer : observers_)
        observer(e); // callback может снова вызвать notify
}

Копирование события Повторный notify до конца текущего Наследование Observer Только recursive_mutex Вызов из другого процесса

Вопрос 9 из 30

Чем pull-модель отличается от push?

// push
observer.on_price_changed(new_price);
// pull
observer.on_changed();
auto price = subject.current_price();

Pull всегда выполняется асинхронно, а push — только в вызывающем потоке Push-модель не использует callback и требует периодического опроса Subject Модели различаются лишь названием метода notify, но передают одинаковые данные Push передаёт данные вместе с уведомлением, а pull сообщает об изменении и предлагает наблюдателю запросить нужное Pull-модель допускает ровно одного наблюдателя, потому что состояние читается напрямую

Вопрос 10 из 30

Как weak_ptr помогает в списке наблюдателей?

std::vector<std::weak_ptr<Observer>> observers;
for (auto it = observers.begin(); it != observers.end();) {
    if (auto observer = it->lock()) {
        observer->notify();
        ++it;
    } else {
        it = observers.erase(it);
    }
}

Он делает notify lock-free Он хранит объект без контрольного блока weak_ptr сам вызывает observer, когда Subject публикует новое состояние Он запрещает циклы вообще Subject хранит weak_ptr и пропускает истёкших

Вопрос 11 из 30

Какой результат естественен для фабрики единственного владельца полиморфного объекта?

struct Shape {
    virtual ~Shape() = default;
    virtual double area() const = 0;
};

std::unique_ptr<Shape> make_shape(const Config& config);

Возвращать `std::unique_ptr<Base>`, явно передавая единственное владение клиенту Возвращать Base по значению, полагаясь на сохранение динамического типа Возвращать сырой Base* без правила, кто и каким деструктором его освобождает Стирать тип до нетипизированного указателя и требовать отдельного cast у клиента Возвращать weak_ptr, хотя у объекта ещё нет сильного владельца

Вопрос 12 из 30

Что должна делать фабрика при неизвестном типе из конфигурации?

std::unique_ptr<Codec> make_codec(std::string_view name) {
    auto it = factories.find(name);
    if (it == factories.end())
        throw UnknownCodec{name, available_names()};
    return it->second();
}

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

Вопрос 13 из 30

Как registry factory позволяет плагинам добавлять типы?

using Creator = std::function<std::unique_ptr<Base>()>;
std::unordered_map<std::string, Creator> registry;

registry.emplace("json", [] {
    return std::make_unique<JsonCodec>();
});

Реестр связывает строковый или типовой ключ с callable, создающим соответствующий объект Каждый плагин расширяет один общий switch и требует пересобрать фабрику Плагин обязан наследоваться от контейнера реестра, например std::map Байты файла приводятся к объекту нужного класса без вызова конструктора Плагин вызывает глобальный new, а тип результата определяют по адресу памяти

Вопрос 14 из 30

Когда Abstract Factory оправдана?

struct UiFactory {
    virtual std::unique_ptr<Button> make_button() = 0;
    virtual std::unique_ptr<Menu> make_menu() = 0;
    virtual ~UiFactory() = default;
};

Как универсальная замена любого конструктора, даже если семейства объектов нет Для создания одного простого значения, не имеющего связанных вариантов Когда нужно создавать согласованные семейства взаимозависимых продуктов Чтобы полностью исключить динамический полиморфизм из клиентов фабрики Когда продукты никак не связаны и могут комбинироваться произвольно

Вопрос 15 из 30

Как compile-time factory может выбирать тип?

template<Backend backend>
auto make_renderer() {
    if constexpr (backend == Backend::vulkan)
        return VulkanRenderer{};
    else
        return SoftwareRenderer{};
}

Тип C++ можно создать из любого runtime имени без реестра Только dynamic_cast Выбрать тип через dlopen во время запуска и вернуть его как compile-time параметр шаблона Через template/if constexpr/traits по статическому параметру Через строку из сети без runtime

Вопрос 16 из 30

Когда variant+visit лучше виртуальной иерархии?

using Shape = std::variant<Circle, Rectangle, Polygon>;
for (const Shape& shape : shapes) {
    area += std::visit([](const auto& s) { return s.area(); }, shape);
}

Когда набор типов закрыт, а операции удобно выражать отдельными visitor Во всех случаях: variant полностью заменяет виртуальные интерфейсы без компромиссов Когда публичная граница должна оставаться стабильным C ABI между разными компиляторами Когда множество возможных типов принципиально открыто и неизвестно во время сборки Когда новые альтернативы добавляются сторонними плагинами после выпуска клиента

Вопрос 17 из 30

Когда обычная free function лучше Command class?

Result normalize(Document document) {
    remove_empty_nodes(document);
    sort_attributes(document);
    return document;
}
// операция не хранится, не ставится в очередь и не имеет undo

Никогда, функции не тестируются Когда нужна сложная история команд Только для private методов Для одноразовой операции без состояния и хранения Чтобы использовать RTTI

Вопрос 18 из 30

Как policy class отличается от Strategy?

Policy обычно выбирается статически как шаблонный параметр, Strategy — во время выполнения Различия нет: оба термина обозначают один обязательный способ реализации Policy представляет только виртуальный базовый класс с чистыми методами Policy загружается как runtime-плагин, а Strategy всегда зашита в бинарник Strategy не может хранить состояние, тогда как policy обязана его хранить

Вопрос 19 из 30

Когда data-oriented таблица переходов лучше State-классов?

Для конечной табличной машины состояний Когда набор расширяется плагинами без перекомпиляции Когда каждый state имеет огромную уникальную инфраструктуру Когда таблица не хранит данных перехода, а вся логика всё равно остаётся в разрозненных условных ветвях Когда состояния содержат сложное независимое поведение и расширяются отдельными модулями

Вопрос 20 из 30

Как ranges pipeline может заменить Visitor над простой коллекцией?

Ranges pipeline выполняет двойную виртуальную диспетчеризацию над каждым элементом и потому является разновидностью Visitor Ranges применим только к коллекции variant и требует std::visit внутри каждого адаптера Pipeline создаёт новые классы элементов и меняет их динамические типы Когда задача сводится к последовательной фильтрации, преобразованию и агрегации элементов Visitor обязателен для любого цикла, даже если тип элементов один и операции просты

Вопрос 21 из 30

Как проверить все Strategy реализации?

Проверить только реализацию, используемую по умолчанию Проверить адреса записей vtable, не вызывая методы стратегии Запускать один общий набор контрактных сценариев для каждой реализации стратегии Сравнить sizeof классов и считать одинаковый размер доказательством поведения Не формулировать общий контракт, чтобы каждая реализация тестировалась независимо

Вопрос 22 из 30

Как воспроизвести reentrancy-баг Observer?

Пусть callback повторно вызовет notify или изменит список подписок во время текущего обхода Добавить одного наблюдателя, который только читает состояние Subject Скопировать список наблюдателей перед вызовом и запретить callback менять подписки Выполнить два последовательных notify после полного завершения первого Вызвать notify на пустом списке и проверить, что обход завершается без ошибки

Вопрос 23 из 30

Что тестировать у registry factory?

Лишь скорость поиска ключа в map без вызова creator Реестр не следует очищать между тестами, чтобы сценарии зависели от порядка запуска Повторную регистрацию, неизвестные ключи, ошибки creator и корректность созданных объектов Один успешный встроенный тип; остальные ветви считаются эквивалентными Только длину строки ключа и её кодировку

Вопрос 24 из 30

Как mutation testing полезен для шаблонов проектирования?

Изменённые ветви и выбор стратегии показывают, замечают ли тесты существенную подмену поведения Mutation testing заменяет экспертную проверку архитектуры, если процент убитых мутантов высок Он изменяет только UML-диаграммы, не затрагивая исполняемый код Инструмент автоматически заменяет выбранный шаблон проектирования другим и ранжирует архитектуры Мутации применимы лишь к арифметическим операторам и не затрагивают выбор стратегии

Вопрос 25 из 30

Как проверить отсутствие цикла владения Observer?

Проверить use_count только во время работы, не разрушая владельца и подписчиков Сравнить только use_count во время работы Освободить обе стороны и проверить деструкторы/weak_ptr Вызвать notify после завершения процесса Сделать все ссылки shared

Вопрос 26 из 30

Что сравнивать при выборе virtual vs variant?

Считать variant безусловно быстрее и компактнее виртуального вызова на любой нагрузке Только длину синтаксиса Только один виртуальный вызов Сравнить только текущее число классов, не учитывая открытость набора типов и операции над ними Открытость типов, ABI и value semantics

Вопрос 27 из 30

Почему `std::function` может аллоцировать?

std::function<int(int)> operation;
operation = [state = std::array<int, 128>{}](int x) {
    return state[x % state.size()];
};
// Захват может не поместиться во внутренний малый буфер std::function.

std::function всегда хранит vector Любой указатель на функцию требует heap Аллокация происходит только при вызове Копирование запрещено Если callable не помещается в small-object buffer

Вопрос 28 из 30

Когда virtual interface лучше шаблонного API для стабильной библиотеки?

Когда нужен устойчивый двоичный интерфейс и открытый runtime-полиморфизм Когда обязательна полная статическая инлайнизация каждого вызова Когда каждый клиент должен видеть и инстанцировать всю реализацию для своих типов Когда двоичный интерфейс меняется без версии при каждом выпуске Только когда все реализации final и новые типы добавлять нельзя

Вопрос 29 из 30

Как слишком мелкая Strategy ухудшает дизайн?

Компилятор запрещает много классов Проблема только в тестах Инфраструктура превышает пользу от реальной заменяемости Strategy должна иметь не меньше 100 методов Мелкие классы всегда оптимальны

Вопрос 30 из 30

Какой признак говорит, что pattern стоит упростить?

Обвязка, регистрации и классы взаимодействуют сложнее, чем сама полезная вариативность задачи В интерфейсе присутствует виртуальный деструктор, соответствующий полиморфному удалению Для реализаций написаны отдельные модульные тесты Компилятор иногда способен девиртуализировать вызов в оптимизированной сборке Владение одной из реализаций выражено через unique_ptr

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

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

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

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