Monday 18 May 2015

Code documentation



Nope, I did better. My simulator has got some documentation.

I'm not a big fan of lengthy and hefty technical documents. When I worked as application developer, I came across those 100-and-more page documents that explained in writing what a single function or method was supposed to do, the way was supposed to work and how it fitted in the overall project structure. After a couple of months, those documents used to become outdated, unreliable and misleading. Basically, they were a waste of money and time for anybody - I'd rather go for no documentations than a misleading document.

But hey, that doesn't mean documentation is all bad. What if I had very light documentation, describing what the inputs and outputs are, fully embedded in the code, easy to generate and update? That is, some sort of way to auto-documenting the code I write.

I must be stating the obvious, but that's exactly what Javadoc does, with some limitations. Javadoc homepage on the Oracle site fully describes Javadoc main features, functionality and limitation, so I won't go much into details. 

I focused my documentation on the interfaces, interface methods and classes definition. Javadoc documentation is generated within the IDE, which provides tools and resources to write documentation quickly. I rarely document how my Java methods work - I often keep code implementations easy to read by using good formatting templates and one-shot variables, since I believe good code snippets document themselves. Eclipse helps keep documentation up-to-date by changing Javadoc comments during code refactoring, avoiding outdated documentation.

For high level documentation, I use UML2 tool for Eclipse. UML2 generates maps of class and interface dependencies, giving me an overview of the overarching project and helping me spot wrong dependencies (dependencies that don't follow the IoC model) or opportunities for optimisation.

Friday 2 January 2015

Dependency injection by Spring

In a previous post I stated that classes must implement interfaces, and interaction between classes will only occur through their respective interfaces. The idea behind this decision is quite simple: in order to facilitate reuse and testing principles, Java classes should be as independent as possible from other classes. Classes that have no hard dependencies - they don't reference any specific class instance - can be used and tested in isolation, primarily through mocking strategies. This program pattern has been extensively defined and comes under the name of dependency injection, or inversion of control (IoC).

Spring is a framework that provides developers with a comprehensive list of tools for the implementation of dependency injection in Java projects. Spring is massive. Spring will make coffee, if properly instructed, and that's the main reason why I adopted Spring. Oh, and also because I used Spring when I was at uni and other options (Guice, Pico) are not very popular, yet. Must be a reason why, after 8 years since I left uni, Spring is still that popular.

I'll be using Spring 3.1.0 libraries and a bunch of dependency libraries such as commons-logging and spring-security. A full list of libraries used in this project is available under the /lib/ folder.