Everything seems to be working just fine. A person can rent a bike from the docking station, and return it at a later date. Sometimes they are clumsy, and have accidents whilst riding (though never fatal ones). Occasionally, a van comes along to take broken bikes to the garage, where mechanics work hard throughout the day to repair them. The van returns to pick up the fixed bikes, and take them back to the docking station. However, upon the van releasing the bikes to the docking station, the bikes disappear. They’re no longer in the van. They’re definitely not in the docking station. Where have they gone?
These are the sorts of problems that can arise during object-oriented programming (OOP). OOP is where your code is organized around objects. It is hard to explain exactly what an ‘object’ is, but we can describe it as structure built up of different types of data, that you can make behave in a range of ways by calling different methods to them. You build up programmes and applications by allowing your objects to interact with one another. When you’ve not done it quite right though, your objects can randomly disappear, and it can take you a while to work out where they’ve run off to.
The last two weeks at Makers have been focused on this style of coding, and I’ve discovered that learning to code can be most fun, yet most challenging when you’re attempting to model real-life systems. I sometimes have a tendency to over-complicate the issue, by thinking too far ahead, and looking at the problem holistically, rather than breaking it down into small, manageable pieces. However, you still need to keep an eye on the big picture. Take the problem described in the first paragraph: although all of my tests were passing (more on this in a later post), when the method I called onto the van removed the fixed bikes from it, there was no equivalent function called to the docking station that would collect those bikes. Hence, I lost them!
We were given the chance to apply what we’d learnt from the Boris Bikes exercise to last Friday’s test. The task here was to create a simple airport system, where planes could land and take-off, provided that there wasn’t a storm brewing. At the risk of confusing some readers, here is a snippet of code from my ‘Weather’ module:
return :sunny if Random.rand(1..10) <= 9
This simply says that when you call the method ‘conditions’, a number is chosen at random from 1 to 10. If the number is 9 or below, the weather is set as ‘sunny’, otherwise it’s ‘stormy’. Hopefully, this code demonstrates to you just how readable Ruby can be, even to the non-coder!