I’ve been in the market now for awhile looking for a good application to help me stay on top of my spending. Having tried numerous applications I have decided that none of them really suit my purposes. This gave rise to the idea of creating my own – a sort of DIY money management application.
Prior to my two week holiday I had spent two weeks working on a rough copy, no test harness, not much design. My only thought was to get a walking skeleton made as fast as possible.
In hindsight, I think this was a mistake. I may have missed a good opportunity to practice the art of dependency inversion – which decouples classes making them easier test, and easier to put together using a third party (open source) framework such as Spring.
However, I wonder if I can retro fit a suite of unit tests and experiment with jUnit and associated technologies. Also I may get a chance to look into Spring – which seems to be widely adopted and an important requisite for a great many jobs in the job market.
I may have to spend the next few weeks trying to understand how to refactor my own code to make it more testable and loosely coupled.
The question is should I get the walking skeleton working first? Or start dismantling the project. Thankfully, its currently only a few dozen classes.
There is one thing I have yet to understand about dependency inversion, with all the DI going around, how do we pull together all the code to make it actually do something?
I understand there is a category of code known as ‘glue code’ that stitches the code together. However, to make it even more flexible, you can use a framework such as Spring – or at least that’s how I understand it.
Firstly, I’ll have to get my head around the basics of Spring and dependency inversion. So I’ll hit a few books, and branch a copy of my money management to experiment with.