In Conquest through extreme composition + glue, Part 1 I set the stage with some driving factors, thoughts on plugability, testing and more.

In Conquest through extreme composition + glue, Part 2 I talked in depth about The Dependency Inversion Principle and how it drives away the “pass through problem” and drives you into an extremely composition based approach.

The basic gist is that you want/ need to have the composition so that you can vary the behavior of your objects by (not editing the code) giving the target class different dependencies (the guys that do the class’s real work). The potential problem this leaves you with, is an object that can have lots of behaviors, but you have the liability of giving it the stuff it needs when you want to use it.

Ideally, you want the target object, and to give it the items you need to give it, on a scenario by scenario basis. In situation A, you want your class to behave 1 way, in situation B, you want it to behave another. What you want to do, is have something that is able to glue this stuff together.

This glue is the bit that you create variants of in order to stick together different stuff in your scenarios. You get the reuse of composed objects that allow their dependencies to be set onto them. This gives you isolation, testability, simplicy, extensibility, etc. In order to stick it together, I woke up ~5 AM last week with an idea…..

I have been a springframework.net zealot for some time. I am still a big fan. A few co-workers had feelings about spring that I had to at least to a level see.

• XML – there are WAY too many XML DSLs in the world. Too many “config files”. Too many different XML formats, etc. Spring is one of those.
• Type obsession. You are always concerned with what “type” you are dealing with in general, type, type, type *as opposed to new Something(), you have MyNamespace.MyType, AssemblyName, etc.
• All reflection based runtime object creation (this is a bone of contention for sure)
• ….Why not just use code?

So – in response – using Glue looks like the Java spring code configuration:

From there, we are just like spring. We can configure Prototype objects (ala factory style), Singleton object, we have constructs for ConfigureObject (inject properties after a class is already alive). We also have some minor trickery that we can use to automatically inject dependencies into winform (or WPF) GUI apps. We also have a way of allowing interested parties to have the ObjectContainer automatically be “stuck onto” them (similar to spring, looks like in their OSGi efforts they are still using the “Aware” pattern for this same thing).

You can also manually register stuff with the container, or replace existing definitions with the ObjectContainer if you like:

The magic of all of this comes from what I have been refering to as  “defered new”. When in spring, you specify a type, this type is reflected to life whenever it needs to create a singleton or a prototype object. In this example, once the class is loaded, the configuration is actually “normal code”. The fact that the Registration of a prototype or singleton is actually a function pointer (delegate) means that the “new” is not done “on the spot” – but defered until you ask for the label (“name1″ in above example”). Note also the passing of the ObjectContainer itself to every registration. This means that any single object defition can do the “spring ref” and get its properties/ constructor arguments from the ObjectContainer, thus not knowing or caring about it’s dependencies dependencies.

This does feel nice to me. I would rather type code. I find myself all the time cut n pasting the actual code constructor into the spring xml file, then mangling it into the XML spring format. The lessons that spring has taught me are great. We’ll see how this all pans out. I KNOW we need some kind of “glue” weather it is this Glue or spring, some other DI container, etc…. We need something in the space for our “Extreme composition + glue”.

-Chris

You can leave a response, or trackback from your own site.

Luke Melia’s IronRuby Talk

EMS’s are important – (I have been chattering about this lately – great stats)

So what’s the deal with Spring-OSGi? (THIS is a great one)

-Chris

You can leave a response, or trackback from your own site.