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
