How Classes and Methods Work in Ruby
I’m starting my fourth week at The Iron Yard and am going to use this space to rephrase some of the concepts I’ve learned in a unique and (hopefully) helpful manner. In this first blog I am going to explain how I choose to look at how classes and methods work within Ruby.
First I would like to quickly discuss the way that The Iron Yard works for those of you who are unfamiliar with the company. The Iron Yard offers programming classes at 15 different campuses at different times each year. I am currently a member of Cohort 7 at the St Petersburg/Tampa campus, and am spending 12 weeks learning Ruby on Rails. The program is immersive and therefore it is taking us from little to no knowledge of how programming and Ruby work to being able to enter the job market as a junior developer.
Now because one of the ways that I learn best is to teach or reframe some of the broader concepts within an area of study I’m going to explain how I have come to view how Classes and Methods work in Ruby:
I view code as a sort of factory filled with incredibly literal and slightly stupid gremlins. These poor little guys can only follow really basic instructions and have such short attention spans that every work station has a series of instructional books on the wall. To me, these books are our classes. Then each chapter of the books, and all of the instructions therein, are our methods. Let me explain.
Let’s say we are writing a program that is used to manipulate a personnel database. You want to be able to know what a person is, create a new person, view all people in the database, view a single person in the database, delete them, search for them, and edit them. All of these are different tasks that will be run through your ‘factory’. For the sake of this example, we’ll say that there is only one little gremlin working in your factory, and he is tasked with doing everything needed for that day. If it makes you feel better, you could imagine that all gremlins working in the factory are able to complete every task and that they’re just waiting around for a job to do, but I am going to stick with the first scenario.
For this scenario, you have will have most likely made two classes which might be named something like People and Database. The People class is fairly simple and only includes some methods that define all of the characteristics of a person. The Database class holds a method for every task associated with the manipulation of the database (edit, delete, add, etc). So now our gremlin (let’s call him Hank) has two books at his station. One is a thin one called people, and the other is a slightly larger book called Database.
Hank gets a job handed to him (this is our code that runs the program and is outside of our classes) telling him that someone needs to see a list of all personnel in the database. Because Hank is a slow little gremlin, the job has a section listed below that tells him exactly which book and chapter he needs to reference to get the job done. In this case, he reads his job sheet and it tells him to grab his Database book (class) off of the shelf. He references the job sheet again and flips to the chapter titled listing all personnel (method). Hank is now looking at a step by step instruction for how to present a list of all personnel in the database that Hank’s little brain can handle. He then follows those steps and in a short amount of time a full list of all personnel is rolling out of his station and presented to the end user to view.
This is handy, because no matter how many different ways or reasons Hank has to print off a list of all employees, he only needs to have his one book with its very helpful chapter. The same concept applies for any other task that he might have to do at his station. This really cuts down on the length of the individual job sheets (again, our actual code) that come to his station.
Now I understand that as you progress you begin to see less and less of what actually is actually happening inside all of your classes and methods, especially when you start working through separate frameworks that are doing some of this work for you. But there will always be a factory, and Hank and his gremlin buddies will still be slaving away in the background of your code. That’s why I felt it was important to cover Classes and Methods in my first mini lesson. I know it helps me to write it down, and I hope that it helps you. Thank you for reading!