Правильный подход к свойствам

Question

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

Подход 1: Имейте некоторый объект статических свойств, доступный каждому классу. (Недостатки: тогда некоторые классы теряют свою общность, если их удаляют из контекста приложения, а также требуют явных вызовов некоторого статического объекта, который находится в другом классе и может в будущем исчезнуть, а просто не feel Право, я не так?)

Подход 2: Имейте Свойства, создаваемые основным классом и переданные другим классам приложений. (Недостатки: вы заканчиваете тем, что передавали указатель на объект «Свойства» почти каждому классу, и он кажется очень избыточным и громоздким; я не , как.)

Любые предложения?

Answer 1

Мне нравится использовать инъекцию пружинной зависимости для многих свойств. Вы можете обрабатывать свое приложение как строительные блоки и вводить свойства непосредственно в компонент, который им нужен. Это сохраняет (поощряет) инкапсуляцию. Затем вы собираете свои компоненты и создаете «основной класс».

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

Answer 2

Похоже, вам нужен компонент диспетчера конфигурации. Он будет найден через какой-то сервис-локатор, который может быть таким же простым, как ConfigurationManagerClass.instance(). Это инкапсулирует все это удовольствие. Или вы можете использовать инфраструктуру инъекций зависимостей, например Spring.

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

Answer 3

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

Инъекционная инъекция также является хорошим способом сделать это.

Answer 4

Собственно, подход 2 работает очень хорошо.

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

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

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

class MyConfig extends Properties {...} 

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

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

Answer 5

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

Answer 6

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

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

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

Answer 7

Подход 2 защищен лучше.

В любом случае, вы не должны допускать поиск другого класса через объект конфигурации. Вы должны наложить конфигурацию, выполненную в объекте config.

Обратитесь к apache commons configuration за помощью с настройкой Impl.

Таким образом, в основном() вы могли бы

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

Вместо

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

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

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

Answer 8

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

Answer 9

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