Интерактивный vs «одна команда = один запуск»

1. Почему возникает вопрос о двух режимах?

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

Давайте назовём их честно:

«Одна команда = один запуск» (one-shot).
Пользователь запускает программу с аргументами, программа делает ровно одно действие и завершает работу.

Интерактивный режим (interactive).
Пользователь запускает программу один раз, а дальше общается с ней в цикле: вводит команды строками, получает ответы, повторяет.

Важно: это не «две разные программы». В идеале это одно приложение, которое умеет работать по двум моделям.

Когда какой сценарий уместен

Иногда студенты пытаются выбрать режим «по красоте» или «по привычке». Лучше выбирать по тому, как программой будут пользоваться. Чтобы не держать всё в голове, удобно свести это в таблицу:

Главная мысль из таблицы простая: «правильного одного режима» нет. Правильный — тот, который соответствует сценарию.

2. One-shot режим: «сделал дело — закрылся»

One-shot режим кажется скучным ровно до тех пор, пока вы не попробуете автоматизировать что-нибудь в реальной жизни. Скрипты, CI, пайплайны, батч‑обработка файлов — всё это держится на предположении, что программа запускается, делает предсказуемое действие, печатает результат и завершается. Никаких «а теперь введите 1, чтобы продолжить». Машины не любят диалоги — они обижаются и начинают зависать.

Как выглядит структура one-shot программы

В упрощённой форме one-shot режим — это «конвейер»:

1. разобрали аргументы,
2. провалидировали,
3. выполнили действие,
4. вывели результат,
5. вернули код выхода.

Для визуализации очень полезно держать в голове простую блок-схему:

flowchart TD
    A[Старт процесса] --> B[Разбор argv]
    B --> C{Аргументы валидны?}
    C -- нет --> D[Сообщение об ошибке в cerr]
    D --> E[return != 0]
    C -- да --> F[Выполнить команду]
    F --> G[Результат в cout]
    G --> H[return 0]

Мини-пример: «одна команда — один запуск»

Пусть у нас есть совсем игрушечная команда --echo TEXT, которая печатает текст и выходит. Пример короткий, но он показывает «ритм» one-shot приложения:

#include <iostream>
#include <string_view>

int main(int argc, char* argv[]) {
    if (argc != 3 || std::string_view{argv[1]} != "--echo") {
        std::cerr << "Error: usage: app --echo TEXT\n";
        return 2;
    }

    std::cout << argv[2] << '\n'; // печатает TEXT
    return 0;
}

С точки зрения пользователя это удобно так:

• запустил;
• получил вывод;
• завершилось.

С точки зрения скрипта — ещё удобнее.

Что важно именно в one-shot режиме

В one-shot режиме ошибку аргументов обычно считают фатальной: если пользователь ввёл неправильные параметры, дальше выполнять нечего. Поэтому поведение «пишем ошибку и продолжаем как будто ничего» здесь вредно: лучше сразу завершиться с понятным сообщением и ненулевым кодом возврата.

Также one-shot режим любит «чистый stdout». Это значит, что если результат вашей программы — число или JSON или строка, то в std::cout должен быть только результат, без «Привет, пользователь!» и «Сейчас я посчитаю…». Всё «человеческое» и диагностическое лучше отправлять в std::cerr.

3. Интерактивный режим: мини‑REPL

Интерактивный режим появляется там, где пользователю важно «прощупать» систему: попробовать команды, посмотреть, что получилось, уточнить, повторить. Это характерно для учебных программ, маленьких админ‑утилит, внутренних тулов, а иногда и для серьёзных инструментов (вспомните python/node REPL или консоли баз данных).

Ключевая мысль: интерактивный режим — это цикл, и в этом цикле ошибка команды обычно не должна «убивать» программу целиком.

Базовый шаблон интерактивного цикла

Тут нас спасает старый добрый паттерн: печатаем приглашение, читаем строку через std::getline, разбираем, выполняем.

