На данный момент мне удалось не допустить, чтобы класс был одноэлементным / реестром, и вместо этого передал экземпляр класса Config туда, где он необходим, с помощью внедрения зависимости.
Если вы передаете один и тот же экземпляр вашего класса Config
в каждую часть вашего приложения и изменяете настройку, он должен отражаться повсюду.
В случае, если вы создаете несколько объектов класса (и каждый раз анализируете этот файл конфигурации ?!), вы можете прекратить это делать. Возможно, это расточительно, и я бы сказал, что это сбивает с толку.
Так что, если вы create only one
и передадите это, все будет хорошо.
В предположении, что вы создаете несколько экземпляров объекта, которые должны существовать только один раз:
Если вы можете «исправить» свою архитектуру, чтобы позволить вам сделать это: Сделайте это.
Если вы не можете к этому ... ну ... создание статического свойства для хранения ваших значений в классе, который вы можете иметь в нескольких экземплярах , это, по крайней мере, в моей книге главный фактор массы тела . Если вы не можете починить (то есть сделать это очень сложно), просто «сломайте» его ожидаемым образом, чтобы другие люди не споткнулись о него.
Я бы предпочел иметь синглтон, чем что-то, что создает все проблемы с синглетами, а также заключается в том, чтобы быть оберткой для глобальной переменной.