Почему так много программ используют конфигурации в стиле "foo.bar.baz = qux"?
Я заметил, что тонны программ хранят информацию о конфигурации в различных иерархических ключах. Например, Firefox about:config имеет такие ключи, как network.http.pipelining а также network.http.pipelining.ssl а также network.http.use-cache, Я заметил этот стиль конфигурации в Firefox, в OS X (Library/Preferences), в sysctlсреди других. Почему это так часто? Была ли какая-то ранняя программа, которая использовала это, так что другие копировали это?
2 ответа
Это иерархическое соглашение призвано обеспечить ясность, помогая нам узнать сферу влияния каждого параметра и различить несколько параметров с одинаковым или неоднозначным именем среди различных модулей.
Это полезно в приложениях со слишком большим количеством возможных настроек, чтобы включить их в основные страницы параметров пользователя (где иерархия показана вкладками или страницами), и хорошей альтернативой обычным файлам INI (с [title] разделители разделов), которые более подвержены ошибкам пользователя и обычно требуют перезапуска приложения для вступления в силу.
Параметры иерархии также могут в определенной степени отражать внутреннюю нисходящую объектно-ориентированную модель, используемую разработчиками:
В этой примерной модели мы могли бы очень хорошо представить, что там будет задан параметр person.profess.disallow_strikes = true, в то время как student.disallow_strikes может оставаться равным false или быть недоступным вообще. Это разделение также является основой для пространств имен в языках программирования (и популярная платформа.NET придерживается того же соглашения об именах: using System.Threading.Tasks).
Итак, теперь мы можем предположить, что network.http.xxx настройка не должна влиять на network.ftp или другие сетевые подмодули, в то время как network.xxx настройки, вероятно, будут влиять на всех из них.
Дополнительная информация полезна...
для пользователя: у нас есть лучшее представление о том, на какую часть приложения будет влиять данный параметр, что облегчает устранение проблем (и позволяет избежать!)
и для разработчиков: человек, работающий над конкретным модулем или устраняющий его проблемы, может легко знать, какие изменяемые пользователем настройки могут повлиять на его / ее текущую работу, и сосредоточиться на этом.
Вы упомянули одну из основных причин в своем первом предложении: иерархические ключи.
Каждая группа ключей сгруппирована. Все связанные с сетью ключи являются сетевыми. Все связанные с http ключи - network.http.something и так далее. Это делает сам ключ несколько самодокументирующим, к чему относится значение. Если использовать стиль файла INI (который, как понятно, ничто не помешает вам использовать эти виды ключей, если вы хотите) с парами [section] и ключ = значение, данный ключ может быть неоднозначным, пока раздел не будет известен. Более того, размещение ключей в файле очень важно. Вставка ключа ssl в раздел [GUI], вероятно, является ошибкой и может привести к игнорированию ключа. Стиль abc должен означать, что порядок ключей в файле не имеет значения. Если вы читаете network.http.ssl.key =, не имеет значения, была ли предыдущая строка gui.background.color = или что-то еще. Полный ключ называется.
Почему это так часто? Это чертовски полезно, вот почему. Людям также легко читать и понимать (от ключа к ключу) и редактировать.
Откуда это? Я бы сказал, что структуры в стиле C, которые, вероятно, имеют происхождение, о котором я не знаю, и которые также проникли во многие другие языки программирования. Установка значения в структуре C будет иметь значение struct.property=value, а для вложенных структур struct.substructure.property=value и т. Д. (Хотя в реальной жизни указатели вместо этого переводят многие из этих точек в ->, но это мелкая мелочь).