💾 Archived View for dmerej.info › en › blog › 0107-classes-suck.gmi captured on 2024-05-12 at 15:01:40. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-07-16)
-=-=-=-=-=-=-
2019, Nov 09 - Dimitri Merejkowsky License: CC By 4.0
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?
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[1] 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.
Here are the specifications of the exercise:
Your 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.
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
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!
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.
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? Let's find out in part two[2]!.
----