Jan 19
Classes and Instances in Object-Oriented Ruby : A Newbie’s Guide
Hello again, Reader! Been a while, right? We’re currently at the start of our second week of Phase 3 Ruby! That’s right, we’ve managed to get through Phases 1 (Vanilla JavaScript) and 2 (React) in one pass. No second-swings at the Code Challenge! Send me all the good vibes and let’s collectively will this hot-streak for this Phase into existence, because I’m definitely feeling a lot less confident this time around! 😅 *AHEM*
Anyway, today, I offer you a little conceptual primer on Classes and Instances in Object-Oriented Ruby!
What is Object Oriented Programming?
Object-Oriented Programming (OOP) is a style of programming based on the concept of “objects,” which are essentially containers for data. The goal of OOP is to create programs using objects that share functionality; making design more intuitive, development faster, and the code itself easier to understand.
You don’t really get it? Don’t worry, you don’t have to fully understand the base concept to be able to grasp it. Most of us learners seem to end up pushing (or trudging) through and looking for that “aha moment,” anyway.
Well, that was <sarcasm>helpful</sarcasm>. What are Classes and Instances, then?
In Ruby, OOP comes in the form of writing your programs into Classes, which house Instances, and both of their respective methods. In broader strokes, your Class houses and standardizes your collection of data, and the Instance is the unique chunk of that data. If we were to think about this conceptually in JavaScript, a Class contains our collection of data, and each Instance would be a unique entry or Instance in that collection. Kind of like in an Array of Objects — The Array contains a bunch of objects that house data, and each of those objects houses unique data.
More specifically, you could say that your Class is like a Form, and your Instance would be the Form’s Submission. Information flows from the Class and is distributed through to its Instances (What data does our form want? Are there default values?), whereas data in the Instance isn’t accessible from other Instances.
Methods and Variables: Class vs Instance
Let’s quickly go over some of the easier-to-spot syntactical differences! Please keep in mind, I’m literally three or four days into Ruby and another three or four into ActiveRecord, so there’s probably room for improvement here.
A Class Method directly affects or accesses information from the Class or Template itself, rather than the instance. Your method call targets the Class. This one is used to create an Instance in our Class.
An Instanced Method… You guessed it! Directly affects/accesses information from the Instance it is being called on!
In this case, the .each is an Instanced method because rather than targeting the Class “blueprint” or “form” itself, you’re targeting its Instance data with .all. Again, in case it wasn’t clear, .all is the Class method that returns all of the Instances of Class, and .each is iterating through each of those Instances.
It may be a little less confusing to just disregard the attempt at the big-brain play there, and just think of Instanced Methods as the the code block (console logs in this case) inside of the .each/.forEach(), for the sake of connecting the dots, for now.
Variables — Class variables are written using two @s, whilst an Instance Variable is written with a single @.
In this case, rather than the blueprint itself, the Class Variable is the container that houses the values of our Instances.
Still uncertain? Check on-the-fly!
Pro-tip: If you’re working with code that someone else has built out to some extent and you’re unsure, you can always use the .class method in IRB/pry to quickly identify the data type you’re working with. If the object you’re trying to identify is a Class, it will tell you so. You can also use .methods in IRB/pry to pull a list of available pre-built methods for that object. Also worth noting — in standardized documentation, Class methods are indicated with a dot (.method), whereas Instance methods are notated with a pound/hash symbol (#method).
Bonus: Self
Self is a pre-set variable used inside of a method that dynamically points at the object at which its called upon. If your method targets a Class, self becomes a reference point to that class; if it targets an instance, it’ll instead represent that instance! Most of the time, when looking at code others have written, we’ll see Class Methods written with def self.method instead of def method.
One last logical leap…
If at this point, Classes and Instances are still unclear, the last conceptual link I can offer up is perhaps the React Component and Prop drilling. When we create a catalogue in React, we typically map out each Card using a collection of data held in State. In this case, we can think of <Card /> as the Class and each uniquely generated Card as the Instance.
Conclusion
PHEW! That was a LOT more in-depth (and hours) than I had intended. Hopefully, all of this helps provide at least *some* clarity. The topic can be quite confusing; I even got myself stuck a couple of times writing this out trying to define Class clearly and concisely. Especially at this stage of my Ruby/OOP career. 😬 Questions? Feedback? Have I made an error? Leave it in the comments! As always, thanks for reading! Stay safe out there!!
