Completing Object Oriented Tic Tac Toe!

It is always satisfying when you get to the end of something. There is a sense of satisfaction and maybe even a bit of apprehension. That is what I can say as I came to the end of the Introduction to Ruby at Flatron School. I can say two things with certainty:

  1. I never thought I would be challenged this much with Tic Tac Toe.
  2. I still don’t feel 100% confident with Ruby. 🙁

I mean, I feel much better with it than I did coming in. I had done some study with it at Treehouse, and the Learn Ruby the Hard Way book from Zed Shaw. Flatiron challenged me. I nearly broke me at times, as anyone following this journey can attest to.

And that was the intro.

In any case, part one is over. As such, this post is going to delve into reviewing the last part of the intro to Ruby: Object-oriented Tic Tac Toe.

To begin, its probably imperative to explain the difference between procedural Ruby and Object-oriented Ruby. I understood it like this.

In the procedural approach, we wrote a series of methods and had the data laying there at the beginning by itself. We then, in a step by step approach, acted on the data. It was not organized into anything, and could be haphazard in how it is handled. We have to know what is happening to the data as we go down the list of procedures. In the procedural version of tic tac toe, we acted on the board array. If we have a procedure that affects it in a way we don’t account for, the next step could break or cause us any number of issues.

In the object oriented approach, the object we create acts on its on data. Inside the object, the data and methods are all bundled together. To see the end result of the procedural tic tac toe, check here. Now, let’s look at the object oriented approach!

First, I’ll lay out my code:

This is the bin file:

And here is the Ruby file:

So, to understand what is happening, we need to start with what a class is. Flatiron decribed it as a blueprint used to build an object. So, we are creating a blueprint here of what a Tic Tac Toe game is. This entire object is the Tic Tac Toe game. When, in the bin file this is called:

It is creating an instance of the Tic Tac Toe game that loads everything needed to play the game until a victor is crowned or it ends in a draw.

I won’t go over everything inside this as it will probably look familiar. There is a big difference, however, in that the board array is created here:

and then passed around inside the object. I will admit to being confused on the argument being passed in here. Flatiron presented this as:

But when I went and built it I just created the board as the Array with 9 empty strings. I did not, and still don’t, understand why the “or” statement is needed here. What is confusing is the need for the argument being (board = nil). I tried doing it with only board passed in and it broke the whole thing…

And this is the error I was given:

I mean, I passed in board still. Why does it need to be nil? In any case, being nil works for it, and who am I to argue…

Now, some things to note. @board is an instance variable. This allows it to be passed around from method to method inside this object. We are creating it inside a special method in Ruby called #initialize which allows us to create certain attributes inside our instance. Every game of Tic Tac Toe needs a board. the board is used throughout this object, so it is best to create it here. Notice though that once we create it here, we don’t need to use it as an argument throughout the rest of the object. Let’s compare the #display_board methods from procedural and object oriented approaches:

Procedural:

Object Oriented:

Notice in procedural that board needs passed in as an argument. You create the argument and then pass it in. In the object oriented approach, we create it in the #initialize method, and now it just needs called. Notice where it is called throughout. We do still have arguments in the other methods, but where board would have needed called, I used the instance variable.

There are two other methods that I should take a minute to look at as they were interesting. Again, the comparison helps here:

Procedural

Object Oriented:

These were tricky and it was because I forgot that in the procedural approach that when i used a helper method I have to pass in its arguments also. In the object oriented approach, the @board instance variable is again already there. The object is handling that data, so you just need to call the method and let Ruby handle the rest!

Otherwise, this lab was pretty straightforward. Wherever the local variable board was in the procedural approach, I replaced it with the @board instance variable, removed it from the arguments and then it worked. Honestly, I was expecting a few days of hell, so I’ll take it.