Tuesday, March 25, 2008

Inversion of Control vs Strategy Pattern

The Inversion of Control (IoC), also known as Dependent Injection (DI) , is orthogonal to the Strategy Pattern. Saying that they were the same pattern would be similar to saying that the Von Neumann Architecture and integrated circuit (IC) were the same thing.

The strategy pattern is one of many object oriented partitioning designs. It suggests how to divide business logics into separated components. Inversion of control (IoC), on the other hand, is one of many application wiring, configuring, and lifecycle controlling scenarios. It is about how to put separated business compnonents together into applications.

Application components partitioned in strategy pattern can be wired, configured, and controlled in various scenarios, not have to be the IoC. For instance, it is pretty common that applications use policy registries (therefore, a directory lookup scenario) to dynamically add, remove, resolve, and swap policy (strategy or algorithm) implementations.

Similarly, IoC has been widely used to assemble applications that are partitioned into components in various scnearios beyond the single strategy pattern. For instance, IoC are used to wire event suppliers/consumers, clients/services, implementations/adapters, etc..

11 comments:

Nick Head said...

Hi Ke - I may have misunderstood you, but would you not say that Strategy is a form of dependency injection? As in, one of may possible techniques available to implement DI?

Cheers
Nick

Ke Jin said...

Strategy pattern is orthogonal to DI as well. Certainly, DI (or IoC) is very popularly used in wiring/injecting policy or algorithm objects to their user contexts (as in GoF's example). However, these policy/algorithm objects can also be resolved by their user contexts using policy/algorithm registry lookup etc.. The fundamental idea of strategy is about factoring out algorithm logics into later binding policy objects, instead of about how these policy objects were resolved (injection vs lookup). Therefore, one can't claim that resolving policy/algorithm objects using directory lookup was not a strategy pattern.

Similarly, DI (or IoC) can also be used to wire applications that was partitioned in OO patterns other than strategy, such as queue, publish/subscribe (see PocoCapsule's gps etc. examples), adapter (see PocoCapsule's CORBA and WebServices examples), etc.. In the publish/subscribe pattern, for instance, event listeners can be injected to a port of an event emitter. Although the code here is similar to that of injecting policy/algorithm objects into an user context, the concept and purpose is completely different. Listeners are absolutely not policies/algorithm of emitters!

If DI (or IoC) was strategy pattern just because it could be used to wire policy objects to the , then, DI (or IoC) would also be these non-strategy patterns by the exactly same reason.

Brian Hartin said...

I don't think Strategy is orthogonal to IoC, although it is orthogonal to DI. IoC is a much broader concept than DI, and I think Martin Fowler does a good job of arguing that even simple callbacks are IoC. See http://martinfowler.com/bliki/InversionOfControl.html.

Ke Jin said...

Brian, I am confused. How could "IoC is orthogonal to DI" and "IoC is a much broader concept than DI" as well? If they were orthogonal, comparing which one was broader than another would hardly make sense at all.

Also, if IoC was merely callback, how about strategy pattern, event (or observer, publish/subscribe) pattern, adaptor pattern, .... ? Could we say all these patterns are also callback? If they were then could we say all these patterns were one same pattern?

Thanks for your comment.

Brian Hartin said...

Hi Ke,

I don't think they're orthogonal - quite the opposite. I also do not think they are equivalent, but rather related. I think IoC/DI is a broad concept, and that strategy, callback, events, even abstract methods are all forms IoC. The additional value of IoC/DI frameworks like Spring/PicoContainer/etc. is that they combine IoC with some other good things like a registry, namespaces, factory patterns and also establish conventions for setter/constructor injections, etc.

Ke Jin said...

Brian,

Saying IoC/DI are orthogonal to strategy/observer/adaptor etc. patterns does not imply IoC/DI can not relate to these patterns. IoC/DI is one of the possible ways to integrate objects that are partitioned in these patterns. This is how IoC/DI relates to them. This is similar to how IC relates to Von Nuemann architecture and vice versa.

Saying IoC/DI are orthogonal to these patterns is because that the issues concerned in these patterns and and issues focused by IoC/DI are orthogonal. Those patterns concern about object partition strategies. Developers use these patterns to decide how a given system is divided into separated objects. The patterns used in system partitions should not depend on what scenario (IoC vs non-IoC) will be used to put separated objects back together into the integrated system. Similarly, IoC/DI is one of object integration methods. The focuse of IoC/DI and non-IoC/DI integration methods are how to wire/configure objects into an integrated system, regardless what were their partitioning patterns. Objects partitioned baesd on these patterns (strategy, observer, adapter, etc.) can be integrated with IoC/DI as well as non-IoC/DI methods, such as directory lookup patterns.

Thanks for you comment again.

Ke Jin said...

Brian,

Again, without using IoC but the directory-lookup, I could assemble any system that was partitioned in strategy, observer (publish/subscribe), adaptor, etc. patterns. Could I say all these patterns are merely a form of the directory lookup?

Anonymous said...

Your blog keeps getting better and better! Your older articles are not as good as newer ones you have a lot more creativity and originality now keep it up!

Unknown said...

Hello, Ke Jin.

I'm just trying to understand the pros and cons of the different component-based frameworks that live out there.

I recently heard of OSGi, and was attracted by the promise of being able to remotely install, start, stop, update and un-install components and applications without requiring a reboot.

Does PocoCapsule support those features too?

I apologise if I have used this blog incorrectly.

Ke Jin said...

Hi Ignacio,

I am busy these days and will answer your question asap. Thanks for the good question and also thanks for posting it to the pococapsule newsgroup (I just saw it there). I will post my answer there.

Anonymous said...

You have tested it and writing form your personal experience or you find some information online?