Photo by Alex Kotliarskyi on Unsplash

If you have ever tried to learn a programming language, you have probably come across the term “Object Oriented Programming” at least once. If you haven’t then don’t worry – you are the target audience for this article.

There comes a point in every programmers journey where they will meet face to face with this concept, and it is at this point that they will realist that they have been doing everything wrong up until now.

By the end of this article you can expect to be a pro at understanding the fundamental concepts of Object Oriented Programming, so even if you don’t know how to program to begin with, you’ll still be in a better position than most people. This may even encourage you to go out and learn how to code! But first, let’s take a look at why OOP came about.

At first, there was nothing

Well not exactly – there were at least some programming languages in the very beginning, however they were procedural languages. This was great for a while, but then as systems started to become more advanced, the infamous spaghetti code would start to appear in scripts, and the sheer complexity of procedural code was being held back by the tools available at the time.

There needed to be a better way for programmers to define the structure of their programs, and that was when a certain Mr O.J. Dahl developed “Simula”, an object oriented language that would revolutionise the programming industry, and spawn a host of new languages that would take the world by storm.

One of such would be derived from the C programming language, which was popular for its efficiency and control over memory. Later on the developer of C would go on to create “C with Classes”, which would eventually become the C++ we all know and love today.

With the appearance of this new concept, programmers would be able to organise the different elements of their code into what are known as “classes”, which are essentially blueprints explaining the various features of objects inside of their code. When we say the word object, what we are really referring to is an element of code that stores both some data and follows a particular set of rules.

then there were Objects

The most basic element of object oriented programming is the object itself as the name suggests. An object is an abstract data type, which allows users to attach attributes and methods to it to allow it to represent an entity in the real world. The entire motivation for OOP was to take real world elements and be able to represent them in a programming language, and allow them to interact seamlessly with each other.

But let’s go back to that word, “abstract”, and look at it a little more closely. When we say abstract, we are referring to a concept of object oriented programming known as “abstraction”. This is the idea of separating the essential features of an object from those the user need not be concerned with.

Say for example your car was an object. Indeed it is an object present in physical space, but say it was an object in terms of programming. All we really care about is putting the keys in the ignition and driving it. We don’t need to control how much fuel is injected into the pistons, or any of the other internal workings of the car (unless it breaks down). This is the same with abstraction. We have an object with potentially loads of attributes, but only some of them are of any concern to the person using the object.

Furthermore, we can go on to describe “Encapsulation”, which is the concept of hiding the inner workings of an object at an implementation level, but we won’t discuss that in this article. The principle of abstraction can be extended further into object oriented programming with the introduction of classes.

followed by Classes

So far our car object isn’t representative of an actual car since there are millions of different cars in the world, yet we’ve only defined a single car object. This is where classes come in. Classes are much like blueprints, in the sense that they contain all the information about how an object is constructed, much like the car would have gone through a design and prototyping stage before being mass produced and sold to the public.

In terms of programming we can instead define a Car class which will store the information about this specific car model, except this time we just make a new instance of it every time we want to refer to a new car.

Let’s take about this new word “instance” that I have just introduced. Since our Car class represents our blueprint, we need something to be made from the blueprint. This is where Instantiation is introduced.

and their Instances

Instantiation is the concept that a class contains all of the information that it requires in order to describe a new object. What that means is that much like a car’s specification describes the inner workings of the car it refers to, a class describes the behaviour of the objects that stem from it.

For example our specification may include the dimensions of the vehicle, as well as the number of seats and doors it has. Whenever we make a new car, the model stems from the blueprint, and this concept is the same in object oriented programming.

Whenever we make a new object using the Car class, we refer to this as an instance of the Car class, since it describes the features that a car has. Some instances may have five doors and five seats, some may only have two doors and two seats, but they are all described by the car class.

But what if we want to go further and start describing other vehicles? For example both a car and a bus has wheels, an engine and seats, however a bus also might have a cash register for passengers to pay their fare, as well as stop buttons and stairs if it’s a double-decker. In this case we can describe a brand new Bus class which “inherits” from the Car class. This leads us on to inheritance.

#game-design #programming #code #programming-languages #software-development #visual studio code