How To “Think OOP” With The game of Classerole

A fun way to learn the fundamentals

Shemar Gordon
The Marcy Lab School
4 min readJul 6, 2021

--

When you first start out, Object Oriented Programming can seem weird. It’s common to start with creating simple functions to accomplish tasks in a functional way. By that I mean, that the data you need to operate on exists independently of the functions you create to do the operations, functions would evaluate and pass the results into other functions and the whole program is essentially a large decision tree. Functional Programming is indeed one of the ways professionals approach problem solving in the real world, but you as an aspiring developer have come across the concept of Object Oriented Programming (OOP) in your studies. If your first language is C-like or similar to Java, you quickly find yourself looking at the mountain that is simply understanding OOP and being able to create and design according to that paradigm. Today I present to you a neat little mental exercise to make thinking in terms of OOP feel more natural over time.

What is Classerole?

Classerole is similar to a lot of party games, like the one where given a letter, a player should come up with as many names starting with that letter etc. In Classerole, given an object in the real world — any object — try to create a class that is as accurate to reality as you can with your current knowledge of the object. Basically, try to model the object as abstractly as possible as if you would have to create that object with code. The player who makes the most thorough class-diagram (or Classerole) with the most valid properties and methods within a given amount of time wins, as determined by an impartial judge. Properties and methods can be scored however the players might like, but since methods are less common and take more time to figure out, they should be worth more points. After time is up, the players will spend some amount of time presenting to the judge their properties and methods.

Let’s Play!

Image Source: polandspring.com

Now lets give it a try! The water bottle above will be our object to be “Classeroled” for this round. Each player will have 5 minutes. Each property will be worth 1 point, each method will be worth 5 points. We will pretend to be judging the Classeroles of two players. Ready? Set. Go!

Results

Time’s up! Lets look at the Classeroles of our two hypothetical players as the judge. Player 1 has 16 properties and 2 methods, Player 2 has 6 properties and 6 methods. Player 1 has given us a very detailed snapshot of the state of the bottle, but not so much on how we can use all that state. Player 2 perhaps has less properties because he/she placed priority on what state can be used to create usuable methods.

After both players make their case to you, you notice that there was a diffence in design choice regarding the opening and closing of a bottle; one player has separate methods for opening and closing, while the other has a single method that toggles the state. As the judge, you can now decide whether to award both players the same 5 points, or give Player 2 10 points should he/she make a compelling case for using two separate methods. This time, we will do the former. Final Scores: Player 1, 26 points and Player 2, 31 points.

Conclusion

The point of this game isn’t necessarily to win, but instead to spur the players on to think in a more object oriented way, and to get used to the challenges and caveats that are included. The other goal of the game is to expose others to different approaches to the same problem, so that group learning occurs. For example, Player 1 went for a super detailed, index-like approach that has a lot of information that can be used later for very powerful and precise methods. Player 2 opted to think more barebones and only defined state that would be useful for the methods.

Of course, all sorts of considerations may come up during the discussion of each Classerole, like the aforementioned design difference, or even deeper rabbit holes — like questioning whether the methods defined on Water Bottle should be on Water Bottle at all, and perhaps belong to a hypothetical Person class instead. While the game does not carefully consider the specifics of how the state and methods would interact, I feel that it is a great little exercise beginners can use to train their minds and perhaps find inspiration to know more about the world around them. Who knows? A bright mind might one day create some cool gadget that stemmed from his/her ability to deconstruct our world into properties and methods.

--

--

Shemar Gordon
The Marcy Lab School

An up-and-coming software engineer from the Marcy Lab School.