Diseño genérico de analizador de archivos en Java usando el patrón de Estrategia

Tengo un par de preocupaciones:

1. Me aseguraría de que realmente necesite un diseño genérico antes de implementar uno. ¿Estás seguro de que necesitarás tipos de archivo distintos de XML? Si no, ¿por qué codificar para ellos? Si finalmente lo necesita, puede actualizar su código en ese momento. No tomará mucho más tiempo, probablemente tendrá otros requisitos que harán que el código se vea diferente a lo que está proponiendo actualmente, y probablemente nunca necesite escribirlo de todos modos. Como dicen, YAGNI (No lo vas a necesitar).
2. Si realmente necesita un diseño genérico, y está bastante seguro de esto, entonces diría que Parser<T> es básicamente correcto. Veo dos problemas potenciales: (1) asume la entrada del archivo: ¿qué sucede si está intentando analizar una secuencia JSON que recuperó de una respuesta HTTP, por ejemplo? y (2) no necesariamente proporciona mucho valor excepto como parte de un marco genérico más grande en el que tiene muchos tipos diferentes de analizadores para muchos tipos diferentes de datos. Pero no estoy convencido de que necesite un marco genérico tan grande. En este momento solo tiene un caso de uso muy simple y concreto, por lo que puedo decir: analizar un archivo XML en una lista de ProductData s.
3. Casi nunca es una buena idea tragar excepciones como lo está haciendo en ProductDataXmlParser . Lo convertiría en una especie de RuntimeException en su lugar.

Su diseño no es la mejor opción. Por su diseño, la única forma de utilizarlo:

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

No podemos ver demasiado beneficio del ejemplo anterior. No podemos hacer cosas como esta:

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

Puede considerar las siguientes dos opciones antes de buscar el genérico:

• 1, la misma salida después del análisis

No importa de dónde sea la fuente de datos, los datos del producto tendrán el mismo formato antes de guardarlos en la base de datos. Es el contrato entre el cliente y su servicio de volcado. Así que asumo que tienes los mismos ProductData como resultado. Simplemente puede definir una interfaz:

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

Además, puede definir ProductData como interfaz si desea que sea más flexible.

Si no desea que el analizador se mezcle con los datos. Puedes dividirlo en dos interfaces:

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

Y tu analizador se verá así:

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

• 2, salida diferente después del análisis

Si ProductData no es similar y desea reutilizar la interfaz del analizador. Puedes hacerlo de esta manera:

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();        
}

Yo también tengo el mismo requisito. Para un cliente necesito analizar el archivo XML, para otro archivo csv del cliente. Entonces, ¿siguió el procedimiento que mencionó o siguió algún enfoque nuevo? Por favor, hágame saber qué patrón ha utilizado.

En caso de que prefiera usar algo ya disponible, he creado una biblioteca java llamada JRecordBind que se basa en XMLSchema (respaldado por JAXB).

Nació para consumir / producir archivos de longitud fija y, dado que XMLSchema define su estructura, puede usarlo con JAXB simple para organizar / desmarcar todos los archivos XML