View Single Post
  #2 (permalink)  
Old January 27th, 2011, 08:48 AM
elbandit's Avatar
elbandit elbandit is offline
Wrox Author
Points: 599, Level: 8
Points: 599, Level: 8 Points: 599, Level: 8 Points: 599, Level: 8
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: May 2007
Location: Southsea, Portsmouth, Hampshire, United Kingdom.
Posts: 107
Thanks: 10
Thanked 17 Times in 15 Posts
Default

Hi MrFixxiT,

First of all thanks for buying the book!

Ok I my knowledge on the ServiceLocator pattern came from the article by Fowler http://martinfowler.com/articles/injection.html which if you have a read should answer your question. Basically the service locator does not have the ability to auto wire up dependencies, it acts more like a registry for services with parameterless constructors. An IoC container on the other hand can create a concrete class that does rely on other interfaces by auto wiring up with appropriate implementations that it has in its registery.

In his article an IoC can resolve the MovieLister class...

class MovieLister...
public MovieLister(MovieFinder finder) {
this.finder = finder;
}


MovieLister lister = (MovieLister) pico.getComponentInstance(MovieLister.class);

The MovieFinder class is auto wired up. When he uses the ServiceLocator, he uses the code...

class MovieLister...
MovieFinder finder = ServiceLocator.movieFinder();


And has to specifically ask for a movie finder. So therefor the class is asking for its dependencies, the IoC container inverts this flow of control and instead of the MovieLister class asking it is instead told.

Either way the main thing is to keep your classes loosely coupled by coding to abstractions.

I hope this has answered your question. If not please let me know.

Cheers
Scott
Reply With Quote