Reputation: 27455
In the documentation about DAO says:
When the underlying storage is not subject to change from one implementation to another, this strategy can be implemented using the Factory Method pattern to produce a number of DAOs needed by the application. The class diagram for this case is shown in Figure 9.3.
The figure 9.3 itself:
What causes misunderstanding is how we can ever apply factory method to produce the number of DAO
s? As far as I understood in the case the DAO might be look like
public interface DAOFactory{
public DAO1 getDAO1();
public DAO2 getDAO2();
}
But it would be not a factory method. It would be an abstract factory, because we're producing a family of objects rather than a single object. Couldn't you exlain what they meant when said
this strategy can be implemented using the Factory Method pattern to produce a number of DAOs needed by the application. The class diagram for this case is shown in Figure 9.3.
Upvotes: 0
Views: 1373
Reputation: 3209
You are right. It is misleading. The Image depicting the use of Factory method is certainly an example of the Abstract Factory design pattern. There's just only one implementation of the factory.
There is a good explanation on the difference between a Factory Method and Abstract Factory here: Differences between Abstract Factory Pattern and Factory Method
The diagram shown in the documentation depicts the Abstract Factory pattern.
I can imagine the following use of DAOs and Factory Method
// the Service contains the business logic and uses DAOs to access data
class BaseService {
public Object doSomething() {
return getDao().retrieveObject("identifier");
}
// Factory method producing DAOs
public IDao getDao() {
return new BaseDao();
}
}
// The DAO interface
interface IDao {
Object retrieveObject(String identifier);
}
// Another Service that overwrite the type of produced DAOs
class SmartService extends Service {
// overwrite the factory method
public IDao getDao() {
return new SmartDao();
}
}
Upvotes: 1