Object-Oriented Programming and Oyster Cards
Today we were told to look into what object-oriented programming actually was and the principles of coding in an OOP language. There were three thing we were told to focus on; Encapsulation, Inheritance and Polymorphism.
What is Object-oriented Programming?
Firstly I will talk about what OOP actually is. OOP is a model for programming languages that focuses on Objects rather than actions. Historically, programming has focused on data, using that data as an input to produce an output. OOP focuses on not only what something is, but also what it does and what can be done to it, so data becomes an object. These objects can collaborate with other objects by sending messages to each other. There are some principles of OOP, and three of them I will go into detail on below.
Encapsulation
Encapsulation basically means that an object should keep as much as possible private so it cannot be seen by other objects. The reason for this is so that other objects can’t create dependancies based on the state of an object. If you didn’t encapsulate, changing one object could break many others. It is most important to keep the state a secret, other objects should only be able to see what methods can be called on an object. Abstraction is an extension of this, where an object only reveals the highest level of information it needs to in order for other objects to use it.
Inheritance
Inheritance helps you from repeating yourself when coding classes that are very similar. You can create a parent class and create child classes based off of it. The child classes would be able to use all the methods defined in the parent, and add anything else more specific to themselves. For example you could have a parent class called ‘Car’, with methods to say it has wheels, windshield, wing mirrors etc, then child classes from that for each type of car, i.e. ‘Ford’, has 4 doors, 5 gears, ‘Ferrari’ has 2 doors and 6 gears etc.
Polymorphism
Polymorphism is Greek for “many shapes”. In terms of programming, Polymorphism is the ability to redefine methods in child classes. Methods that have been inherited from the parents but can be changed depending on the child class. Sticking with the ‘Car’ example, the parent class may have a ‘Seats()’ method, ‘Ford’ would redefine the method to have 5 seats, ‘Ferrari’ would redefine it to 2.
This post by Alexander Petkov was very helpful in explaining the terms, with useful images as well. I also found a useful definition of Polymorphism here. Doing some further reading I cam across this page, which was very helpful and used examples based in Ruby.
We were also told to look into the SOLID principles of OOP. These principles should help ensure code is readable and easy to maintain. Here is a brief overview of those from the Wikipedia page. I will probably go into more detail another time (when I understand it myself!)
- Single responsibility principle – A class should have only a single responsibility, that is, only changes to one part of the software’s specification should be able to affect the specification of the class.
- Open–closed principle – “Software entities should be open for extension, but closed for modification.”
- Liskov substitution principle – “Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.”
- Interface segregation principle – “Many client-specific interfaces are better than one general-purpose interface.”
- Dependency inversion principle – One should “depend upon abstractions, not concretions.”
The challenge for our afternoons starting today is Oyster Cards. This will build on our knowledge of OOP and TDD, and throw some more challenged at us. The first step was setting up a Gemfile which is already something we haven’t done before, so I think there will be some interesting challenges ahead!
In terms of the challenge itself, the program will function similar to Boris Bikes, just more complex. We need to create an Oyster Card, which can be loaded with money, then used to pay for journeys by being touched at barriers. The cost will be calculated depending on the journey and the zones of the stations starting at a minimum cost, the customer should also be able to view all of their previous journeys. Finally there needs to be a penalty for not tapping in/out.
The first 11 challenges were fairly straight-forward, very similar to things we had already done. Tomorrow we will continue on, and apparently from this point on is where things start getting harder!
Today’s music is from Childish Gambino, mainly because I went to see him at the O2 last night and he was awesome!
Josh's Blog 