Dear Scott,

When discussing IoC Containers in chapter 8, you mention that your client code does not have to know about concrete implementations and it gets the right implementation injected.

I don't really see it I guess. You still need to wire up the dependencies in the Bootstrapper, which resides somewhere in the client. Actually the whole Resolve method looks like a Service Locator / Factory to me. You just specify that you want the concrete implementation of some interface and you will get it. How it knows what to get is in the bootstrapper.
The main difference is that by writing a Service Locator yourself, you have all the wiring code in the Locator and need a bit more work maybe, as with an IoC container you don't need to write the Locator, but just set it up. But both are somewhere in your client code.

Am I missing something?

What I do see is the auto-wireup of a dependency chain, which is very neat and does feel like a plus.

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

Thanks for answering, but... :)

In that example you (or Fowler) uses the Locator inside the MovieLister class. Maybe that's when it's offcially called a Service Locator. If you still use DI via the constructor for the MovieLister class, like in the first example, and then use a Locator when instancing the MovieLister class to insert all the dependecies into the MovieLister class, it's almost the same as with the IoC container. The only difference being that you have to write all of the Service Locator yourself.

The advantage has to do with the location of asking for the concrete implementation.

And like I said, the auto-wiring is cool and a genuine advantage over writing heave Service Locator classes that do the dependency chains by themselves.

I think traditionally a service locater used with a service that has a constructor would look like:

var movie_service = ServiceLocator.Locate<IMovieService>("with_IMDB_fi nder");

or

var movie_service = ServiceLocator.Locate<IMovieService>(FinderType.Am azon);

i.e.you are asking the service for what finder you want it to use. Its a very subtle difference, and may have been blurred over time, plus I think people use the term interchangeably.

But yes auto wiring is cool !

Cheers
Scott

Which you can do with StructureMap for example, where you can specify multiple concrete implementations for an interface, identified by a string like that.
I guess that part of an IoC container (or at least StructureMap) is really (a lot like) a Service Locator.

But you did make things clearer. Thanks very much. Best book I read for quite some time by the way. Keep up the good work.

I think you have a very valid point with the blurring of definitions over time. It's good we have names for design patterns, so we have a vocabulary to talk about them, but I guess at least some of them have been miss-interpreted along the way resulting in a couple of mismatches between what most people think now and what the original definition is (or has been). Most of the time discussions about these things are just syntactical, and we should have a better look at what we're trying to do. :)

Thanks MrFixxi, don't suppose you want to add a review on Amazon of how you feel about the book

I might. Never done it before, but will have a look into it when I get some time.
But do you need it? You've got lots of wonderful reviews already!