It's not unusual that when you first approach programming you will encounter this phrase “object-oriented programming” or perhaps just “object orientation”, and you're trying to figure out what this means. But reading about it just makes things worse because then you're surrounded by a bunch of jargon or terms like polymorphism and encapsulation, and phrases like composition over inheritance or dependency inversion.
It is challenging to understand it first. That's because object orientation is an idea, or rather a set of ideas. It's a bunch of different principles that have been adopted and implemented in slightly different ways by many programming languages. Out of all of these languages, the only one that doesn't support at least some object-oriented features is C.
Fig 5.7.1: List of languages that support OO (object-Oriented) features (except C)
A lot of these languages are highly oriented. So, it's important, because most popular languages have some object-oriented features and some of them have a lot. That means the language expects you to understand those ideas and follow those principles. If you don't, writing code is going to be like pushing against the tide.
Now I could do an entire course on object orientation. In fact, I have done and I will do again, but that's not my focus here. In the next few minutes I want to cover a few of the most important ideas and a few of the words you'll encounter again and again.
But before we get into any of the jargon, here's the larger, more fundamental idea behind all of this. If we just sit down and write code, we go by the seat of our pants, we write variables, we write functions, we use loops, and so on. We can use all of the things we've covered so far.
Imagine I'm writing the eCommerce section of a website, dealing with members and their purchases.
Fig 5.7.2: Variables and functions of a sample ecommerce website
I'll have a bunch of different variables: information about orders, data about customers, data about discounts, and a bunch of different functions, such as everything from signing up for a newsletter to processing a payment, to changing the email address of a member.
Even if I was trying to organize my code as I wrote it, I might do something like just put all my variables (all my data) in one place, and all my functions in another. I might even put them in separate files.
But with object orientation, what would be important is the way that we separate and group things. Just putting your data and logic in two massive areas like this is the wrong approach.
Instead, we should think about the objects in our program. So, what are objects?
Well, first think of the things I'd naturally say as a human being when talking about what this program needs to do. What are the nouns I would use? Talking about e-commerce I might say,
“A customer can begin a new order by adding an item to the shopping cart”.
First, I'll look at the nouns in this:
Those might be good potential objects I might use an object-oriented version of this program.
In a media player program, the objects might be things like
In a game, the objects could be
So, it's these objects that should drive the way that we group and separate our program. See Fig 5.7.3.
Fig 5.7.3 Examples of objects in different object-oriented programs
The important thing is objects are not just data, they're not just a few variables gathered together. Objects have both data and functionality. They have behaviour and code that actually performed tasks on that data.
In a game for example, I might want a spaceship object that will hold data like its position, its shield level, its name and its color, but it would also hold its own functionality like firing a missile, flying, exploding and everything that the spaceship needs to do. So, each object becomes almost a self-contained miniature program that’s able to manage both its own data and its own behavior. See Fig. 5.7.4.
Fig 5.7.4: Examples of data and behavior in a “Spaceship” object-oriented program
Now there are a few words used a lot across object-oriented programming languages and here's the first two:
I'm explaining both at the same time because these words or ideas are two sides of the same coin. You can't have one without the other. In object-oriented programming, the class is how we define what an object should be, how we describe it, whereas an object isn't a description of anything. It is the object itself.
To make two analogies, a class is like a blueprint for a house and the object is the house that was actually made from that blueprint.
Fig 5.7.5: Comparing Class and Object in object-oriented programming
Alternatively, a class is like a recipe. It is the detailed description of the stamps and ingredients, but you can't eat a recipe. So, the object is the actual dish created when that recipe is followed. See Fig 5.7.5.
There're are two ideas to take from these analogies. One is that each class can be used to make multiple objects, like one blueprint could be used to make multiple houses. Similarly, a recipe could be followed again and again. The other idea is that the class comes first. You define a class and then you can make objects from that class.
So, when writing code, the class is the code we actually write to define what it means to be a customer, a spaceship or a person. You define a customer class and then you can make a thousand customer objects from that one customer class. You can make a spaceship class and make a dozen spaceships from that class.
Now you don't have to make multiple objects every time, but you can. In most object- oriented programming languages, there is a keyword class that you use when defining one. In Fig 5.7.6, for example, I'm creating a class and calling it spaceship (the name is up to me). Inside the class (the code block), I'll define both the data and the behavior that I want for objects of this class.
Fig 5.7.6: A sample code containing class and objects (a simple object-oriented program)
This could be something as simple as just writing a few variables and a function or two. We've talked a lot about variables and functions in earlier chapters, but in object orientation we often use a different name for variables and functions defined inside a class, to differentiate them from conventional variables and functions.
So, we say that the pieces of data are the properties of the class, and any behaviors we have are the methods of the class. Like a blueprint or a recipe, there is no point defining a class unless you're then going to create an object from that class. So, there's one more word. When we actually make an object from a particular class, there's a term we use for this:
We are creating a new instance of this class. See “instantiation” in Fig 5.7.7.
Fig 5.7.7: Examples of properties, methods and instantiation of a class
There's often a specific keyword used for instantiation. The most common one is new. So, after our spaceship class was defined in Fig 5.7.7, I can create a new object…
new Spaceship()
of that spaceship class type. I call this new object whatever I want. It's the usual naming rules. I can then access once inside it usually with dot syntax to get to its data or its properties. I can also call its methods, its behaviour.
If I wanted to, I could then create another new instance of this class (another object), and each object is completely independent of the other objects. They all contain their own copies of their own data, their own behavior. See “// Instantiate another object” at the bottom right side of Fig 5.7.7.
Okay. If the last few paragraphs were your very first introduction to these ideas, I would not expect things to seem clear yet. Bear in mind, these are principles and concepts that have been evolving for 35 to 40 years from some of the nerdiest people on the planet. It is okay if it takes some time to grasp this.
But if you can get comfortable with one of the basic ideas that once a class has been defined, you can create or instantiate multiple objects based on that class. I can tell you something that will make this easier. You see, you won't have to make the class for most of the objects you will instantiate because it already exists. It's already done.
In most real-world programming environments, there are a huge amount of classes already defined and just available for you to use, often hundreds or even thousands of them. Everything from basic things like dates, times, images or sound players. There are classes for graphics, classes for audio, for encryption, classes for making a user interface like buttons and sliders and check boxes. It's all there.
Becoming productive as a programmer is often less about writing everything yourself and more about finding what's available and tapping into it. But we have to talk about this for that subject to make sense and that's what we're going to explore in the next chapter.