Это плохо или нормуль ?

Как-то раз у меня была нужда написать командный интерпретатор.
При том, что я совершенно не представлял себе как это делать.
Почесал репу и придумал такой вариант:

Пишется класс с кучей методов на все нужные команды.
Далее интерпретатор берет строку и пробует найти нужный метод с соотв. параметрами.
В строке сначала команда - имя метода, далее параметры через пробел.
Если валидация прошла, вызываем метод через рефлексию.

Вышло с одной стороны просто и быстро, с другой стороны сомнительно.

Как думаете, так норм или стоило поискать других вариантов ?

Я-бы сделал чуть иначе.

Один объект класса 1, который представляет собой командную строку и её разбор (разделение на команду и параметры). Плюс поиск обработчика.
В нем регистрируются объекты потомки абстрактного класса 2 - команды. В них есть идентификаторы команд и метод обработки параметров с возвращаемым результатом.

Когда будет нужна новая команда, то создается потомок класса 2 и регистрируется в объекте класса 1.

А я бы не парился и задействовал Bison.

grok,

Специально для этого существуют учебники. В первую очередь: "Драконья книга"

Dimitry Sibiryakov
А я бы не парился и задействовал Bison.

сначала flex

- читаем входную строку
- разбиваем её на две (по первому пробелу): команда и аргументы
- команду ищем в ассоциативном массиве (мапе) cmdName -> Command, где Command - интерфейс с одним методом Result run(String arguments)
- вызываем реализацию нужной команды, реализация сама парсит свои аргументы, делает полезную работу и возвращает результат для вывода на экран.

grok
Вышло с одной стороны просто и быстро, с другой стороны сомнительно. Как думаете, так норм или стоило поискать других вариантов ?

так смотря сколько команд, насколько сложных и вариативных, будет ли это все развиваться и разрастаться со временем, на каком языке, нет ли на нем уже готовых решений? Я думаю что ==поиск вариантов== - не самоцель. кусок проги может быть не идеален, но если у него вполне понятный интерфейс, такой что его можно выдернуть и заменить - это нормально. По моему.

Сделал бы почти как wadman.

Парсер командной строки, в котором регистрируются доступные команды по имени (для простого и быстрого поиска в какой-нить хэш массив загнал бы)
Сами команды представляют из себя тоже объекты с методами parse (предопределённый, но каждая команда может его переписать под свои нужды и разбирать собственные параметры как ей вздумается) и run (а этот абстрактный, разумеется, что бы каждая команда его определила под себя).

Тогда основной парсер читает только название команды и передаёт управление непосредственно нужному объекту, а тот устанавливает свои атрибуты самостоятельно и запускает run. Ещё в объект команды можно было бы запихнуть разные методы help и другую вспомогательную мелочь для удобства

scf
реализация сама парсит свои аргументы

мне казалось, реализации вообще лучше не знать что оно в каком-то интерпретаторе используется.
single responsibility принцип.

разве только сделать трехслойную схему.

PS: а всякие лексические/синтаксические анализаторы,
это имхо "микроскопом гвозди забивать"
для задач такого уровня.

grok
scf реализация сама парсит свои аргументы мне казалось, реализации вообще лучше не знать что оно в каком-то интерпретаторе используется. single responsibility принцип. разве только сделать трехслойную схему. PS: а всякие лексические/синтаксические анализаторы, это имхо "микроскопом гвозди забивать" для задач такого уровня.

А при таком подходе она и не знает. Тут следует уточнить, что команда по сути принимает 1 строковый параметр, но как его интерпретировать решает самостоятельно. Тут было бы менее правильно возлагать такую работу на глобальный объект, который понятия не имеет для чего будет использоваться та или иная команда и что ей может для работы понадобиться.

Если возлагать эту работу на основной интерпретатор, то команды придётся заганять в узкие рамки протокола получения аргументов, а это минус к гибкости.