Object Oriented Programming: An Introduction

Subscribe to my newsletter and never miss my upcoming articles

Some of what I said in this post is not entirely accurate. I was going off of what I thought OOP was in my mind. The point made about it defining actions, rather than data, is correct. I am leaving my original post, however, for archive purposes. We all learn new things over time.

What is Object Oriented Programming? Why is it so commonly used? How does it differ from procedural programming? OOP is a massive concept that is so powerful, and robust that the world's most complex systems are built using it.

TL;DR; Object-Oriented Programming is like a blueprint to things. A Class is like a noun: A person, place, thing, or idea. A Method is an action, like a verb: A plane can fly, or a door can open and close. These are actions of that object. OOP helps us to create portable, reusable and highly scalable applications and code. OOP makes me smile inside.

When I began programming, which was some time during 2013/2014, I was learning PHP on codecademy.com. The way they teach on that website can be a little unhelpful in the way of context. I'm a very visual learner and I was able to get the code to run and do what it was supposed to do, but I didn't quite understand the practical application of it. Once I began learning to develop websites with PHP it made more sense, but the more I wrote code the more I noticed even then that I was duplicating a lot of it. This led to having to maintain those same functions or snippets across the entire application. If the purpose of that code changed I would have to go find all of the other spots I used it and change it their as well. Not ideal if your application gets to be hundreds or even thousands of files big.

In my early days of writing PHP I didn't even know what a function was. My definition of a function was copy pasting a series of variables and if/then snippets all over the place. Using a function was a major concept for me to learn. After a while I got comfortable with them and I learned to keep them in separate files which I could "include" in other files. At this point in my dev career I felt as if I knew what OOP was. Sadly, I did not. Just writing a function does not make your code Object-Oriented, but it is a step in the right direction.

It's easy enough to Google what Object-Oriented Programming is, but when I was first trying to understand it these definitions didn't do squat for me. Every definition I read ended up leaving me less confident in an answer than I already was. So, I'm going to give you my own definition of what I think OOP is. Buckle in, because it's story time.

OOP is a way of defining things (most often data) in the form of objects. We are surrounded by objects. Your car is an object, your computer is an object, and even an idea can be an object. A good way to relate this to some very rudimentary topics is to think of an Object like a noun. An Object can be any person, place, thing, or idea. You can define the "shape" of that object through what are called Properties. A car will have doors, windows and a motor. But, the car can also do things. This is what we refer to as Methods. A method is really just another word for a function, the primary difference is that it is inside of an object (a Class actually, but more on that later). What do these functions/methods do inside of an object? They perform some kind of action. Think of a method as being like a verb. You can start the engine on your car, and then of course you can shut off the engine. These are both examples of a function that the car, or you, would perform on the object.

Okay, big deal, why is this so helpful if all you're doing is saying your car has doors and windows and what not? Well, let's say you want to go from building your first car, to being able to mass produce your cars. You're going to start your own car company called Edison. You're going to be the foremost pioneer in the new world of electric cars. If you are going to do this you don't want to have to build every single car from the ground up. Each new car you produce you'll have to define the same specifications over and over. "Oh, we need another car, this new car also needs doors, windows and a motor, etc." So, instead you create a blueprint from which you can mass produce them. What is this blueprint called, you ask? It's a Class! An object's structure or what I call it's shape is called a Class.

Here's an example of what it would look like in JavaScript if you kept building each new car from the ground up. This is also often referred to as Procedural Programming.

Without the Benefits of OOP:

// Our first car
var car1Model = "F";
var car1Doors = 4;
var car1Windows = 6;
var car1Engine = "Electric Mark 1";
var car1Year = 2020;

// Our second car
var car2Model = "F";
var car2Doors = 4;
var car2Windows = 6;
var car2Engine = "Electric Mark 1";
var car2Year = 2019;

In the non-OOP example above you can already see how cumbersome it can be to write that way. For every new car you make you have to make sure you get all of the specs correct on it every single time. If you make 100 of these cars all written out by different people you may get some that are missing doors, or windows, or that have an engine in them that doesn't even exist. The reason is that there is no blueprint. You're relying on everyone knowing exactly what they should need to make one of your cars. Good luck with quality control doing that!

