This weeks big new topic, object oriented programming or OOP. Firstly it acronym is far to close to ‘oops’ and is how I read it every time I see it. Setting my superstitions aside we career through the basics of objects and classes. First up is programming a selection of classes capable of tracking Boris bikes.
This is not the first time I have tried OOP programming, but I quickly realise I have only explored it at the most basic level so far. Done properly I can see the potential and am very interested in what it can achieve. By the end of Monday we had code for classes representing bike, docking stations, vans and a garage but none of the files seamed to hold the actual program. Everything is in a library folder. I find this the oddest thing and I’m not the only one. With all functionality pushed to classes there is no file called 'main.program’ and so I don’t quite know how to use it. Another feature of OOP is a rapidly ballooning quantity of files.
Key to the understanding of OOP is the difference between a class and an instance. As I understand it an instance is a particular realisation of a class. For example Person is a class it can own values like name etc. However it is only in an instance of a person that these values are defined. I am a person instance with name 'Peter’. Here is an explanation of classes, objects and instances. As with so many of these things the explanation is far less illuminating that just playing around and seeing what can be done.
Favourite quote from Monday, and quite possibly the week, was in response to the statement that person is a class and the person sitting next to you is an instance.
“So birth and death are instance methods.”
All through the week we continued to pair program and drive our development with tests. On most days we are reminded that this is how the rest of our career should go. As much as I like TDD I have yet to see how it is used to develop a full application. There seams to be a gulf between the small scale testing we have done so far and the ability to test a full application. I have tried using TDD to push the development of my SVG handling code, which I want to incorporate into London Layout. So far it has not been much help and been rather a bottleneck in the process. On a recommendation I have checked out Jasmine, a testing framework for JavaScript. I will keep writing about progress in this area.
Though the rest of the week we are tasked with solving a variety of problems in the object oriented style. One challenge that causes particular issue is this kata on codewars. This caused particular challenge because when blindly solving tests it is very possible to get led into a rather tricky corner. To escape this impasse in my case involved more of less rewriting the entire body of code so far. No impressed eventually Evgenny(teach). volunteers to show us how he would code it from scratch. Expecting him to solve it in 10 min or so it was interesting to see him take 1hr+. Also was the fact the the code he produced was requiring a large amount of re-factoring. So moral of the story seams to be every system has its weakness and there is no replacement for thinking ahead (a bit) regardless from what bottom up TDD seams to suggest. I should find a more snappy saying to encompass that message.
This week the obsession on codewars continues. By the end of the week the best January score has surpassed the best from the November cohort. They don’t care they are working on real projects. Briefly I hold first place, its a glorious achievement but short lived. I have also authored to kata now. This one being my favourite.