Где хранить глобальные переменные, такие как пути к файлам в java?

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

значки используются в разных классах, поэтому на самом деле нет смысла хранить их в одном из этих классов в частности.

Я читал, что глобальные переменные являются злом, но допустимо ли использовать класс (например,Commons), содержащие только public static final поля для хранения этого короля данных ? Какое решение используется в профессиональных приложениях ?

6 ответов


Глобальные Константы

как утверждают другие, глобальные константы не имеют той же отрицательной коннотации, что и глобальные переменные. Глобальные переменные затрудняют отладку и обслуживание программы из-за неконтролируемых изменений. Глобальные константы (public static final) Не создавайте ту же проблему

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

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

Воплощение Ценностей

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

вот несколько способов воплощать эти ценности и несколько ссылок, чтобы вы начали. Это конечно не исчерпывающий список:


глобальные переменные являются злыми (поскольку они делают почти невозможным выяснить, кто что изменяет), но константы не зло. public static final String поля в порядке, так как они не могут быть изменены.


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


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

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

имейте в виду, что в случае "константы" на самом деле настраиваются, вам лучше пройти Configuration объект для методов, которые в нем нуждаются. Ну, у вас может быть статика где-то, но с точки зрения тестируемости необходимо ввести их / передать их.


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


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

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