1. Introduction
Object-oriented programming tries to model the world similarly as our brains do.
In this short tutorial, we’ll explore the core concepts behind this modeling.
2. How We See the World
The human brain doesn’t process the world as it is: it simplifies it. Otherwise, it wouldn’t be able to handle the tremendous amount of information it receives every second. Of course, it matters how we simplify the world: we take into account the important things and ignore the others.
In other words, we create a model of the world in our minds:
3. Modeling With Classes
This modeling process is based on finding similarities between things. When our brain finds two items to appear similar enough, it puts them into the same category, otherwise in different categories.
For example, dogs are similar enough to put them in the same category. (Indeed, the word “dog” is the category itself. We’ll get back to this in a moment.) We know a dog has properties such as weight and color, and it can do something, for example, bark and wag its tail:
Dogs, cats, and tables are similar in the terms that usually all of them have four legs. But we wouldn’t consider putting a table in the same category, with dogs and cats. However, dogs and cats are similar enough for us to create a category in which all of them fit: mammals, or animals:
We have many other categories, depending on how broad we want the category to be. We can even come up with a category, in which tables can fit too: four-legged-things:
This categorization has a more scientific name: classification. Therefore, we prefer to call these categories classes.
4. Objects: Classes in the Real World
As we’ve mentioned, a class represents the similarities between the things we label with the class.
These classes or models don’t exist in the real world. They’re abstractions of reality, only present in our minds:
We never met the thing we call ‘dog’. Yes, it sounds ridiculous, but we need to understand the difference. When we say the sentence ‘I saw a dog today’ is just a short version to ‘I saw a creature today, which I classified as a dog’:
What exists in reality (or at least, existed) are Lassie or Laika. They’re balls of fur and love, which we can pet.
We don’t see the dog class itself, but instances of the dog class in the real world. We often call these instances objects.
5. Encapsulation: Data and Behavior
Dogs can be big or small. They may be grey or brown. Besides, they recognize their name. These are properties of the dogs — data, which we know about them. Every dog has these properties; hence we assign these to the dog class itself. But every dog has different values for these properties.
We don’t necessarily know the values of these properties, but we can obtain them because we know they exist. For example, we can look at them to see their color or ask their owner to learn their name.
In programming, we store theis data in fields:
On top of that, objects have behavior. Dogs can change their state (sit or lay), interact with other objects (fetch a ball), or their environment (make everyone smile around them by acting funny).
In programming, we represent these behaviors in methods.
We define both fields and methods in a class. As a result, all instances will have these properties and behaviors. More importantly, we wrap these seemingly unrelated concepts (data and behavior) into a single entity. In other terms, we encapsulate data and the actions which operate on them:
It makes perfect sense: we tell the dog, and it sits. We don’t put a standing dog in a device, which spits out a sitting dog. Instead, we couple the action with the data because that’s how the world works.
6. The Power of Relationships
Objects can do a lot of things in themselves. But they can do even more when they cooperate. In that case, they’re in a relationship. Cooperating objects are much more than the sum of them.
For example, when the owner throws a ball, it flies away. But the dog runs after the ball, catches it, and brings it back to its owner. This little dance between the owner, the dog, and the ball wouldn’t be possible without any of the participants.
These relationships can have many forms. For more details, please visit our (techy-er) articles about inheritance, composition, aggregation, association, and the difference between them.
A fun fact: in programming, we model some relationships as data.
7. Visibility: Hiding What Others Shouldn’t See
Objects can have data and behavior we don’t want to see, or we shouldn’t see. These details are part of the inner working of the objects. In programming, we call them implementation details.
For example, we don’t see a dog’s organs because the dog’s body hides them. We don’t have a clue about their existence or their working.
This is a good thing, as these things are too complicated for us to understand in most scenarios. We don’t usually want to know how to pump blood through a dog’s veins and lead electricity through its nerves just to make it run. We want one simple thing: a running dog.
The dog uses a simple solution: it publishes a set of well-defined behaviors to the outside world and keeps the other details to itself. The dog doesn’t want the outside world to have the power to intervene in its internal state. It would make it possible to have too much control over the dog, which we want to avoid. With great power comes great responsibility:
In programming, an object’s fields and methods can be independently accessible by other objects. For example, in Java, we control these with access modifiers.
8. State Handling: Mutable or Immutable
Objects can be mutable and immutable, depending on if they can change their internal state (data) or not, respectively.
For example, dogs are mutable because their weight changes depending on how much they eat. In contrast, a banknote is immutable. After it comes out of the printer, it’s currency and value won’t change. A $10 bill will never become a €5 bill.
In most programming languages, objects are mutable by default. We need to do additional work to make them immutable.
9. Referencing Things
Sometimes we want to specify which object we’re talking about. For example, we may have multiple dogs. To avoid confusion, we name them and call them by their names. Also, they can have numerous names, for example, nicknames. Nevertheless, dogs answer to their names. We reference or point to a specific dog by its name.
When we talk about a dog, we put its reference in the middle of the sentence. For example, when a family has a dog, and someone says, ‘I’ll walk the dog,’ everyone knows which dog she means. But unfortunately, dogs have a shorter lifespan than humans do, which means that the dog can die, and the family can have a new dog. When this happens, the same ‘I’ll walk to the dog’ sentence will mean a different thing.
It’s the same variable, but it refers to a different object. The value of the variable can change:
In programming, we store objects in memory. But we can’t access them directly; we need a way to refer to that particular memory address, where an object is. To do this, we use variables, which are references to parts of the memory. These variables have names, so we can understand what object they hold.
10. Things That Don’t Change
There are constant things in life. When we refer to these, the time is irrelevant; they always mean the same thing.
For example, when we say Earth, it always means the same planet. Of course, someday, the Sun will expand, explode, and destroy the Earth, but there won’t be another planet that will take its place. Earth is this ball of rock we live on, and nothing else.
In programming, we can’t assign a new value to a constant. Depending on the programming language, the exact time when a constant gets its value may change.
11. Constants vs. Immutables
To put things together: variables refer to objects. Two things can change here: the internal state of the object, and the object itself that the variable points to.
Immutability is about the internal state of objects. Final or nonfinal is whether we can change which objects we refer to.
These things are independent. We can have all four combinations.
12. Conclusion
Object-oriented programming works so great because it tries to model the world with the same modeling techniques as our brain does.
In this article, we introduced these concepts and demonstrated them with simple, real-life examples.