tf.exe является интерфейсом командной строки для Team Foundation Server.
В моем случае сложность и структура перестановок ключей командной строки аналогичны.В приложении с графическим интерфейсом имеется около двух десятков различных типов отчетов, которые я пытаюсь использовать из командной строки (я могу сделать это через надстройку), и будет около полудюжины различных команд.Я начну с реализации простейшей функциональности, но затем добавлю сложности, так как у меня больше времени.Это означает, что это будет продолжать развиваться, и я никогда не буду знать исчерпывающий список всех возможных перестановок.
В общем, синтаксис cli будет:
Manipulate.exe <Command> <ReportType> <Followed by options that depend on the first two switches>
Например:
Manipulate.exe Open ABCReport /option1:"1 2 3" [/option2:2 [/option3:"3 3"]] | /option4:4 | /option5
Manipulate.exe Open XYZReport /option1:"1 2 3" /option2:2 [/option3]
...
Manipulate.exe Close ABCReport (/reportid:987 | /reportmnemonic:"ABC12 Report")
Manipulate.exe Close XYZReport (/reportid:876 | /reportmnemonic:"ZYZ98 Report")
...
Manipulate.exe Refresh ABCReport (/reportid:987 | /reportmnemonic:"ABC12 Report")
Manipulate.exe Refresh XYZReport (/reportid:876 | /reportmnemonic:"ZYZ98 Report")
...
Manipulate.exe SelectRows ABCReport (/reportid:987 | /reportmnemonic:"ABC12 Report") <followed by select criteria flags>
Manipulate.exe SelectRows XYZReport (/reportid:876 | /reportmnemonic:"ZYZ98 Report") <followed by select criteria flags>
....
В связи со сложностью этого, я думаю о том, чтобы хотя бы частично развернуть свою собственную логику синтаксического анализа, например, было бы abstract ReportOpener, ReportCloser, ReportRefresher, ReportRowsSelector,и т. д. класс (все потомки абстрактного ReportManipulator), а затем более конкретные классы, такие как ABCReportOpener, ABCReportRowSelector и т. д., которые должны будут реализовать PrintUsage, ParseArguments, PerformAction.Может существовать простой диспетчер, который просматривает первые два аргумента, проверяет правильность типа команды и отчета и затем пытается выполнить диспетчеризацию по этой комбинации (если она реализована / может быть найдена) путем создания правильного подкласса.
Я думаю, что мне понадобятся абстрактные классы - так родительский класс сможет реализовать некоторые общие задачи.Однако в моем случае диспетчеризация не является произвольной, как в мульти-методической диспетчеризации, а является иерархической, поэтому я хотел бы как-то использовать силу ОО.Если бы только ReportOpener, ReportCloser, ReportRefresher, ReportManipulator могли бы быть созданы и иметь знания всех своих потомков, а также способность извлекать нужного потомка на основе значения только ОДНОГО переключателя командной строки.... но тогда они не могут быть abstract.
Это разумный подход к этой задаче или вы можете предложить что-то лучшее?Какая библиотека лучше всего подходит для анализа оставшихся (с третьего по последний) аргументов, учитывая приведенный выше пример синтаксиса?