aspose file tools*
The moose likes Java in General and the fly likes Service Locator and Dependency Injection Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Service Locator and Dependency Injection" Watch "Service Locator and Dependency Injection" New topic
Author

Service Locator and Dependency Injection

Kartik Patel
Ranch Hand

Joined: Sep 12, 2005
Posts: 73
Can I say, Service locator is one of the way to implement DI? DI is just a cleaner approach of getting desired object. Where as SL is more simpler when it comes to debugging the code?

Does this sound good?


Chop your own wood, and it will warm you twice. - Henry Ford
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
The main concept of dependency injection is removing hard-coded dependencies between two or more objects. The dependency between the objects is not removed. It is "injected" instead of being hard-coded.

A Service Locator is used to encapsulate low-level details and reduce, if not eliminate any hard-coded look-up and creation operations.

The main difference is that with dependency injection, the dependency is not removed.

When a client object uses a Service Locator it is requesting an object to do some operation. There is no "injection". The client object is simply making a request and receiving an object. There is no coordinating/assembling/injector object in the Service Locator pattern.

Hope this helps.
[ April 21, 2008: Message edited by: James Clark ]
Kartik Patel
Ranch Hand

Joined: Sep 12, 2005
Posts: 73
So does that mean "Injecting dependency" = "Client not asking for any object (the way it is asking in service locator), but some background process generates the Object / dependency for me and add it to client code without knowing client."

Will my bytecode change? How can I ensure that NullPointerException won't get generated at the time using that object as I am not aware when the object instantiation is taking place in case of DI. Its some callback method or may be framework's thread is responsible for generating the object.
Aditya Jha
Ranch Hand

Joined: Aug 25, 2003
Posts: 227

Hi Kartik,

ServiceLocator is all about encapsulation of lookup-technicalities corresponding to 'service-access' (technically, 'object-access').

A client of a ServiceLocator needs to supply some parameters which might be dependent upon the exact method of service-lookup (for example, a JNDI lookup needs a JNDI-name and probably some factory-name, URL as well as credentials). Some of these are passed from client, and some can be taken from System properties or external configurations.

The point is, though the exact algorithm of lookup is encapsulated in a ServiceLocator, the clients still needs to be aware of the parameters required to perform that lookup.

In case of DI, though, it is all about encapsulating the lookup ITSELF. That is, the client of a service need not worry about HOW to obtain handle to a service or even WHAT parameters are required to obtain the same. This obviously makes less dependency on environmental (deployment) settings and gives you a cleaner approach.

In both cases, the client works with a handle to a service, usually a reference of an interface which the service implements. So, I didn't really get it when James says:


The main difference is that with dependency injection, the dependency is not removed.


If you work with interfaces to promote loose-coupling, I don't see any reason as to why dependency is not removed. I think the client won't even be aware if the service is a local POJO, an EJB 3 component or a Spring-enabled HTTP invoker. All it needs is an injectible property of type same as the business-interface of service.

As far as byte-code changing is considered, that usually won't happen, unless you require some out-of-context aspects to be applied.

Normally, the DI container will simply instantiate your client, call setter method for DI and (hopefully) gives you a callback wherein you can test if the client has been correctly initialized.

Hope this helps.

Best regards,

- Aditya
[ April 22, 2008: Message edited by: Aditya N Jha ]
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
My comments above were to distiguish the Service Locator design pattern from the design concept of dependency injection. In regards to my statement, "...the dependecy is not removed", I provide an example below.




In the code above, Chef has a dependency upon FancyOven. An implementation detail stemming from the dependency is that the concrete class name of FancyOven is hard-coded in the constructor. There is tight coupling between Chef and FancyOven. If we wanted to have a Chef cook with BetterOven, we would have to revise, recompile, and test the Chef class.

Redesign with dependency injection



Both FancyOven and BetterOven implement the Oven interface. The client object that instantiates a Chef will "inject" the dependency using constructor injection. The Chef is still dependent upon the Oven object to start cooking, however, the Chef class will work with many types of ovens and will not require revision or compilation. The dependency still remains.

A Service Locator is used to find a service. The concepts are very similar, but there are differences as well, in my opinion.
[ April 24, 2008: Message edited by: James Clark ]
 
 
subject: Service Locator and Dependency Injection