Enter OOP.

Example of Mass Producing with OOP:

class EdisonCar
        public Model: string;
        public Doors: number;
        public Windows: number;
        public Engine: string;
        public Year: number;

// Now, we always have to make a car that has all the same properties
var car1 = new EdisonCar();
car1.Model = "F";
car1.Doors = 4;
car1.Windows = 6;
car1.Engine = "Electric Mark 1";
car1.Year = 2019;

var car2 = new EdisonCar();
car2.Model = "F";
car2.Doors = 4;
car2.Windows = 6;
car2.Engine = "Electric Mark 1";
car2Year = 2020;

In the example that we use OOP principles in we create what's called "an instance" of an object, which is our car, and once we do we set the properties of that car. By looking at the code you might say, "that doesn't look like we're saving much in the way of writing code?" But, that's not the point here. When you have a very small example like this you won't see much in the way of less writing. I also admit I picked probably the weirdest properties of a car to use for the example, but whatever, mistakes were made.

Let's take this a step further. Imagine that you aren't able to manufacturer your cars in your own country. Instead you need to ship out your cars designs to factories in other countries. To do this, you need to make sure that each factory makes your cars in exactly the same way. Here's where OOP becomes so powerful. If you were to put an order in for 100 cars from factory 1 (let's assume you have 2 factories) and they don't have a blueprint for your car, who knows what you'll get back!? To put this in terms of programming again, why this strict adherence to the data type we expect is because if we make a request for some data, our car in the example, and we end up getting back an object of a truck or even a house, we absolutely will not be able to work with that. If Edison Car company gets back trucks and tries selling them people are going to question whether you should be the chairman of the board anymore. They also will not be amused by your tweets that people should get over the fact that they ordered a car and instead got a truck...

All ridiculous joking about famous people getting themselves kicked out of their own company aside, Object-Oriented Programming allows our code to be extremely portable, reusable and increases our ability to scale up. You now know that no matter which factory you send your blueprints to you can always expect the same results to come back.

So, to recap a little bit. Object-Oriented Programming is a very literal term for programming with the mindset that we are working with real life objects. Even abstract objects like an idea still have properties to them. A company may not exist yet, but if you are just starting to think of a new company it will have a Name, an Ideal Location, Employees and Products or Services. All of those are properties of the idea of your company. When you grasp the concept of OOP you can take your programming skills to the next level.

One thing that I find fascinating about OOP is that the concepts and applications it are never-ending. There are different ways of structuring your code within OOP. Another thing is the similiarity between OOP and factory techniques. OOP is all about efficiency and effectiveness. You will hear the term "abstract" thrown around a lot within the subject and something else that you may see is the use of interfaces. I won't get into too much detail here, but an interface is still a blueprint, but it's use can be spread out to many different objects. Let's use the car example again. A car is a type of vehicle. A truck is also a type of vehicle. So, you could make an interface that defines characteristics that both cars and trucks share. The "Vehicle" interface will contain things like a motor, wheels and windows. But a car is not a truck, and a truck is not a car. They only share similar properties with each other. That's it's own topic altogether, but I wanted to give a glimpse of how far this rabbit hole goes.

I hope that this was a relatively painless introduction to what OOP is and that you are left feeling a little more confident about the concept. I will be very honest, it took me several years before the concept clicked. I remember sitting in a China Buffet one night frustrated out of my mind Googling all the things about OOP, but still not being able to grasp it. If it's now clicking immediately, just keep learning the code, at some point it will definitely sink in.

Photo by Oli Woodman on Unsplash

Comments (3)

Maxi Contieri's photo

Thanks for the article

I strongly disagree with this 'OOP is a way of defining things (most often data) in the form of objects'

In OOP the focus is always on behavior (essential) and not about data (accidental)

I think you are writing about anemic objects or DTOs, no OOP

It is just an opinion

Charles Jennings's photo

I appreciate the feedback. What would be a better way to word that while still keeping the definition short and simple?

Maxi Contieri's photo

Charles Jennings OOP is about independent entities who talk to each other to fulfill objectives.

But there are surely better and more compact definitions out there.

It is ok to talk about data on structured programming. but in OOP we talk about behavior and don't care about any data.

Again. it is just my opinion