Действительно ли ИНТЕРПРЕТАТОР является антишаблоном?

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

Знание того, когда использовать шаблон, - вот что мешает ему стать анти-шаблоном.

Любой шаблон проектирования при неправильном использовании является анти-шаблоном.

Хорошее использование Шаблон интерпретатора :

• Программный компилятор
• Механизм оценки SQL
• Анализатор входных данных графического калькулятора
• Анализатор XML

Все это программы, которые решают проблему вычисления слов на языке , каким бы он ни был .

Имейте в виду, что «шаблон интерпретатора» - это особый шаблон проектирования в ООП.

Он не имеет ничего общего с «интерпретаторами» или их использованием в целом.

Возможно, реализация компилятора Лиспа включает пример паттерна Интерпретатор.

Я не думаю, что вам следует говорить, что, например, «колесо» - это антишаблон , хотя обычно вам следует покупать колеса в готовом виде, а не изобретать их заново.

Интерпретатор - это идея, лежащая в основе генератора синтаксического анализатора JavaCC. Думаю работает нормально.

Интерпретатор - гораздо более респектабельный шаблон GoF, чем Синглтон. Это тот, за который нужно проголосовать за пределами острова. Может быть, и Memento.

Одна из причин изобретения XML состояла в том, чтобы спасти нас от написания интерпретаторов EDI; но по крайней мере объем был четко определен, и все мы сделали это примерно одинаково (по крайней мере, достаточно) эффективно. По крайней мере, я все еще достаточно заблуждаюсь, чтобы думать, что это было правильным поступком.

Похоже, вы пытаетесь создать новую городскую легенду? Вы врожденный противник доменных языков?

Обычно фазы компилятора / интерпретатора выглядят следующим образом:

1. Синтаксис
2. Дерево синтаксического анализа
3. AST
4. Компиляция или интерпретация

В Лиспе, 1 и 2 объединены в 3.

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

Однако я должен сказать, что рукописное написание AST-деревьев неприятно и не является концом всего языка, независимо от того, сколько лисперов это утверждают.

В какой-то момент проекту, вероятно, понадобится конфигурация система. что-то простое - это обычно все, что нужно сначала, что-то вроде пар ключ-значение, чтобы система могла подключиться к локальной базе данных, или что-то подобное. Если это все, что нужно, принято просто взломать простой парсер для диалекта INI или CSV и двигаться дальше. Но по мере роста и развития системы все большее значение приобретает конфигурация. Это нормальная и здоровая функция рефакторинга и ответственность перед правильным уровнем абстракции. С этого момента разработчики или даже пользователи (задыхаясь) захотят более выразительного языка конфигурации. Прежде чем кто-либо заметит, в систему встроен и используется полный язык Тьюринга.

Это основной паттерн Гринспаннинга. Все было хорошо спроектировано вплоть до последнего бита, когда специальный язык был внедрен в сферу реальной вычислительной работы.

Любая система приличного размера, вероятно, должна содержать хотя бы половину clisp.

Знать это заранее - большой шаг. Очень удобный способ написания больших систем - выбрать красивый, легко взломанный интерпретирующий язык и написать на нем свою систему. Это именно то, для чего предназначен TCL, но в наши дни трудно привлечь кого-нибудь, кто стоит за большим проектом на этом языке. С другой стороны, существует множество других языков, которые теперь предлагают все эти преимущества.

Преимущество такого подхода - Active File Pattern . Простые конфигурации написаны способом, совместимым с анализатором языка, доступным в системе. Поскольку файл анализируется языком, можно легко встроить более сложную логику.

Примером этого является файл settings.py django. По какой-то причине django не очень умно угадывает, где установлен проект django. Используя небольшое количество стандартного python в файле конфигурации, это может быть обработано в общем случае переносимым способом, который подойдет почти каждому возможному пользователю. Несмотря на это, большая часть файла settings.py выглядит как простые старые пары ключ = значение, типичные для файлов конфигурации в стиле .ini.

Связь с паттерном интерпретатора заключается в том, что эти зрелые языки, вероятно, получат паттерн правильно даже для некоторых патологических применений. Как только вы поймете, что вам нужно что-то проанализировать, придумайте очень вескую причину не использовать для этого существующий язык.

