Общий дизайн анализатора файлов в Java с использованием шаблона Strategy

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

Что я пробовал до сих пор? (Настоящее время) Я имею в виду следующий дизайн, основанный на шаблоне Стратегии. Я быстро записал код в eclipse, чтобы передать мой дизайн, поэтому было бы замечательно, если другие аспекты, такие как правильный способ обработки исключений, пока игнорируются.

Parser: интерфейс стратегии, который предоставляет метод синтаксического анализа.

 public interface Parser<T> {
        public T parse(String inputFile);
    }

* Причиной использования универсального параметра является разрешение любого возвращаемого типа, а также обеспечение безопасности типов во время компиляции.

ProductDataXmlParser Конкретный класс для анализа файла product.xml, который содержит информацию о продукте. (используя XMLBeans)

public class ProductDataXmlParser implements Parser<ProductDataTYPE> {

    public ProductDataTYPE parse(String inputFile) {
        ProductDataTYPE productDataDoc = null;
            File inputXMLFile = new File(inputFile);

        try {
            productDataDoc = ProductDataDocument.Factory.parse(inputXMLFile);
        } catch(XmlException e) {
            System.out.println("XmlException while parsing file : "+inputXMLFile);
        } catch(IOException e) { 
                 System.out.println("IOException while parsing file : "+inputXMLFile);
        }
        return productDataDoc.getProductData();
    }
} 

где : ProductDataTYPE и ProductDataDocument являются классами XMlBean POJO, созданными с использованием команд xsd и scomp.

Будущее

Если у меня есть файл product.txt для анализа в будущем, я могу определить свой собственный POJO с именем ProductData, который будет содержать необходимое содержимое файла. Затем я могу создать конкретный класс с именем ProductDataFlatFileParser, который реализует интерфейс Parser, и после анализа файла метод parse заполняет для меня ProductData POJO.

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

У меня есть пара проблем:

1. Я хотел бы убедиться, что вам действительно нужен общий дизайн перед его внедрением. Вы уверены, что вам понадобятся другие типы файлов, кроме XML? Если нет, зачем код для них? Если вам это в конечном итоге понадобится, вы можете в этот момент модифицировать свой код. Это не займет много времени, у вас, вероятно, будут другие требования, которые приведут к тому, что код будет отличаться от того, что вы предлагаете в настоящее время, и вам, вероятно, никогда не придется его писать. Как говорится, ЯГНИ (Тебе это не нужно).
2. Если вам действительно нужен общий дизайн, и вы в этом совершенно уверены, то я бы сказал, что Parser<T>это в основном звук. Я вижу две потенциальные проблемы: (1) он предполагает ввод файла - что, если вы пытаетесь проанализировать поток JSON, полученный, например, из ответа HTTP? и (2) он не обязательно обеспечивает большую ценность, за исключением того, что является частью более крупной универсальной структуры, где у вас есть много разных типов синтаксических анализаторов для множества разных типов данных. Но я не уверен, что вам нужны такие большие общие рамки. Насколько я могу судить, сейчас у вас есть очень простой, конкретный вариант использования: разобрать файл XML в список ProductDatas.
3. Это почти никогда не хорошая идея, чтобы проглотить исключения, как вы делаете в ProductDataXmlParser. Я бы преобразовал это в какой-то тип RuntimeException.

Ваш дизайн не лучший вариант. По твоему замыслу единственный способ его использования:

ProductDataXMLTYPE parser = new ProductDataXmlParser<ProductDataXMLTYPE>().parse(input); 
ProductDataTextTYPE parser = new ProductDataTextParser<ProductDataTextTYPE >().parse(input);

Мы не видим слишком много пользы от приведенного выше примера. Мы не можем делать такие вещи:

Parser parser = getParser(string parserName);
parser.parse();

Вы можете рассмотреть следующие два варианта, прежде чем искать универсальный:

• 1, тот же вывод после разбора

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

public interface Parser {
    public ProductData parse(String inputFile);
}

Более того, вы определяете ProductData как интерфейс, если хотите, чтобы он был более гибким.

Если вы не хотите, чтобы парсер смешивался с данными. Вы можете разделить его на два интерфейса:

public interface Parser {
     public void parse(String inputFile);
}
public interface Data {
    public ProductData getData();
}

И ваш парсер будет выглядеть так:

public class XMLParser implements Parser, Data {} 
public class TextParser implements Parser, Data {}

• 2, другой вывод после разбора

Если ProductData не похожи, и вы хотите повторно использовать интерфейс Parser. Вы можете сделать это следующим образом:

public interface Parser {
   public void parse(String inputFile);
}

class XMLParse implements {
      @Override
      public void parse(String inputFile);

      ProductDataXML getProductData();        
}

class TextParse implements {
      @Override
      public void parse(String inputFile);

      ProductDataText getProductData();        
}

На всякий случай, если вы предпочитаете использовать что-то уже доступное, я создал библиотеку java под названием JRecordBind , основанную на XMLSchema (при поддержке JAXB).

Он был создан для того, чтобы потреблять / производить файлы фиксированной длины, и, поскольку XMLSchema определяет их структуру, вы можете использовать его с простым JAXB для маршалирования / деинсталляции XML-файлов.