#include <iostream>
#include <string>

int main() {
    std::string line;

    while (true) {
        std::cout << "> ";
        if (!std::getline(std::cin, line)) {
            break; // EOF: пользователь закрыл ввод (Ctrl+D / Ctrl+Z)
        }

        std::cout << "You typed: " << line << '\n';
    }

    return 0;
}

Этот код делает важную вещь: он корректно выходит, если вход закончился. В реальной жизни это случается не только когда пользователь нажал «странные клавиши», но и когда вы подали программе вход из файла или пайпа.

Почему в интерактиве почти всегда сначала getline, а потом парсинг

Новички любят std::cin >> token, потому что «оно проще». Но интерактивный интерфейс обычно живёт строками. Пользователь может ввести команду с пробелами (например, заметку или текст задачи), и если вы читаете токены через >>, вы теряете всё после первого пробела.

Поэтому «правильный» подход:
сначала берём строку целиком (getline),
потом разбираем её на команду и аргументы (например, через std::stringstream, который вы уже видели раньше в курсе).

4. Как поддержать оба режима в одном приложении

Очень легко сделать так: «если есть аргументы — one-shot, если нет — интерактив». Это нормальный старт. Но как только добавляются флаги, дефолты и --help, хочется, чтобы код оставался читаемым, а не превращался в набор вложенных if.

Наша цель — структура, где main остаётся «тонким»: определяет режим и делегирует работу функциям.

Простое правило выбора режима

Сделаем простое, но полезное правило:

• если указан --interactive, мы всегда идём в интерактив;
• иначе, если кроме имени программы нет аргументов (argc == 1), тоже идём в интерактив;
• иначе — one-shot.

Это не «единственно верно», но это хороший старт: явный флаг имеет приоритет, а поведение «без аргументов» становится удобным для ручного запуска.

Код выбора режима

#include <string_view>

enum class Mode { one_shot, interactive };

Mode choose_mode(int argc, char* argv[]) {
    for (int i = 1; i < argc; ++i) {
        std::string_view arg = argv[i];
        if (arg == "--interactive") {
            return Mode::interactive;
        }
    }
    return (argc == 1) ? Mode::interactive : Mode::one_shot;
}

Обратите внимание: здесь мы не делаем «полный парсер аргументов». Мы только выбираем режим. Это важно: каждая функция должна решать одну задачу, иначе вы сами себе устроите баги (и бесплатную депрессию в комплекте).

5. Практический пример приложения: мини‑менеджер задач TaskPad

Дальше нам нужно не просто «поговорить о режимах», а почувствовать их в коде. Поэтому возьмём простое учебное приложение — менеджер задач. Мы будем хранить задачи в std::vector<std::string> (в памяти). Команды сделаем такие:

• add ТЕКСТ — добавить задачу (текст может быть с пробелами),
• list — показать все задачи,
• done N — отметить задачу выполненной (для простоты: удалим её),
• help — показать подсказку,
• quit — выйти (только для интерактива).

Сразу честно: это не промышленный todo-лист. Но он идеально подходит, чтобы увидеть разницу режимов.

Почему нам нужна «модель команды»

Если вы сделаете обработку команд прямо в main через «пять if-ов», оно заработает. Но как только вы захотите поддержать и one-shot, и интерактив, вы заметите дублирование: команды-то одни и те же, а источники ввода разные.

Значит, удобно иметь маленькую структуру Command, которую можно получить либо из argv, либо из введённой строки.

#include <string>

enum class CommandType { add, list, done, help, quit, unknown };

struct Command {
    CommandType type = CommandType::unknown;
    std::string arg; // для add это текст, для done это индекс строкой
};

Да, arg строкой — не идеально. Но для учебного примера это удобно: мы разберём индекс позже прямо перед выполнением.

6. Интерактивный режим в TaskPad

Сейчас мы соберём «сердце» интерактива: цикл, который не падает от первой же опечатки пользователя. В интерактивном режиме пользователь учится, экспериментирует, ошибается — и это нормально.

