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

No Responses to “Conquest through extreme composition + glue, Part 3”

1. robertmaldon, on May 28th, 2007 at 21:28, said:
   

   Having used Spring on a few large projects in recent years I can’t say that I am exclusively happy with either the pure-XML or pure-annotations approach.

   To me the main value of a Spring XML config file is that you can get an understanding of how an application works – the main components, how they are related, maybe even the “workflow” of the application – much quicker than digging through lots of code.

   The downside of the pure-XML approach is that it is easy to get caught up with defining everything in Spring XML, which has a few nasty side effects (just ask my colleague Solomon – http://jroller.com/page/Solomon?entry=compiling_xml_for_faster_startup).

   Where possible, therefore, I lean towards defining only the top level application objects and “workflow” components in Spring XML and use annotations for the rest.

   One question on Glue: Do you have the option of overriding the annotations? For example, in a test env you may want the object to be prototype but in the main app you need the same object to be configured as a singleton.

2. chrisdrop, on May 29th, 2007 at 00:22, said:
   

   Hey there. I also think that XML config files give you that “understanding of how an application works”. You can think of a glue config as exactly the same thing as a spring config XML. It is NOT an annotation approach like CAB that asks you to annotate THE TARGET OBJECTS – but an approach that exists OUTSIDE the target objects. I found myself taking ‘ctor code from so many classes, cut’n'pasting them into a spring objects xml file – turning it into XML… So I tried to bang out something that was identical to that – but C#.

   After a few years of springin’ – I think that having “sensible defaults” saves you a lot of over-springin’. I still want the OPTION of injecting something – but by default – I want a sensible constructor overload and/ or a setter aviailable as a “seam” when I need it. This gets rid of much of the over-springin’ IMO.

   As to annotations – I do not like to decorate my actual target classes with ANYTHING like this stuff. This is why I opted for an approach where I still have POCO’s (except in the container-aware scenarios where I need a handle to the factory) – that are not embellished with any container info – just a config – like spring – and a container “up high” in the app that pulls it all together.

   As to “overriding the annotations” – the answer is no – BUT the deeper answer is – it is not needed because you can have different configs’ just like in spring. In fact, you can get a good degree of reuse as well by simply using composed sets of glue cofigs. You can import a config using composition. You then put your environmental depends and per-enviroment variations in configs that are small – and import the main configs – just like I have done using spring.

   Since they all lie outside your actual code – you can again think of them as the same as a spring config. In fact – if you package them by themselves, you can wire your hard dependencies to the cofig package alone and your other packages have not a clue – they just ref your core abstractions.

   There it is:)

   I hope you are well – and that Sunguard is treating you all well these days. My best to Solomon next time you see him.

   -Chris

3. robertmaldon, on May 29th, 2007 at 03:20, said:
   

   Ah, apologies, I didn’t read through the post thoroughly enough to understand you were coding the config, not annotating the actual domain objects. Interesting idea. I would be curious to see how it scales for a medium or large application, and whether you have to “include” multiple GlueConfig objects to compose an application.

   Keep up the blogging!

Comment on this post below

You must be logged in to post a comment.

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