Object Oriented Programming#
We're making a big leap now, we're shifting paradigms! In the beginning, we did imperative programming — we gave commands or instructions to our machine and changed some variables. Later we did procedural programming — we were able to put certain parts of our programs into their own structures (functions) with their own scopes. With object oriented programming we're reaching another big milestone that will give more structure to your programs and hopefully will make them more readable and maintainable!
Imperative | Procedural | Object Oriented |
---|---|---|
instructions that change variables | reusable functions with scope | cohesive objects that interact on a defined interface |
Interacting Objects#
So, what does it mean when Objects interact? We're still using variables and we still have functions we even still have commands we give to the machine. We just have yet a smarter way of grouping and structuring these things.
When you wrote your projects so far, you probably had a whole lot of variables in place that were doing different things. If you were completing the Lunar Lander assignment, you might have had a list of variables like these:
float playerX = 0;
float playerY = 0;
float health = 100;
float targetX = 0;
float enemyX = 0;
float enemyY = 0;
int score = 0;
float direction = 0;
These variables would later be updated to make the player move and to control the general flow and outcome of our game. This works (as evidenced by hundreds of programs written this way), but it has a key shortcoming: It places a lot of the burden on you, the programmer. You need to remember that playerX
and playerY
and health
are related to the same player character in your game. You also need to keep in mind that enemyX
and enemyY
belong together, but targetX
and score
are completely separate from all of the above.
what does direction
belong to?
Truth is, we can't be sure. If I already know what the program does, I can speculate. In a Lunar Lander, I would assume that this is the player's direction of travel, but this uncertainty is not ideal.
This is the key thing that Object Oriented Programming solves, in my opinion. We have yet a better way to keep things with each other that belong to each other. This also keeps things separate that are supposed to be separate. And it introduces even better possibilities to hide internal complexity from the outside world.
Importance of good Names - reloaded
In the code example above, the variable names help tie certain variables together visually. That is a good start, but Object Oriented Programming goes way beyond that. But even with OOP, please put effort into your variable names!
Keeping Things in Your Head#
Even though the second graphic contains much more information, the relationships are more clear. We don't just have a faint understanding about which variables belong together, the "belonging" is enforced by the fact that they are "in" an object together. This second graphic also illustrates another key point: Objects don't just contain variables.
Variables and Functions in One Place#
Objects put the data (1) and behavior (2) in the same place together. You will access them from the same variable name.
- The technically correct term for this data is "attribute" or "property". But in an object, these work exactly like variables, so if you call them variables in your head, that's OK.
- The technically correct term for those behaviors is "method". But in an object, these work exactly like functions that belong to an object.
To accomplish that, we tell our computers, what the blueprint of our Object is going to be. We're telling our computer "this is going to be a Student, and each of them will need a name and an email address and they can listen and speak".1
This is what we call a "class" of things. Not because this is about students, but because they all are built the same way.
-
I realize that all of you are more complex than that, but this is also part of programming: understanding which parts you need to have in your particular program and which parts you don't. ↩