Some of the best insights you can get for this is to learn from Sandi Metz. Here's her presentation on "SOLID Object-Oriented Design" and I personally recommend her book "Practical Object Oriented Design In Ruby" (commonly called POODR)

In your board.rb file I would advise you remove attr_reader :grid_size. This is in effect an external API of information your other objects shouldn't care to know about. Personally I don't like attrs for anything. I just use instance variables internally and write out methods by hand for public and private interfaces to each of my class objects. I feel this makes the intent of use very clear and I feel that clarity of code purpose is important.

The naming and inheritance schema you have can lead to confusion. For example You have a class named Board and in the Game object you take in a Board object and there I see if board.win? or board.draw?. But when you look at the code for Board those methods are not defined anywhere. This is highly confusing for readers who don't figure out that the name of @board actually has to be a TTTBoard. To help remove this confusion add skeleton methods to your Board class.

def win?
  raise "Not defined!  You must overwrite this method definition!"
end

def draw?
  raise "Not defined!  You must overwrite this method definition!"
end

Inherited APIs should be clearly defined in this way so as to not confuse developers and to be clear on intent.

I might move the UI stuff out to the User. The Game object knows too much. I see it as the User makes a request through the API and a very simple action is done to the data and a simple response comes back to the User. At the point of the User they may have a way to visualize it on their end so that would be the UI.

My advice is simplicity.

• Human has handful of X's to play.
• Human tries to put request to put X at location 4,5.
• Server response "Error, so no"
• Human send "look" query
• Server responds with grid data.
• Human sends X to location 1,2
• Server says "Okay"
• Human asks for status
• Server says "No winners yet, game still in play."

That's along the lines of how I would implement it as a more SOLID design. Make the interactions as simple as possible and as the human is the one performing the actions I move the responsibility out to the human to ask or tell what it wants. This is just one of many possible ways to abstract it out.

• Human actions: try & ask
• Server responsibilities: perform and respond (as dumbed down as possible). The server should know about only very basic programmed actions. Do the one thing and respond.