История изменений

Я может непопулярную вещь скажу, но не надо запихивать обработку команд в словарь std::map. Простой if-else-if-else намного выразительней и гибче. На каждую команду ты сможешь вызвать какие-то обработчики, только с теми параметрами, что ему нужны. Или обработать команду-однострочник сразу на месте. Также ты можешь сделать обработку паттернов, например cmd.startsWith(prefix). Словарь же фиксирует и обобщает интерфейс обработчиков, заставляет выносить даже тривиальные обработчики в отдельную функцию или класс. Кроме того, словарь — это элемент рантайма и дополнительный источник энтропии. Что, если он мутабельный — держи в голове, откуда он модифицируется. Что, если команда записана в словаре, но ее обработчик не установлен (nullptr) — определяй семантику, ошибка это или эквивалент отсутствия команды в словаре. Что, если обработчик команды удалён — контролируй лайфтаймы (привет, ржавая мразь).

Хоть это и может показаться тривиальным, в перспективе развития проекта множеством людей (они приходят и уходят) на длительный период, чем больше такой динамики, тем больше и больше распухает контекст и информационный шум, с которыми приходится иметь дело программистам. Я не говорю, что динамика — плохо, но у неё должна быть лучшая причина чем «чтоб было красиво».

Я может непопулярную вещь скажу, но не надо запихивать обработку команд в словарь std::map. Простой if-else-if-else намного выразительней и гибче. На каждую команду ты сможешь вызвать какие-то обработчики, только с теми параметрами, что ему нужны. Или обработать команду-однострочник сразу на месте. Также ты можешь сделать обработку паттернов, например cmd.startsWith(prefix). Словарь же фиксирует и обобщает интерфейс обработчиков, заставляет выносить даже тривиальные обработчики в отдельную функцию или класс. Кроме того, словарь — это элемент рантайма и дополнительный источник энтропии. Что, если он мутабельный — держи в голове, откуда он модифицируется. Что, если команда записана в словаре, но ее обработчик не установлен — определяй семантику, ошибка это или эквивалент отсутствия команды в словаре. Что, если обработчик команды удалён — контролируй лайфтаймы (привет, ржавая мразь).

Хоть это и может показаться тривиальным, в перспективе развития проекта множеством людей (они приходят и уходят) на длительный период, чем больше такой динамики, тем больше и больше распухает контекст и информационный шум, с которыми приходится иметь дело программистам. Я не говорю, что динамика — плохо, но у неё должна быть лучшая причина чем «чтоб было красиво».

Я может непопулярную вещь скажу, но не надо запихивать обработку команд в словарь std::map. Простой if-else-if-else намного выразительней и гибче. На каждую команду ты сможешь вызвать какие-то обработчики, только с теми параметрами, что ему нужны. Или обработать команду-однострочник сразу на месте. Словарь же фиксирует и обобщает интерфейс обработчиков, заставляет выносить даже тривиальные обработчики в отдельную функцию или класс. Кроме того, словарь — это элемент рантайма и дополнительный источник энтропии. Что, если он мутабельный — держи в голове, откуда он модифицируется. Что, если команда записана в словаре, но ее обработчик не установлен — определяй семантику, ошибка это или эквивалент отсутствия команды в словаре. Что, если обработчик команды удалён — контролируй лайфтаймы (привет, ржавая мразь).

Хоть это и может показаться тривиальным, в перспективе развития проекта множеством людей (они приходят и уходят) на длительный период, чем больше такой динамики, тем больше и больше распухает контекст и информационный шум, с которыми приходится иметь дело программистам. Я не говорю, что динамика — плохо, но у неё должна быть лучшая причина чем «чтоб было красиво».