IMO, the vast benefits of using IoC far outweigh any perf penalties, and if done right I think any “penalty” is pretty easily mitigated.

One of the options listed is the aforementioned Funq. I have not tried any of these — my MonoTouch apps have thus far been dead simple in terms on dependency management.

One of the options listed is the aforementioned Funq. I have not tried any of these — my MonoTouch apps have thus far been dead simple in terms on dependency management.

Personally, I no more “switched” to Ruby than I “switched” to inversion of control and dependency injection. Both of these were continuous transitions from limitations I had run into previously, to solutions that I had realized by struggling with the limitations and knowing that there just had to be a better way.

One of the biggest artificial limitations to moving beyond .NET’s limitations is ascribing such Big Deal status to transitioning to a compositional language from a class-oriented language.

There was a time not too long ago where getting a job where you could use a Dependency Injection framework in .NET meant making some non-trivial lifestyle changes. It took a lot of work to get dependency injection to be acceptable in a more mainstream context in .NET. It took a lot of work because the previous form of stasis obstruction that was in the way of dependency injection framework use was also a human obstruction, or rather a fixated attachment to what came before. But, the transition was possible and more mainstream shops use these approaches now without thinking twice.

The same pattern is playing out now, but with more obstruction than the mainstream has with dependency injection. This time, it’s you guys facing the same kind of challenge that the mainstream faces when the dependency injection issue is put to them.

Ultimately, you risk entering a tighter and tighter spiral of micro-optimizations that yield ever-less for more and more cost. There are real situations where continuous improvement no longer has the right yield and where radical improvement becomes the inevitable next step.

Maybe I’m the odd man out here. When I saw that the design qualities I was trying to achieve were already available in another toolset, the pull of the toolset I was using simply evaporated. The goal became to use the tools that we most natural to what I was trying to achieve as a programmer and designer. The realization took a couple of years to crystalize, but the transition, when finally realized, was fairly instantaneous.

If the next step forward doesn’t bring .NET along for the ride, why does that matter? If we only allow ourselves to achieve programming and design goals within the boundaries of .NET, are we facing real limitations, or ones that we’re creating?

The organizations that now benefit from dependency injection tools didn’t ask their programmers to move the organization to those techniques, it was the programmers who had to work to change the status quo. Dependency injection itself and .NET itself are just as endowed with the potential to be status quo obstructions as the things that they displaced.

Compositional design is very much at home in compositional languages. Compositional design in static class-oriented languages is only ever something that you can do as a bolt-on after thought. Dependency injection tools will always be limited to the limits of their environment. They exist to address limits of their environment. If you’re forced to live within those limits, then those tools are helpful. But if you can change the circumstances that bring those limits into play, then you don’t have to live in an environment that has to work around the constraints.

Rather than chase after ever smaller optimizations in an environment of hard limitations, why not remove the root cause of the limitation altogether?

Removing that root cause will be no more instantaneous than getting the .NET mainstream aware of dependency injection, or TDD before that, or unit testing before that, or Agile before that. But it is a somewhat radical change that can be executed with smooth flow.

Just saying: from .NET to beyond .NET is just a transition. If the design qualities that you benefit from are becoming increasingly unnatural to try accomplish with your tools, and if there are tools that are less hostile to your goals, then you can make the transition. This is true because there’s nothing but precedent stacked on top of precedent that proves that we’ve been doing this all along.

As for business constraints, you don’t have to just take them at face value. Business cases have been made for transitions for as long as there have been business cases and transitions.

In the end, I don’t think everybody should see the continuous path of skills development leading to Ruby, or some other compositional language. I think that the only people who should transition to something like Ruby are the ones who are trying to do things in their current language that require bolt-on workarounds and that should rather be addressed by the language as first class language features.

In my own experience with Ruby (for example), I’ve learned that what I thought of as Inversion of Control from my experience in C# was just a narrow band of things that can be done with Inversion of Control. The reason that this happened was because my understanding on Inversion of Control was limited to only those parts of it that the current frameworks in their current state could express.

In the end, bolt-on workarounds will always be playing catch-up to tools that aren’t limited to begin with. And when you no longer see software design through the limitations of your tools, how you see software design expands as well.

If make the effort to exercise our minds to not see transitioning to Ruby as “switching” to Ruby then the consternation that goes with seemingly-radical changes quiets down and we get to deal with the move smoothly and methodically – just as we’ve been doing the whole time on this continuous improvement trajectory. If the trajectory does indeed point out of the .NET ecosystem, then don’t let yourself belief that it points to oblivion, because that’s terrifying. There are other ecosystems beyond .NET, and some of them already have the answers to questions that we’re just beginning to ask.

So what´s the root cause? I´d say, dependencies are a cause. Dependenies require decoupling through IoC and usage of a DI container. But depdencies are not the root cause.

The root cause is a programming paradigm based on dependencies.

I haven´t used a DI container in any significant way during the past few months. And I haven´t used a Mock framework in the past few months. Still my designs are modular/evolvable and testable.

What have I done? I have abandoned traditional dependency based object oriented programming. If you like, check this out by reading a couple of articles in my blog: http://geekswithblogs.net/theArchitectsNapkin

Let´s discuss who to solve the basic dependency problem.

-Ralf

I’ve had my eye on the DI in .NET book for a while, too. I’m going to have to pick up a copy.

thanks!

agreed on the expressiveness / terminology. I haven’t really run into any issues with this my use of delegates, but I can see how it could cause the code to be less understandable. your suggestions on how to correct it look pretty good. i’ll have to keep these in mind as i’m exploring these ideas.

Not the least is terminology. I like to frequently think of an instance of IMap to mean “the conceptual realm of all possible users” and calling Map(“fred”) to mean “give me the one that matches the string ‘fred’”. As such writing something like
var fred = users.Map(“fred”) seems less awkward than
var fred = users(“fred”) or
var fred = users.Invoke(“fred”).

Matter of fact, I still find Map to awkward and usually introduce an extension method alias in the appropriate namespace so that I can do things like
var fred = users.GetTheOneMatching(“fred”) or even
var fred = “fred”.GetMatchingFrom(users)

Anyways, I agree with you, these are just the ways that I’ve gotten around the same anoyances that you talk about.