файлы конфигурации в стиле ini.

Связь с паттерном интерпретатора заключается в том, что эти зрелые языки, вероятно, получат паттерн правильно даже для некоторых патологических применений. Как только вы поймете, что вам нужно что-то проанализировать, придумайте очень вескую причину не использовать для этого существующий язык.

файлы конфигурации в стиле ini.

Связь с паттерном интерпретатора заключается в том, что эти зрелые языки, вероятно, получат паттерн правильно даже для некоторых патологических применений. Как только вы поймете, что вам нужно что-то проанализировать, придумайте очень вескую причину не использовать для этого существующий язык.

Шаблон интерпретатора не подразумевает написания полного общего языка сценариев. Если вам это нужно, очевидно, было бы разумнее использовать хорошо известный язык, о котором люди уже написали хорошие книги (или, что лучше всего, чтобы позволить пользователю выбирать язык).

Шаблон интерпретатора больше об идее сохранения графа объектов, но с выбором формата сохранения, который удобен для чтения и редактирования человеком (например, 2 + 3 , представляющий объект Addition с указателями на пару Целочисленные объекты). Даже если он никогда не раскрывается клиентам как «язык», он все равно помогает отладке, поддержке, взлому на месте и так далее. Другими распространенными примерами могут быть языки запросов, такие как HQL в [N] Hibernate - ни один существующий язык не был бы столь же хорош для описания запроса на этом уровне абстракции.

Как предполагали другие, XML обычно используется как базовый синтаксис для этого (особенно если рассматривать постоянный граф объектов как «файл конфигурации» и см. также XAML от Microsoft), но на самом деле это неоптимальный выбор. JSON в UTF-8 (или аналогичном) будет чище, проще для синтаксического анализа, более читаемым и редактируемым, а значит, вероятно, лучше для большинства приложений. Но есть несколько отличных облегченных библиотек синтаксического анализатора, которые принимают описание синтаксиса, подобное BNF, а затем могут анализировать текст в структуру, похожую на DOM, и все это во время выполнения, поэтому создание узкоспециализированного краткого синтаксиса не проблема.

XML обычно используется в качестве базового синтаксиса для этого (особенно при представлении графа постоянных объектов как «файла конфигурации» и см. Также Microsoft XAML), но на самом деле это неоптимальный выбор. JSON в UTF-8 (или аналогичном) будет чище, проще для синтаксического анализа, более читаемым и редактируемым, а значит, вероятно, лучше для большинства приложений. Но есть несколько отличных облегченных библиотек синтаксического анализатора, которые принимают описание синтаксиса, подобное BNF, а затем могут анализировать текст в структуру, похожую на DOM, и все это во время выполнения, поэтому создание узкоспециализированного краткого синтаксиса не проблема.

XML обычно используется в качестве базового синтаксиса для этого (особенно при представлении графа постоянных объектов как «файла конфигурации» и см. Также Microsoft XAML), но на самом деле это неоптимальный выбор. JSON в UTF-8 (или аналогичном) будет чище, проще для синтаксического анализа, более читаемым и редактируемым, а значит, вероятно, лучше для большинства приложений. Но есть несколько отличных облегченных библиотек синтаксического анализатора, которые принимают описание синтаксиса, подобное BNF, а затем могут анализировать текст в структуру, похожую на DOM, и все это во время выполнения, поэтому создание узкоспециализированного краткого синтаксиса не проблема.

и поэтому, вероятно, лучше для большинства приложений. Но есть несколько отличных облегченных библиотек синтаксического анализатора, которые принимают описание синтаксиса, подобное BNF, а затем могут анализировать текст в структуру, похожую на DOM, и все это во время выполнения, поэтому создание узкоспециализированного краткого синтаксиса не проблема.

и поэтому, вероятно, лучше для большинства приложений. Но есть несколько отличных облегченных библиотек синтаксического анализатора, которые принимают описание синтаксиса, подобное BNF, а затем могут анализировать текст в структуру, похожую на DOM, и все это во время выполнения, поэтому создание узкоспециализированного краткого синтаксиса не проблема.