I am agree with Louis Lembcke . Once I decide to use some template , I have to remove those switch case from my code. Sometime , replace it with Class.forName(implementName).newInstance(); Am I right?
And , while your use those solution to resolve your problem. your have to face that you had to maintain many implements of your DataBase Access Object. Once your had to change one of them , your have to change all of them.I think that it is recommend to use Entity Bean to replace you factory / template . While your inserting or updating and some of selecting , you can use Entity Bean which is wraped by a Session Bean . And for many of your selecting , your can use the SQL-92 based query . So, it would be easily to maintain. Am I right? Louis Lembcke wrote: >Greetings, > >You might use a combination. You have two problems to resolve ... >selecting which alternate implementation class to instantiate, and >design/development of the alternate implementation classes. > >Factories are used to instantiate a specific implementation object from >a set of alternate implementations classes. The choice of which >implementation to instantiate is hidden within the factory so that the >client-code does not have to be hard-coded to use one particular >implementation or another. The Factory returns an object that >implements an interface and the client-code uses the interface to invoke >the methods on the returned implementation object. So, the alternate >implementations don't have to have any relationship (inheritance) other >than that they all implement that interface. > >AbstractFactories are where the implementation factory itself is >abstract. This is commonly used when your create an implementation >factory that generates a whole family of related objects. You have a >higher-level factory which generates another factory ... a factory >factory, a factory which generates another factory. In this case, the >factory factory is used to select a whole family of implementation >classes. An example can be found in JDBC where you have factories which >generate whole families of objects - such as vendor implementations for >the JDBC interfaces (Connection, Statement, ResultSet, >ResultSetMetaData, etc.). Your first step is to select the >implementation factory (i.e. Driver) you want to select the >implementation factory (Oracle, DB2, SQL Server, etc.). This >implementation factory will then be used to get all the other >implementation classes. The selection of that factory is done via >another factory - a factory factory (i.e. the DriverManager). > >Great, so we know how to abstract the selection/instantiation of our >factories and implementation classes so that our code is neutral and not >bound to any one implementation. But what about the design of those >implementation classes... > >When I'm designing alternate implementations for the same abstract >purpose, it's quite usual to come up with a common implementation >framework where only the details differ between the alternates. In that >case, I can implement the framework in an abstract base class and the >details in the concrete subclasses. This is where the template pattern >is very beneficial. > >An example of the template pattern can be found with Servlets where the >web container knows to call the init(...), service(...), and >destroy(...) methods and where the developer then fills in the details. >The JSP tag extension API is another great example of the template >pattern. > >You notice that, in your example for the template pattern, you used a >switch/case statement to make the choice of which child class to >instantiate. The choice of which class to instantiate was hard-coded in >your code. So, your use of the template pattern didn't help you >abstract the selection/instantiation of the alternate implementation >classes. It only helped to design and code the implementation classes. >Hiding the choice of which child to instantiate - removing it from your >code - could be done via a factory. So, you will likely want to use a >combination of the various factory and template design patterns. > >Louis W. Lembcke, Principal >Chicago Systems Group >180 N. Stetson, Suite 3200 >Chicago, IL 60601 USA >Main Tele: +1 312.444.2760 >Facsimile: +1 425.969.6391 >mailto:[EMAIL PROTECTED] >http://www.ChicagoSystemsGroup.com/ > > >-----Original Message----- >From: Anye M. Sellers [mailto:[EMAIL PROTECTED]] >Sent: Friday, May 03, 2002 8:44 PM >To: JDJList >Subject: [jdjlist] OT: Design patterns: Abstract factory vs. factory >method/template method > > >Hi folks, >This is aimed toward the architect types in the >audience.... I'm working on an app that needs to >support both Oracle and SQL Server and that needs >different implementations of the data access classes >as a result. > >I've been studying design patterns and I've found a >couple similar patterns that seem ideal but I am >having trouble getting a feel for when you would use >each one. One is the abstract factory, which returns >to the client either the SQL or Oracle version of a >data object that implements the custom IDataAccess >interface. It has a couple extra steps in there: >client --> Factory Maker --> Factory --> Object as >interface --> call methods on interface >like so: >DBObjFactory dbfact = new DBObjectFactory(); >IDBObj objFact; >IDBAccess objDA; >objFact = dbfact.GetDataObjectFactory(dbtype); >objDA = objFact.GetDBObject(); >objDA.DoStuff(); > >The other is the Template method pattern (in fact the >book I'm reading used my case study as its example!) >where I would define an abstract class that defines >the public method which is called by the client and >that has abstract methods for the db specific stuff >which are implemented by child classes (one for each >DB). In this scenario, it seems that the flow is >client --> instantiate child object and assign to >parent reference --> call methods on parent reference, >the code from child is used. >like so: >DBAccess dba; >switch(intDBtype){ > case 0: // oracle > dba = new OraDBAccess(); // inherits DBAccess > case 1: // Sql > dba = new SqlDBAccess(); //inherits DBAccess >} > >dba.DoStuff(); > >(If I'm misunderstanding any of these, please let me >know...) >It looks like abstract factory has more overhead in >terms of objects created, but it seems like it might >favor composition over inheritance and would allow me >to use the same factory maker for other types of >factories that I may need. Do any of you folks know >the advantages and disadvantages of each method and >which would be better? > >Thanks in advance, >Anye > >__________________________________________________ >Do You Yahoo!? >Yahoo! Health - your guide to health and wellness >http://health.yahoo.com > >To change your membership options, refer to: >http://www.sys-con.com/java/list.cfm > > >To change your membership options, refer to: >http://www.sys-con.com/java/list.cfm > > > > To change your membership options, refer to: http://www.sys-con.com/java/list.cfm
