Coding forwards

So I’ve been drinking the dependency injection Kool-Aid for a while now and it got me thinking about the way I represent business logic in code. Maybe I’ve just come back to the basics of 50yr old programming, but that’s ok because the basics are the basics. And I think they’re this: you’ve got Data and you’ve got Processes. So how did dependency injection (with an IoCContainer/DependencyResolver) get me here? (Skip this long story by jumping to the asterisks *******)

3 words: inversion of control. They flip (invert) the whole development process on it’s head…or maybe it’s been upside down this whole time and it’s flipped it on it’s feet. I suspect so. I used to do my analysis and start coding the data access components: writing queries, building classes and server-side processes to return this data to a client that would utilize it. Now, I start with the top of the application.

I can do this because my dependencies are abstractions that don’t have to be implemented for the consumer to be completed or even for the project to compile. The reason I do this is because it keeps me on target. I’m not building some large infrastructure back-end that ends up being a few pieces of data off. Those can be big things to fix. But by starting with the application, I know exactly what the next layer down needs to do. There’s almost no mystery at all. It feels like I’ve been driving backwards this whole time and now I’ve finally turned my truck around.

And here’s where that meets with a new fixation on “processes.” Because I start at the top, I easily recognize these big tasks to do. If the application had a “Do the yard work” feature, these big tasks would be “mow the yard,” “weed eat,” and “blow off the drive way”. These tasks are the processes. In business perhaps they’d be stuff like “bill the customer” or “report a claim.” Immediately, I see how this flows naturally with the language of my business customers and I like that…a lot.

So in my backwards driving days, because I was working from the inside out, I’d notice that lots of data and processes were related and I’d package them up inside a single class. This lead to sizable classes, sometimes with many methods, often methods that I’d create because they seemed like they could be handy even though I didn’t know of a specific case that needed it. Remember, I was driving backwards from the supposed data to the application. Who knows what I might need? In reality, seldom would any one consumer use all these methods. Typically, the consumer instantiated the class for just one method.


But driving forward I see clearly what methods I actually need and I make just those. But make them where? In an interface, of course! “Bill the customer” becomes a BillCustomer() method inside the interface ICustomerBiller. “Report a claim” becomes ReportClaim() inside IClaimReporter. I was initially super excited about the separation and independence of the interfaces, but their definitions seemed a bit…contrived. ICustomerBiller? I saw that I was trying to make a noun out of all these processes, usually by swapping the words and adding an “er.” Works great, but these phony nouns seem hokey, and at times even vague. Definitely not going for vague. Then I thought, ** I don’t even need the noun! ** I’m just interested in the process. So then came IBillCustomerProcess. I love how the name is clear, the declared dependencies are equally clear (x process depends on IBillCustomerProcess), and the unit tests become clear (The BillCustomerProcess should invoke the CreateInvoiceProcess).

Excellent. But by now someone is crying, “But the name and method sound so redundant: BillCustomerProcess.BillCustomer()???” Yes, it is redundant, at least from a consumer’s point of view. The redundancy in the eyes of the consumer bothers me. I really just want to say something like “do the BillCustomerProcess.” Returning to my unit test (+1 for TDD), one process needs to call or “invoke” another process…hmmm, invoke sounds like delegates to me. What if I could depend on a delegate? Then the consumer could just BillCustomerProcess.Invoke(), or even .BeginInvoke for easy multi-threading stuff. Cool. At this point I laugh at myself. This is probably in a number of freshmen level textbooks somewhere for classes I never took. Oh well, better late than never.

So now I’m experimenting with delegate dependencies. Up front, my biggest uneasiness is that the delegate displaces the need for an interface. And I really like interfaces. They’ve become a kind of security blanket. I suppose I just really like abstraction and delegates are abstractions, but it doesn’t feel safe yet. That, and the IoC Container registration looks ugly. And I’m not sure other consequences there might be.

I still must have my IoC Container, of course, to auto-wire these dependencies. No compromise there. So here’s some example code of how I did that…

First, the process will be a simple “print message” process defined like so…

public delegate void PrintMessageProcess();

Next, my TestClass will declare the dependency in its constructor…

public TestClass( PrintMessageProcess printMessageProcess )
   _printMessageProcess = printMessageProcess;

I still have to write a function in a class somewhere, so I’ll do that…

public class PrintClass
   public void Print()
      Console.WriteLine( "Hello world." );

Then the ugly part, registering it in an IoC Container. I’ll use StructureMap here…

x.For<PrintMessageProcess>().Use( () => ObjectFactory.GetInstance<PrintClass>().Print );

Finally, somewhere in my TestClass…

public void RunTest()

And that’s it.

One of the things I really like is that the implementation doesn’t have to know anything about the delegate, which is unlike interfaces. This could make breaking down legacy code easier since the classes wouldn’t have to reference anything. The only one that knows what’s going on is the IoC Container.

One of the things I don’t like is that the implementation doesn’t have to know anything about the delegate, which is unlike interfaces. 😀 This could make for unintended behavior since the implementation is not subject to a defined contract. Scary.

If anybody actually read this far, any thoughts?


One Response to Coding forwards

  1. Pingback: Unit test formats, Episode 1 : A foundation emerges « FullRewrite

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: