Those semantic markers are available in most programming languages. It’s nothing special to C# or Java. Unfortunately though, these markers in C# and Java, and languages like them, introduce unnecessary constraints on code construction.

Part of the reason for using generics and interfaces to define your roles, I think, was because it was semantically pleasant to work with in C#. So, if you have a class that implements an : IUseLazyLoading, then it is clear to the person looking at it what is going on. You actually see a lot of this in NServiceBus, where you have combinations of interfaces like: IConfigureThisEndoing, As_A.Publisher

If all you have is an environment where you must use something like an IoC framework to get by, then it’s a good thing that they exist. But when there are better alternatives available, it’s as much an imperative to master them as it was to master IoC frameworks back in the day before you had realized the value of IoC frameworks.

When I talk about the learning trajectory pointing out of the .NET sphere, this is an example of what I mean.

For me, I want to make the most of my abilities, and work in an environment that compliments my understanding and ability to the absolute utmost – just as I had done when I started day-to-day use of an IoC framework in 2005 (admittedly late to the IoC party).

The skills that we’ve learned from the programming patterns that are in the same sphere as IoC tools are vastly more effective one the constraints the require an IoC tool are lifted. I want all of that ability and all of that productivity – regardless of whether it runs on open source on Microsoft technology or open source on non-Microsoft technology.

.NET is not my bottleneck. I hope that it doesn’t persist in being the bottleneck in this community, because there’s enough smarts and ability in this community to be really lit up by removing these same constraints that I mentioned.

I wonder what people in this community could achieve if the fullest potential of their abilities were unleashed from mere frameworks and language constraints.

Just a thought…

Why loop through a container rather than just loop through the subclasses of a class?

Of course, it’s a loaded question because looping through the subclasses of a class is a non-trivial problem in .NET. Building a list of subclasses of a parent class suggests that something dynamic is going to be done with those classes.

This is a case where using the assembly-scanning abilities of a container makes a lot of sense, but in the end, it makes sense because there really aren’t many better choices.

Here’s how I’d do this in a language that has this feature as a first class capability.

BusinessEvent.subclasses.each { |clazz| clazz.do_something }

One implementation for this can be seen at: http://gist.github.com/591695

This is possible because class definitions are runtime code rather than frozen at some point between the editor and runtime.

Another way to do this would be to query the object space at runtime: http://gist.github.com/591707

The object space is the active memory of a Ruby program. Every object in memory is available through the object space. Since every class in Ruby is an object, a program’s classes are also available through the object space. Note, that Ruby objects are garbage collected, so take this into consideration when using the object space.

In either case, the code to collect subclasses can be generalized to a module and included into any base class that offers this service. It can also be added to the Class class, extending the service to every class in an app.

This is a good example of a reasonable argument against container frameworks on the grounds of protecting design elegance from low cohesion components like composition containers that have to take on all of the dynamic programming patterns under the sun because static languages aren’t amenable to this style of programming out of the box.

Ultimately, the responsibility for providing a list of subclasses is the responsibility of the base class of interest. If the environment doesn’t allow for this, then we have to fall back to workarounds.

Nonetheless, it’s a darned good use of a framework in a static language. I just don’t think that these – as I’ve called them – “bionic crutches” should be celebrated when really they are signaling some fairly significant limitations that require remediation tools before they can be really useful. No doubt, they’re useful when needed, but the other way around this is to change the environment so that these needs are no longer concerns.

Is Udi’s counsel here on using an IoC tool due to the supremacy of an IoC tool for this job, or that this is just the way that Udi does things in that he’s been a static language developer for a good part of his career?

Ultimately, is this some kind of best way to do it, or just the way we currently have available to us in C#?

> Then it’s just a matter of looping through the instances and executing them one by one.

I have used a similar approach – letting the container grab all instances of a type (in my case events) and executing them one by one. What do you do to control the order of these tasks, if necessary. I could see the need for running startup tasks in a specific order.

http://groups.google.com/group/growing-object-oriented-software/browse_thread/thread/ef299b03620a4cef/f1dcfecb9969e174?lnk=gst&q=Ioc#f1dcfecb9969e174

Thanks for the insight! I do agree that lifecycle management shouldn’t just be a switch that’s flipped on or off. Perhaps IoC is not the right name for everything that’s going on in containers these days.

The only real reason for moving lifecycle management away from a consumer is if the complexity of various lifecycle strategies reduces the cohesion of the consumer to a point where it’s no longer possible to gain understanding of the service at a glance.

If the lifecycle of the dependency changes, then it’s very likely that the semantics of the service will change. If those semantics are not part of the service abstraction, then it’s possible that there’s knowledge missing from that abstraction. This affects the design elegance of the abstraction. This is an essential consideration for the usability of code and for reducing relearning. And those are productivity and human workflow concerns, and these concerns, like testability, have huge influence on the shape of development cost depending on how they’re tuned for the specific circumstances of a project.

When you say “we don’t want to let the design of an implementation of a dependency affect the service” I hear robotic thinking. You can say it well enough, but there’s no real design principle that will universally serve the goals of software product development that supports that statement.

I’m not saying that this kind of separation is necessarily bad, but it’s also not necessarily good. There are circumstances that are served by this pattern, and circumstances dis-served by the pattern. It isn’t the universal truth that static language pattern orthodoxy suggests.

Inversion of Control doesn’t mean that we remove responsibility for wiring up dependencies from the service requesting or needing them. That’s what “Inversion of Control Framework” means. That’s more of a definition of dependency injection than Inversion of Control. Inversion of Control means that the control of creation of a dependency is removed from the module that uses the dependency. Lifetime management can certainly be combined in a framework with autowiring features, but that’s not specifically what Inversion of Control means as a design quality.

As a side note, Inversion of Control tools and Inversion of Control principles seem to be increasingly mashed up into a single glob, and I think that the conglomeration of these two separate concerns creates some muddy water. You can see this in colloquialisms in the community where “IoC” has become synonymous with “IoC tool” or “IoC framework”.

Lifecycle management and Inversion of Control share some concerns, but they’re not necessarily the same thing. Some frameworks smush these two concerns together, and do so to good effect. Some frameworks don’t smush these two concerns together, and do so to good effect. Either approach can be as easily influenced by the way that the programming language works as by the way that the tool works. And the way that the tool works will reflect its operating environment.

This strikes me as an example of tools occluding principles. Not that you’re not getting benefit from it in your work, but there’s something being lost in not recognizing the precision in the subtlety in the difference between Inversion of Control and Inversion of Control Tool, and the tool’s uses and practices, and the reasons for its design. If the tool informs your whole concept of the principle, the principle’s whole meaning and power risks becoming something lesser than its entire potential.