java - Need suggestion on Parser Design Strategy -

i need suggestion on parser design strategy

consider type1, type2, type3 3 different csv files different formats parsed parser1, parser2, parser3 respectively.
in future evolve parse info other sources dbs.
there new parsers come. best way design parser? factory/ abstract factory candidate?
benefits , examples helpful?

type1 - parser1     type2 - parser2     type3 - parser3 

i have put down code, looking valuable suggestions.

interface parser<t>{     public list<t> parse (string s); }  //where t - data model   class parser1csv implements parser<model1>{     //implement      //s-csv file     public list<model1> parse (string s){     } }  class parser1db implements parser<model1>{     //implement      //s- connection string     public list<model1> parse (string s){     } }  class parser2csv implements parser<model2>{     //implement      //s-csv file     public list<model2> parse (string s){     } }  //same way other parsers implemented  interface abstarctfactory<t>{     public parser<t> createparser(); }  class parser1factory implements abstarctfactory<model1>{     private string type;     parser1factory(string type){         this.type = type;     }      public parser<model1> createparser(){         if(type.equals("csv"){             return new parser1csv();         }else if(type.equals("db"){             return parser1db();         }else{             throw unsupportedoperationexception("not supported.");         }     } }  //same way other parser factories implemented  class parserfactory{     public static <t> parser<t> getparser(abstarctfactory<t> factory){         factory.createparser();     } }  //usage: parser<model1> parser = parserfactory.getparser(new parser1factory("csv")); list<model1> list = parser.parse(file); 

currently, i'm not using di framework. benefits , impact when needed use?

1) design issues have room personal interpretation/taste, in approach much, it's common in industry due flexibility & modularity. sometimes without hierarchy of factories, varies depending on circumstances.

2) what's use of "class parserfactory"? don't see adds flexibility/decoupling, opposed old "new parser1factory("csv").createparser()"... perhaps had viable design intent i've missed.

3) regarding di, testify spring - code play nicely it. point of di "ok, know how create parsers, how pass them on business code"? e.g. if have 'bankservice':

// without di: public class bankservice {    private abstarctfactory factory= new parser1factory();    public void depositfundsfromfile(file file){       //  use factory    } } // di: public class bankservice {    @autowired    private abstarctfactory factory; // injected framework    public void depositfundsfromfile(file file){       //  use factory    } } 

=> di makes bankservice independent of concrete factory type: bankservice doesn't contain concrete commitment "new parser1factory", it's ready work factory, allows several bankservice instances co-exist , each different factory type... you'll give framework separate instructions how create concrete factori(es) , e.g. "new parser1factory("csv"). spring such separate instructions come in xml files, or in @configuration code.

4) depending on requirements, di inject parser rather factory (again, framework need separate instructions parser creation):

public class bankservice ... {    @autowired    private parser parser; // injected framework    public void depositfundsfromfile(file file){       //  use parser    } } 

5) could consider implementing springs' factorybean interface, though don't have to: it's legitimate decision avoid framework-dependent code.