Object Oriented C

I'm waiting for virus updates to complete and the new windows GitHub client to install - why is my computer so slow today!?

Anyway a chance to write a blog post then.

I'm becoming increasingly agile :) ... no not like a cat :s

Recently I completed my certified Scrum Master and Product Owner training and we're making great progress at work putting it all into practice. It really has reinvigorated my interest in software development and once again I am reading voraciously on subjects that actually excite me (you'll maybe shake your head when you realise what those subjects are ;)). Can't remember having this feeling since I first started coding back in University.

So what's on my mind today?

Well, I've been reading Michael Feather's "Working Effectively With Legacy Code" and once again I have found an author who really does reflect, distill and reinforce what I only really knew at the back of my mind. This is great as it gives me more confidence that I'm on the right path but also provides a glimpse of where that path leads.

One place that it leads is to greater use of object oriented principles in our code.

Some background... We write software for the OpenTV middleware in C to run on digital TV set top boxes. This is not object oriented. It isn't even really C, we can't use standard libraries and have to write pretty much everything from scratch. This has included basic libraries and a lot of tools and frameworks. Our main focuses at the moment are

• Reduce build times and complexity
• Use more off the shelf and advanced development/debugging tools
• There is a freely available OpenTV IDE based on Eclipse which is very useful as it also includes a set top box emulator allowing us to step through code (http://community.opentv.com)
• Automate builds / implement continuous integration (Jenkins)
• This conflicts with the eclipse IDE which is not good with headless builds, we've worked around this though, it just means we can't take advantage of standard OpenTV project templates. No biggy, we know what we're doing :)
• Add a unit testing framework and increase test coverage of legacy code
• Test driven development
• We have the framework so we have to do this to really reap the benefits in my opinion
• Automate tests
• Very much a TODO - the set top box emulator does not like to run on our continuous integration server unless it is not running as a service and some one is logged on. It uses DirectX :s
• Move away from specification documents to specification by tests.
• We are looking at integrating Fit and FitNesse to capture business rules and automate acceptance testing

So why more OO?

Simple really. We need units to test. We need those units to be independent so that we can develop and verify them quickly. The approaches of TDD and the means of dealing with legacy code to make it more maintainable/manageable require great discipline and effort. We need to make the task less onerous. A major part of doing that is to use interfaces to break dependencies between libraries. There are other options in C (preprocessor for example) and we have to be careful about performance on our platform. But with careful application I am convinced that we will get the best mileage out of a consistent application of OO interfaces.

So today I am going to figure out a good standard pattern for implementing classes and interfaces in C. Probably using the preprocessor to do some of the hard work. Previous attempts have always resulted in a lot of unwieldy repetition that I sometimes think only I understand (making it instant legacy code!).

Ok, installs completed :) New git repository created. I wonder if I'll just end up reinventing Objective C.