In the real world there are objects we interact with everyday. We have objects in code, too. That’s because as programming evolves, it comes closer and closer to how we behave and think in the real world.
There are two things common to all objects: state and behavior. By creating an object in code that maintains state and exposes behavior, it allows you to hide how things actually work from the user of your object.
A great example of this is a radio. It has some state. Is it on or off? What station is it tuned to? And it has some behavior that it exposes, such as turning the power on or changing the station. How does it actually work? Just by looking at it we have no idea. It’s implementation details are hidden from us, but it’s behavior is exposed and we can manipulate the state that it wants us to change.
This is one of the huge benefits of object-oriented programming (OOP). By writing code this way, you’re exposing exactly how it’s intended to be used.
Most languages expose behavior through methods, which are related lines of code that can change the state of each specific object. This has its benefits to the maintainer of the object. Because the user of the object only knows *what* methods an object is capable of but not necessarily *how* that method is implemented, the maintainer of the code can iterate on making the methods as efficient as possible, while not breaking any existing uses of the object. For instance, most car radios seamlessly switched from radio waves to using satellite, while leaving the familiar interface more or less the same.
I’m in the camp that believes proper use of objects leads to more legible code. Object-oriented code is intended for reuse and the more clear the exposed state and behavior are, the more likely it will be used.
This morning, while I was making coffee, I was trying to think of a good example to show that you already know how to work with some pretty advanced object interactions. While I was pouring my cup, I realized that it was right in front of me! Check out this pseudo code:
# Check the state of the Coffee Pot object
if coffeePot.isEmpty
# Perform method on the Grinder object
grounds = grinder.grind(beans)
# Check state of the Coffee Machine object
if coffeMachine.waterLevel is empty
# Call a method that changes the water level state
coffeMachine.fillWater(3)
# Add the results of the Grinder object to the Coffee Machine object
coffeeMachine.addGrounds(grounds)
coffeeMachine.brew()
while coffeeMachine.isBrewing()
# Pun-intended
sleep
# Other objects can also return objects
mug = cupboard.findCoffeeCup()
while not mug.isFull
cofeePot.pour(mug)
Do you see how clearly you can read that code? Well-written object-oriented code is very clear and leads to great re-use of objects. If you had those objects (which you probably do) you could fairly easily figure out how they are intended to work together.
Now take a second and look at your surroundings. What real life objects do you see? What state do they maintain, and what behaviors are you aware of?
Please be careful. Looking at the world this way is quite addicting, and you’ll find yourself having a hard time stopping yourself from breaking down everything you see in real life into a coding exercise.
Don’t worry, we’re here to help, we have a ton of courses in our library on this topic specifically. Here are just a few of our offerings on the subject:
- Java Objects
- Ruby Objects and Classes
- Object-Oriented Python
- Object-Oriented PHP Basics
- Object-Oriented Javascript
Please come and dive deeper. I just released the Java Objects course and I had a great time making it. If you enjoyed thinking about objects, I think you’ll love the course.
Come learn with us!