Conway’s Game of Life
The fundamentals of writing quality code through a simple project
The journey so far
The two projects that I have done with 8th Light have had quite an impact on me. The end results have surprised me and looking at them, my reaction goes something like “Oh wow! I didn’t think I could do that!” Working on these projects have helped me feel much more confident about my abilities.
I have learned that there is a very fine line between self-introspection and self-doubt, and crossing it could be harmful to any engineer’s growth. Making an unbeatable tic-tac-toe and now, the game of life has given me the inspiration to strive for bigger, better challenges.
I have learned that there is a very fine line between self-introspection and self-doubt, and crossing it could be harmful to any engineer’s growth.
Conway’s Game of Life
The Game of Life is a cellular automaton devised by the British mathematician John Horton Conway. The Game of Life is played on a two-dimensional rectangular grid of cells. Each cell can be either alive or dead. The status of each cell changes each turn of the game — also called a generation — depending on the statuses of that cell’s eight neighbors.
You can find out more about the Game of Life by watching this awesome video or reading this Wikipedia entry.
4 Rules of Simple Design — Corey Haines
We have to make a series of the decision while writing a program, ranging from high-level design decisions to the smaller yet critical decisions that we make almost continuously. These include things like the variable/method names, the size of the methods, the responsibility that each method owns, etc. These are the decisions that are often overlooked when working on a deadline, and hence we fail to see many great approaches to solving a problem.
The book, 4 Rules of Simple Design, helps us discover these possibilities by creating Conway’s Game of Life while following the following four rules of simple design:
- Tests Pass
- Expresses Intent
- No Duplication — not just code, also knowledge duplication
- Small
The Code.
User Interface to see if the code works? — Bad Idea!
The first thing I realized was that despite being aware of the various testing strategies, my first instinct was to be still somewhat dependent on the User Interface to ‘see’ if my code is working correctly. This is because of the way I was initially introduced to coding — write a piece of code, see it work. If it does, Yay!
UI does not tell you anything about the behavior of the code, and one cannot be sure about the correctness of the code just by seeing the output. Further, such an approach can lead to the UI being tightly coupled with your code, which is a bad situation to be in. Therefore, I started my code by writing a couple of tests. I am still learning to write good tests, and so I was nervous taking this approach, but I knew that this is the best way to go ahead.
UI does not tell you anything about the behavior of the code and one cannot be sure about the correctness of the code just by seeing the output.
Keep responsibilities in mind to make your code Object Oriented
The first thing I did was to create a Cell class and write all the rules of the game as tests within it. This turned to not be the best place for it, but it was a good starting point. Later, I created a different object altogether to deal with these rules, and I learned that if you keep the responsibilities of code in mind, the code evolves to be more object oriented.
In my code as of today, these rules are in another class called World while the Cell class is a much smaller entity with very limited behavior. Another class, called Grid, manages the cells as per the game rules.
The world is the entity that decides how the grid operates and in turn, decides the fate of each cell — whether it will live or die.
Our code should read like well-written prose
This is a craft that I am still learning, and I have attempted to make my code self-expressive. While seeking the feedback of my code from my mentor, Stephen, he told me that there are parts of my code that use the rules of the game in a rather arbitrary fashion which won’t be comfortable to an unfamiliar eye. This feedback was accompanied by an awesome suggestion- extract out methods, each having a single responsibility and a descriptive name.
Sometimes figuring out what exactly is being done can lead to extracting a method with a descriptive name. — my mentor @ 8th Light, Stephen
Here are a few examples of how I used this advice:
This is a piece from a method that decides which cells to kill and which to revive. This is easy to read and you can quickly understand how the code progresses. Depending on whether a cell should die or live, you add that cell to an appropriate place in the hash cells_to_update.
It’s easy to see here that this game has four rules and a cell dies if rule #1 or rule #2 applies and the cell lives if rule #3 or rule #4 applies.
Finally, the implementation details of the rules stay in their own private methods. My aim was that any reader can identify what the rules of the game are at the first glance and that s/he understands where do these checks and verifications come from, in the code.
Final Thoughts
I will be once again quoting my mentor at 8th Light, Stephen Walker to conclude this blog.
“One of the best ways to gain knowledge is through experience. Try different approaches, weigh the pros and cons of each approach and see which one resulted in more robust and intuitive code. Then you can think about which approach you prefer, did either approach teach you something you didn’t know before? One of the approaches may be more performant, but is the complexity worth it? Could it be both more performant and intuitive? These are the questions and experiences that will push you forward as a software developer.”
PS: Don’t forget to check out my Conway’s Game of Life, here on my Github.
