2009-08-27 2 views
1

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

Каждый конкретный импортер или экспортер может иметь разные параметры, которые необходимо инициализировать для работы. Например, если данные импорта поступают из файла CSV, вам нужен только путь к файлу, но если данные поступают из базы данных, вам нужна строка подключения, имя пользователя, пароль и т. Д. То же самое для экспортеров.

Моя реализация в настоящее время:

метод
public interface Importer { 
    public void setup(Map<String,String> params); 
    public List<ConfigEntry> getList(); 
} 

public interface Exporter { 
    public void setup(Map<String,String> params); 
    public void writeDocument(List<ConfigEntry> entries) throws IOException; 
} 

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

Является предпочтительным вариантом инициализации стиля JavaBean? Это означает, что для каждого дочернего класса добавляются setConnnectionString(), setCSVFilePath(), setX().

В чем преимущества, недостатки этих подходов?

+0

Как упомянуто как @Stephen C и @ ChssPly76, используя рамки инъекции зависимостей «предпочтительным» решение в настоящее время. –

ответ

1

Есть два очевидных минусов к карте на основе подхода:

  1. Отсутствие четко определенных имен параметров. Да, вы могли бы определить их как константы где-то, но вам все равно нужно проверить, что имя параметра действительно как принятое.
  2. Отсутствие четко определенных типов параметров. Еще хуже, чем выше - если мне нужно передать целое число, мне придется преобразовать его в String, и вам придется его разобрать (и иметь дело с возможными ошибками). Может быть несколько смягчено с помощью Map<String,Object> и автоматической привязки, но тогда вам все равно придется проверять соответствующие типы.

Сеттерский подход имеет только один недостаток - это невозможно. То есть он не может быть надежно выполнен с помощью сеттеров ALONE - вам необходимо дополнить его каким-то методом init() или afterPropertiesSet(), который будет вызываться после всех сеттеров и позволит вам выполнить дополнительную (зависящую от) проверку и шаги инициализации.

Кроме того, что-то вроде этого практически требует какой-то рамки Dependency Injection. Например, Spring, например.

0

Я бы не сказал, что передача объекта Map (или Properties) в конструкторе обязательно предпочтительнее, чем для дочернего класса, или наоборот. Какой подход лучше всего зависит от того, как вы собираетесь создавать экземпляры классов.

Если вы собираетесь создавать классы непосредственно из Java, то подход к карте, как правило, более аккуратный, особенно если у вас есть хороший способ собрать карты. (Например, загрузка объекта Properties из файла свойств.) Подход «сеттер» заставляет вас писать код для каждого из API-интерфейсов дочерних классов.

С другой стороны, если вы собираетесь создавать экземпляры классов, используя некоторую инфраструктуру контейнера, которая поддерживает «проводку», «инверсию управления» и т. П. (Например, Spring, PicoContainer, JavaBeans и т. Д.), Тогда сеттеры обычно лучше. Структура обычно заботится о том, когда и как создавать экземпляры классов и вызывать сеттеры, используя отражение под капотом для выполнения работы.

Таким образом, ответ ... это зависит ...

Смежные вопросы