Sometimes even the simplest objects are complex systems. Take our humble alarm clock from before. If we flip that alarm clock over and look inside that little door on the bottom, what will we find? A battery compartment!
Suppose the battery compartment is empty and we need to purchase a battery. You would need to specify the type of battery for your clock before the salesperson could locate one for you. You’d have to describe its attributes, say the shape (AA, AAA, etc.), whether it’s a rechargeable battery, and so on.
You might need to describe some of its behaviors, like if it tells you its charge level. Wait a minute...that sounds familiar...does this mean a battery is yet another object? I bet you’ve already figured this out, haven’t you? 🤓
That’s right, just like we saw in the video with our house and solar panels, our alarm clock has an attribute that’s also an object in and of itself - a battery! This means that the battery has its own blueprint (class) describing its specific attributes. It could look something like this:
AA, AAA, 9V
alkaline, zinc, lithium
Why is it useful to use objects as part of other objects?
Creating the battery as its own class of object gives you more flexibility. Imagine you need to improve the battery to capture sunlight for self-recharging. Do you want to change the alarm clock as well? I certainly hope you said "NO WAY!"
Well, since the battery is an object, you don’t have to! You can modify the blueprint (class) of your battery object without affecting the alarm clock, or any object that uses it. As long you don’t change how the battery plugs into the alarm clock, it doesn’t have to pay attention to how the battery does its thing! And like the Tesla smart-car, all devices using the battery get the new and improved self-charge feature. Nice!
Why stop at alarm clocks? You can certainly think of more complex examples of this in real life. Take a look at this extreme example of a car:
This is an automobile before assembly. Each of the parts you see lying on the floor is an attribute of the automobile, but each attribute is also an object. Pretty neat, right?
Independent objects used as a part of other objects need a way to communicate. Since they’re not one and the same, they can’t magically understand what the other object wants or needs without communicating. That is why they send messages! Just like the solar panels sent messages to the house so it could use any solar energy gathered, the battery sends messages to the alarm clock. This ensures that it knows the level of battery charge left. That’s why your alarm clock can warn you when it’s low on batteries!
Think about your smartphone. It has a brand, a price, a carrier, and a battery, which is its own object. It can do lots of things, but one of them is turning on. When you press the power button, you’re asking it to turn on. When this happens, it will send a message to its battery, asking it to provide power. And the battery will send the smartphone power.
Can you imagine a different kind of interaction, where the battery determines that providing power is not possible at the moment? If the battery is depleted and has no more power, it will send a message to your smartphone telling it that it can’t provide any more power. The same happens when the battery starts to run out. It can send a message to the smartphone, warning it before it has to shut off.
If the phone is able to power on, we might say that the phone has a charge. However, now that you are becoming the object-oriented expert, it is more accurate to say that the phone's associated battery has a charge!
So, what is a complex object-oriented system?
In an attempt to make this as simple as possible, let's reduce it to what it actually is.
Everything should be made as simple as possible, but no simpler.
- Albert Einstein
We have discussed objects and learned about how they interact. It would be accurate to define an object-oriented system as a network of interacting objects. In a nutshell, those five words sum it all up rather succinctly.
Objects can have attributes that are objects. These objects also have their own independent blueprint (class), attributes, behaviors, and access.
Objects communicate with one another by sending messages.
Associating objects with other objects allows you to more easily adapt and make changes to your system.