То, что вы предлагаете, не расточительно;скорее вы просто страдаете от компромисса между «многофункциональным» и «простым» (в отношении интерфейса и анализа).
Мы сделали то, что вы предлагаете лот ,Главный вопрос: Могу ли я упростить это (например, как «таблица переходов» при разборе), или мои требования и реализация разбора требуют инфраструктуры, позволяющей в будущем расширение для конкретного приложения?
Основываясь на ответе на вопрос, мы сделали оба: лот :
Если "нет" , у вас есть дискретный (длинный) список(плоского) разбора, когда вы «пытаетесь» проанализировать команду (с ее параметрами), потерпеть неудачу, а затем перейти к следующей попытке и т. д., пока не пропустите все двадцать (или некоторое число) командкоторые "проверены". Преимущество : Плоская, простая, каждая команда может иметь свои собственные пользовательские параметры (поскольку каждая попытка анализа может проверять параметры, специфичные для этой команды). не требует от вас наличия класса для каждой команды (но вы можете, если хотите).Например, у вас может быть класс single MyCommand, который пытается проанализировать себя двадцатью различными способами, чтобы получить двадцать различных типов перечисляемых команд с различными параметрами.
If "да ", вы инвестируете в рамки.Как правило, это получить «движок», который может быть расширен в зависимости от приложения.В нашем случае он также имеет тенденцию отражать несколько иерархий команд, где каждая иерархия может быть "расширена" для команд специфичными для приложения способами.И, поскольку это отдельные иерархии, мы получаем большие преимущества в повторно используемом состоянии и логике (с общими базовыми классами для разных иерархий).В этом случае «основа» каждой иерархии «нюхает» команду и, если она совпадает, выясняет, какой из производных экземпляров должен выполнять анализ и инстанцирование.Это значительно упрощает синтаксический анализ, потому что у вас разные потребности в обработке данных для разных иерархий (и этот код установлен в базе), и у вас нет парсера-монстра.Как правило, у нас есть производный класс для каждого типа команды с его собственными требованиями к пользовательским параметрам.Эти производные классы сгруппированы в «иерархии», которые могут (или не могут) иметь общий базовый класс (например, модель «дерево» или «лес»).
Если вы ожидаете, что ваш протокол будет относительно ограниченным/ без изменений, с непротиворечивыми параметрами и типами команд, "flat" отлично работает.Если вам нужна расширяемость для конкретного приложения, продолжайте и вкладывайте средства в инфраструктуру типа «одна команда на класс» - после «трудозатрат» для первоначальной реализации это работает ОТЛИЧНО, особенно когда вы позже понимаете, что ваши параметры неверны и выНужно изменить реализацию (что происходит постоянно).Это намного проще сделать с помощью одной команды на класс (которая также содержит анализ вашей команды, а не супер-монстр-мастер-парсер), хотя я допускаю, что это было намного большекод для установки этой инфраструктуры.