Learning Outcome — Thur 5th March 2020.

Area of Focus.

As I continued to build upon the human player feature of the TIC TAC TOE CLI game with Ruby(See Part 1 of this journal series). I was tasked with the need to modularise my code. Ruby modules allow you to create groups of methods that you can then include or mix into any number of classes. Modules only hold behaviour, unlike classes, which hold both behaviour and state. 

I had to refactor the existing code to include some level of abstraction. Abstraction permits this modularisation because it decomposes the whole into components that can be modelled separately, and then built in such a way that they interact, i.e. by breaking the game feature down, I can consider creating separate classes that represent a method which runs the game in a separate module. A separate class that represents a method that controls the game board state.

What I learned.

I looked up Object-Oriented programming in Ruby. I learned that If you want to really understand Ruby you’ve to understand Object-Oriented Programming. You could write any Ruby program without OOP, but using OOP makes things easier if you’re writing a non-trivial program. Why? Because OOP is all about how you design & organise your code, you create classes that represent concepts in your program, and each class is responsible for doing something.

Surprises

Nothing came as a surprise to me.

Frustrations

There are presently no frustrations for me, rather every instruction from my mentor is an opportunity for me to learn better ways of improving my code so as to enforce quality.

Reference: 

Getting Modular

Understand Ruby

Thumbnail Image

Previous
Previous

Apprenticeship journey Day 11

Next
Next

Learning Outcomes - 5th March