We are currently in a 2 week design spike. We are developing a solution with one primary goal:

Integrated User Experience

The product will be used to unify many .net based applications. The product must enable developers to deliver faster than ever to their trading clients. The product must provide radical levels of integrated user experience. We must go far beyond our simple “plugin model” if we are to provide the ability for peer plugins to be themselves extensible, for the host application to be itself extensible and for all participants to get maximal reuse.

Amidst the course of this spike, we are all coding a lot and talking a lot. The team has lots of smart folks with a collective ton of experience building desktop applications serving the hard demands of traders. We are trying hard to keep our deliverables “end user effecting” yet during the spike, we are basically focused on defining a basic set of architectural buckets (see plinko model) into which our end user effecting features will fall during implementation.

What do we really want?

1. extensibility/ plugability
2. reusability
3. testability

I think the crux of it is:

1. Really practicing composition
2. Really practicing The Dependency Inversion Principle
3. Sticking stuff together contextually - some glue
4. … sort of an afterthought … Getting away from too much procedural programming hiding in OO code.

That is really it. We want to rely on abstractions and not know/ care about what our implementing parts need to have in order for them to work. We want to support The Open-Closed Principle by varying the behavior of our system by providing different collaborating implementors.

I am trying hard to help a lot of folks understand the need for The Dependency Inversion Principle. I am trying with step by step success to move lots of folks to really writing unit tests. I believe this:

1. You start writing unit tests
2. You earn the understanding of why you need The Dependency Inversion Principle
3. You practice The Dependency Inversion Principle
4. You get more adaptable software that is composition based
5. You earn the problem that spring and other dependency injection containers solve - the need for “formalized glue” to stick everything together.

I have seen this evolution time and time again. In stead of “ramming this all down people’s throats” - I try to let people “earn their next problem”. As soon as people earn the next problem, they see the value of the solution at the next level.

Anyhow - this bunch of stuff says, ideally you are:

1. Relying on abstractions
2. Allowing your implementors to be given to you in stead of newing your concrete dependencies

Your abstractions typically have N implementors - a bucket of IThingable’s are available. This is plugability - the reliance on an abstraction and the ability to “inject” something along that seam. The isolation factors of The Dependency Inversion Principle gives you the testability. The fact that you have buckets of things that can be implemented at a level of abstraction + composition gives you the reusability.

This gives us a picture that looks like .. coming in part 2

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

1. Chris Donnan : Programming - Brooklyn Style - Conquest through extreme composition + glue, Part 3, on May 25th, 2007 at 3:54 am, said:
   

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

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.