Mar 23, 2011
The way I see it is like this...
Short answer: No, they're not the same.
Slightly longer answer: No, they're not the same. But the Strategy pattern works well with IoC/DI.
Long answer: The strategy pattern is useful when you want classes to depend on the interface rather than the implementation. And you can easily swap out behavior depending on which concrete implementation you provide.
IoC/DI comes into play when you want the concrete strategy implementation injected into a class. For example, you could use the DI Framework Ninject and configure it so that it will know which concrete strategy implementation to inject into a class in specific scenarios.
Hope that helps!
Regarding IoC == DI, I have seen several posts on the topic claiming they're the same OR that DI is a type of IoC. Where IoC is a broader principle that covers more than DI. Haven't read enough to decide what is what though. I believe more people are leaning towards the latter.
Nov 24, 2016
First it's important for the community to recognize that DI is a junk term. Injecting a dependency is just pointless re-terming of a simple concept: passing a reference.
On the other hand, IOC and Strategy are not the same thing. Strategy is an example of IOC. Your comment about them seeming like the same thing is interesting because Strategy is really the best example of IOC.
In a system that uses the Strategy pattern, the top level classes are "told what to do" by the lower level, plug-in Strategy classes. Rather than a top level class branching on endless if then/statements, it just asks the Strategy to execute its particular behavior to alter the system's behavior.
It's true there may be other aspects of the system choosing which Strategy to plug-in. Or it may be the user's behavior. Either way, a different reference is passed to the container of the Strategy. We don't need to say it was "injected".
Offhand, I find it hard to think of something other than Strategy as an example of IOC. Menuing systems are often given as an IOC example. Menu's in a GUI are issuing commands, rather than some higher level part of the system asking if x menu was clicked / else if y menu was clicked, and so on. Menus can be plugged and exchanged freely.
I find anything defined as 'pluggable' as an example of IOC.
And one other thing: good programmers will naturally design IOC into their code, even if they don't know the term.