Разбор строки в команду

Нам нужно превратить строку вроде:

• add Buy milk
• done 2
• list

в Command.

#include <sstream>
#include <string>

Command parse_line(const std::string& line) {
    std::stringstream ss(line);

    std::string verb;
    ss >> verb;

    if (verb == "list") return {CommandType::list, ""};
    if (verb == "help") return {CommandType::help, ""};
    if (verb == "quit") return {CommandType::quit, ""};

    if (verb == "done") {
        std::string idx;
        ss >> idx;
        return {CommandType::done, idx};
    }

    if (verb == "add") {
        std::string rest;
        std::getline(ss, rest);          // rest начинается с пробела
        if (!rest.empty() && rest[0] == ' ') rest.erase(0, 1);
        return {CommandType::add, rest};
    }

    return {CommandType::unknown, verb};
}

Заметьте маленький трюк: после add мы забираем «остаток строки целиком». Это делает команду add удобной для человека: можно писать текст задачи как угодно, не экранируя пробелы.

Выполнение команды

Теперь сделаем функцию, которая выполняет команду над нашим vector задач. Пусть она возвращает bool: true — продолжаем, false — выходим из интерактивного цикла.

#include <iostream>
#include <vector>

bool execute(std::vector<std::string>& tasks, const Command& cmd) {
    if (cmd.type == CommandType::list) {
        for (std::size_t i = 0; i < tasks.size(); ++i) {
            std::cout << (i + 1) << ") " << tasks[i] << '\n';
        }
        return true;
    }

    if (cmd.type == CommandType::add) {
        if (cmd.arg.empty()) {
            std::cerr << "Error: add requires text\n";
            return true;
        }
        tasks.push_back(cmd.arg);
        std::cout << "Added.\n";
        return true;
    }

    if (cmd.type == CommandType::quit) {
        return false;
    }

    std::cerr << "Error: unknown command\n";
    return true;
}

Мы пока не реализовали done и help, чтобы не перегрузить один кусок кода. Главное — увидеть подход: одна функция «понимает команду», и её можно вызывать из любого режима.

Интерактивный цикл TaskPad

Теперь собираем цикл:

#include <iostream>
#include <string>
#include <vector>

int run_interactive() {
    std::vector<std::string> tasks;
    std::string line;

    std::cout << "TaskPad interactive. Type 'help' or 'quit'.\n";

    while (true) {
        std::cout << "> ";
        if (!std::getline(std::cin, line)) break;

        Command cmd = parse_line(line);
        if (!execute(tasks, cmd)) break;
    }

    return 0;
}

Здесь есть три важных UX-момента.

Во-первых, приветствие в интерактиве — нормально: пользователь «зашёл внутрь» программы.

Во-вторых, промпт > печатается только в интерактивном режиме. В one-shot он был бы мусором в stdout.

В-третьих, выход по EOF работает корректно: это важная «вежливость» к пайпам/файлам.

7. One-shot режим в TaskPad

Теперь делаем версию, когда команда задаётся через argv. Сразу поясню: если мы не сохраняем задачи в файл, one-shot менеджер задач выглядит «странно», потому что при каждом запуске список пустой. Но как учебный пример структуры (режимы, разбор, выполнение) — он отлично подходит.

Парсим argv в команду

Сделаем очень простой контракт:

• app list
• app add TEXT... (тут проблема: TEXT... будет разбит на несколько argv, мы соберём его обратно)
• app done N

#include <string>

Command parse_argv(int argc, char* argv[]) {
    if (argc < 2) return {CommandType::help, ""};

    std::string verb = argv[1];
    if (verb == "list") return {CommandType::list, ""};
    if (verb == "help") return {CommandType::help, ""};

    if (verb == "done" && argc >= 3) {
        return {CommandType::done, argv[2]};
    }

    if (verb == "add" && argc >= 3) {
        std::string text = argv[2];
        for (int i = 3; i < argc; ++i) {
            text += ' ';
            text += argv[i];
        }
        return {CommandType::add, text};
    }

    return {CommandType::unknown, verb};
}

