Корректный подход к Свойствам

Если бы свойства необходимы большому количеству классов, я пошел бы для подхода 1. Или возможно вариант, в котором Вы используете шаблон разработки Singleton вместо всех статических методов. Это означает, что Вы не должны продолжать раздавать некоторый объект свойств. С другой стороны, если только нескольким классам нужны эти свойства, Вы могли бы выбрать подход 2 по причинам, которые Вы упомянули. Вы могли бы также хотеть спросить себя, как, вероятно, случается так, что классы, которые Вы пишете, на самом деле будут снова использованными и если так, сколько из проблемы это должно также снова использовать объект свойств. Если повторное использование маловероятно, не беспокойтесь им теперь и выбирайте решение, которое просто для текущей ситуации.

На самом деле приблизьтесь к 2 работам действительно хорошо.

Я пытался использовать объект свойств Singleton на недавнем проекте. Затем когда это прибыло время для добавления опций, я должен пересмотреть Singleton и сожалел, что имел необходимость определить местоположение каждого места, где я использовал MySingleton.getInstance().

Приблизьтесь 2 из передачи глобального информационного объекта через Ваших различных конструкторов легче управлять.

Используя явный метод set помогает, также.

class MyConfig extends Properties {...}

class SomeClass {
    MyConfig theConfig;
    public void setConfi( MyConfig c ) {
        theConfig= c;
    }
    ...
}

Это работает хорошо, и Вы будете рады, что плотно управляли точно, каким классам на самом деле нужна конфигурационная информация.

Кажется, что Вам нужен компонент менеджера конфигурации. Это было бы найдено через своего рода сервисный локатор, который мог быть столь же простым как ConfigurationManagerClass.instance(). Это инкапсулировало бы всю ту забаву. Или Вы могли использовать платформу внедрения зависимости как Spring.

Много зависит от того, как компоненты находят друг друга в Вашей архитектуре. Если Ваши другие компоненты раздаются как ссылки, сделайте это. Просто будьте последовательны.

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

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

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

При поиске чего-то быстрого, можно использовать свойства System, они доступны всем классам. Можно сохранить Строковое значение или если необходимо сохранить список 'материала', можно использовать Систему. Свойства () метод. Это возвращает объект 'Свойств', который является HashTable. Можно затем сохранить то, что когда-либо Вы хотите в таблицу. Это не симпатично, но это - быстрый способ иметь глобальные свойства. YMMV

Не сделали Java некоторое время, но не можете Вы просто поместить Ваши свойства в java.lang. Системные свойства? Таким образом, можно получить доступ к значениям отовсюду и постараться не иметь "глобальный" класс свойства.

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

Внедрение зависимости является также хорошим способом сделать его.

Approache 2 является defenetly лучше.

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

Смотрите на апачскую конфигурацию свободного городского населения для справки с конфигурацией Impl.

Так в основном () Вы могли иметь

MyObject mobj = new MyObject();
mobj.setLookupDelay(appConfig.getMyObjectLookupDelay);
mobj.setTrackerName(appConfig.getMyObjectTrackerName);

Вместо

MyObject mobj = new MyObject();
mobj.setConfig(appConfig);

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

этим путем Ваш объект становится очень легко тестируемым.