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

Question

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

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

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

Есть предложения?

Answer 1

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

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

Answer 2

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

Answer 3

На самом деле, подход 2 работает очень хорошо.

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

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

Использование явного установщика также помогает.

class MyConfig extends Properties {...}

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

Answer 7

Подход 2 определенно лучше.

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

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

Так что в main () вы могли бы иметь

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

Вместо

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

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

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

Answer 8

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

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

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

Answer 9

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

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