Progettazione di parser di file generici in Java utilizzando il modello di strategia

Ho un paio di dubbi:

1. Mi assicurerei che tu abbia effettivamente bisogno di un design generico prima di implementarne uno. Sei sicuro di aver bisogno di tipi di file diversi da XML? Se no, perché programmare per loro? Se alla fine ne hai bisogno, puoi adattare il tuo codice a quel punto. Non ci vorrà molto più tempo, probabilmente avrai altri requisiti che renderanno il codice diverso da quello che stai proponendo e probabilmente non avresti mai bisogno di scriverlo comunque. Come si suol dire, YAGNI (non ne hai bisogno).
2. Se hai effettivamente bisogno di un design generico e ne sei abbastanza sicuro, allora direi che Parser<T> è fondamentalmente audio. Vedo due potenziali problemi: (1) presuppone l'input dei file - cosa succede se si sta tentando di analizzare un flusso JSON recuperato da una risposta HTTP, ad esempio? e (2) non fornisce necessariamente molto valore se non come parte di un quadro generico più ampio in cui si hanno molti diversi tipi di parser per molti tipi diversi di dati. Ma non sono convinto che tu abbia bisogno di un quadro generico così ampio. Hai solo un caso d'uso concreto molto semplice in questo momento, per quanto posso dire: analizzare un file XML in un elenco di ProductData s.
3. Non è quasi mai una buona idea ingoiare le eccezioni come si fa in ProductDataXmlParser . Lo convertirò in una sorta di RuntimeException invece.

Il tuo design non è l'opzione migliore. Dal tuo design, l'unico modo per usarlo:

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

Non possiamo vedere troppi benefici dall'esempio sopra. Non possiamo fare cose del genere:

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

Puoi prendere in considerazione le seguenti due opzioni prima di cercare il generico:

• 1, stesso risultato dopo analisi

Indipendentemente da dove proviene l'origine dati, i dati del prodotto avranno lo stesso formato prima di salvarlo nel database. È il contratto tra il cliente e il tuo servizio di dumping. Quindi presumo che tu abbia lo stesso ProductData come output. Puoi semplicemente definire un'interfaccia:

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

Inoltre, si definisce ProductData come interfaccia se lo si desidera più flessibile.

Se non si desidera che il parser venga mixato con i dati. Puoi dividerlo su due interfacce:

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

E il tuo parser sarà simile a questo:

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

• 2, output diverso dopo analisi

Se ProductData non è simile e si desidera riutilizzare l'interfaccia Parser. Puoi farlo in questo modo:

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

Anch'io ho lo stesso requisito. Per un cliente ho bisogno di analizzare il file XML, per un altro file csv del client. Quindi, hai seguito la procedura che hai menzionato o hai seguito un nuovo approccio. Per favore fatemi sapere quale schema avete usato.

Nel caso in cui preferisci usare qualcosa già disponibile, ho creato una libreria java chiamata JRecordBind basata su XMLSchema (supportato di JAXB).

È nato per consumare / produrre file a lunghezza fissa e, dal momento che XMLSchema definisce la loro struttura, è possibile utilizzarlo con un semplice JAXB nei file XML marshall / unmarshall