Есть объект класса Settings, ссылка на который запрашивается через Registry::getSettings() в конструкторах моих классов. В этом объекте хранятся значения глобальных настроек сайта. Их изменение в процессе работы скриптов не требуется, и даже нежелательно, то есть надо организовать к значениям доступ ReadOnly.
Вопрос - как правильно запрашивать настройки в коде классов, чтобы максимально абстрагироваться от специфики моего способа предоставления настроек?
Итак, в конструкторах классов ссылка на объект класса Settings сохраняется в свойстве $config. Варианты доступа к значениям настроек (внутри методов класса):
1. $this->config['parameter']
2. $this->config->parameter (в классе Settings я магическим методом читаю значения, а запись запрещаю)
3. $this->config->getParameter()
4. $this->config->get('parameter')
Какой из интерфейсов наиболее адекватный и общепринятый? Так как обращаться я к настройкам буду часто, потом не хочется всё заново переписывать или иметь код, который не смогут нормально использовать другие люди.
Мне нравятся 2 и 4, при чем если параметров конечное число вы можете в 2 добавить ещё PhpDoc секции в $this->config, тогда даже подсказки в IDE получите, я у себя обычно делаю оба, кому как удобно.
Второй вариант самый простой и компактный. Но здесь не очевидно, что параметр доступен только на чтение.
Если попытаться перезаписать значение параметра - выскочит либо Fatal Error, либо исключение.
То, что вы ищите обычно называют не мутабельными моделями.
Все настройки задаются в конструкторе, там же они валидируются и присваиваются приватным свойствам. Сеттеров нет, только геттеры (вариант 3).
Конкретно для настроек имеет смысл создать класс с константами, например в таком виде:
config/AbstractConstant.php - общие настройки для всей системы И настройками "по умолчанию".
config/Constant.php (Наследует AbstractConstant) - это класс содержит настройки для текущего окружения.
В итоге в любой части системы вы получите доступ к настройкам примерно так:
\Contant::MYSQL_USER
То есть вы говорите, что не надо во всех методах обращаться к внешнему объекту, а надо один раз в конструкторе считать нужные параметры в текущие свойства, так?
Вообще, да, логично, это сводит к минимуму внешние зависимости.
Насчет формы хранения настроек - уже всё передумал. Решил хранить в массиве PHP, а в качестве интерфейса доступа использовать класс Settings.
На счет настроек в массивах такой подход тоже имеет право на жизнь, но есть подводный камень: когда их будет реально много - ориентироваться по нему станет не просто.
На счет констант: когда я впервые увидел этот подход - сначала думал, что эт какой-то шлак, но на деле оказалось очень здорово то, что вам нет необходимости прописывать геттеры, IDE константы само подтягивает + в случае если что-то забыли - сразу четко знаем что. В случае с массивом - обязательно необходимо выполнять проверку существования, иначе будет бида.
