I think that the Patrick assertions are right when you consider that in general the effort to reduce the dependencies in a project concerning the work that each member (developer) has to do every day. Of course if you are working on an application framework, as RBS may be considered, the prospects are very changeable.

Everyone who writes enterprise level applications should use IoC patterns to prevent static dependencies. With a tool like ReSharper you can create a interface with a mouse click. Use a IoC framework like Windsor Containers, Unity, NInject, Spring.net and you have a static dependency less.

In my opinion abstracting is kind a useless when you still have static dependencies. So yes, it may be easier to change a certain implementation, but it still requires a code change.

A 'good' example how IoC is abused is misunderstood is Microsoft SCSF. Modules are indeed using interfaces to communicate with, but the module initializers decide which implementation is used.

Our CAB framework is using a WCF service for configuration and updates. This prevents that end-users have change (and theirfor need to understand) config files so the oracle NHibernate driver is used in stead of the SQL2008 driver.

@ Dave:

The way I currently work is make it work with static dependencies, then refactor to an IoC container (Unity is my flavour of the month). I've taken on this approach in many parts of my development, from the interface (make it work without ajax, then add the flavour) to code.

"In my opinion abstracting is kind a useless when you still have static dependencies. So yes, it may be easier to change a certain implementation, but it still requires a code change."

So it's not useless, it makes implementation easier. One thing I personally have to keep in mind constantly is to not abstract everything right away. Only abstract when needed, else you risk creating a true 'enterprisey' application. Could also be my inexperience with IoC containers though.

Apologize for the responding delay, I missed this post.

As Tommaso pinpoint I think your example is a bit biased, a bus component is by its very nature here to avoid static dependencies between serviced components. So if the bus implementation itself has few static dependencies it is certainly a good think (more extension points).

But in the general case, too many dynamic dependencies is time-consuming, often useless and makes a program hard to understand while not enough dynamic dependencies makes a program monolithic, hard to maintain.

Patrick,

This isn't the case in most of the applications that I build.

If we take NH Prof as a good example, the entire system is build as a set of pluggable components that come together to create some common behavior.

Rules and analysis are a good example of that, but I am also talking about things like deciding when a session is started and ended, or how to detect a SQL statement.

Having large number of dynamic dependencies can certainly make a system more complex, _if you don't have conventions_.

If your system is full of special cases, then you wouldn't be able to understand it. If it is convention based, you have very few conventions, and you are done.

Personally I am a big adpet of the tenet:

fool me once, don't fool me twice

It means I avoid creating abstractions to serve one implementation now and maybe some others in the future. Notice that it doesn't mean I never create abstractions since the beginning.

The nice consequence of applying this tenet is that I constantly have the minimum amount of abstractions needed in my code. The other consequence is that abstractions created this way are very relevant: I am often pleasantly surprised to figure out how well old crafted abstractions serve nicely new needs I haven't forecasted.