Recently at Shop It To Me Engineering we’ve been talking about the topic of the DCI model of application design. It’s interesting and we’ve been trying to think of real world applications of this model. We’ve also been trying to figure out if this model has a place in our codebase.

The essential gist of DCI, in my book, is that you start with a simple instance of a class (traditionally a BankAccount that knows how to increment and decrement its balance). In a certain context, that BankAccount receives temporary knowledge and becomes a TransferrorBankAccount while another BankAccount becomes a TransfereeBankAccount. Thus, instead of BankAccount going about its daily life always knowing how to transfer money, every now and again when it is in the context of transferring money, it powers-up and gains knowledge of how to perform that particular task, and then “powers down” that knowledge when it’s no longer needed.

It’s an interesting idea. This means that certain activities can be coded and certain states represented only when they take on a certain aspect.

For me, the real take-away is that you can integrate DCI with good OO. I thought I’d try my hand at coding something along the DCI methodology. Since my understanding of DCI hinges on “powering up” and “powering down” I was brought back to recalling the days of my youth squandered spent playing “Super Mario Brothers” and other great 8-bit side-scrollers.

This code tries to explain my understanding. It’s not perfect, but it felt a good bit more lively than some boring triviality about BankAccounts.

You can clone the code at GitHub or you can read the following gist. Comments and insights are appreciated via email (via GitHub). Code displays after the jump.

Superfluous whitespace lines at top of code sample reported as a bug to GitHub