In the project im working on, people wrote services class to access DAO. Almost every business object has it's own service which use it's own DAO. On some services, we are using references to other services. At the moment, people are instantiating needed services inside the constructor.
But now, I have trouble because service A needs service B and service B needs service A so a call to either constructor results in stack overflow ...
Example (pseudo-code) :
//Constructor of OrderService
public OrderService() {
orderDAO = DAOFactory.getDAOFactory().getOrderDAO();
itemService = new ItemService();
}
//Constructor of ItemService
public ItemService() {
itemDAO = DAOFactory.getDAOFactory().getItemDAO();
orderService = new OrderService();
}
How would you solve this ? using singleton pattern ?
Thanks
The Spring Framework solves this problem by using dependency injection. In short, what it does is to instantiate all the DAOs, and then set the dao-dependencies after instantiation, but before main business logic.
If you have to do this manually, here's an example:
Can you separate out the "service" from the Constructor?
Or in other words, lets say you have an OrderService and it needs to consult its own personal copy of an ItemService. Will this ItemService instance need it's own copy of the OrderService to fulfill the request from the OrderService calling it?
Thus, it would be a sort of lazy initialization--don't create the new item unless and until you actually need it. And don't link up the additional service unless and until you need it.
Second idea: can you pass a copy as part of the Constructor?
e.g.:
Or possibly in the reverse direction?
Let the OrderService just do things with orders. Let the ItemService just do things with items. Then create a OrderItemService which combines the two.
Yes, the "singleton pattern" along with lazy initialisation will do. Don't initialise services in the constructor, but in static getters:
As Jonathan stated, you can also inject services to other services, but that might not be needed. If synchronisation is prone to lead to a memory issue, you can resolve this using
volatile
. See also this answer here, elaborating on the "double-checked locking pattern" (be careful though, to get this right!)