Introduction
A long time ago I received a lecture about the usage of databases and software design. More specifically, how to translate relationships like “one-to-one”, “many-to-many”, or “one-to-many” inside databases schemas.
Ten years later, I still remember one thing the teacher said at the beginning of the course:
When you are designing your database schema, your enemy is the real world. The real world is always more complicated than you anticipated.
This is not new, of course, but it raises some interesting questions: how can we model the real world in our code? Is it worth it? Is not all software made of abstract objects? Are classes and instances the correct way to do it?
A two-part exploration
In these two parts series, we’ll try and answer the last question.
We will use an exercise I’ve stolen from the exercism.io website, and the two parts will argue opposing points of view.
Let’s start with part one: classes suck. Bear in mind there we’ll be a part two called classes rock, so don’t leave angry comments below just yet :)
One last thing: this is a story based on real events: the code I’m about to show below was written this way by students I’ve just taught about instances and classes in Python.
The Robot factory exercise
Here are the specifications of the exercise:
You are a developer inside a robot factory. Your task is to manage robot settings. Here are the rules:
When robots come off the factory floor, they have no name.
The first time you boot them up, a random name is generated in the format of two uppercase letters followed by three digits, such as RX837 or BC811.
Every once in a while we need to reset a robot to its factory settings, which means that their name gets wiped. The next time you ask, it will respond with a new random name.
And here’s the code we’re given a starting point:
class Robot:
# Put your code here:
pass
def test_name_is_not_set_at_first():
robot = Robot()
assert robot.name() is None
def test_started_robots_have_a_name():
robot = Robot()
robot.start()
actual_name = robot.name()
assert re.match(r"^[A-Z]{2}\d{3}$", actual_name)
def test_name_does_not_change_when_rebooted():
robot = Robot()
robot.start()
name1 = robot.name()
robot.stop()
robot.start()
name2 = robot.name()
assert name1 == name2
def test_name_changes_after_a_reset():
robot = Robot()
robot.start()
name1 = robot.name()
robot.stop()
robot.reset()
robot.start()
name2 = robot.name()
assert name1 != name2
Let’s try to fix tests one by one, starting with the first one.
Making the first tests pass
All we need is a name() method that returns None:
class Robot:
def name(self):
return None
For the next test, we need a start method that will cause the name to change. Let’s store the name in a private attribute _name and adapt the rest of the code:
def generate_name():
# implementation omitted for brevity
class Robot:
def __init__ (self):
self._name = None
def name(self):
return self._name
def start(self):
self._name = generate_name()
To fix the next test, we need to implement stop:
def generate_name():
...
class Robot:
def __init__ (self):
self._name = None
def name(self):
return self._name
def start(self):
self._name = generate_name()
def stop(self):
pass
And then we get:
test_name_does_not_change_when_rebooted:
> assert name1 == name2
E AssertionError: assert 'KJ721' == 'JO813'
E - KJ721
E + JO813
Making the test about reboot pass - first attempt
Clearly, we have a bug in our implementation. The robot's name must not change when it’s rebooted.
If we follow the “code objects must reflect real-world objects” rule, we may be tempted to say that robots have a state and that this state can be used to know when the name must be regenerated.
And we can choose to represent the state of the robot with a stopped attribute inside the Robot class:
class Robot:
def __init__ (self):
self._name = None
# Better make sure robots are stopped when
# they come out of the factory floor :)
self.stopped = True
def name(self):
return self._name
def start(self):
self._name = generate_name()
self.stopped = False
def stop(self):
self.stopped = True
And that’s where classes have failed us. This stopped attribute does not help at all making the test pass.
We tried and model the real world in our class but it was useless. And then we realize that there’s no so such thing as a “boolean” in the real world. In the real world, robots have LEDs that are turned on or turned off!
Making the test about reboot pass - second try
Let’s revert the change that introduced the stopped attribute, and look at the implementation again. It becomes clear that to make the test pass, we just need an if in the start method:
class Robot:
def __init__ (self):
self._name = None
def name(self):
return self._name
def start(self):
if self._name is None:
self._name = generate_name()
def stop(self):
pass
Making the last test pass is easy: we only need to reset the ._name attribute when the robot is reset:
class Robot:
def __init__ (self):
self._name = None
def name(self):
return self._name
def start(self):
if self._name is None:
self._name = generate_name()
def stop(self):
pass
def reset(self):
self._name = None
Now all test pass and we’re done.
(Temporary) conclusion
Looking at the code, it looks like our object has nothing to do with the real world. The closest connection with the real world is the ._name attribute which is probably just a bunch of zeros and ones inside the memory chip of the robot.
Let’s face it, using classes to represent the real world is a myth, probably spread by overzealous Java developers, or clueless researchers locked inside their ivory towers.
Or is it? Stay tuned for part two to find out!
Oldest comments (6)
Thank you for the article. I'm having trouble to follow your train of thought here though. I prefer functional programming over class based approaches myself but from this article it's not really clear to my why classes suck. Because they nudge you towards overcomplicated solutions? Maybe you can flesh this out a little more?
Yeah, I went for click-bait here. I'm just pointing out that there's something weird going on with classes, software design, and the real world. It seems we can use classes to represent real-world objects, but it also seems doing so sometimes backfires.
They definitely do that too. For more, see the Stop Writing Classes video. But I'm not talking about complexity here, I'm talking about links between code and the real world.
Well, there will be a part two soon and I hope it will make things easier to understand.
Here's part two if you want to check it out.
Classes are definitely not real-world objects, that's just how bad teachers teach it.
If you code in C you'll notice that you often end up working on a given struct/handler/pointer for various operations. Classes are syntactic sugar so
selfgets passed to all your methods automatically.And then you have interfaces, which build upon the way classes are exposed to make abstraction of implementation details and let you create abstractions easily.
Sooooo, I'm not sure what's your point. Should
main()not be a method from a useless class? Definitely. Are classes bad? I don't know, how bad are knives, pillows or airplanes?Totally agree. But why? Surely there must be a reason why they tell us that, right?
That's because I'm not finished :) I wanted to have a cool cliffhanger in the middle of a two-part series instead of one big boring article. I hope you can forgive me.
Part two was just published, we can continue the discussion there if you want :)