This is the second article in a 2-part series of blog posts that examine the complicated relationships between the real world and object-oriented code. If you haven’t already, you should read the first part: classes suck first.
Let’s recap: we used a
Robot class to implement the
client specifications. It worked well, until we tried to model the
stop methods with a mutable state. We concluded that
blindly using classes (with methods and mutable attributes)
to represent real-worlds objects was a mistake.
Taking a second look at the code #
Let’s look at the code again (minus the
along with the spec:
- When robots come off the factory floor, they have no name:
def __init__(self): self._name = None
- The first time you boot them up, a random name is generated:
def start(self): if self._name is None: self._name = generate_name()
- When a robot is reset, its name gets wiped:
def reset(self): self._name = None
So we were modeling real-world objects with our class after all: the mistake we made was trying to model the robot. But using code to model the specification worked!
If you’re not convinced, consider this: the
stop() method is
empty because the specification said nothing about what happens when the robot is
If the specification said something like the robot cannot be reset when it is
started, then using a
stopped attribute may have been a good idea.
So far we talked only about methods and attributes. There’s another aspect of programming with classes I’d like to examine next: the concept of encapsulation, or how to separate “private” implementation and “public” interface.
Basically, there are some details of a class that matter to the people who wrote the class but that users of said class should not know about.
What does this have to do with the real world? Everything! Let me show you.
A single line telling a whole story #
In Python, to signify to users of a class that an attribute is not part of the “public” interface, you prefix it with an underscore, like this:
class Robot: def __init__(self): self._name = None
By the way, there are already two pieces of information here:
- robot names are empty at first
- the name likely changes over time (otherwise it would probably have been passed as a parameter in the constructor)
But that’s again about the specification. What does it mean to have
_name as a private attribute?
Working in teams #
Let’s imagine we are writing software inside a big company with several teams. Reading the specification again, it’s clear that the client is extremely worried about robot names: each and every line of the specification talks about it! If there is a bug affecting the robot name, the client is going to get pissed.
And that’s where using encapsulation makes sense: by “hiding” the
name attribute from the users of the Robot class,
we are actually covering our bases. If someone from another team writes
robot._name = "something-else",
the client will get mad (the robot name no longer has the correct format), but we can tell him it’s not our fault:
the other team should not have broken the encapsulation without asking us first!
So, which is it? Do classes rock or suck at modeling the real world?
Well, it all depends on what you mean by “the real world”. My advice to you is:
- clarify specifications as much as possible
- write code that closely resembles the specification
- use encapsulation when necessary to protect yourself against misuses of your code
When used correctly, classes are a great way to accomplish all of the above, but they are also easy to misuse.
Finally, let’s go back to our original question: “is modeling the real world in code worth it?”.
Well, if it allows you to implement the specifications correctly and makes things easier for you and your teammates, then yes, it’s definitely worth it.
It’s hard, but trying and solve this challenge is what I love about programming.
Update 2021-09-16: see also this fantastic article by By Mathias Verraes and Rebecca Wirfs-Brock: called Design and Reality.
Thanks for reading this far :)
I'd love to hear what you have to say, so please feel free to leave a comment below, or read the contact page for more ways to get in touch with me.
Note that to get notified when new articles are published, you can either: