Comparing these two patterns - Factory and DAO patterns, I see that they are quite similar:
Both of them have interface (Product/Dao), Factory (ProductFactory/DaoFactory) and concrete implementation (ConcreteProduct,ConcreteDao).
Factory creates some concrete implementation object and this object is used by client via interface.
So are they similar or I don't understand something? Or maybe is Dao pattern a specific implementation of factory pattern?
Thanks in advance.
The Data Access Object (DAO) pattern abstract away the details of persistence in an application. Instead of having the domain logic communicate directly with the database, file system, web service, or any other persistence mechanism : The domain logic speaks to a DAO layer instead. This DAO layer then communicates with the underlying persistence system or service.
The advantage of the DAO layer is that if you need to change the underlying persistence mechanism you only have to change the DAO layer, and not all the places in the domain logic where the DAO layer is used from.
Look at this article for better understanding.
In Factory pattern, we create object without exposing the creation logic to the client and refer to newly created object using a common interface.
The client needs a product, but instead of creating it directly using the new operator, it asks the factory object for a new product, providing the information about the type of object it needs.
The factory instantiates a new concrete product and then returns to the client the newly created product(casted to abstract product class).
The client uses the products as abstract products without being aware about their concrete implementation.
Read this article for better understanding.
Factory pattern talks about creation of object & DAO patterns talks about management of data
IMO They are pretty different
DAOs are used to transform between serialized (normally sql) versions of the data and Java objects
On the other hand, a Factory can be used to facilitate generic solutions for problems where a significant proportion of the work is similar. An example of this that I created a while back was a SocketHandlerFactory, to be used by a generic ServerSocket, so that however the generated Socket needs to be handled, you can configure this in the Factory.
Does that shed some light?
I'm assuming that when you are referring to the DAO pattern then you have something like this in mind:
However DAO's don't necessarily require factories to create them. For example in the Spring context there is no difference between Repositories and DAOs and there are no Repository factories as far as the client is is involved.
Quoting the Oracle article, that the diagram was taken from, they are in fact making use of a the GoF factory patterns (there are 2 in the Gang of Four book; Abstract Factory and Factory Methods):
The DAO pattern can be made highly flexible by adopting the Abstract Factory [GoF]
and the Factory Method [GoF] patterns (see "Related Patterns" in this chapter).
In summary, there is a clear difference in use-case if not structure of both patterns and that the factory within the DAO-pattern likely refers to a 'real' factory patterns that was added as an additional benefit, not as integral part of said pattern.
The major difference lies in the semantic context in which these design patterns are used.
DAO is used to abstract away the domain logic of Database Handling.
Fatory is used to abstract away the object creation logic.
Dont bother about the implementation/interface details.
Separate your application into layers and if you require a database, then, Having DAO is one option, which could be used across layers.
