Understanding the DCI Paradigm: Super Mario Brothers Demo
- 2 minutes read - 305 wordsRecently 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 (link retired) 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