Understanding OO

Ever since I went through the pre-CLI section of Object Orientation, I have been nervous to return to the subject in full. I have had several "A-ha!" moments conceptually throughout the beginning of my journey to learn programming (albeit very basic ones), but I failed to internalize how changing some variables to variables with @ signs would do anything to help, for example, my procedural ruby tic tac toe - of which I was proud and viewed to be just fine. But as I keep hearing throughout lectures, metaphors help us understand why a functionality within a language might be needed or useful. And in this case, I have needed several different metaphors, including a metaphor I've created in my mind, to allow the usefulness of OO to sink in.

We want our methods to accomplish a specific task, and we want our methods to work together to accomplish a big task, but trying to give one method too much to do can get ugly. So if there is a way to classify the "big task" and then allow the "specific tasks" to live and work together within the Big Task, why wouldn't we want to do that? Things began to make more sense when I understood attr_accessors, and I finally started to see the bigger picture when we were introduced to @@class_variables and class methods. The idea that there is a hierarchy of variables and methods in terms of their functionality within a class made it clear why having complex functions encapsulated in a class can be so useful. 

The takeaway from my change of heart for Object Orientation is to recognize that learning a language might not be in the same order as the design of the language, but it's necessary to gain the knowledge one step at a time. I have to stay positive, learn the concepts in each section to the fullest, but remain open to the fact that my entire perception of that concept might change when a new element is added to it.