Http Hobo

Another blog with web-development tips’n’tricks. | About me

1 post tagged


EMLIAF: Object Oriented Programming

Hi all,

EMLIAF stands for Explain Me Like I Am Five. I have been tutoring for a while, and realized that there are a lot of things in the programming world that nobody really bothered to explain in a human-friendly way. I’ll try to feel that gap, who knows if I’m good at that.

First I will start with Object Oriented Programming (OOP in short), as it is a very basic concept. Basically OOP is a way to organize data storage and operations with the data.

OOP is based on two pillars: classes and objects.

It’s basically a blueprint, set of rules. Imagine we are producing a car of a particular model. That model blueprint is basically a class. You cannot do anything with the blueprint other than building a car based on it. That would be an object or a class instance.

Since an object is an instance of a class, it doesn’t have any rules, it follows them. However, this is something storing data and functionality, so it can be used. There can be multiple objects of a single class, i.e. there can be thousands of cars of a particular model. You cannot ride a blueprint (class), but you can ride a car (object).

Objects basically store data and provide functionality. Data is stored in “properties”, functionality is provided in “methods”.

Car has a lot of properties, i.e. color, maximum speed, number of wheels. All the properties are defined in class, but values are set in object. I.e. there can be multiple cars of the same model but with different colors. Property can also contain another object. Imagine we also have an *engine* class, and several different engine objects – less powerful and more powerful. Car can have a property with a value pointing to a particular engine object. Engine will have it’s own properties and methods too.

Basically a function attached to an object. Methods are defined in class, and they normally operate with properties. Methods can call other methods. Imagine a car having a method “turn on”, property “engine” pointing to an engine object, and engine having a method “ignite” and property “working” which is Boolean (“Yes”/“No” type). Now when we call car’s “turn on” method, the following happens:

  • Engine’s method “ignite” is called
  • “Ignite” method sets engine’s property “Working” to “Yes” and returns signal of success back.

That’s basically how classes and objects work. However, there are three important concepts in OOP: encapsulation, inheritance and polymorphism.

Have you seen those movies where a car thief messes with some wires trying to ignite it? He uses a so-called “private” method. This method is not supposed to be called by an object user, it’s supposed to be called internally. I.e. you shouldn’t mess with the wires, you should press the button or put a key in and turn it. Pressing the buttons or using a key would be so-called “public” method. This is encapsulation – defining responsibilities and scope for methods and properties. It is important to keep correct state of things. Imagine car engine’s “working” property is set to “yes”, whereas the gasoline tank is empty. This creates an error state, and encapsulation is used to prevent it. Engine’s “working” property should be private, so you cannot just change it however you want. Method “turn on” should be public though, it would check if there is gasoline and only after that set “working” to “yes”. This ensures correct flow of data in the program.

Imagine a car manufacturer. Some regular one. It produces a bunch of different car models. However, all these models are still cars. Does manufacturer need to put all basic car specifications in every model’s blueprint? No. Because there is a class “Car” and every model class inherits from it. So the “Car” class will basically define everything common for all the cars, and then children classes will add details. “Car” class will have such properties as “engine”, “transmission”, “number of wheels”, etc. Model class will have properties like “body type”, “interior”, etc.
Now let’s get back to encapsulation. There are three levels: “private”, “protected” and “public”. “Private” is restricted to a particular class, i.e. car’s private methods can be called by car class instances only. “Protected” is restricted to a class itself, also to it’s parent and children classes,, i.e. car’s protected methods can be used by model class instances too. “Public” is allowed to be called by anybody.

I couldn’t make a good example with cars for this. Instead imagine a multitool – it has knife and a screwdriver. Let’s make it classes: first would be “knife”, it has method “cut”; second would be “screwdriver”, it has method “screw” and “unscrew”. Multitool can do all. Polymorphism means ability to exist in different forms, and multitool can be a knife and screwdriver at the same time. Some happens in programming, there can be a class which basically can inherit from multiple other classes.

Basically that’s it for the Object Oriented Programming. Important to understand that:

  1. Not all programming languages support OOP, and among those supporting not all support it fully.
  2. There are more details like interfaces, different additional access levels like “private protected”, static methods, etc. This is out of scope of this article, it’s purpose is to only give an idea of a concept.

Let me know in comments if this is useful and clear. Do you want to have more articles like this?