Что отличает Ruby DSL от обычного API

Question

Каковы некоторые определяющие характеристики Ruby DSL, которые отличают его от обычного API?

Answer 1

Когда вы используете API, вы создаете экземпляры объектов и вызываете методы обязательным образом. С другой стороны, хороший DSL должен быть декларативным и представлять правила и отношения в вашей проблемной области, а не инструкции, которые нужно выполнить. Более того, в идеале DSL должен быть читаем и изменяем кем-то, кто не является программистом (что не относится к API).

Также имейте в виду различие между внутренним и внешним DSL.

• Язык, специфичный для внутреннего домена встроен в язык программирования (например, Ruby). Это легко реализовать, но структура DSL зависит от родительского языка, в который он встроен.
• Язык, специфичный для внешнего домена - это отдельный язык, разработанный с учетом конкретного домена. Это дает вам большую гибкость, когда дело доходит до синтаксиса, но вы должны реализовать код для его интерпретации. Это также более безопасно, так как человек, редактирующий правила домена, не имеет доступа ко всем возможностям родительского языка.

Answer 2

DSL (предметно-ориентированный язык) - это чрезмерно раскрученный термин. Если вы просто используете подмножество языка (скажем, Ruby), чем он отличается от оригинала? Ответ таков.

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

Answer 3

Создание DSL:

• Добавление новых методов в класс Object, чтобы вы могли просто вызывать их, как если бы они были встроенными языковыми конструкциями. (см. грабли)

• Создание методов для пользовательского объекта или набора объектов, а затем наличие файлов сценариев для запуска операторов в контексте объекта верхнего уровня. (см. Капистрано)

Дизайн API:

• Создание методов для пользовательского объекта или набора объектов, поэтому пользователь создает объект для использования методов.

• Создание методов как методов класса, так что пользователь ставит префикс имени класса перед всеми методами.

• Создание методов в виде смеси, которую пользователи включают или расширяют для использования методов в своих пользовательских объектах.

Так что да, между ними тонкая грань. Преобразовать пользовательский набор объектов в DSL просто, добавив один метод, который запускает файл сценария в нужном контексте.

Answer 4

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

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

Answer 5

На самом деле это одно и то же. DSL, как правило, реализуются с помощью обычных языковых механизмов в Ruby, поэтому технически они все API.

Однако, чтобы люди распознавали что-то как DSL, обычно заканчивалось добавлением в существующие классы декларативных операторов. Что-то вроде валидаторов и объявлений отношений в ActiveRecord.

class Foo << ActiveRecord::Base
  validates_uniqueness_of :name
  validates_numericality_of :number, :integer_only => true

end

выглядит как DSL, а следующее - нет:

class Foo <<ActiveRecord::BAse
  def validate
    unless unique? name
      errors.add(:name, "must be unique")
    end

    unless number.to_s.match?(/^[-]?\d$/)
      errors.add(:number, "must be an integer")
    end
  end
end

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

Answer 6

Разница между DSL и API для меня заключается в том, что DSL мог бы быть, по крайней мере, понят (и проверен), если бы кто-то в этом домене не написал его как дополнительный язык Ruby.

Например, у вас могут быть финансовые аналитики, пишущие правила для приложения для торговли акциями в Ruby DSL, и им никогда не придется знать, что они используют Ruby.