Abstract Factory and Factory Pattern applied to Sun's Blueprint on DAO
Joined: Jun 16, 2003
I have been trying to wrap my head around the differences between Abstract Factory and Factory Pattern over the last week. I obtained a copy of Head First Design Patterns which has helped a great deal. However, just whenever I thought I was understanding some things I came across Sun's writeup on DAO design:
They give examples here of how to apply the Abstract Factory and Factory Patterns to DAOs and datasources. Could someone explain a bit more how this example relates to the standard definitions of these two Patterns described in HFDP and by the GoF? Are the databases in this example being used as the "object" that we want to create?
Thank you very much for your time.
"...and the Truth will set you free."
Joined: Apr 16, 2008
Could someone explain a bit more how this example relates to the standard definitions of these two Patterns described in HFDP and by the GoF?
Basically here you are asking someone to read the definitions of the patterns in two books AND to read the webpage about DAO. That's a lot of reading to simply answer your question. It might be better if you could describe in a bit more detail what exactly do you not understand.
To possibly help you understand, it is important to realize that a particular design pattern and an implementation of the design pattern are not the same thing. An object-oriented design pattern can be implemented in many, many, many, many, different ways. There is one design pattern, which does not govern or dictate how it is implemented. And then there is an implementation (one of many.) The design pattern falls in software design category. The implementation falls in software programming category.
One design pattern ----> Many implementations
Are the databases in this example being used as the "object" that we want to create?
In terms of the DAO pattern in general, the factory object or factory method creates an "object" which has data members. The data that is used to populate the data members "could" come from a database. The database and the database management system are used to store the data. They are not the "object" that is created in a DAO implementation.
Joined: Jun 16, 2003
First, let me apologize for posing a rather vague question. I was in a hurry and did not take the time to properly compose it. Let me try to explain in a bit more detail.
Let's say I have a Snake Factory...which (not surprisingly) creates Snakes. I want to create RattleSnakes, GarterSnakes, and CornSnakes. And I also want to create them specific to a continent. So all three snakes will be in the Americas, Australia, etc. This would look something like...having a concrete AmericanRattleSnake, AustralianRattleSnake (yes, I am aware there are no rattlesnakes in Australia), etc. class(es).
Using this idea, which is a standard implementation of the Factory Pattern (correct me if I'm wrong), how does the Core J2EE Patterns - Data Access Object article relate using DAOs? Specifically, relating to Figure 9.3 and the related text?
Are RdbDAO1 and RdbDAO2 synonymous with a RattleSnake and GarterSnake? And if so, where does the country level play in to Sun's example? I'm failing to find a correspondence in Sun's implementation of the Factory Pattern described in Gof and HFDP with the "contintent" level of abstraction.
Second, I am definitely not asking anyone to read two books and an article to answer my question. My assumption (founded by reading other threads in this forum) is that there are numerous people in this forum who are well versed in both Factory Pattern and Abstract Factory Pattern described in these two books and could easily answer a question about them applied to something else. I do apologize, however, for not specifying that "something else" very well!
Thank you each for your time!
Joined: Apr 16, 2008
No problem. First, what you find in design pattern documentation in terms of examples are simply that, they are only examples. And, the examples provided do not cover all possible ways to implement the design or other application specific requirements and such.
In terms of your Snake example, the factory would need two peices of information in order to create the correct object. This information will come from the client object of the factory. The client object will know what type of Snake it wants to create and the specific country of the Snake as well.
The factory will receive the request to create a Snake object and use the information provided by the client to create the correct object.
In regards to connecting the DAO documentation to your specific example, not sure if this is realistic. The documentation does not speak to implementation details. So, you will not and should not find a correlation to the implementation detail that you are interested in, e.g. the country characteristic.
Are RdbDAO1 and RdbDAO2 synonymous with a RattleSnake and GarterSnake? And if so, where does the country level play in to Sun's example?
No, RdbDAO1 and RdbDAO2 would be synonymous with AmericanRattleSnake, AmericanGarterSnake, AustralianRattleSnake, and AustralianGarterSnake.
Aside, there is no such thing as a "standard implementation" of any design pattern. This is true mostly because (1) design patterns do not dictate how they can or should be implemented, (2) there are many different styles of programming, (3) there are many different programming languages that have differences in how they are used.
Below is one example implementation to ponder
The SnakeFactory class is an implementation of the Factory Method design pattern and createSnake() is the factory method.