Да, это ручная склейка. В one-shot режиме пользователь мог бы писать app add "Buy milk" (кавычки склеят аргумент на уровне shell), но мы не хотим зависеть от тонкостей оболочек — поэтому показываем подход, который работает «как есть».

Запуск one-shot

#include <iostream>
#include <vector>

int run_one_shot(int argc, char* argv[]) {
    std::vector<std::string> tasks;

    Command cmd = parse_argv(argc, argv);
    bool ok = execute(tasks, cmd);

    if (!ok) {
        std::cerr << "Error: quit is not meaningful in one-shot mode\n";
        return 2;
    }
    return 0;
}

Обратите внимание на деталь: команда quit логична только в интерактиве, а в one-shot она бессмысленна (процесс и так завершится). Такие «семантические различия» — нормальны. Главное, чтобы программа объясняла их понятным сообщением.

8. Тонкий main: режим выбираем, логику делегируем

Финальный кусок: main определяет режим и вызывает нужную функцию. Это выглядит скучно — а значит, правильно.

#include <iostream>

int main(int argc, char* argv[]) {
    Mode mode = choose_mode(argc, argv);

    if (mode == Mode::interactive) {
        return run_interactive();
    }

    return run_one_shot(argc, argv);
}

Если ваш main примерно такой — поздравляю: вы уже пишете код так, как пишут «взрослые» утилиты. Не потому что это модно, а потому что это ремонтопригодно.

9. Политика ошибок: интерактив vs one-shot

Сейчас важная мысль, ради которой вообще стоило городить два режима.

В one-shot режиме ошибка — это почти всегда «ничего не сделано», и программа должна сообщить об этом через std::cerr и ненулевой код выхода.

В интерактивном режиме ошибка — это чаще «пользователь опечатался», и программа должна:

• сказать, что не так,
• подсказать help,
• продолжить цикл.

Это приводит к разной «политике ошибок», даже если команды одинаковые. И это нормально. Более того, это признак того, что вы думаете про UX, а не просто про компиляцию.

10. Типичные ошибки

Ошибка №1: интерактивный промпт печатается всегда, даже в one-shot режиме.
Так ломается сценарий автоматизации: ваш stdout засоряется строками > , и скрипты, которые ожидали «чистый результат», начинают плакать. Привыкайте к мысли, что промпт — это часть интерактивного интерфейса и должен появляться только там.

Ошибка №2: в интерактиве читают команды через std::cin >> token.
Первые тесты проходят, пока команды без пробелов. Потом появляется add Buy milk, и внезапно задача превращается в Buy, а milk остаётся висеть в потоке ввода как «следующая команда». Правильная привычка: сначала std::getline, потом парсинг строки.

Ошибка №3: в интерактивном режиме любая ошибка завершает программу.
Пользователь опечатался — и всё, «до свидания». Это раздражает сильнее, чем кажется: интерактив создан как раз для того, чтобы ошибаться безопасно. Лучше печатать ошибку в std::cerr и продолжать цикл, оставляя «жёсткий выход» для quit или EOF.

Ошибка №4: one-shot и интерактив реализованы как две почти одинаковые копии логики.
Сначала вы пишете «быстро и просто», потом добавляете вторую версию, потом чините баг в одной и забываете чинить в другой. Итог: два разных поведения, которые расходятся всё сильнее. Лечится архитектурой: команда парсится в общую модель (Command), а выполнение команд — одна функция execute(...).

Ошибка №5: отсутствует понятная команда выхода и понятный help.
Интерактив без help и quit превращается в «комнату без дверей»: пользователь тыкается, не понимает синтаксис, не понимает как выйти, и начинает завершать программу через закрытие терминала (что работает, но выглядит как крик о помощи). Даже минимальный help резко повышает дружелюбность интерфейса.